Subject: RE: [MMUSIC] Accept wew workitem:draft-hautakorpi-mmusic-sdp-media-content-01.txt?

From: "Eric Burger" <[email-masked]>
Date: Wed, 24 Aug 2005 07:47:26 -0400

I don't see there ever being a namespace collision: the semantics of a
given "content" string is by definition application-defined.  This means
that only the application knows and understands (and negotiates) what
the meanings of the strings are.

Let's take the example from the draft: "alt-video" is entirely
content-free.  If I am an office conferencing application, I probably am
the white-board.  Oh wait: I am the audience.  Who knows?  The
application.

Is the "sl" the sl of the "main-video", "speaker", "alt-video", ???

Yes, you can give me definitions, BUT ONLY FOR A GIVEN APPLICTION.

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]] 
Sent: Wednesday, August 24, 2005 4:05 AM
To: Eric Burger
Cc: [email-masked]; Jani Hautakorpi (JO/LMF)
Subject: Re: [MMUSIC] Accept wew
workitem:draft-hautakorpi-mmusic-sdp-media-content-01.txt?

Hi Eric,

I already addressed in a previous mail the difference between "label" 
and "content". We cannot use the exisiting labels because we would have 
a backwards compatibility problem. The issue has to do with reserving 
entries within a name space at any time in the future... it does not 
work because you may have collisions. We better define a different 
namespace for well-known semantics (i.e., a new SDP attribute different 
from label).

Regarding the registry, it was discussed in the meeting, and it is clear

that, as you point out, we want a common registry. Note that the 
registry does not belong to any WG... it belongs to IANA. The only thing

we have to come up with is the rules to populate that registry (e.g., an

RFC is needed, or fist come first serve...)

Thanks,

Gonzalo

Eric Burger wrote:
> On the one hand, the concept of adding semantics to a stream is
> sensible.  See RFC3458.
> 
> However, at the SDP level, is the "content" anything other than an
> opaque string?  It is the application (two layers over SDP) that
applies
> semantics to the "content."
> 
> Why is this important?  For one thing, if there is an IANA registry at
> all, it belongs to the Applications, not to MMUSIC.
> 
> Once it is recognized this is an application-layer construct, do we
> really need anything other than "label" from
> draft-ietf-mmusic-sdp-media-label?
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Joerg Ott
> Sent: Tuesday, August 23, 2005 10:02 PM
> To: [email-masked]
> Cc: Colin Perkins; Jon Peterson; [email-masked]
> Subject: Re: [MMUSIC] Accept wew
> workitem:draft-hautakorpi-mmusic-sdp-media-content-01.txt?
> 
> Folks,
> 
> from the comments that were made to the list, the chairs conclude
> that there is interest and justification in pursuing this individual
> draft as an MMUSIC work item.
> 
> The discussion has also shown that a delineation of this work
> from what is done in e.g. XCON is needed.  The authors are encouraged
> to ensure a well-defined scope and define the relationship to and
> difference from the work pursued in XCON.
> 
> The chairs will take up the necessary actions with the ADs.
> 
> Cheers,
> Joerg
> 
>  > From: [email-masked] [mailto:[email-masked]] On
> Behalf
>  > Of Joerg Ott
>  > Sent: Monday, August 15, 2005 3:34 PM
>  > To: [email-masked]
>  > Cc: Colin Perkins; [email-masked]
>  > Subject: [MMUSIC] Accept wew work
>  > item:draft-hautakorpi-mmusic-sdp-media-content-01.txt?
>  >
>  > Folks,
>  >
>  > at the last IETF, we had some discussion of
>  > draft-hautakorpi-mmusic-sdp-media-content-01.txt entitled "The SDP
>  > (Session Description Protocol) Content Attribute"
>  > and it appeared to be considered generally useful.
>  >
>  > It definitely poses a couple of questions on where to draw the line
in
>  > "semantic" descriptions of media streams in SDP.
>  >
>  > An interesting aspect to bear in mind is that we are already
capable
> of
>  > labeling media streams and thus can, in principle, assign semantics
by
>  > means of a conference control protocol developed in XCON or some
other
>  > external means.
>  >
>  > However, the scope of semantic identification of the purposes of
>  > individual m= lines is valuable beyond conferencing scenarios
(e.g.,
> in
>  > the case of media streaming with several streams of the same media
> type,
>  > among others).  So, there appears value in a
conferencing-independent
>  > approach.
>  >
>  > This is a poll to whether or not the MMUSIC WG should consider this
>  > problem as "its own" and create a working group document for this
>  > purpose -- which includes a commitment from the group to put effort
> into
>  > this.  The WG draft may be based upon the input received so far
from
> the
>  > authors of the above individual submission but further contributors
> are
>  > encouraged if we decide to take this up.
>  >
>  > Please comment to the list.
>  >
>  > Thanks,
>  > Joerg
> 

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 24 Aug 2005 15:04:39 +0300

Hi Eric,

yes, the content entries are defined by applications. However, instead 
of having a registry per application, what we are doing is defining a 
general registry so that they can use the same name space without 
collisions. I believe having a general registry is clearer. Implementers 
can find registered entries in an easier way and applications can reuse 
already defined entries if they find it appropriate. In any event, we 
expect this to be a rather short registry.

And yes, a given stream may have several contents associated to it 
(e.g., the main video and carry sign language).

Cheers,

Gonzalo

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo