Christian, The text, as with much of the text in this document, gives the impression that there are meaningful "RFC 2327 implementations", and that the compatibility issues are due to RFC 4566 changing the specification. I think that's greatly misleading, and gives the impression that there are more issues than actually exist.
In reality, RFC 2327 is self-contradictory and unclear in a number of places, and useful implementations rely on a large number of extensions and interpretations of the standard. RFC 4566, while not perfect, greatly clarifies the text to fix those problems, and to reflect existing practice. It's my belief that there are no more compatibility issues between an "RFC 2327 implementation" and one based on RFC 4566, than between any two RFC 2327 implementations. Colin On 5 Jun 2007, at 12:13, Christian Groves wrote: > Thanks for the extra information. Would the following text capture > your clarification? > > Dan: I've also added some additional text to address your proposal. > > "I.2.2.1 RFC 4566, "a=" attribute > > The ABNF syntax of RFC2327 does not support the use of "-" in an > attribute name however despite stating that attributes names must > be in the US-ASCII subset of ISO-10646/UTF-8. The ABNF syntax of > RFC4566 was updated to support the inclusion of "-" to address this > inconsistency. Therefore the use of attribute names containing "-" > is problematic for RFC2327 implementations as several examples of > attribute names containing "-" were registered prior to the > definition of RFC4566. RFC2327 Implementors may consider exceptions > when parsing an "a=" where attribute names containing "-" are > involved. > > Beyond the addition of "-" in attribute names, the RFC4566 ABNF > "token" syntax defines additional characters (see item 22/I.2.4.2) > that would also pose similar problems." > > Regards, Christian > > Colin Perkins wrote: >> On 5 Jun 2007, at 02:40, Christian Groves wrote: >>> 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. " >> >> It's not that simple, since RFC 2327 is inconsistent. The ABNF >> allows only alphanumeric characters in attribute names, but the >> text only states that attribute names "must be in the US-ASCII >> subset of ISO-10646/UTF-8". >> > > _______________________________________________ > 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
