Re: [MEDIACTRL] Question about draft-ietf-mediactrl-call-flows: Is "a=ctrl-package" OK?

[Eric Burger <[e-mail]>]

This question has been open for two weeks, and the consensus of those responding to the list is unanimous to take out the as of now (or perhaps ever) non-standard SDP usage.

Thank you for your participation in the discussion.

On May 9, 2013, at 2:15 PM, Dale R. Worley <[e-mail]> wrote:

> [as chair]
> 
> We're working on finishing up draft-ietf-mediactrl-call-flows and want
> to get the WG's input on an issue:  Should the example call flows show
> uses of the "a=ctrl-package" attribute in the SDP?
> 
> A typical example is in the SDP in the body of this INVITE to
> establish a CFW connection:
> 
>   To: <sip:[e-mail]:5060>
>   From: <sip:[e-mail]:5060>;tag=4354ec63
>   Call-ID: MDk2YTk1MDU3YmVkZjgzYTQwYmJlNjE5NTA4ZDQ1OGY.
>   CSeq: 1 INVITE
>   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, REGISTER
>   Content-Type: application/sdp
>   Content-Length: 263
> 
>   v=0
>   o=lminiero 2890844526 2890842807 IN IP4 as.example.com
>   s=MediaCtrl
>   c=IN IP4 as.example.com
>   t=0 0
>   m=application 5757 TCP cfw
>   a=connection:new
>   a=setup:active
>   a=cfw-id:5feb6486792a
>   a=ctrl-package:msc-ivr/1.0
>   a=ctrl-package:msc-mixer/1.0
> 
> Historically, this attribute was defined in
> draft-boulton-mmusic-sdp-control-package-attribute, which was intended
> to proceed to standardization.
> 
> But the effort to standardize "a=ctrl-package" has been abandoned and
> the last version of the draft expired in March 2012.
> 
> But at least one vendor has implemented the attribute.
> 
> Should we keep the "a=ctrl-package" attributes in the SDP examples?
> 
> There are a lot of ways that you can look at this situation:
> 
> - Devices that do not understand "a=ctrl-package" can safely ignore
>  it, so examples containing it are upward-compatible with the
>  standards (and probably with the real world).
> 
> - The official examples should conform to the official standards.
> 
> - If we intend to resume the standardization effort (respinning the
>  draft), it is reasonable to presume its eventual success when
>  writing examples.
> 
> - If enough vendors implement it, it is a de-facto standard and should
>  be shown.
> 
> And then there's the problem that implementors don't properly
> distinguish between the specifications of the standard and the details
> of the examples.  As was once stated vigorously, "The problem is
> people will code implementations to the call flows document, NOT the
> actual RFCs that define the protocols. Our choices are to take it out
> altogether or surround the section with lots of all-capital letters
> saying this may not be in the final specifications and is highly
> likely not to be the way it works in the wild."
> 
> How should we handle this situation?
> 
> Dale
> _______________________________________________
> MEDIACTRL mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl