Re: RE: Problems with RFC 2327 vs RFC 4566, and between 4567 and 4568

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