[MMUSIC] Updating iana SDP parameter registries in 4566bis

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 07 October 2013 17:52 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59DAE21E816A for <mmusic@ietfa.amsl.com>; Mon, 7 Oct 2013 10:52:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.177
X-Spam-Level:
X-Spam-Status: No, score=-0.177 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
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 CNeT6oajIrs7 for <mmusic@ietfa.amsl.com>; Mon, 7 Oct 2013 10:52:00 -0700 (PDT)
Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 3402111E8102 for <mmusic@ietf.org>; Mon, 7 Oct 2013 10:51:56 -0700 (PDT)
Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta09.westchester.pa.mail.comcast.net with comcast id aC1B1m0040EZKEL59HrsLf; Mon, 07 Oct 2013 17:51:52 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id aHrs1m00E3ZTu2S3MHrsU5; Mon, 07 Oct 2013 17:51:52 +0000
Message-ID: <5252F4B7.4070303@alum.mit.edu>
Date: Mon, 07 Oct 2013 13:51:51 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: mmusic@ietf.org
References: <20130701185623.25213.31890.idtracker@ietfa.amsl.com> <523AEC68.5050005@nteczone.com> <5252109C.7020609@cisco.com>
In-Reply-To: <5252109C.7020609@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1381168312; bh=bzOPuCuWzFx0ujhTLazZSIFldQmjwUvtdZKWGommGnA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=gdP20f+kkNVMZHvHlzQHYLqx883gwm3Cb3Q80jZspph6wT0SHWCYlawnI7f6sNzoV xe9VoghmvGcBe2Pp0Hi1wcwJS6O14Tf8OqEyPUfrEI+DaaugCT+iAJtalxf/R5ZsMb AauC8fBTNNlIhuoQ0OkG/pYDINksVLGl48ni6DAvbX1n0jAkplgWdwXDfksoHSpjuJ nU4TFa2E0r7HgUgeOQF6FmZZk9Z9vQtFrsTC+1d17oK5117ZcBa8UQtCYlhJrlt4XO 2JTAJ9zGVc0S6Z3H8nJRlPK07maajYCmVclYPay7TphSOYFdJFCANlT7qDtQGnufkN zxkChklw2F+0g==
Subject: [MMUSIC] Updating iana SDP parameter registries in 4566bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Oct 2013 17:52:04 -0000

Changing the topic because I'm hijacking the thread.

On 10/6/13 9:38 PM, Flemming Andreasen wrote:
> Hi Christian
>
> We had a thread on this particular issue about a year ago. See
>
> http://www.ietf.org/mail-archive/web/mmusic/current/msg09599.html
>
> and the conclusion in
>
> http://www.ietf.org/mail-archive/web/mmusic/current/msg09621.html

Thanks for remembering!

In that mail I suggested that 4566bis take on updating the format of the 
IANA registries to reflect the dependency between addrtype and nettype.

There are also other ways that the iana registries of SDP parameters are 
deficient. (Notably the registration of att-field names at 
session/media/source level.)

How do we go about updating 4566bis to improve the iana registries?

	Thanks,
	Paul

> I hope this addresses your concern as it relates to -cs draft.
>
> Thanks
>
> -- Flemming
>
>
> On 9/19/13 8:22 AM, Christian Groves wrote:
>> FYI, I was looking at the IANA registry for SDP parameters (
>> http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml)
>> and noticed that there was a registration for addrtype E164 linked to
>> this CS draft.
>>
>> There's a problem that there's already an addrtype E164 in RFC3108.
>> This earlier usage of E164 should have been registered with IANA but
>> seems to have been missed. To complicate things the format of the
>> RFC3108 E164 addrtype is different to the one in the CS draft.
>>
>> I've already raised this with IANA but I thought it would be worth
>> mentioning in MMUSIC.
>>
>> Christian
>>
>>
>> On 2/07/2013 4:56 AM, The IESG wrote:
>>> The IESG has approved the following document:
>>> - 'Session Description Protocol (SDP) Extension For Setting Audio and
>>>     Video Media Streams Over Circuit-Switched Bearers In The Public
>>>     Switched Telephone Network (PSTN)'
>>>    (draft-ietf-mmusic-sdp-cs-21.txt) as Proposed Standard
>>>
>>> This document is the product of the Multiparty Multimedia Session
>>> Control
>>> Working Group.
>>>
>>> The IESG contact persons are Gonzalo Camarillo and Richard Barnes.
>>>
>>> A URL of this Internet Draft is:
>>> http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/
>>>
>>>
>>>
>>>
>>> *Technical Summary
>>> *
>>>
>>> The document describes use cases, requirements, and protocol extensions
>>> for using the Session Description Protocol (SDP) Offer/Answer model for
>>> establishing audio and video media streams over circuit-switched bearers
>>> in the Publich Switched Telephone Network (PSTN)
>>>
>>> *Working Group Summary
>>> *
>>>
>>> The WG had some discussion around the format to use for E.164 numbers
>>> and whether to align this with the existing definition in RFC 3108. The
>>> RFC 3108 definition was seen as deficient and the WG agreed it was
>>> better to align with relevant parts of the tel URI format defined in RFC
>>> 3966, not least since SDP address types are defined in the context of a
>>> particular network type, and hence RFC 3108 compatibility is not a
>>> concern (the implication is that the "E164" address type may differ
>>> between network types in SDP).
>>>
>>> *Document Quality
>>> *
>>>
>>> There are currently no known implementations of the draft, however the
>>> draft is a dependency for 3GPP, so future implementations are expected.
>>>
>>> The document has received good overall review in the WG, some of which
>>> resulted in changes to the detailed specification. The document has been
>>> reviewed in detail several times, including of the last few versions.
>>> The major contributors to these as well as earlier discussions are
>>> listed in the Acknowledgements section of the document.
>>>
>>>
>>> *Personnel
>>> *
>>>
>>> Document Shepherd: Flemming Andreasen
>>> Responsible AD: Gonzalo Camarillo
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>> .
>>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>