> On Aug 10, 2018, at 2:33 PM, Eric Rescorla <[email protected]> wrote: > > > > S 5.2. > > The remaining channel mapping families (2...254) are reserved. A > > demuxer implementation encountering a 'channel mapping family' > > value that it does not recognize SHOULD NOT attempt to decode the > > packets and SHOULD NOT use any information except for the first 19 > > octets of the ID header packet (Fig. 2) and the comment header > > (Fig. 10). > > What is the rationale for this change? Also, why are you doing it in > this document? This seems like it's going to be extremely hard for > implementors to find in future. > > These paragraphs are updates to RFC 7845, which needed to be revised to > accommodate the proposed channel mapping families in this draft. > > Sorry, I don't understand. Why did they need to be revised to have this > change? > > > The authors of RFC 7845 and RFC 6716 suggested that the necessary updates to > RFC 7845 should be included in this draft. > > I understand, but my point is that people are likely to ignore this draft if > they don't care about ambisonics and thereby miss out on a relevant > information. In any case, I'll defer to the WG and AD. >
Closing the loop on this point: We have commonly put updates to RFCs in the documents that create the need for the updates, even if the update is generally applicable. We have the “Updates/Updated by” relationships to track this sort of thing. I am sympathetic to Ekr’s argument, in that I agree it would be more convenient for the reader to find the update in a smaller, dedicated draft. But at this point in the process, I highly doubt the wg has the energy to do that sort of restructuring. Therefore I am inclined to leave this the way it is. Thanks, Ben.
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ codec mailing list [email protected] https://www.ietf.org/mailman/listinfo/codec
