Christer, There were some media type values referenced in RFC 2327, but removed in RFC 4566. This was because they were under-specified, due to not being valid top-level media types, not because they were unused. If they're used, then someone should document their semantics (i.e. register them as top-level media types).
Colin On 5 Jun 2007, at 06:32, Christer Holmberg (JO/LMF) wrote: > Another difference between 2327 and 4566 is that some of the media > types were removed from 4566, based on claims they aren't used > anywhere. > > At least one of them is. > > But, since that didn't affect the ABNF I guess it shouldn't be a > problem from a parser perspective. > > Regards, > > Christer > >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf >> Of Dan Wing >> Sent: 5. kesäkuuta 2007 5:23 >> To: 'Christian Groves' >> Cc: [email protected]; [EMAIL PROTECTED]; >> [EMAIL PROTECTED] >> Subject: Re: [Sip-implementors] [MMUSIC] RE: Problems with >> RFC 2327 vs RFC4566, and between 4567 and 4568 >> >> I agree such issues should be documented. Add a caveat like: >> >> Beyond the addition of "-" in attribute names, there are >> additional grammar differences between RFC2327 and >> RFC4566; enumerating those changes is left as an exercise >> for the reader >> >> and everything would be covered. >> >> -d >> >> >>> -----Original Message----- >>> From: Christian Groves [mailto:[EMAIL PROTECTED] >>> Sent: Monday, June 04, 2007 6:40 PM >>> To: Dan Wing >>> Cc: 'Randell Jesup'; [email protected]; >>> [EMAIL PROTECTED]; [EMAIL PROTECTED] >>> Subject: Re: [MMUSIC] RE: Problems with RFC 2327 vs RFC 4566, and >>> between 4567 and 4568 >>> >>> Hello, >>> >>> The document Albrecht originally pointed to is now an Appendix to >>> ITU-T H.248.49. This was done to ensure that Albrecht's work was >>> captured. The latest draft can be found at: >>> http://ftp3.itu.int/av-arch/avc-site/2005-2008/0703_She/TD-62.zip >>> >>> I think Randell's point that the use of "-" in attribute >> names between >>> RFC2327 and RFC4566 should also be captured in the Appendix. >>> Better that >>> these sorts of issues are documented. Something along the lines of: >>> >>> >>> "I.2.2.1 RFC 4566, "a=" attribute >>> >>> The syntax of RFC2327 does not support the use of "-" in an >> attribute >>> name however the syntax of RFC4566 has been updated to support the >>> inclusion of "-". Therefore the use of attribute names >> containing "-" >>> is problematic for RFC2327 implementations however several >> examples of >>> attribute names containing "-" were registered prior to the >> definition >>> of RFC4566. RFC2327 Implementors may consider exceptions >> when parsing >>> an "a=" where these attribute names containing "-" are involved. " >>> >>> Another way to lessen the problem would be that the internet drafts >>> using "-" in the attribute name remove "-" from the draft >> before going >>> RFC and the IANA registration procedures be updated to >> ensure that "-" >>> isn't used in the future for names. From looking at the IANA >>> registrations the widespread use of "-" seems to be a relatively >>> recent phenomena. I guess those who have implemented the drafts >>> wouldn't be happy though :)..... >>> >>> Regards, Christian >>> >>> Dan Wing wrote: >>>> ... >>>> >>>>> Sure, but there's still an issue here, or at least >>> something needing >>>>> clarification: Is RFC 4568 trying to refer to a=key-mgmt >>> when it uses >>>>> a=keymgt? >>>>> >>>> >>>> I can only expect that was the intent, yes. This should be noted >>>> via http://www.rfc-editor.org/errata.html (which isn't >>> ideal, but it's >>>> all we have). Might want to ping the authors first to make >>> sure that >>>> was their intent. >>>> >>>> >>>>> It seems like RFC 4566 section 10 (Summary of changes >>> since RFC 2327) >>>>> should have mentioned this issue, and others where >>> complying with 4566 >>>>> would make you (at least in theory) not interoperable with >>> RFC 2327. >>>>> All 4566 says about it is: >>>>> >>>>> The ABNF grammar in Section 9 has been extensively revised and >>>>> updated, correcting a number of mistakes and >>> incorporating the RFC >>>>> 3266 IPv6 extensions. Known inconsistencies between the >>>>> grammar and >>>>> the specification text have been resolved. >>>>> >>>> >>>> Without going into a case-by-case analysis of those >> changes, I dunno >>>> if there would be much value in highlighting "-" in >> attribute names; >>>> highlighting it might cause some readers of the errata to >>> assume that >>>> was the only change, which could make RFC4566 >> 'compliance' worse (if >>>> that was thought by some implementor to be the only substantive >>>> change to the grammar). >>>> >>>> -d >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> [EMAIL PROTECTED] >>>> https://www1.ietf.org/mailman/listinfo/mmusic >>>> >>>> >>>> >> _______________________________________________ >> Sip-implementors mailing list >> [email protected] >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >> > > _______________________________________________ > mmusic mailing list > [EMAIL PROTECTED] > https://www1.ietf.org/mailman/listinfo/mmusic -- Colin Perkins http://csperkins.org/ _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
