Subject: Re: [MEDIACTRL] Protocol Version!!!!

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 7 Jul 2009 13:57:40 -0500

Dear MediaCtrl,

Speaking as co-chair, we haven't had any list traffic responding to Chris's 
note on including a protocol version number in the control framework.

We need to have a sense of what the working group thinks, in order to 
advance the control framework specification.

Could people who DISAGREE with Chris's suggestion please say so onlist (or 
to the chairs), by July 14?

Speaking only for myself, I'm fine with Chris's suggestion to do as MSRP 
did, and assume that if we make non-backward compatible changes, we'd be 
talking about a new protocol. (Isn't this about the fourth generation of 
media control protocols? How much could we still be missing? How much could 
we be missing that would require breaking backward compatibility?)

Thanks,

Spencer

> As a result of feedback from our AD (Robert Sparks) we need to make a 
> couple of changes to the Media Channel Control framework before we can 
> proceed.  The following was called out:
>
> The protocol has no version field inside it, and there
>       doesn't appear to be a way to version it in the SDP that's
>       setting up its use. Am I missing something?
>
> My question to the group is - do we feel we need a protocol version 
> number?  Will it add any value?
>
> MSRP chose not to have a version and included the following text:
>
> MSRP was designed to be only minimally extensible.  New MSRP methods,
>   header fields, and status codes can be defined in standards-track
>   RFCs.  MSRP does not contain a version number or any negotiation
>   mechanism to require or discover new features.  If an extension is
>   specified in the future that requires negotiation, the specification
>   will need to describe how the extension is to be negotiated in the
>   encapsulating signaling protocol.  If a non-interoperable update or
>   extension occurs in the future, it will be treated as a new protocol,
>   and MUST describe how its use will be signaled.
>
>
> If the group thinks we need a version number then we should look at 
> proposals ELSE I will include similar text to that specified for MSRP in 
> our doc.
>
> Thoughts please.
>
> Chris.

---

From: Jean-Francois Bertrand <[email-masked]>
Date: Tue, 7 Jul 2009 12:12:53 -0700

I'm also fine with Chris's suggestion.
/JF
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Spencer Dawkins [[email-masked]]
Sent: Tuesday, July 07, 2009 2:57 PM
To: [email-masked]
Subject: Re: [MEDIACTRL] Protocol Version!!!!

Dear MediaCtrl,

Thanks,

Spencer

> proposals ELSE I will include similar text to that specified for MSRP in

_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 21 Jul 2009 15:01:57 -0500

Just to polish this open item off...

> Dear MediaCtrl,
>
> Speaking as co-chair, we haven't had any list traffic responding to 
> Chris's note on including a protocol version number in the control 
> framework.
>
> media control protocols? How much could we still be missing? How much 
> could we be missing that would require breaking backward compatibility?)
>
> Thanks,
>
> Spencer

I saw two posts on the mailing list that said "I agree", and no one opposed, 
so I've asked Chris to insert text, as he suggested. The current text looks 
like this:

11.  Extensibility

   The Media Control Channel Framework was designed to be only minimally
   extensible.  New methods, header fields, and status codes can be
   defined in standards-track RFCs.  The Media Control Channel Framework
   does not contain a version number or any negotiation mechanism to
   require or discover new features.  If an extension is specified in
   the future that requires negotiation, the specification will need to
   describe how the extension is to be negotiated in the encapsulating
   signaling protocol.  If a non-interoperable update or extension
   occurs in the future, it will be treated as a new protocol, and MUST
   describe how its use will be signaled.

   In order to allow extension header fields without breaking
   interoperability, if an Media Control Channel device receives a
   request or response containing a header field that it does not
   understand, it MUST ignore the header field and process the request
   or response as if the header field was not present.  If a Media
   Control Channel device receives a request with an unknown method, it
   MUST return a 500 response.

We are one MMUSIC review away from IETF Last Call, so if you don't agree, 
please say so REAL soon!

Thanks,

Spencer

---

From: Dan York <[email-masked]>
Date: Tue, 21 Jul 2009 16:32:36 -0700

Spencer,

My apologies for missing the requested deadline of July 14th.

