Re: [MMUSIC] Updated MSID draft

Harald Alvestrand <harald@alvestrand.no> Fri, 01 November 2013 09:00 UTC

Return-Path: <harald@alvestrand.no>
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 BC9A121E80C5 for <mmusic@ietfa.amsl.com>; Fri, 1 Nov 2013 02:00:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCXAxoh-Qfga for <mmusic@ietfa.amsl.com>; Fri, 1 Nov 2013 02:00:33 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4023811E82E7 for <mmusic@ietf.org>; Fri, 1 Nov 2013 02:00:28 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BD3E439E516 for <mmusic@ietf.org>; Fri, 1 Nov 2013 10:00:25 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNvtKo5zXDUY for <mmusic@ietf.org>; Fri, 1 Nov 2013 10:00:23 +0100 (CET)
Received: from [172.16.6.227] (unknown [195.70.5.235]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id B699F39E0C8 for <mmusic@ietf.org>; Fri, 1 Nov 2013 10:00:23 +0100 (CET)
Message-ID: <52736DA6.4010102@alvestrand.no>
Date: Fri, 01 Nov 2013 10:00:22 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: mmusic@ietf.org
References: <5270B191.9030603@alvestrand.no> <527119EA.2030005@alum.mit.edu>
In-Reply-To: <527119EA.2030005@alum.mit.edu>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [MMUSIC] Updated MSID draft
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: Fri, 01 Nov 2013 09:00:37 -0000

On 10/30/2013 03:38 PM, Paul Kyzivat wrote:
> A few comments about this version. Actually the comments aren't
> specific to this revision, but they relate to things I didn't notice
> earlier.
>
> Msid-Semantic syntax:
>
>      attribute =/ msid-semantic-attr
>      msid-semantic-attr = "msid-semantic:" token (" " identifier)*
>      token = <as defined in RFC 4566>
>
> The usage of "*" is backward. (Following regex syntax rather than abnf
> syntax). This ought to be:
>
>      attribute =/ msid-semantic-attr
>      msid-semantic-attr = "msid-semantic:" token *(" " identifier)
>      token = <as defined in RFC 4566>

Thanks!


>
> Just following that:
>
>    The semantic field may hold values from the IANA registries
>    "Semantics for the "ssrc-group" SDP Attribute" and "Semantics for the
>    "group" SDP Attribute".
>
> I have a couple of issues with this:
>
> Section 5 defines a new registry "Semantics for the msid-semantic SDP
> attribute", and defines a new semantic "WMS" in it. The text above
> doesn't even reference this registry.

Yep, that section needs to be re-thought. The SSRC-group registry is now
irrelevant, since we don't do things on SSRC any more.
>
> Because the two mentioned registries are independent, AFAIK there is
> no guarantee that they couldn't someday contain different definitions
> for the same "semantic" name. Then, if that name were used with msid
> the proper definition to use would be ambiguous. (I realize this is
> implausible, but nothing prevents it.) IMO the *right* answer would be
> to merge all these grouping semantics into a single table. But that is
> a hassle right now. Perhaps it would be sufficient to say that only
> semantics that are uniquely defined across all of these tables may be
> used with msid. E.g.,
>
>    The semantic field may hold any value that is uniquely defined
>    in one and only one of the IANA registries "Semantics for the
>    msid-semantic SDP attribute", "Semantics for the "ssrc-group"
>    SDP Attribute" and "Semantics for the "group" SDP Attribute".

That would work - it should then ask IANA to update the instructions for
those registries to disallow the registration of new values with
conflicts between them.

This effectively turns them into one registry...

>
>     Thanks,
>     Paul
>
> On 10/30/13 3:13 AM, Harald Alvestrand wrote:
>> Roni and Flemming pointed out that I hadn't managed to submit the fixes
>> I made to -msid after the reviews of -01 before the deadline, and had
>> even managed to forget to send it to the list.
>>
>> I had missed a number of occurences where "SSRC" needed to be changed to
>> "m-line" in the text (with some more adjustments to language around
>> that).
>>
>> Here it is. I'll submit it on Monday, when the I-D repository reopens.
>>
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


-- 
Surveillance is pervasive. Go Dark.