Subject: RE: Simple Capabilities

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 1 Feb 2001 14:05:43 -0500

I would think agreement on the use of multiple session descriptions as
alternatives would be one not-too-radical step.  If we could possibly
consider syntactic innovations, the use of ranges for numerical attributes
might be useful.

-----Original Message-----
From: Flemming Andreasen [mailto:[email-masked]]
Sent: Thursday, January 18, 2001 8:13 PM
To: Taylor, Tom-PT [NORSE:B901:EXCH]
Cc: Joerg Ott; [email-masked]; [email-masked]
Subject: Re: Simple Capabilities

Tom-PT Taylor wrote: 

I would like to suggest that anything we do should move toward making the
Megaco adaptations of SDP in the MGC-MG direction more useful in the reverse
direction.

Can you be a little more specific as to what those are ? 

Also, I would want to note that Megaco stepped outside the syntactic (and
semantic) bounds of RFC 2327 in its use of "SDP" in the MGC-MG direction - I
assume you are not proposing we should adopt that. 

-- Flemming 

That's a slightly milder requirement than what I'd really like: that if we
choose to add a certain feature to SDP and Megaco has already provided a
solution for that feature, we should use the Megaco solution. 

> -----Original Message----- 
> From: Joerg Ott [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Thursday, January 18, 2001 6:30 AM 
> To: [email-masked] 
> Cc: [email-masked] 
> Subject: Simple Capabilities 
> 
> 
> Folks, 
> 
> at the last IETF, a *very* simple capability negotiation as addition 
> to SDP was discussed: draft-andreasen-mmusic-sdp-simcap-00.txt. 
> Numerous comments came up and it was agreed to proceed as follows: 
> 
> 1.  We will have a period of two weeks for posting comments (and 
>     potential additions) to the list. 
> 
>     This is to expire by 31 January 2001. 
> 
> 2.  From his draft and the additional input, the author will compile 
>     a very brief requirements draft which is to be posted to the list 
>     and will be discussed. 
> 
>     This will take about one weeks (8 February 2001). 
> 
> 3.  After this, the author will modify/extend/fix/... the draft within 
>     three weeks time to make the final I-D deadline (2 March 2001). 
> 
> Please keep in mind that we do not want to accomplish 
> everything with this 
> document but rather provide a simple short-term solution to relatively 
> simple REAL WORLD problems ONLY.  Anything beyond this will 
> not be integrated 
> in the revised document. 
> 
> Cheers, 
> Joerg 
> 
> 
>

-- 
Flemming Andreasen 
Cisco Systems

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 01 Feb 2001 14:36:13 -0500

Tom-PT Taylor wrote:

>  I would think agreement on the use of multiple session descriptions
> as alternatives would be one not-too-radical step.
>
> FSA: I strongly disagree. What you propose is something above and
> beyond the SDP spec itself. I am aware that Megaco chose to use this
> approach in it's use of SDP just as Megaco chose to extend/modify the
> syntax with some new wildcard constructs. However other users of SDP,
> e.g. SIP, has not done that, at the last thing I want to do is to
> carry baggage from one particular protocol into SDP, especially when
> it is not needed. There is a perfectly well-defined extension
> mechanism within RFC 2327 that is capable of seamless backwards
> compatibility with all users of SDP that conform to RFC 2327. The
> mechanism is attributes and that is what we should use.
>
>
>
>  If we could possibly consider syntactic innovations, the use of
> ranges for numerical attributes might be useful.
>
> FSA: Fair enough. I'll add the ability to express numerical ranges in
> a capability as a requirement.
>
> -- Flemming
>
>
>     > I would like to suggest that anything we do should move
>     > toward making the Megaco adaptations of SDP in the MGC-MG
>     > direction more useful in the reverse direction.
>
>      Also, I would want to note that Megaco stepped outside the
>      syntactic (and semantic) bounds of RFC 2327 in its use of
>      "SDP" in the MGC-MG direction - I assume you are not
>      proposing we should adopt that.
>
>      -- Flemming
>
>
>     > That's a slightly milder requirement than what I'd really
>     > like: that if we choose to add a certain feature to SDP
>     > and Megaco has already provided a solution for that
>     > feature, we should use the Megaco solution.
>     >
>     > > From: Joerg Ott [mailto:[email-masked]]
>     > > to SDP was discussed:
>     > draft-andreasen-mmusic-sdp-simcap-00.txt.
--
Flemming Andreasen
Cisco Systems