[MMUSIC] Comments on draft-alvestrand-mmusic-msid-01

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 15 October 2012 21:10 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A673321F8A1D for <mmusic@ietfa.amsl.com>; Mon, 15 Oct 2012 14:10:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.361
X-Spam-Level:
X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFv5ReKCQOTv for <mmusic@ietfa.amsl.com>; Mon, 15 Oct 2012 14:10:42 -0700 (PDT)
Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id A70ED21F89FF for <mmusic@ietf.org>; Mon, 15 Oct 2012 14:10:41 -0700 (PDT)
Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta03.westchester.pa.mail.comcast.net with comcast id BTWr1k04M1ap0As53ZAmPH; Mon, 15 Oct 2012 21:10:46 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id BZ6G1k0043ZTu2S3iZ6GXn; Mon, 15 Oct 2012 21:06:16 +0000
Message-ID: <507C7AA4.1010405@alum.mit.edu>
Date: Mon, 15 Oct 2012 17:05:40 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: IETF MMUSIC WG <mmusic@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [MMUSIC] Comments on draft-alvestrand-mmusic-msid-01
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Oct 2012 21:10:42 -0000

Harald,

I looked this over, and have a few observations:

Section 2, 1st paragraph

OLD:

    This document extends the Source-Specific Media Attributes framework
    [RFC5576] by adding a new "msid" attribute that can be used with the
    "a=ssrc" SDP attribute.  This new attribute allows endpoints to
    associate RTP media streams that are carried in different RTP
    sessions, as well as allowing application-specific information to the
    association.

The above suggests the mechanism is only for associating media streams 
in *different* sessions. But they can also be in the *same* session. So 
I would suggest:

NEW:

    This document extends the Source-Specific Media Attributes framework
    [RFC5576] by adding a new "msid" attribute that can be used with the
    "a=ssrc" SDP attribute.  This new attribute allows endpoints to
    associate RTP media streams that are carried in the same or
    different RTP sessions, as well as allowing application-specific
    information to the association.

Syntax:

      ; "attribute" is defined in RFC 4566.
      ; This attribute should be used with the ssrc-attr from RFC 5576.
      attribute =/ msid-attr
      msid-attr = "msid:" identifier [ " " appdata ]
      identifier = 1*64 ("0".."9" / "a".."z" / "-")
      appdata = 1*64 ("0".."9" / "a".."z" / "-")

Do you *really* want to allow identifiers like "-----", "---abc--" and 
"0---0--0-0"??? If these seem silly and error prone then the syntax 
could be made more restrictive.

If you *do* want to be this flexible, why not go further, and use 
<token> as defined in 4566 for both <identifier> and <appdata>?

Since it is recommended to generate the identifier via a random number 
generator, then why not define a representation that is a common 
encoding of an integer, such as hex or base64? The examples are 
obviously not generated this way. So maybe RECOMMENDED is too strong for 
use of random numbers. (It was offered as a possibility, but not 
recommended, in the prior version. Why the change?)

Section 3 - Msid-Semantic:

    The ABNF of msid-semantic is:

      attribute =/ msid-semantic-attr
      msid-semantic-attr = "msid-semantic:" " " identifier token
      token = <as defined in RFC 4566>

Above appears broken - there is no separator between identifier and 
token. Presumably you meant:

      attribute =/ msid-semantic-attr
      msid-semantic-attr = "msid-semantic:" " " identifier " " token
      token = <as defined in RFC 4566>

Also, the text isn't clear on the relationship between
a=msid-semantic:
a=ssrc-group:
a=group:

Are these all just *analogous* but independent mechanisms for grouping? 
Or is it intended that these can be used together to group things of all 
these types together?

RFC 5576 makes it clear that ssrc-group and group are analogous but 
independent with independent registries.

I find in the iana considerations section that msid-semantic is reusing 
the "Semantics for the "ssrc-group" SDP Attribute" registry, and 
registers "WMS" in that registry. So apparently one can use WMS with 
a=ssrc-group. That suggests it is intended that can be used together.

BUT, ssrc-group is a media level attribute. That implies that the 
namespace for ssrc-group tokens is independent for each media section in 
the SDP. But msid-semantic is session-wide. Using it would couple the 
namespaces of different media sections.

I don't know the answer here, but it at least needs clarification and 
may require some changes.

Section 4:

This section feels like it belongs in a separate draft. If it were 
non-normative then it might be ok as an example. But it is normative. 
The following clearly is:

    When an SDP description is updated, a specific msid continues to
    refer to the same media stream; an msid value MUST NOT be reused for
    another media stream within a PeerConnection's lifetime.

It isn't clear if that is intended only for WebRTC media streams. 
Hopefully so, since it is in a section scoped that way, and might not be 
desirable for all uses.

Even for this use that limitation is problematic. Anything that requires 
the generation of new SDP in a session to be aware of all the historical 
SDP in that session is problematic. It is easy to get situations 
(transfer, federation) where contributors to the SDP come and go without 
knowledge of history prior to their joining.

(This is already a problem in SDP with the requirement that a payload 
number can never be reused for a different codec within an RTP session. 
It is my impression that this is often violated, usually without problem.)

	Thanks,
	Paul