[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MEDIACTRL] Protocol Version!!!!

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:


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.
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

 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
_______________________________________________
MEDIACTRL mailing list
MEDIACTRL at ietf.org
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl


--
Dan York, Director of Conversations
Voxeo Corporation   http://www.voxeo.com  dyork at voxeo.com
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