I do *disagree* with Chris' suggestion.   To your point, this *is*  
probably the fourth generation of media control protocols.... why do  
we have to keep creating new ones?  Why should we close off  
extensibility?  To "How much could we still be missing?", wasn't that  
question probably asked by the authors of the previous three  
generations?  We don't have any clue what might appear in the future  
(or if you do, please clue me in so I can buy appropriate stock and  
capitalize on it!).  There very well might be some new media service  
that makes sense for a media server to handle... and for our media  
control protocol to handle - and in a way that might break backward  
compatibility.  There's that famous saying about someone saying we'd  
never need more than 640K RAM... ;-)

As an implementor, I don't want to be in the business of implementing  
new media control protocols.  New protocols require new specs,  
potentially require new tools... and require new education of the  
customers, engineers... and, well, everyone.

I'd much rather implement ONE protocol and then deal with extensions  
through a version check.  From a product development point-of-view,  
dealing with extensions is then implementing a new version of an  
existing protocol... which I can explain easily.

My 2 cents,
Dan

On Jul 21, 2009, at 1:01 PM, Spencer Dawkins wrote:

>> We need to have a sense of what the working group thinks, in order  
>> to advance the control framework specification.
>>
>> Could people who DISAGREE with Chris's suggestion please say so  
>> onlist (or to the chairs), by July 14?
>>
>> Speaking only for myself, I'm fine with Chris's suggestion to do as  
>> MSRP did, and assume that if we make non-backward compatible  
>> changes, we'd be talking about a new protocol. (Isn't this about  
>> the fourth generation of media control protocols? How much could we  
>> still be missing? How much could we be missing that would require  
>> breaking backward compatibility?)
>>
>> Thanks,
>>
>> Spencer
>
> I saw two posts on the mailing list that said "I agree", and no one  
> opposed, so I've asked Chris to insert text, as he suggested. The  
> current text looks like this:
>
> 11.  Extensibility
>
> We are one MMUSIC review away from IETF Last Call, so if you don't  
> agree, please say so REAL soon!
>
> Thanks,
>
> Spencer

-- 
Dan York, Director of Conversations
Voxeo Corporation   http://www.voxeo.com  [email-masked]
Phone: +1-407-455-5859    Skype: danyork

Join the Voxeo conversation:
Blogs: http://blogs.voxeo.com
Twitter: http://twitter.com/voxeo  http://twitter.com/danyork
Facebook: http://www.facebook.com/voxeo

---

From: Lorenzo Miniero <[email-masked]>
Date: Wed, 22 Jul 2009 13:27:12 +0200

Hi Dan,

I agree with you about the need for extensibility, but when talking about new functionality and the like that applies to packages rather than to the framework itself. The framework already provides what it is needed for, and the new services you foresee may be addressed by extensions to the existing packages or completely new packages, which would likely work without problems with the current version of the framework.

That said, I think the approach suggested by Chris is fine, but of course that's just my two cents as well.

L.

On Tue, 21 Jul 2009 16:32:36 -0700

-- 
Lorenzo Miniero <[email-masked]>

---

From: "McGlashan, Scott" <[email-masked]>
Date: Wed, 22 Jul 2009 14:51:28 +0000

I agree with Lorenzo about protocol extensibility rather functional extensibility which we address thoroughly through the package mechanism - that was the point of separating protocol from functional package. 

In terms of protocol extensibility, I don't see the point of adding a protocol version if there isn't a version negotiation mechanism. If it had been a requirement on the protocol from the beginning, then yes it needs to be addressed. 

So I'm also fine with the approach proposed by Chris at this stage. 

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lorenzo Miniero
Sent: Wednesday, July 22, 2009 13:27
To: Dan York
Cc: [email-masked]
Subject: Re: [MEDIACTRL] Protocol Version!!!!

Hi Dan,

L.

On Tue, 21 Jul 2009 16:32:36 -0700
Dan York <[email-masked]> wrote:

> >  The Media Control Channel Framework was designed to be only 
> > minimally  extensible.  New methods, header fields, and status codes 
> > can be  defined in standards-track RFCs.  The Media Control Channel 
> > Framework  does not contain a version number or any negotiation 
> > specified in  the future that requires negotiation, the 
> > specification will need to  describe how the extension is to be 
> > negotiated in the encapsulating  signaling protocol.  If a 
> > non-interoperable update or extension  occurs in the future, it will 
> > be treated as a new protocol, and MUST  describe how its use will be signaled.
> >

