Re: [MMUSIC] Updating iana SDP parameter registries in 4566bis

["Ali C. Begen (abegen)" <[e-mail]>]

On Oct 9, 2013, at 2:00 PM, Flemming Andreasen <[e-mail]> wrote:

> 
> On 10/7/13 1:51 PM, Paul Kyzivat wrote:
>> 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?
> 
> I think we ask Ali to make sure it is covered as part of 4566bis (possibly with some mailing list discussion first if you believe that is needed). If there are specific text suggestions, then all the better.

So, in the bis document, we can try to make it clearer but are we supposed to do a whole registry update as well? And certainly, the discussion will be a lot easier with some text proposals...


> 
> Thanks
> 
> -- Flemming
> 
>> 
>>    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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> mmusic mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>> .
>>>> 
>>> 
>>> _______________________________________________
>>> mmusic mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>> 
>> 
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>> .
>> 
>