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