---

From: Chris Boulton <[email-masked]>
Date: Wed, 22 Jul 2009 09:42:15 +0100

Hi Dan,

I'm staying neutral on this one but I have embedded some comments 
inline.  We could really do with the rest of the group adding their 
comments at this late stage as we need get this nailed.

Chris.

Dan York wrote:
> we have to keep creating new ones?
[Chris] I don't believe we are creating new ones (perhaps I am missing 
something?).  This is the **first** standard protocol for SIP+xml that I 
have been involved with within the IETF.
>   Why should we close off extensibility?
[Chris] I am keen to understand what you think would be required outside 
of adding new methods and headers etc (as stated in the text) in the 
future that would make us digress of a path also taken by MSRP.  While 
MSRP is not the perfect template they arrived at a decision based on a 
lot more discussion that we have had.
>   To "How much could we still be missing?", wasn't that question 
> probably asked by the authors of the previous three generations?
[Chris] Of the features that are wrapped up in the PDUs - yes. I agree.  
But the control packages have a version identifier for such 
modifications.  Remember we are only talking about the underlying 
connection mechanisms.
>   We don't have any clue what might appear in the future (or if you 
> do, please clue me in so I can buy appropriate stock and capitalize on 
> it!).
[Chris] Too late - i've snapped it all up :-).
>   There very well might be some new media service that makes sense for 
> a media server to handle...
[Chris] Agreed.
> and for our media control protocol to handle - and in a way that might 
> break backward compatibility.
[Chris] It certainly is possible.  Although I am struggling with this 
outside of adding new framework methods and headers.
>   There's that famous saying about someone saying we'd never need more 
> than 640K RAM... ;-)
>
[Chris] I think we all agree with that one.
> existing protocol... which I can explain easily.
[Chris] At the end of the day I am not passionate about this one and its 
for the group to decide.  If all we are talking about is adding a 
version identifier somewhere (probably in top line of message) and an 
error response for incompatible versions - then its not a massive 
issue.  I just want to get this completed as we are getting pulled into 
the typical IETF process of dragging specs on for years as we think of 
new things to add at the end.
>>> changes, we'd be talking about a new protocol. (Isn't this about the 
>>> fourth generation of media control protocols? How much could we

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 23 Jul 2009 08:42:12 -0500

Hi, Dan,

Speaking as chair...

While WGLC has ended, technical objections are always in order.

Having said this, it would be GREAT to provide text if you're asking the 
working group for consensus on a late change - we're expecting to get 
feedback from MMUSIC by the end of the IETF meeting next week, and your 
objection is the last issue we need to work through before we can tell 
Robert that we're ready to go to IETF Last Call.

And we REALLY need to be finished with our core documents. That's not your 
problem, but it is mine (and Eric's).

Thanks,

Spencer

> probably the fourth generation of media control protocols.... why do  we 
> have to keep creating new ones?  Why should we close off  extensibility? 
> To "How much could we still be missing?", wasn't that  question probably 
> asked by the authors of the previous three  generations?  We don't have 
> any clue what might appear in the future  (or if you do, please clue me in 
> so I can buy appropriate stock and  capitalize on it!).  There very well 
> might be some new media service  that makes sense for a media server to 
> handle... and for our media  control protocol to handle - and in a way 
> that might break backward  compatibility.  There's that famous saying 
> about someone saying we'd  never need more than 640K RAM... ;-)
>
> As an implementor, I don't want to be in the business of implementing  new 
> media control protocols.  New protocols require new specs,  potentially 
> require new tools... and require new education of the  customers, 
> engineers... and, well, everyone.
>
> dealing with extensions is then implementing a new version of an  existing 
> protocol... which I can explain easily.
>
> My 2 cents,
> Dan
>
>
>
>>> Could people who DISAGREE with Chris's suggestion please say so  onlist 
>>> (or to the chairs), by July 14?
>>>
>>> MSRP did, and assume that if we make non-backward compatible  changes, 
>>> we'd be talking about a new protocol. (Isn't this about  the fourth 
>>> generation of media control protocols? How much could we  still be 
>>> missing? How much could we be missing that would require  breaking 
>>> backward compatibility?)
>>>
>>> Thanks,
>>>
>>> Spencer
>>