Re: [MEDIACTRL] Protocol Version!!!!

["Spencer Dawkins" <spencer at wonderhamster.org>]

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