> -----Original Message-----
> From: Randell Jesup [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 04, 2007 12:22 PM
> To: Dan Wing
> Cc: [EMAIL PROTECTED];
> [email protected]; [EMAIL PROTECTED]
> Subject: Problems with RFC 2327 vs RFC 4566, and between 4567 and 4568
>
> "Dan Wing" <[EMAIL PROTECTED]> 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-2008/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).
Such an implementation would also reject:
a=rtcp-xr (RFC3611, standards track)
a=phone-context (RFC2848, standards track)
a=Q763-nature (RFC2848, standards track)
a=Q763-plan (RFC2848, standards track)
a=source-filter (RFC4570, standards track)
a=rtcp-fb (RFC4585, standards track)
Working Group Internet Drafts:
a=accept-types (draft-ietf-mmusic-file-transfer-mech)
(draft-ietf-simple-message-sessions)
(draft-niemi-simple-chat)
a=accept-wrapped-types(draft-ietf-mmusic-file-transfer-mech)
(draft-niemi-simple-chat)
a=file-selector (draft-ietf-mmusic-file-transfer-mech)
a=file-disposition (draft-ietf-mmusic-file-transfer-mech)
a=file-date (draft-ietf-mmusic-file-transfer-mech)
a=file-icon (draft-ietf-mmusic-file-transfer-mech)
a=file-range (draft-ietf-mmusic-file-transfer-mech)
a=loopback-source (draft-ietf-mmusic-media-loopback)
a=loopback-mirror (draft-ietf-mmusic-media-loopback)
a=loopback-mode (draft-ietf-mmusic-media-loopback)
a=ice-pwd (draft-ietf-mmusic-ice)
a=ice-ufrag (draft-ietf-mmusic-ice)
a=-m (draft-ietf-mmusic-sdp-capability-negotiation)
a=dccp-service-code (draft-ietf-dccp-rtp)
Individual Internet Drafts:
a=qos-mech-send
(draft-polk-mmusic-qos-mechanism-identification)
a=qos-mech-recv
(draft-polk-mmusic-qos-mechanism-identification)
a=flute-tsi (draft-mehta-rmt-flute-sdp)
a=flute-ch (draft-mehta-rmt-flute-sdp)
a=FEC-declaration (draft-mehta-rmt-flute-sdp)
a=FEC-OTI-extension (draft-mehta-rmt-flute-sdp)
a=content-desc (draft-mehta-rmt-flute-sdp)
a=udp-setup (draft-saito-mmusic-sdp-ike)
a=switch-context-id (draft-einarsson-mmusic-rtsp-macuri)
a=ssrc-group (draft-lennox-mmusic-sdp-source-attributes)
a=floor-control (draft-even-xcon-pnc)
a=zrtp-zid (draft-zimmermann-avt-zrtp)
a=zrtp-sas (draft-zimmermann-avt-zrtp)
This vendor needs to reconsider their desire for interoperability.
> 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.
> 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.
> 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.
Untenable, as this isn't the only attribute name affected by a
strict parser.
-d
> --
> 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
