Subject: [MMUSIC] Working group last call: draft-ietf-mmusic-sdp-media-label-00.txt

From: Colin Perkins <[email-masked]>
Date: Sun, 5 Dec 2004 18:33:05 +0000

This is to announce a working group last call on the SDP Media Label 
draft (draft-ietf-mmusic-sdp-media-label-00.txt). Please send any final 
comments on this draft to the list by 17th December 2004. If no 
substantive comments are raised by that time, we will request this 
document be published as a proposed standard RFC.

Colin

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

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 06 Dec 2004 13:54:08 +0100

Hi,

I have reviewed the document and have some comments. I am sorry that I 
have not been active earlier and come this late:

1. Section 4: No ABNF definition of "token". I assume that you use that 
of SDP. However it needs to be either referenced or explicitly defined.

2. No reference to what BNF you are using. I guess a reference to RFC 
2234 is all that is needed. Otherwise, there would however be some 
uncertainties about spacing. Is any white spaces allowed between 
"a=label:" and the pointer. In RFC 2234 BNF the syntax would say no. In 
some other BNF the answer may be yes.

3. Section 5. I am a bit worried about the offer/answer section. It is 
very unclear on the handling of this attribute. Can we really trust 
applications to define such behavior? From my work with Offer/Answer I 
sometimes find it difficult to get the right behavior out of SDP in 
offer/answer usage. If this behavior is left to the application then 
there is need for a much more explicit section that explains the 
different choices. Also I think using application defined behavior will 
result in quite divergent behavior.

4. Reference [4] is only informative.

I do hope this quick comments make people believe they do not need to 
read the document in the WG last call.

Cheers

Magnus

-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 14 Dec 2004 13:28:36 +0200

Hi Magnus,

> of SDP. However it needs to be either referenced or explicitly defined.

yes, I got this comment from Colin before in a conversation we had. We 
will reference SDPnew and clarify that the attribute value is not 
arbitrary text but a token.

> some other BNF the answer may be yes.

We will reference RFC 2234.

> result in quite divergent behavior.

If this was an attribute that had any influence in the offer/answer 
behabior I would agree with you. But this attribute, from the 
offer/answer point of view, is just informational. That's why offerers 
and answerers can use it as the wish. It does not have any influence in 
the session being established.

The behavior we expect applications to define would be something like, 
"use the same label in the media line as in the XML document you are 
using to describe your conference". Note that this attribute is always 
for the remote's UA information, so, the values that this attribute 
takes in an answer is completely independent from the value it takes in 
the offer.

> 4. Reference [4] is only informative.

We'll fix it.

Thanks for the comments,

Gonzalo

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 15 Dec 2004 13:59:56 +0100

Hi Gonzalo,

The proposed changes looks fine. See below about point 3.

> takes in an answer is completely independent from the value it takes in

Okay, I do understand. I think it is okay with the current text.

Cheers

Magnus Westerlund

---

From: Colin Perkins <[email-masked]>
Date: Fri, 17 Dec 2004 13:13:13 +0000

This last call ends today. It looks like there are minor issues to be 
resolved in an updated draft. Once the revised draft is available, 
we'll allow a short time to check that all comments have been 
addressed, then advance the draft.

Colin