It's a comment on my side, so I leave it to your discretion On Fri, Aug 24, 2018 at 1:51 PM, Ben Campbell <[email protected]> wrote:
> > > > 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. > > > > >
_______________________________________________ codec mailing list [email protected] https://www.ietf.org/mailman/listinfo/codec
