[MMUSIC] syntax for attributes in 4566bis

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 06 May 2013 18:42 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 C36B221F86DE for <mmusic@ietfa.amsl.com>; Mon, 6 May 2013 11:42:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.162
X-Spam-Level: **
X-Spam-Status: No, score=2.162 tagged_above=-999 required=5 tests=[FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
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 32jBdCN4Fanu for <mmusic@ietfa.amsl.com>; Mon, 6 May 2013 11:42:25 -0700 (PDT)
Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 96C9B21F859C for <mmusic@ietf.org>; Mon, 6 May 2013 11:42:22 -0700 (PDT)
Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta08.westchester.pa.mail.comcast.net with comcast id YgqU1l0041c6gX858iiMX1; Mon, 06 May 2013 18:42:21 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id YiiL1l01T3ZTu2S3jiiLsh; Mon, 06 May 2013 18:42:21 +0000
Message-ID: <5187F98C.6010705@alum.mit.edu>
Date: Mon, 06 May 2013 14:42:20 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: draft-ietf-mmusic-rfc4566bis@tools.ietf.org, IETF MMUSIC WG <mmusic@ietf.org>
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=q20121106; t=1367865741; bh=DIv3LkZRPqyA5Hlv8kqYo07RERmS6OsLITJDh0L1Y7A=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=D3EWPJ9r/BBt90lFXnL7E5eE5AzaKrrUrcf1OiFZfNS6DrQLKoVTE3eOG54y0/Ds7 GPRZJOkz1o/SNk9IR7zrOKbP6p+oHRoGDCbk7LyhRvNw2J6mxTRBTht/ru+w/XjO5o pu9xkYa1v9+/30+iBFR4yNFRgDlxNkUxqhvwds3oQLzIhett5fYkiN5e319w5i3JRu vGCFxlK7tG8A0mR7hBB6jpgPZWTiOEnYNIkbH8NAn/dR18sH3L9VTSmtt+X9dz37++ UXJnZDAYiDLwmuwyB+9XRILdckWKeYOR2eVlJ03EtL2YlhZ8Jkn0ZshBocFE14qDmZ ACpl9P8oVKk7w==
Subject: [MMUSIC] syntax for attributes in 4566bis
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, 06 May 2013 18:42:31 -0000

I have been working on an SDP Directorate review of a draft that defines 
some new SDP attributes. In the process of doing that I came across some 
things that I think ought to be improved in 4566bis:

1) The formal syntax for SDP in 4566 defines a generic syntax for 
attributes:

    attribute-fields =    *(%x61 "=" attribute CRLF)
    attribute =           (att-field ":" att-value) / att-field
    att-field =           token
    att-value =           byte-string

This is fine. Elsewhere it defines a number of specific attributes:

       a=cat:<category>
       ...
       a=keywds:<keywords>
       ....

These are defined with informal patterns such as above, along with text. 
There is no formal specification of the syntax of the values of these 
attributes.

Then in the IANA considerations section these attributes are added to 
the IANA registry of SDP attributes.

The main problem with the above is the lack of syntax for the values.
With newer attributes in other drafts we have typically required ABNF. I 
think 4566bis ought to provide ABNF syntax for all of the attributes it 
defines.

2) If syntax is to be provided, then there is a question of *how* it 
should be done. There are a number of possibilities. Here are two:

- link it right into the full SDP syntax. E.g.,

    cat-attr = "cat:" category
    category = token
    attribute =/ cat-attr

- define the syntax of the attribute, but *don't* link it into the
   the full SDP syntax.

In my opinion it is better to *not* link into the general syntax. It 
doesn't matter much for this draft, but it sets a bad precedent for 
other drafts that define attributes. Each draft that does so (via use of 
'attribute =/ ...' is an *update* to the rfc that defines 'attribute', 
and should be marked as such.

The existence of the IANA registry for attributes means that it is not 
necessary to formally extend the syntax of 'attribute' and so the draft 
need not be an update.

Whatever we do here will become a defacto template for how future drafts 
define attributes. So we should make it a good example.

3) The IANA registration of attributes has become a mess. Section 8.2.4 
both defines the IANA registry for attributes and populates it with the 
attributes defined in the draft. But it doesn't precisely specify the 
name or format of the table. It *does* specify what information must be 
provided.

What is actually present in IANA are *four* different tables for attributes:

SDP Parameters att-field (both session and media level)
SDP Parameters att-field (media level only)
SDP Parameters att-field (session level)
SDP Parameters att-field (source level)
SDP Parameters att-field (unknown level)

This is hard to read, and its hard for a draft to specify precisely what 
table things should go in.

I suggest it would be good to reorganize the IANA registry, so that it 
only has one table, with a separate column (or columns) to indicate 
where the attribute may be used: session, media, source.

Then ensure that the registrations for the attributes defined in the bis 
are good examples of how to use this, including explicitly referencing 
the table to be updated.

4) RFC5576 introduced the notion of source-level attributes. In 
principle the same attributes may be used at source level and the other 
levels, so they should be incorporated into the same table structure. 
Some thought ought to be given to how to ensure 4566bis integrates well 
with 5576 regarding definition and registration of attributes. Perhaps 
it would be better to make 4566bis replace 5576 as well. Or maybe that 
isn't necessary. Should be discussed.

	Thanks,
	Paul