On 11 Dec 2015, at 17:52, Ron wrote:
[I have no opinion on the "not valid audio samples" discussion.]
- 5.1.1.4: Why not MUST?
I think the idea was to allow assigning reserved values without
explicitly
updating this specification. Even though I expect we _would_ want to
update
this specification, given how long it's taken to get this draft
published,
I'm wary of adding more pressure to people not to deploy new mappings
(because this RFC says they MUST not), even when it looks like
they'll be
relatively stable and interoperable. At least not for the sole reason
that
they haven't gotten an RFC number yet.
Mark Harris and I had some discussion about this in the light of
whether
it should be MUST or SHOULD - and perhaps the most interesting thing
to
come out of that was wondering if we should in fact offer some advice
on
ways that people can safely use experimental new mappings before a new
channel mapping number has been allocated for them.
One option would be to suggest they use mapping 255 (which existing
decoders SHOULD/MUST ignore) along with a special comment field of
their own choosing which allows experimental decoders to know how to
treat that stream.
It's a common practice to mark certain code points or ranges as
"experimental" in IETF specs.
If the experiment fails, we lose an arbitrary unique name in the
comment
space, if it succeeds and gets consensus, we can add a mapping for it,
and decoders can continue to recognise both the magic comment and the
new mapping as appropriate. But we don't end up with incompatible
uses
for the same mapping number.
It may be a bit late in the game to be adding something like that to
this document - but we probably also don't strictly need to, since it
doesn't change anything that is already normatively specified, it
would
just offer advice about how to proceed if you are developing a new
mapping. Which means maybe it's also uncontroversial to add it too?
I think adding that at this point would require mention on the working
group list, to give people a chance to object. But that's not difficult.
- 13:
Is this needed? Are the IETF BCP 78 and 79 provisions incorrect for
this?
This text was specifically requested by the Debian project (and I
support it
personally). The same issue came up for RFC 6716 (for the same
reasons). See
the discussion at
<https://www.ietf.org/mail-archive/web/codec/current/msg02845.html>
and
<https://www.ietf.org/mail-archive/web/ietf/current/msg73116.html>.
Reviewing those conversations, I do notice that the language of that
section
was changed after last call for RFC 6716, but the corresponding
language in
our source repository was not updated (because it was added to the
document
boilerplate manually by the RFC Editor, and not included in a
separate
section).
Yes, I think this probably needs to be changed to something more like
what IETF legal suggested for RFC 6716, granting "the right to extract
sections 1 - 14 ...". This allows people to make liberal use of the
details in this document, but ensures they can't misrepresent any such
use as somehow being an RFC.
Using the modified boilerplate from RFC 6716 would make more sense, if
this document really needs it. But why does this document need it? It
doesn't include code (normative or otherwise) like 6716. Or more to the
point, why does this document need the extra grants more than any other
standards-track RFC?
Thanks!
Ben.
_______________________________________________
codec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/codec
