- Clarify that 125,829,120 is just 120 MB.
- Add a figure to Section 3 of an example logical stream.
- Add a reference for Q notation.
- Refer to the downmixing figures in the text.
- Clarify that user comments are UTF-8.
- Clarify that the -573 and 111 gain values are examples.
- Add specific advice to implementors on areas that have security
   implications.

Apparently the IETF does not like having the BSD copyright in the
 .xml source (despite the CODEC WG's IPR advisor saying this was
 okay), so we need a new version.

Hopefully this is even clearer.
Thanks again to Mark Harris for the suggestion.

This avoids the claim that all possible Opus implementations would
 run at rates that divide 48 kHz.
Thanks to Mark Harris for raising the issue.

This also removes the request for an additional grant from the IETF
 Trust on the final RFC.
I believe this is sufficient to exercise our ability to allow
 downstream modifications as proposed in RFC 5377 Section 4.4.
See the discussion at
 <https://www.ietf.org/mail-archive/web/codec/current/msg03169.html>
 for details.

Thanks to Ron Lee for the suggestion.

Thanks to Sabrina Tanamal for pointing out the ambiguity.

Thanks to Joel Halpern for the suggestion.

Thanks to Joel Halpern for pointing out the discrepancy.

Thanks to Ben Campbell for the report.

From AD review.

From AD review.

Removed 2119 language for general Ogg requirements.
Added IANA registry for channel mapping families.
Adjusted additional copyright grant to match RFC 6716.
Additional comments addressed (see the CODEC mailing list).

Mark Harris convinced me that the significant delay between "WG
 consensus" and "RFC" means we shouldn't rely on RFC updates to
 give people permission to start deploying new things.

Thanks to Mark Harris for the report.

Also remove most <preamble>/<postamble> usage for expository text,
 as most places center the result, which looks ugly (only local
 xml2rfc HTML output does not center: tools.ietf.org HTML output
 still does, as does the .txt version).

To avoid confusion with an RFC 6716 encoder/decoder.
No part of this document is intended to update RFC 6716.

I *think* all we need to do is document this and the RFC editors
will take care of it.

We mention this in the description of Channel Mapping Family 0.
Might as well link to RFC 7587.

Review comment from Mo Zanaty.

This improves readability in the xml2rfc html output, but
generates Markdown-style *bold* in the txt output, and
more importantly in the nroff-like html output of the
tools.ietf.org toolchain, which Mo Zanaty and some in
IRC objected to.

Based on Mo Zanaty's review comments.

Response to comments from Mo Zanaty. Using "muxer/demuxer"
really isn't less ambiguous than "encoder/decoder" but does
help distinguish between this draft and a 'codec encoder/decoder'
described by the Opus RFC.

This version resolves some issues with the packet size limits
 raised by Mark Harris.

1. Removed an inappropriate normative MAY.
2. Gave an explicit range of sample rates deemed to be "non-crazy".
3. Give explicit guidance on packet sizes that SHOULD and MAY be rejected.

This is just a should, so we want to leave the RFC 6716 reference
to the second occurance, but using the same language ties them
together and to the later occurances.

The Opus RFC doesn't really say what to do beyond rejecting
a particular packet, but having the reference reinforces that
we're trying to leverage the same constraints in the specific
context of ogg encapsulation, and this isn't a new rule.

Suggestion from mark4o.

This avoids confusion with the number of frames being defined
by more than the first byte with code 3 packets.

Patch from mark4o.