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

From: [email-masked] (Dale R. Worley)
Date: Thu, 9 May 2013 14:15:16 -0400 (EDT)

[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:[email-masked]:5060>
   From: <sip:[email-masked]: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

---

From: Eric Burger <[email-masked]>
Date: Sun, 12 May 2013 17:41:23 -0400

[not as chair]
I would say take it out.

Leaving it in makes it look like it IS part of the standard. It is not.

If we do resurrect draft-boulton-mmusic-sdp-control-package-attribute, there is no guarantee the ultimate result will look like the example in the call flows. Worse yet, if for some reason the example in the call flows is broken, people will be arguing to keep them broken because people coded to the call flows document and we need to be backwards compatible (!!!).

[as chair]
This is worse than the danger I was worried about when we chartered doing the call flows.  My main concern was that we would get an example wrong, contradicting the specification, and through physics, the call flows document would become the standard. This is worse because we are making up a specification, without writing it down or going through the Internet Standards Process.

What do others think?

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

> _______________________________________________
> MEDIACTRL mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl

---

From: Tim Melanchuk <[email-masked]>
Date: Sun, 12 May 2013 15:13:05 -0700

strongly agree with eric - call flow document should NOT introduce things not in standards
because it leads to implementation confusion.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 13 May 2013 00:05:41 +0000

I'd endorse taking it out.

While one does not need an RFC to define an attribute, I'd suggest that the only attributes used in the examples are those registered by RFC's.

Regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Eric Burger
> Sent: 12 May 2013 22:41
> To: [email-masked] mailing list
> Subject: Re: [MEDIACTRL] Question about draft-ietf-mediactrl-call-flows:
> Is "a=ctrl-package" OK?
> 
> [not as chair]
> I would say take it out.
> 
> If we do resurrect draft-boulton-mmusic-sdp-control-package-attribute,
> there is no guarantee the ultimate result will look like the example in
> the call flows. Worse yet, if for some reason the example in the call
> flows is broken, people will be arguing to keep them broken because people
> coded to the call flows document and we need to be backwards compatible
> (!!!).
> 
> [as chair]
> This is worse than the danger I was worried about when we chartered doing
> the call flows.  My main concern was that we would get an example wrong,
> contradicting the specification, and through physics, the call flows
> document would become the standard. This is worse because we are making up
> a specification, without writing it down or going through the Internet
> Standards Process.
> 
> What do others think?
>

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 13 May 2013 13:52:02 -0400 (EDT)

[as an individual]

> From: [email-masked] (Dale R. Worley)
> 

I've not been in Mediactrl for a long time, but on general principles,
I am against including in the quasi-official examples an attribute
unless it is standardized, or we are working on standardizing it, or
it is a de-facto standard in the industry.

Dale

---

From: Eric Burger <[email-masked]>
Date: Thu, 23 May 2013 10:34:35 -0400

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.