Problems with RFC 2327 vs RFC 4566, and between 4567 and 4568

"Dan Wing" <dwingcisco.com> writes:
>> fyi,
>> I did some analysis in scope of SDP usage at H.248
interfaces:
>> 
>> AVD-3020: Comparison of SDP variants between RFC
4566 and RFC 2327
>> 
>> http://ftp3.itu.int/av-arch/avc-site/2005-20
08/0703_She/AVD-3020.zip
>
>Very nice analysis.

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).

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?

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.... :-(   We could use a
"private" attribute as suggested,
at least for them, but then interconnections with other
networks may be an
issue, and that would be a violation (though very minor) of
RFC 4566.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone),
ex-Amiga OS team
rjesupwgate.com
"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
Sip-implementorscs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinf
o/sip-implementors