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-bounces cs.columbia.edu
>> [mailto:sip-implementors-bounces cs.columbia.edu] On Behalf
>> Of Dan Wing
>> Sent: 5. kesδkuuta 2007 5:23
>> To: 'Christian Groves'
>> Cc: sip-implementors cs.columbia.edu; mmusic ietf.org;
>> Albrecht.Schwarz alcatel-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.Groves nteczone.com]
>>> Sent: Monday, June 04, 2007 6:40 PM
>>> To: Dan Wing
>>> Cc: 'Randell Jesup'; sip-implementors cs.columbia.edu;
>>> mmusic ietf.org; Albrecht.Schwarz alcatel-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
>>>> mmusic ietf.org
>>>> https:/
/www1.ietf.org/mailman/listinfo/mmusic
>>>>
>>>>
>>>>
>> _______________________________________________
>> Sip-implementors mailing list
>> Sip-implementors cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinf
o/sip-implementors
>>
>
> _______________________________________________
> mmusic mailing list
> mmusic ietf.org
> https:/
/www1.ietf.org/mailman/listinfo/mmusic
--
Colin Perkins
http://csperkins.org/
_______________________________________________
Sip-implementors mailing list
Sip-implementors cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinf
o/sip-implementors
|