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

[[e-mail] (Dale R. Worley)]

[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