[MEDIACTRL] Fw: New MRB document (-04)

"Spencer Dawkins" <spencer@wonderhamster.org> Wed, 31 March 2010 13:26 UTC

Return-Path: <spencer@wonderhamster.org>
X-Original-To: mediactrl@core3.amsl.com
Delivered-To: mediactrl@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8BBA3A696A for <mediactrl@core3.amsl.com>; Wed, 31 Mar 2010 06:26:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.132
X-Spam-Level: *
X-Spam-Status: No, score=1.132 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLYBLdqY-qrn for <mediactrl@core3.amsl.com>; Wed, 31 Mar 2010 06:26:29 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 2C19F3A6936 for <mediactrl@ietf.org>; Wed, 31 Mar 2010 06:26:29 -0700 (PDT)
Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0LfCvQ-1NCwt40XsW-00obyt; Wed, 31 Mar 2010 09:26:47 -0400
Message-ID: <4B30AD0EDF5C4941BADD24236F19FF35@china.huawei.com>
From: Spencer Dawkins <spencer@wonderhamster.org>
To: mediactrl@ietf.org
Date: Wed, 31 Mar 2010 08:26:29 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0860_01CAD0AB.DCBD02C0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5843
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-Provags-ID: V01U2FsdGVkX1/L1DhvincyJYMbFYRsudThiYl0z2GwlvSYKwT sOfHbQ88SOIKhwglqOXL3iMq9btFun4FG15hDpJuqzccn629GN PgN8+IGBxufs+SYj5m1K59qC6+gOUfqQree6jDCu88=
Subject: [MEDIACTRL] Fw: New MRB document (-04)
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Media Control WG Discussion List <mediactrl.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 31 Mar 2010 13:26:30 -0000

Hi, Chris,

This is NOT my understanding of the requirement for SIP option tags (see MARTINI for a counter-example) - the whole point of http://tools.ietf.org/html/rfc5727/, as I understood it, was to allow multiple groups to extend SIP, as long as they used a Standards Action for option tags, and as long as they weren't touching RFC 3261-3265, which is still the domain of SIPCORE.

If the point of this option tag is to say "yeah, we know a lot of SIP implementations don't support MIME multipart/mixed, but we're going to use it", I do think that a note to DISPATCH might be useful, and I'm thinking that the option name should not be tied to the IAMM usage (because it's applicable to other usages), but I think MEDIACTRL can do this. 

Eric, Robert - am I getting this right?

Thanks,

Spencer

----- Original Message ----- 
From: Chris Boulton 
To: mediactrl@ietf.org 
Sent: Wednesday, March 31, 2010 3:14 AM
Subject: Re: [MEDIACTRL] New MRB document (-04)




2) Required/Support header in SIP

Ben also pointed out that a proper piece of information, an option tag, may be needed in the Required/Supported headers for the Consumer-over-SIP case to address the use of multipart/mixed payloads in IAMM. A proper name for the option tag, considering the use case, might be just 'iamm'. Is it acceptable to specify such information in this document (and if so, is there any guideline that should be followed), or is it something that falls instead under the responsibility of other WGs, e.g., SIPCORE?

  [Chris] We had similar issues earlier in the MediaCtrl process that got a bit messy when we started adding stuff to MediaCtrl documents and have taken a wide berth since.  I think we will upset a few people by having it defined in the MRB doc - do the chairs agree in the new world of SIPCORE and DISPATCH?  I suspect to complete we do need an option tag - and I suspect it needs to be submitted to SIPCORE?  Eric/Spencer - thoughts?

Chris.


-- 
Chris Boulton
CTO & Co-founder
NS-Technologies
m: +44.7876.476681



--------------------------------------------------------------------------------


_______________________________________________
MEDIACTRL mailing list
MEDIACTRL@ietf.org
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl