Re: [MMUSIC] Fwd: New Version Notification for draft-ietf-mmusic-rfc4566bis-12.txt

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 23 September 2014 19:18 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F5B1A1BEC for <mmusic@ietfa.amsl.com>; Tue, 23 Sep 2014 12:18:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.235
X-Spam-Level:
X-Spam-Status: No, score=-3.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_I_INVITATION=-2, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HrLIw-5WW6a for <mmusic@ietfa.amsl.com>; Tue, 23 Sep 2014 12:17:59 -0700 (PDT)
Received: from resqmta-po-06v.sys.comcast.net (resqmta-po-06v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:165]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 684B21A88B8 for <mmusic@ietf.org>; Tue, 23 Sep 2014 12:17:58 -0700 (PDT)
Received: from resomta-po-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-06v.sys.comcast.net with comcast id ujGx1o00158ss0Y01jHxfR; Tue, 23 Sep 2014 19:17:57 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-14v.sys.comcast.net with comcast id ujHw1o00V3Ge9ey01jHxot; Tue, 23 Sep 2014 19:17:57 +0000
Message-ID: <5421C764.1030906@alum.mit.edu>
Date: Tue, 23 Sep 2014 15:17:56 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: mmusic@ietf.org
References: <20140923172922.4281.75884.idtracker@ietfa.amsl.com> <E5C5A6C6-1993-4EE7-BCE3-8D72BCB5E74B@cisco.com>
In-Reply-To: <E5C5A6C6-1993-4EE7-BCE3-8D72BCB5E74B@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1411499877; bh=mOptcLto7FyuWXkU2MUNze/FkGxpbLKSUXpMbyjssAE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=dnc1Y/WIAW/pflN5G8SW43doFB+d6HfZ6O/9od+n0VAN5VXsqeFHT+hn0v2vJYUr/ PUkIsZI1fDDbT+Nd6JlKvHzNYevEud1dQFXCTGjebUMXpk4tCsvc1JL4B0/4ApT406 0cjH05o/iZn9+X/k39zDeQ0iTjq1eb7mC9hF/rPbNf09lddS4u1detQHcUVH/KsWxu IhdttBZqjtaY/DGZNASnOTrO6z8IhD5mKOk34GQ7NTHAI1MTrV9oZD3lJSdHUJ2A8y 98u/Rv15p28m+xWT8phnb7QQ6pljj2I2SBMeJb29sEKFayCXO3DFIOb4F75g4opxl9 WyF7hr6ys9Asg==
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/OQdr35b0WhFeyoWkpnH-vHVTkR8
Subject: Re: [MMUSIC] Fwd: New Version Notification for draft-ietf-mmusic-rfc4566bis-12.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 23 Sep 2014 19:18:02 -0000

In Toronto I took an action item to make a proposal for the syntax of 
attributes in 4566bis. Version -12 has the changes I am recommending for 
that.

I would very much appreciate feedback, both on specific syntax details 
and on the overall approach of documenting attributes.

There are at least two goals for this:
- clarify the definition of these attributes
- establish some best-practice examples for how to define attributes,
   that can be followed when other documents define attributes in
   the future.

Note that the general approach I'm taking is that the ABNF defines the 
syntax of the *value* of the attribute, not including the name of the 
attribute. And this is done without extending the base syntax of SDP. 
(I.e., no 'attribute =/ ...' or 'att-value =/ ...')

There are a variety of reasons for this, that have been discussed 
before. A new one is the question of whether attribute names are 
case-sensitive. IMO 4566 isn't very clear about this. Section 5 says:

    An SDP session description consists of a number of lines of text of
    the form:

       <type>=<value>

    where <type> MUST be exactly one case-significant character and
    <value> is structured text whose format depends on <type>.  In
    general, <value> is either a number of fields delimited by a single
    space character or a free format string, and is case-significant
    unless a specific field defines otherwise.  Whitespace MUST NOT be
    used on either side of the "=" sign.

That means that everything after "a=" is case-significant unless there 
is something saying otherwise. Section 6 on attributes has never said 
anything about it, so presumably attribute names are case-sensitive, and 
values are too unless a particular attribute says otherwise.

If we were to define an attribute via 'attribute =/ "foo=" foo-value' 
that would (by the rules of ABNF) imply that the attribute name is 
case-insensitive.

Some things I request to pay special attention to and comment on:

* In practice, do people's implementations assume that attribute names 
should be case-insensitive? Should we explicitly define that they are?

* If attribute names are to be matched in a case-sensitive way, should 
we forbid registering an attribute whose name differs only in case from 
a previously defined attribute?

* For each defined attribute that contains text fields, which, if any, 
of those text fields it contains should be matched in a case-insensitive 
way? The ones in doubt in that are defined in this draft are 'orient' & 
'type'.

* I have embedded questions into the syntax. I'm looking for consensus 
on these.

* There is a notable issue about the encoding-params field in rtpmap. I 
need to know if anybody believes this is, or might in the future be, 
used for anything except the number of audio channels.

	Thanks,
	Paul

On 9/23/14 1:33 PM, Ali C. Begen (abegen) wrote:
> A revision for the 4566bis has been submitted. This draft has substantial edits by Paul K. It attempts to provide more proper attribute definitions. Paul will send an email to the list asking for reviews. Please spare some time and review the changes.
>
> Also this draft refers to the avtext's rtp grouping taxonomy definitions.
>
> Begin forwarded message:
>
>> From: <internet-drafts@ietf.org>
>> Subject: New Version Notification for draft-ietf-mmusic-rfc4566bis-12.txt
>> Date: September 23, 2014 at 11:29:22 AM MDT
>> To: Van Jacobson <van@parc.com>om>, "Mark J. Handley" <m.handley@cs.ucl.ac.uk>uk>, "Ali C. Begen" <abegen@cisco.com>om>, "Dr. Colin Perkins" <csp@csperkins.org>rg>, Colin Perkins <csp@csperkins.org>rg>, Van Jacobson <van@parc.com>om>, Ali Begen <abegen@cisco.com>om>, Mark Handley <m.handley@cs.ucl.ac.uk>
>>
>>
>> A new version of I-D, draft-ietf-mmusic-rfc4566bis-12.txt
>> has been successfully submitted by Ali Begen and posted to the
>> IETF repository.
>>
>> Name:		draft-ietf-mmusic-rfc4566bis
>> Revision:	12
>> Title:		SDP: Session Description Protocol
>> Document date:	2014-09-23
>> Group:		mmusic
>> Pages:		58
>> URL:            http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc4566bis-12.txt
>> Status:         https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis/
>> Htmlized:       http://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-12
>> Diff:           http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rfc4566bis-12
>>
>> Abstract:
>>    This memo defines the Session Description Protocol (SDP).  SDP is
>>    intended for describing multimedia sessions for the purposes of
>>    session announcement, session invitation, and other forms of
>>    multimedia session initiation.  This document obsoletes RFC 4566.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>