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

If we're keeping score, here's a RFC 2327 <-> 4566
compatibility
issue...

RFC 4566 opted to add the following sentence to the
definition of the
"a=fmtp" SDP attribute,

	At most one instance of this attribute is allowed for each
format.

There are countless I-Ds and RFCs which leverage multiple
instances of
the "a=fmtp" SDP attribute per media format. 

Joe

-----Original Message-----
From: Colin Perkins [mailto:cspcsperkins.org] 
Sent: Tuesday, June 05, 2007 8:50 AM
To: Christian Groves
Cc: Dan Wing (dwing); sip-implementorscs.columbia.edu; mmusicietf.org;
Albrecht.Schwarzalcatel-lucent.de
Subject: Re: [MMUSIC] RE: Problems with RFC 2327 vs RFC
4566,and between
4567 and 4568

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

-- 
Colin Perkins
http://csperkins.org/

_______________________________________________
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

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

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