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

worley@ariadne.com (Dale R. Worley) Thu, 09 May 2013 18:16 UTC

Return-Path: <worley@shell01.TheWorld.com>
X-Original-To: mediactrl@ietfa.amsl.com
Delivered-To: mediactrl@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA82821F8477 for <mediactrl@ietfa.amsl.com>; Thu, 9 May 2013 11:16:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level:
X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9k0xeJZiode for <mediactrl@ietfa.amsl.com>; Thu, 9 May 2013 11:16:02 -0700 (PDT)
Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id BE9C821F8470 for <mediactrl@ietf.org>; Thu, 9 May 2013 11:16:02 -0700 (PDT)
Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r49IFHSV026243 for <mediactrl@ietf.org>; Thu, 9 May 2013 14:15:19 -0400
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r49IFHeE4444833 for <mediactrl@ietf.org>; Thu, 9 May 2013 14:15:17 -0400 (EDT)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r49IFG0i4424540; Thu, 9 May 2013 14:15:16 -0400 (EDT)
Date: Thu, 9 May 2013 14:15:16 -0400 (EDT)
Message-Id: <201305091815.r49IFG0i4424540@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: mediactrl@ietf.org
Subject: [MEDIACTRL] Question about draft-ietf-mediactrl-call-flows: Is "a=ctrl-package" OK?
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Media Control WG Discussion List <mediactrl.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mediactrl>
List-Post: <mailto:mediactrl@ietf.org>
List-Help: <mailto:mediactrl-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 May 2013 18:16:08 -0000

[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:MediaServer@ms.example.net:5060>
   From: <sip:ApplicationServer@as.example.com: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