Re: [MMUSIC] comedia-fix-00 comments

[David Yon <yon.ietf@rfdsoftware.com>]

At 07:39 PM 1/6/2003, Paul Kyzivat wrote:
> David,
>
> Haven't seen you post for a long time. I thought maybe you had dropped off 
> the face of the earth. I guess not. :-)
My primary interest in MMUSIC was comedia, and since it looked like it was 
on track to RFC-land, I've been laying low.  Silly me. :-)



> Back when I first got involved with comedia I shared the same desire for 
> the "hook". Since I came in in the middle of the development, I took it as 
> a requirement that "shoe-horning additional information into an arbitrary 
> protocol was outside the bounds of what SDP could impose."
>
> Accepting that limitation led to the existing comedia.
>
> However, for the curent exercise, we started with the requirements for 
> simple, with a protocol that is being designed concurrently. That gives us 
> more flexibility. Then, starting with comedia, we tried to generalize, but 
> relaxing the restrictions to fit the needs of simple. With relaxed 
> restrictions that "hook" can be available, so other solutions are possible.
One thing that occurs to me---especially if you are dealing with a new 
protocol---is perhaps to make the hook generic in terms of the SDP but 
specific to each media type.  I.e., many existing protocols have something 
in their initial handshake that can be used to uniquely identify the 
stream.  Our protocol at Dialout.Net has such a thing, presumably SIMPLE 
has or could add one, and I thought there was discussion very early in 
comedia's development that RTP has a candidate (SSID?).  This would be much 
less intrusive than comedia-fix's proposal (which is my big beef with 
endpoint-ID), yet would accommodate session correlation at least for those 
protocols that have suitable comedia hooks.

Here's a strawman:

        - The hook is optional, to account for protocols that do not
          have an existing hook, or if their hook has not been standardized.

        - The syntax would be similar to the endpoint-ID proposal (but
          maybe named "media ID" or something that ties it to the media).

        - The hook must be simple, preferably a 32-bit integer, or at most
          definable as integer or short ASCII string.

        - The hook is defined on a per-protocol basis.  The ones we can
          think of today we put into comedia, later ones get defined in
          a one-page RFC.

This still tightly couples signalling with media more than I would like 
(see my decomposed gateway argument), but I could live with it.


> Of course, relaxing the restrictions potentially invalidates potential 
> uses of comedia as it was. We have discussed various ways of dealing with this:
> - make the "fixed" comedia be a new draft that coexists with the "old" comedia
>
> - modify the "old" comedia draft so that it specifies two alternative ways 
> of working - one compatible with the old restrictions, one with the new 
> restrictions
>
> - simply modify comedia to support the new assumptions, accepting the 
> invalidation of some formerly valid cases
I think it depends on where we end up with this.  If the changes end up 
being less radical than what's in comedia-fix, then I think another spin of 
comedia makes sense.


> None of us knew whether there are any existing applications of comedia, so 
> we couldn't assess the impact of invalidating them. We decided to simply 
> float the proposal and see what kind of responses we got. Based on that we 
> could decide which path to take.
>
> You have provided us with at least one data point - that somebody cares 
> about the "old" version. Do you know of current applications of it?
We are not widely deployed enough to care about backward compatibility yet, 
but I have gotten several emails over the past year from folks asking me 
questions about comedia.  So from my perspective changing comedia is not a 
problem in principle, but I do have some strong opinions about the 
side-effects of any changes---as you saw in the last email. :-)

Again, let's see where we end up.  If the changes aren't too radical then 
we'll just respin.  I may be out of sync, but I believe most folks 
understand that implementations based on working drafts can be rendered 
obsolete.


_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic