List Info

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




Re: RE: Problems with RFC 2327 vs RFC 4566, and between 4567 and 4568
country flaguser name
China
2007-06-04 20:40:00
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
> 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 RFC4566, and between 4567 and 4568
country flaguser name
United Kingdom
2007-06-05 04:01:37
Christer,

There were some media type values referenced in RFC 2327,
but removed  
in RFC 4566. This was because they were under-specified, due
to not  
being valid top-level media types, not because they were
unused. If  
they're used, then someone should document their semantics
(i.e.  
register them as top-level media types).

Colin




On 5 Jun 2007, at 06:32, Christer Holmberg (JO/LMF) wrote:
> Another difference between 2327 and 4566 is that some
of the media  
> types were removed from 4566, based on claims they
aren't used  
> anywhere.
>
> At least one of them is.
>
> But, since that didn't affect the ABNF I guess it
shouldn't be a  
> problem from a parser perspective.
>
> Regards,
>
> Christer
>
>> -----Original Message-----
>> From: sip-implementors-bouncescs.columbia.edu
>> [mailto:sip-implementors-bouncescs.columbia.edu] On Behalf
>> Of Dan Wing
>> Sent: 5. kesδkuuta 2007 5:23
>> To: 'Christian Groves'
>> Cc: sip-implementorscs.columbia.edu; mmusicietf.org;
>> Albrecht.Schwarzalcatel-lucent.de
>> Subject: Re: [Sip-implementors] [MMUSIC] RE:
Problems with
>> RFC 2327 vs RFC4566, and between 4567 and 4568
>>
>> 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:Christian.Grovesnteczone.com]
>>> Sent: Monday, June 04, 2007 6:40 PM
>>> To: Dan Wing
>>> Cc: 'Randell Jesup'; 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
>>>
>>> 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
>>>> 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
>>
>
> _______________________________________________
> mmusic mailing list
> mmusicietf.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

Re: RE: Problems with RFC 2327 vs RFC 4566, and between 4567 and 4568
country flaguser name
United Kingdom
2007-06-05 03:57:33
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".

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



_______________________________________________
Sip-implementors mailing list
Sip-implementorscs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinf
o/sip-implementors

[1-3]

about | contact  Other archives ( Real Estate discussion Medical topics )