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

Tim Melanchuk <tim.melanchuk@gmail.com> Sun, 12 May 2013 22:13 UTC

Return-Path: <tim.melanchuk@gmail.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 7829521F8DFC for <mediactrl@ietfa.amsl.com>; Sun, 12 May 2013 15:13:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.199
X-Spam-Level:
X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[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]
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 wDJwR+05OMeU for <mediactrl@ietfa.amsl.com>; Sun, 12 May 2013 15:13:09 -0700 (PDT)
Received: from mail-pd0-f176.google.com (mail-pd0-f176.google.com [209.85.192.176]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9B821F8D92 for <mediactrl@ietf.org>; Sun, 12 May 2013 15:13:09 -0700 (PDT)
Received: by mail-pd0-f176.google.com with SMTP id x10so3943356pdj.35 for <mediactrl@ietf.org>; Sun, 12 May 2013 15:13:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=kfK10hjfgjDCQQnWkCR+iq6LwarRT11txe+A21SXA1E=; b=Qrxp6c/fwRGpV1qNuCsVh/DtyoHaUbubuoCjqry+nEslRbtZaVkWh0E1DZ+kfYGPoR mYihQ4YnBOyLNBCCsZWd9jTM1ai0EW7Yh5YxhoOIqZQJChyhMPCoyQYIndqF72neFt/C OYDkgb23c0Bejjao0QLfpVFkbtR6Sq8moFBGiS2+XV+TkPIcxSXXzFgluqiRAQk3chIP nD+DMWcaMTzreuuro7Belbhv+mB9V6HaHZvq4A4D7vYm6TdC1tT1WfQO1ViWsEytE0lB +E5rG3pnTC0KKsBDGJBf6LHIZtqmGNbVRcS5RQ2tAbromEF7f5E+dCKQoobb+RwCWCBq 8YpA==
X-Received: by 10.66.146.7 with SMTP id sy7mr6675104pab.16.1368396789061; Sun, 12 May 2013 15:13:09 -0700 (PDT)
Received: from [192.168.1.66] (d99-199-108-186.bchsia.telus.net. [99.199.108.186]) by mx.google.com with ESMTPSA id uq10sm11385566pbc.5.2013.05.12.15.13.06 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 12 May 2013 15:13:07 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Tim Melanchuk <tim.melanchuk@gmail.com>
In-Reply-To: <CA7A9B90-CE7F-48F4-A234-C5FABE6D6183@standardstrack.com>
Date: Sun, 12 May 2013 15:13:05 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <F57DE85B-55A2-417C-8DAB-FA8699C032DE@gmail.com>
References: <201305091815.r49IFG0i4424540@shell01.TheWorld.com> <CA7A9B90-CE7F-48F4-A234-C5FABE6D6183@standardstrack.com>
To: Eric Burger <eburger@standardstrack.com>
X-Mailer: Apple Mail (2.1085)
Cc: "mediactrl@ietf.org mailing list" <mediactrl@ietf.org>
Subject: Re: [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: Sun, 12 May 2013 22:13:14 -0000

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

On 2013-05-12, at 2:41 PM, Eric Burger wrote:

> [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 <worley@ariadne.com>; 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: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
>> _______________________________________________
>> MEDIACTRL mailing list
>> MEDIACTRL@ietf.org
>> https://www.ietf.org/mailman/listinfo/mediactrl
>> Supplemental Web Site:
>> http://www.standardstrack.com/ietf/mediactrl
> 
> _______________________________________________
> MEDIACTRL mailing list
> MEDIACTRL@ietf.org
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl