Re: [MMUSIC] Hitchhiker's guide to SDP

[Andrew Allen <[e-mail]>]

+1

Maybe also having a reference to the IANA registry where to look for other proprietary extension attributes that have been registered with IANA would also be useful.



----- Original Message -----
From: Miguel A. Garcia [mailto:[e-mail]]
Sent: Wednesday, March 14, 2012 03:04 AM
To: Bert Greevenbosch <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [MMUSIC] Hitchhiker's guide to SDP

Hi:

Let me restate my opinion, as an individual contributor, not as a chair.

I think the document, for it to be useful, has to list the 
usages/extensions of SDP in *any* IETF document. This includes SIP, 
H.248/MEGACO, and RTSP as a least.

So, I believe the document should have at least 4 sections, one where you 
discuss core documents used by any protocol (probably RFC 4566bis, 
perhaps a few others as well).  And then the document should list 
extensions that are believed to be useful with only one particular 
protocol (that one being SIP, H.248, or RTSP).

That leaves outside the scope of the document those extensions that are 
created in non-RFCs, for example, in ITU-T, ETSI, OMA, or 3GPP documents 
(assuming there are those extensions, I don't know). So we restrict the 
document to IETF-created extensions used by IETF-created protocols.

Of course, we can start listing SDP extensions to SIP documents, bearing 
in mind that this is not the final goal. So, we can leave for a next 
iteration the addition of additional extensions used by other protocols.

How about that?

/Miguel


On 14/03/2012 2:24, Bert Greevenbosch wrote:
> Hi Miguel, all,
>
> Thanks for these references. I consulted the IANA site when writing the first draft, but in light of the current discussion on the scope of the document, I may have to do that again.
>
> The other reference (from opsawg) indeed contains some references to SIP.
>
> Do I correctly sense that it is the general feeling of the group that SIP should be in scope of the document? How about Megaco/H.248 and RTSP?
>
> Best regards,
> Bert
>
>
>
> -----Original Message-----
> From: Miguel A. Garcia [mailto:[e-mail]]
> Sent: 07 March 2012 18:56
> To: Bert Greevenbosch
> Cc: [e-mail]
> Subject: Re: [MMUSIC] Hitchhiker's guide to SDP
>
> Bert,
>
> Here is another document with the same purpose. You can use it for
> inspiration. This is a bit more complex document, because it has to deal
> with several different protocols, rather than only one.
>
> http://tools.ietf.org/html/draft-ietf-opsawg-management-stds
>
> The other document that you need to consult is the IANA SDP Parameters
> registry at:
>
> http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml
>
> This contains a list of all the SDP extensions, and they all should be
> listed in the hitchhiker's guide.
>
> /Miguel
>
> On 07/03/2012 3:54, Bert Greevenbosch wrote:
>> Hi all,
>>
>> On Monday, I have uploaded a v00 draft for "Hitchhiker's Guide to SDP". It is based on the "Hitchhiker's Guide to SIP" (RFC 5411). I have copied most initial text from there, and in addition included an initial list of RFCs / drafts that seem relevant.
>>
>> https://datatracker.ietf.org/doc/draft-greevenbosch-hitchhikersguide-sdp/
>>
>> If the group is happy with this approach, I will be happy to maintain an editor's role, and write more text. Obviously other people's input will be highly appreciated, and indeed is needed.
>>
>> I look forward to your comments.
>>
>> Best regards,
>> Bert
>>
>> P.S. Unfortunately, I forgot to include "mmusic" in the name of the draft. How to deal with this?
>>
>>
>>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of Christer Holmberg
>> Sent: 27 February 2012 04:53
>> To: Gonzalo Camarillo; Mary Barnes
>> Cc: [e-mail]
>> Subject: Re: [MMUSIC] Hitchhiker's guide to SDP
>>
>>
>> Hi,
>>
>> As a directorate member, I am willing to co-author such draft, should a decision to write one be taken.
>>
>> Regards,
>>
>> Christer
>>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of Gonzalo Camarillo
>> Sent: 23. helmikuuta 2012 19:31
>> To: Mary Barnes
>> Cc: [e-mail]
>> Subject: Re: [MMUSIC] Hitchhiker's guide to SDP
>>
>> I agree.
>>
>> Gonzalo
>>
>> On 23/02/2012 7:06 PM, Mary Barnes wrote:
>>> I would think that in order for the document to have integrity that at
>>> least one of the directorate members should at least be a co-author.
>>>    Otherwise, I see a lot more stuff falling through the cracks and
>>> needing to be resolved during WGLC and later, which usually isn't a
>>> good thing.  The SIP Hitchhiker's guide provides a good example in
>>> that the author was also a primary contributor to RFC3261, etc.
>>>
>>> Mary.
>>>
>>> On Thu, Feb 23, 2012 at 6:30 AM, Gonzalo Camarillo
>>> <[e-mail]
>>> <mailto:[e-mail]>>
>>> wrote:
>>>
>>>       Hi Mary,
>>>
>>>       yes, the members of the SDP directorate would need to review such a
>>>       guide. However, the fact that they agreed to be members of the
>>>       directorate does not mean they will necessarily have cycles to
>>>       significantly contribute to the creation of the guide. We need to make
>>>       sure we have enough energy around this effort in order to start it.
>>>
>>>       Cheers,
>>>
>>>       Gonzalo
>>>
>>>       On 15/02/2012 7:14 PM, Mary Barnes wrote:
>>>       >   I think this is a good idea.  I would think the experts that can
>>>       >   contribute (and should review) can be found in the new SDP
>>>       >   directorate:
>>>       >   http://www.ietf.org/iesg/directorate/sdp.html
>>>       >   BTW, it would be nice to have a link to this page on the MMUSIC WG
>>>       wiki:
>>>       >   http://trac.tools.ietf.org/wg/mmusic/trac/wiki
>>>       >
>>>       >   As far as whether to publish, I think it would be a good idea to
>>>       >   complete publication as IMHO that improves the integrity of the
>>>       >   information - i.e., more eyes review a published RFC than a draft.
>>>       >   It could later be updated to reflect more recent RFCs OR a "More of
>>>       >   Hitchhikers Guide" could be published.
>>>       >
>>>       >   Thanks,
>>>       >   Mary.
>>>       >
>>>       >   On Wed, Feb 15, 2012 at 12:29 AM, Bert Greevenbosch
>>>       >   <[e-mail]
>>>       <mailto:[e-mail]>>   wrote:
>>>       >>   Hi Miguel, Andrew, all,
>>>       >>
>>>       >>   Sounds like a good idea. I would be happy to volunteer to play a
>>>       central role in it (i.e. be the editor, create the initial draft,
>>>       ...), but I would need support from other experts too.
>>>       >>
>>>       >>   As for practicalities, I see that the "Hitchhiker's Guide to SIP"
>>>       has become an RFC (5411). That means that it has been frozen, and to
>>>       add new info new individual or WG drafts are needed.
>>>       >>
>>>       >>   Would this be the same approach for SDP? Currently, there are
>>>       already quite some new drafts that extend SDP. How will future
>>>       extensions be handled? Maybe it would be good to make it a permanent
>>>       WG draft, which is updated every now and then.
>>>       >>
>>>       >>   Best regards,
>>>       >>   Bert
>>>       >>
>>>       >>
>>>       >>   -----Original Message-----
>>>       >>   From: [e-mail]<mailto:[e-mail]>
>>>       [mailto:[e-mail]<mailto:[e-mail]>] On
>>>       Behalf Of Miguel A. Garcia
>>>       >>   Sent: 14 February 2012 15:42
>>>       >>   To: Andrew Allen
>>>       >>   Cc: [e-mail]<mailto:[e-mail]>
>>>       >>   Subject: Re: [MMUSIC] Do we need to update in time 4566bis?
>>>       >>
>>>       >>   Sounds good to me too. If someone wants to start such draft...
>>>       >>
>>>       >>   /Miguel
>>>       >>
>>>       >>   On 13/02/2012 23:15, Andrew Allen wrote:
>>>       >>>
>>>       >>>   What about considering a hitchhikers guide to SDP similar to
>>>       what was done for SIP?
>>>       >>>
>>>       >>>   One umbrella document that points the reader to all the SDP
>>>       capabilities available that they might want to take advantage of.
>>>       >>>
>>>       >>>   Just a suggestion.
>>>       >>>
>>>       >>>   Andrew
>>>       >>>
>>>       >>>   ----- Original Message -----
>>>       >>>   From: Miguel A. Garcia [mailto:[e-mail]
>>>       <mailto:[e-mail]>]
>>>       >>>   Sent: Saturday, January 28, 2012 06:23 AM
>>>       >>>   To: mmusic<[e-mail]<mailto:[e-mail]>>
>>>       >>>   Subject: [MMUSIC] Do we need to update in time 4566bis?
>>>       >>>
>>>       >>>   <as an individual>
>>>       >>>
>>>       >>>   Hi all,
>>>       >>>
>>>       >>>   You know we are revising RFC 4566. So far, the effort has been
>>>       in bug fixing.
>>>       >>>
>>>       >>>   The first SDP version was published as RFC 2327 in 1998 (i.e.,
>>>       14 years
>>>       >>>   ago), and was then revised as RFC 4566 in 2006.
>>>       >>>
>>>       >>>   Lots of things have happened since then. We have SDP offer answer,
>>>       >>>   Grouping, QoS, ATM, Bandwidth modifiers, TCP media, SDES, comeida,
>>>       >>>   labels, BFCP, FEC, ICE, CapNeg, and many other that are in the pipe.
>>>       >>>
>>>       >>>       From the point of view of a reader who takes 4566 (or its current
>>>       >>>   4566bis incarnation), I think it will be difficult for her or him to
>>>       >>>   understand a protocol that ignores those other extensions. For
>>>       example, I
>>>       >>>   recently post another e-mail where there is an apparent
>>>       contradiction
>>>       >>>   between 4566 and ICE (see
>>>       >>>   http://www.ietf.org/mail-archive/web/mmusic/current/msg09089.html ).
>>>       >>>
>>>       >>>   So, I was wondering if time has come to make not a bug correction in
>>>       >>>   4566bis, but also put that RFC in context with the other
>>>       extensions that
>>>       >>>   exist. This may include:
>>>       >>>
>>>       >>>   - Add minor extensions to the core document, similarly to what
>>>       we did
>>>       >>>   with IPv6 support (i.e., 4566 = 2327 + 3266). I don't know which
>>>       of these
>>>       >>>   extensions make sense to include, this would be an exercise to
>>>       do, but
>>>       >>>   let me give you one potential example: RFC 4574, the SDP "label"
>>>       >>>   attribute is a 6 pages RFC.
>>>       >>>
>>>       >>>   - Adding references to extensions, when it makes sense. For
>>>       example, ICE
>>>       >>>   should be referred somewhere (see my previous post regarding the "o"
>>>       >>>   line). I guess capneg could be also mentioned, perhaps others.
>>>       >>>
>>>       >>>   I know this is a bigger effort than anticipated, but the result
>>>       could
>>>       >>>   really help newcomers to this world.
>>>       >>>
>>>       >>>   Now, it is your turn to express your opinions. Please do it.
>>>       >>>
>>>       >>>   /Miguel
>>>       >>
>>>       >>   --
>>>       >>   Miguel A. Garcia
>>>       >>   [phone]<tel:%2B34-91-339-3608>
>>>       >>   Ericsson Spain
>>>       >>   _______________________________________________
>>>       >>   mmusic mailing list
>>>       >>   [e-mail]<mailto:[e-mail]>
>>>       >>   https://www.ietf.org/mailman/listinfo/mmusic
>>>       >>   _______________________________________________
>>>       >>   mmusic mailing list
>>>       >>   [e-mail]<mailto:[e-mail]>
>>>       >>   https://www.ietf.org/mailman/listinfo/mmusic
>>>       >   _______________________________________________
>>>       >   mmusic mailing list
>>>       >   [e-mail]<mailto:[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
>>
>

-- 
Miguel A. Garcia
[phone]
Ericsson Spain
_______________________________________________
mmusic mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mmusic

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.