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
