Re: [codec] AD Evaluation of draft-ietf-codec-oggopus-09

[Ron <[e-mail]>]

On Fri, Dec 11, 2015 at 02:16:39PM -0800, Timothy B. Terriberry wrote:
> Ben Campbell wrote:
> >Here is my AD evaluation of draft-ietf-codec-oggopus-09. Codec
> >encapsulation is not my strong suit, so I suspect many of my comments
> >can be answered with "this is the way we normally do this thing". But
> >I'd still like to discuss these before going to IETF last call.
> 
> Thank you for the very thorough review. Comments in-line below (as an
> individual).

Indeed.  I think Tim has already covered most of my thoughts here, so
just a couple of extra things:

> >- 4.2, 2nd paragraph:
> >-- "samples which SHOULD be skipped": Why not MUST?  (also, s/which/that)
> 
> Some specific applications might have a reason for looking at that data (for
> example, when you have multiple files that you know were produced by
> chopping up a single existing file without re-encoding). In practice we
> haven't needed anything stronger to convince people to implement this
> correctly (especially when we point them to
> <https://people.xiph.org/~greg/opus_testvectors/correctness_trimming_nobeeps.opus>).

We might still want to clarify "These samples are not valid audio." at
the end of that second paragraph - since as the last paragraph points
out, some of them may actually be valid but just cropped for
synchronisation or other aesthetic reasons.

Maybe just moving that sentence up to the end of the first paragraph
instead would make a bit more sense?  Since it's the samples which
are described there which are not valid audio, while the pre-skip
field itself may overlap both those and some additional valid audio.

 
> >- 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.

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?


> >- 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.


  Cheers,
  Ron