Hi, more comments inline. I deleted sections that do not seem to need
further discussion.
Thanks!
Ben.
On 28 Dec 2015, at 7:00, Timothy B. Terriberry wrote:
[...]
What does it mean, in context, to "reject" headers?
The same thing as rejecting a stream (i.e., don't try to play/decode
it). Changed to say that instead.
Which "that"?
To quote the attached diff:
-Implementations SHOULD reject ID headers which do not contain enough
data for
- these fields, even if they contain a valid Magic Signature.
+Implementations SHOULD reject streams with ID headers that do not
contain
+ enough data for these fields, even if they contain a valid Magic
Signature.
I don't find that in the attached diff.
Maybe this is a conventional way to say things in the codec
community,
but when I see "reject" I usually think that means you generate some
sort of error back to the source of the thing you reject. (As opposed
to
"ignore")
Well, the most likely behavior here is to tell the user that the file
is not a valid Ogg Opus file, so your sense of "generating some sort
of error back" is in fact correct. But that makes some
application-level assumptions I'm not sure I'm comfortable writing
normative text around. Any ideas for a better way to phrase this?
"treat as invalid"?
If this spec reserves those values, then people still need to update
it
to assign them. If you want to make it extensible, then perhaps it
needs
an IANA registry, which, depending on the assignment policy, may not
require an RFC at all (seems like "expert review" or "specification
required" might make sense).
An IANA registry actually does not seem like a terrible idea. Reading
RFC 5226 it doesn't seem too hard to set one up. I attempted to draft
some text.
it's what our "UPDATES" process is for. The idea that you might want
to
informally experiment with different approaches is more convincing.
But
if that is the case, it would be helpful to have a sentence to that
effect in the text.
Okay, I will add one.
That text looks good, except that I would avoid normative language:
s/ "IANA SHALL..."/"IANA is requested to..."
s/"All maintenance within and additions to the contents of this name
space MUST be according"/"Modifications to this registry follow..."
[...]
For the second, this is the same as the previous comment about
excessive allocations. I have no objection to changing this one,
either.
I realize now there were 3 SHOULDs in that paragraph. I mean the one
about avoiding excessive allocations. It sounds like
You may have forgotten to complete your thought here.
Apparently. I think I meant to delete "It sounds like". I think my
original thought was about whether the SHOULD in "Demuxers SHOULD avoid
attempting to allocate excessive amounts of memory when presented with a
very large packet." should be a MUST or otherwise be explained. But on
reflection, I think I am okay with that one.
Please consider saying something like "For more information on linear
prediction, see [XXX]." As it's currently stated, it looks like it
says
MAY do X, where the reference specified X, which would require a
normative reference.
That's a good suggestion. Done.
That language is a bit of a problem for a standards track RFC. If
people
You mean the current text, or the actual text that wound up in RFC
6716?
Either, really. But obviously the 6716 was accepted, so it would be
easier to accept due to precedent. The question I have is whether that
precedent applies here. And you will recall that there was some
tooth-gnashing over it for 6716 :-)
are really attached to it, we can pursue allowing it. But I expect
objections down the line. Keep in mind "NOTE WELL" says that any
contributions are subject to the rules of BCP 78 and 79.
Yes, I think this has more to do with letting people use such
contributions _outside_ the context of the IETF (i.e., it grants
additional rights to those already granted in BCP 78 and 79, which I
understand is allowed).
You are probably right about people objecting down the line (again),
but I am happy to address those objections when they come, as we did
for RFC 6716.
In any case, 6716 is a bit more code centric , so the discussion made
more sense there.
Well, from our point of view, the XML source for both RFCs is included
in the repository with libopus, which is distributed in Debian. If we
didn't have some kind of grant like this, they would have to somehow
strip those documents out. So it is not so much the code being in the
RFC as the draft being distributed with the code.
I'm curious--are there no other RFCs distributed in Debian?
In any case, I have attempted to draft an RFC Editor's note requesting
the same text that RFC 6716 used. Since that text grants a license
from the IETF Trust, instead of the authors, I assume that someone
from the Trust will have to approve of it, however (and reading
<http://www.ietf.org/proceedings/85/slides/slides-85-iesg-opsandtech-15.ppt>
it seems that the current opinion of the Trust is that this approach
is legally required).
I'll let that (as updated) go to IETF LC. But don't be surprised if
there's further discussion to be had here.
I have also gone through and finished removing the 2119 language for
general Ogg requirements.
The diff of all changes is attached. If these look good (or if it's
simply helps in reviewing them) I can publish a new version.
_______________________________________________
codec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/codec
