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

From: Joerg Ott <[email-masked]>
Date: Mon, 15 Aug 2005 14:34:06 +0200

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: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Aug 2005 09:19:05 -0400

Joerg,

You raise an interesting question.

I think these are not entirely independent mechanisms, but instead are 
simply different views or aspects of the same problem - to assign 
semantics to a media stream.

So I see no reason why there need be separate mechanisms to assign 
labels to the same media stream for the two purposes. Instead, it seems 
to me that a single label could be used for both purposes. Certain label 
values could (as in draft-hautakorpi-mmusic-sdp-media-content-01) have 
some predefined semantics, while others do not. Then external 
mechanisms, such as XCON, can augment the semantics associated with a label.

	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 17 Aug 2005 00:53:00 +0300

Paul,

they are two different problems, and so, we need a new attribute. The
already defined 'label' attribute uses an unrestricted name space. That
is, implementations can use whatever string they want as labels.

Now, if you start defining semantics for some of those labels, you would
break existing implementations... furthermore, every time you defined a
new semantically-meaningful label, you would break existing
implementations that may use that label without knowing that had been
reserved at a later point.

It would be like if you were programming in C and named a variable in
your program 'foo'... and suddenly, I reserve the name 'foo' for a new C
command... your program would break.

My proposal is to go ahead define a new attribute, as the current draft
proposes. It has much better extensibility properties than overloading
the existing parameter.

Thanks,

Gonzalo

Paul Kyzivat wrote:
> I think these are not entirely independent mechanisms, but instead
> are simply different views or aspects of the same problem - to assign
> labels to the same media stream for the two purposes. Instead, it
> seems to me that a single label could be used for both purposes.
> Certain label values could (as in
> draft-hautakorpi-mmusic-sdp-media-content-01) have some predefined
> semantics, while others do not. Then external mechanisms, such as
> XCON, can augment the semantics associated with a label.
> 
> Paul
> 
> Joerg Ott wrote:
> 
>> Folks,
>> 
>> 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.
>> 
>> 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.
>> 
>> Thanks, Joerg
>> _______________________________________________ mmusic mailing list
>>  [email-masked] https://www1.ietf.org/mailman/listinfo/mmusic
>> 

-- 
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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Aug 2005 19:54:33 -0400

Gonzalo,

You are probably right that it can't be unified for reasons of backward 
compatibility. Were we starting over it could probably have been dealt 
with somehow.

In any case it isn't worth arguing about esthetics of SDP, which has none.

	Paul

Gonzalo Camarillo wrote:
>>> 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.
>>>