"Dan Wing" <[EMAIL PROTECTED]> writes:
>Randell Jesup wrote:
>> One item that's mentioned obliquely but not commented upon is
>> the change in token, and the impact that has on attribute (a=) names.
>> We've run across a problem talking to a vendor's RFC 2327 implementation,
>> which rejects any invite with a=key-mgmt. Their point-of-view is that
>> dashes in an attribute name violate the BNF in RFC 2327. They suggest
>> using a=keymgmt (which no one else uses, and isn't registered).
>
>Such an implementation would also reject:
[ huge list of a= values with dashes removed ]
>This vendor needs to reconsider their desire for interoperability.
Agreed.
>> My commentary:
>> RFC 2327 is internally inconsistent, in that it allows X-*
>> attributes but the BNF given doesn't allow them (alpha-numerics
>> only for attribute names). In this case, the text would seem to
>> override the BNF, at least for X-. The text also says to ignore
>> unknown atributes, but that assumes you've been able to parse
>> the attribute name.
>>
>> RFC 4566 allows '-' (and a lot of other characters) in
>> attribute names.
>> There's no discussion of the compatibility impact of this.
>>
>> RFC 4567 defines a=key-mgmt, with no reference to RFC 2327. RFC 4568
>> suggests people use "a=keymgt" (referencing RFC 4567), which doesn't
>> actually exist in RFC 4567(!)
>>
>> Houston, we have a problem. :-)
>>
>> So: how do we resolve the disagreements between specs (4567
>> and 4568 in particular), and why is there no commentary in 4566
>> or especially 4567 about compatibility with attribute names? And
>> why was a name chosen that might break backwards compatibility? Was
>> this issue known before it became an RFC? And how will this be
>> handled for the next attribute named? Should we suggest people
>> stay away from non-alpha-numerics in attribute names?
>
>I think it's too late for such encouragement.
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?
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.
>> And what are our options dealing with a *strict* 2327 grammar
>> implementation? They don't expect to support 4566 until the
>> end of 2009, if it doesn't slip.... :-(
>
>Full compliance with RFC4566 isn't necessary to be more liberal
>in accepting "-" in an unknown attribute name.
Agreed.
--
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[EMAIL PROTECTED]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
- James Madison, 4th US president (1751-1836)
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
