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
> mmusic ietf.org
> https:/
/www1.ietf.org/mailman/listinfo/mmusic
--
Colin Perkins
http://csperkins.org/
_______________________________________________
Sip-implementors mailing list
Sip-implementorscs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinf
o/sip-implementors
|
