[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MEDIACTRL] Protocol Version!!!!
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: mediactrl-bounces at ietf.org [mailto:mediactrl-bounces at ietf.org] On Behalf Of Lorenzo Miniero
Sent: Wednesday, July 22, 2009 13:27
To: Dan York
Cc: mediactrl at ietf.org
Subject: Re: [MEDIACTRL] Protocol Version!!!!
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
Dan York <dyork at voxeo.com> wrote:
> 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
>
>
>
>
>
>
>
>
> _______________________________________________
> MEDIACTRL mailing list
> MEDIACTRL at ietf.org
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl
>
--
Lorenzo Miniero <lorenzo at meetecho.com>
_______________________________________________
MEDIACTRL mailing list
MEDIACTRL at ietf.org
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl