[MMUSIC] RE: Problems with RFC 2327 vs RFC 4566, and between 4567 and 4568

["Dan Wing" <[e-mail]>]

 

> -----Original Message-----
> From: Randell Jesup [mailto:[e-mail]] 
> Sent: Monday, June 04, 2007 12:22 PM
> To: Dan Wing
> Cc: [e-mail]; 
> [e-mail]; [e-mail]
> Subject: Problems with RFC 2327 vs RFC 4566, and between 4567 and 4568
> 
> "Dan Wing" <[e-mail]> 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
> [e-mail]
> "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)

_______________________________________________
mmusic mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mmusic