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

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 23 Sep 2014 17:33:21 +0000

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: <[email-masked]>
> Subject: New Version Notification for draft-ietf-mmusic-rfc4566bis-12.txt
> Date: September 23, 2014 at 11:29:22 AM MDT
> To: Van Jacobson <[email-masked]>, "Mark J. Handley" <[email-masked]>, "Ali C. Begen" <[email-masked]>, "Dr. Colin Perkins" <[email-masked]>, Colin Perkins <[email-masked]>, Van Jacobson <[email-masked]>, Ali Begen <[email-masked]>, Mark Handley <[email-masked]>
> 
> 
> 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
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 23 Sep 2014 15:17:56 -0400

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:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 23 Sep 2014 15:30:50 -0400

Nits:

There are a number of places where things are erroneously indented. The 
ones I noticed are:

- A couple of the paragraphs after the exmple in 6.11

- first line of the paragraph after the example in 6.13

I think this is a bug in xml2rfc.

	Thanks,
	Paul