Hello Colin, I agree there are going to be compatibility issues between RFC2327 implementations, or RFC4566 implementations or SIP implementations etc. If humans are involved then there will be some error. Its not the scope of the Appendix to discuss this.
The Appendix documents the compatibility issues which resulted from the text of the RFC upgrade. There are compatibility issues between the text of the two RFCs. Even if I had a "meaningful" RFC2327 implementation (based on extensions and "interpretations") the result of adopting RFC4566 would be that I would need to look to see what the impacts are. The place I would start to look is by comparing the two RFCs for changes. Isn't it better to highlight what the differences are so that they are known? Several people have commented that Albrecht's analysis has been helpful for them because the summary of changes documented in RFC4566 wasn't detailed enough. That's partly why we've adopted it. Albrecht's analysis is usually thorough and methodical so I can't see that there was any desire to be misleading. If there's specific text in the Appendix that's erroneous or misleading please flag it so we can address it, or if you have some modified text even better :) . As co-author of RFC4566 I'm sure people will appreciate any extra guidance you can propose for the text. Regards, Christian Colin Perkins wrote: > 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 > > > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
