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

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 13 Jan 2015 11:10:13 +0000

This version addresses Colin’s and Christer’s comments (except Christer’s
comment on O/A procedures, which is pending a resolution).

Things to do at this point:
1) issues in the tracker
http://trac.tools.ietf.org/wg/mmusic/trac/report/7

2) inserting the text from 4566bis-iana-updates

If there are things I omitted, please speak up.

-acbegen

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Tuesday, January 13, 2015 at 1:06 PM
To: Van Jacobson <[email-masked]>, "Mark J. Handley"
<[email-masked]>, "Ali C. Begen" <[email-masked]>, Colin Perkins
<[email-masked]>, Colin Perkins <[email-masked]>, Van Jacobson
<[email-masked]>, "Ali C. Begen" <[email-masked]>, Mark Handley
<[email-masked]>
Subject: New Version Notification for draft-ietf-mmusic-rfc4566bis-13.txt

>
>A new version of I-D, draft-ietf-mmusic-rfc4566bis-13.txt
>has been successfully submitted by Ali Begen and posted to the
>IETF repository.
>
>Name:		draft-ietf-mmusic-rfc4566bis
>Revision:	13
>Title:		SDP: Session Description Protocol
>Document date:	2015-01-13
>Group:		mmusic
>Pages:		57
>URL:            
>http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc4566bis-13.txt
>Status:         
>https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis/
>Htmlized:       http://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-13
>Diff:           
>http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rfc4566bis-13
>
>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, 13 Jan 2015 12:07:54 -0500

> If there are things I omitted, please speak up.

Here are some corrections to what appeared in -13:

* Section 6.1:

s/none-ws-string/non-ws-string/

* Section 6.6:

This now says:

       payload-type = integer
...
    Note that the payload type number is indicated in a
    7-bit field, limiting the values to incusively between 0 and 127.

But the definition of 'integer' doesn't include 0.

IMO it was a mistake to define integer that way, but its too late to 
change that. I suggest we define another rule that give a name to a 
number that includes zero. E.g.:

    zero-based-integer = "0" / integer

And then use that here and other places where it is appropriate.

It could be defined as (1*DIGIT), but that opens the possibility of 
arbitrarily long padding with zeros on the left, so I think the above is 
preferable.

* Section 6.11:

includes:

       sdplang-value = Language-Tag (as defined in <xref
         target="RFC5646"/>)

The xref didn't get expanded (because it is in artwork.) In any case I 
suggest one of the following:

       sdplang-value = Language-Tag
       Language-Tag = <defined in RFC5646>

or

       sdplang-value = Language-Tag
       ; Language-Tag defined in RFC5646

* Section 6.12:

This has the same problem with Language-Tag, but needs a different 
solution since it is a reuse. I thought it was fine in -12.

* Section 8.2.4:

I see a number of things have been removed from this section. IIUC this 
is because of concerns that came up with Christer tried to follow the 
new style for a draft. The problem there was that all this information 
was included in the IANA Considerations section, and was redundant with 
information in the body of the draft.

But with the new changes there is no longer a requirement to provide 
this information at all. Note that the beginning of this section says:

    New attribute registrations are accepted according to the
    "Specification Required" policy of [RFC5226], provided that the
    specification includes the following information:

This calls for the information in the *specification*, not in the IANA 
Considerations section of the specification.

So "Attribute value" needs to be reinstated. This is the only place 
where the syntax is required.

(I'm fine with Long-form going away. It doesn't seem to serve any purpose.)

	Thanks,
	Paul

> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 13 Jan 2015 17:27:21 +0000

Hi Paul,

-----Original Message-----
From: Paul Kyzivat <[email-masked]>
Date: Tuesday, January 13, 2015 at 7:07 PM
To: "[email-masked]" <[email-masked]>
Subject: Re: [MMUSIC] FW: New Version Notification for
draft-ietf-mmusic-rfc4566bis-13.txt

>s/none-ws-string/non-ws-string/

Good catch.

>And then use that here and other places where it is appropriate.

Done.

>       ; Language-Tag defined in RFC5646

Fixed.

>solution since it is a reuse. I thought it was fine in -12.

Used the same solution from the above.

I will address the comments below separately.

-acbegen

>>> Htmlized:      
>>>http://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-13
>>> Diff:

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 13 Jan 2015 17:56:51 +0000

Hi Paul,

-----Original Message-----
From: Paul Kyzivat <[email-masked]>
Date: Tuesday, January 13, 2015 at 7:07 PM
To: "[email-masked]" <[email-masked]>
Subject: Re: [MMUSIC] FW: New Version Notification for

>where the syntax is required.

OK, I see your point. I added the “attribute value” from -12. Also, one
item below, I change the text:

OLD:
Usage level of the attribute. (One or more of: session,
              media).

NEW:
Usage level of the attribute. (One or more of: session,
              media, source).

>(I'm fine with Long-form going away. It doesn't seem to serve any

It is gone already :)

-acbegen

PS I confirmed the charset abnf with the appsawg co-chair. There is a new
work for that (draft-iana-charset-reg-procedure). I am now referring to
that draft for the abnf definition.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Jan 2015 13:05:31 -0500

I have a suggestion that will improve the readability of the draft 
without changing the semantics at all, by using an extension to ABNF 
defined recently (by me) in RFC7405. It allows the direct specification 
of case-sensitive strings in ABNF. Using that I suggest the following 
changes:

* Section 6.8:

OLD:

       orient-value = portrait / landscape / seascape
       portrait  = %x70.6f.72.74.72.61.69.74    ; "portrait"
       landscape = %x6c.61.6e.64.73.63.61.70.65 ; "landscape"
       seascape  = %x73.65.61.73.63.61.70.65    ; "seascape"
         ; Note: this assumes the intent was to be case-sensitive
         ; Does anything think this should be matched in a
         ; case-insensitive way???

NEW:

       orient-value = portrait / landscape / seascape
       portrait  = %s"portrait"
       landscape = %s"landscape"
       seascape  = %s"seascape"
         ; NOTE: These names are case-sensitive.

* Section 6.9:

OLD:

       conference-type = broadcast / meeting / moderated / test / H332
       broadcast = %x62.72.6f.61.64.63.61.73.74 ; "broadcast"
       meeting   = %x6d.65.65.74.69.6e.67       ; "meeting"
       moderated = %x6d.6f.64.65.72.61.74.65.64 ; "moderated"
       test      = %x74.65.73.74                ; "test"
       H332      = %x48.33.33.32                ; "H332"
         ; NOTE: These names are case-sensitive.

NEW:

       conference-type = broadcast / meeting / moderated / test / H332
       broadcast = %s"broadcast"
       meeting   = %s"meeting"
       moderated = %s"moderated"
       test      = %s"test"
       H332      = %s"H332"
         ; NOTE: These names are case-sensitive.

* Section 9:

OLD:

    This section provides an Augmented BNF grammar for SDP.  ABNF is
    defined in [RFC5234].

NEW:

    This section provides an Augmented BNF grammar for SDP.  ABNF is
    defined in [RFC5234] and [RFC7405].

OLD:

    proto-version =       %x76 "=" 1*DIGIT CRLF
                          ;this memo describes version 0

    origin-field =        %x6f "=" username SP sess-id SP sess-version SP
                          nettype SP addrtype SP unicast-address CRLF

    session-name-field =  %x73 "=" text CRLF

    information-field =   [%x69 "=" text CRLF]

    uri-field =           [%x75 "=" uri CRLF]

    email-fields =        *(%x65 "=" email-address CRLF)

    phone-fields =        *(%x70 "=" phone-number CRLF)

    connection-field =    [%x63 "=" nettype SP addrtype SP
                          connection-address CRLF]
                          ;a connection field must be present
                          ;in every media description or at the
                          ;session-level

    bandwidth-fields =    *(%x62 "=" bwtype ":" bandwidth CRLF)

    time-fields =         1*( %x74 "=" start-time SP stop-time
                          *(CRLF repeat-fields) CRLF)
                          [zone-adjustments CRLF]

    repeat-fields =       %x72 "=" repeat-interval SP typed-time
                          1*(SP typed-time)

    zone-adjustments =    %x7a "=" time SP ["-"] typed-time
                          *(SP time SP ["-"] typed-time)

    key-field =           [%x6b "=" key-type CRLF]

    attribute-fields =    *(%x61 "=" attribute CRLF)

NEW:

    proto-version =       %s"v" "=" 1*DIGIT CRLF
                          ;this memo describes version 0

    origin-field =        %s"o" "=" username SP sess-id SP sess-version SP
                          nettype SP addrtype SP unicast-address CRLF

    session-name-field =  %s"s" "=" text CRLF

    information-field =   [%s"i" "=" text CRLF]

    uri-field =           [%s"u" "=" uri CRLF]

    email-fields =        *(%s"e" "=" email-address CRLF)

    phone-fields =        *(%s"p" "=" phone-number CRLF)

    connection-field =    [%s"c" "=" nettype SP addrtype SP
                          connection-address CRLF]
                          ;a connection field must be present
                          ;in every media description or at the
                          ;session-level

    bandwidth-fields =    *(%s"b" "=" bwtype ":" bandwidth CRLF)

    time-fields =         1*( %s"t" "=" start-time SP stop-time
                          *(CRLF repeat-fields) CRLF)
                          [zone-adjustments CRLF]

    repeat-fields =       %s"r" "=" repeat-interval SP typed-time
                          1*(SP typed-time)

    zone-adjustments =    %s"z" "=" time SP ["-"] typed-time
                          *(SP time SP ["-"] typed-time)

    key-field =           [%s"k" "=" key-type CRLF]

    attribute-fields =    *(%s"a" "=" attribute CRLF)

OLD:

    media-field =         %x6d "=" media SP port ["/" integer]
                          SP proto 1*(SP fmt) CRLF

NEW:

    media-field =         %s"m" "=" media SP port ["/" integer]
                          SP proto 1*(SP fmt) CRLF

OLD:

    fixed-len-time-unit = %x64 / %x68 / %x6d / %x73

NEW:

    fixed-len-time-unit = %s"d" / %s"h" / %s"m" / %s"s"
         ; NOTE: These units are case-sensitive.

OLD:

    key-type =            %x70 %x72 %x6f %x6d %x70 %x74 /     ; "prompt"
                          %x63 %x6c %x65 %x61 %x72 ":" text / ; "clear:"
                          %x62 %x61 %x73 %x65 "64:" base64 /  ; "base64:"
                          %x75 %x72 %x69 ":" uri              ; "uri:"

NEW:

    key-type =            %s"prompt"
                          %s"clear:"
                          %s"base64:"
                          %s"uri:"
         ; NOTE: These names are case-sensitive.

OLD:

    token-char =          %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
                          / %x41-5A / %x5E-7E

NEW:

    token-char =          ALPHA / DIGIT
                          / "!" / "#" / "$" / "%" / "&" /
                          / "'" ; (single quote)
                          / "*" / "+" / "-" / "." / "^" / "_"
                          / "`" ; (Grave accent)
                          / "{" / "|" / "}" / "~"

(I can't tell you how many times I have had to look at the definition of 
token-char and an ascii chart to figure out if a particular special 
character is allowed in a token!)

* Section 12.1:

Add a reference to RFC7405.

	Thanks,
	Paul

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 15 Jan 2015 04:07:21 +0000

Hi Paul,

I am all good with these simplifications and vote for making them.

-acbegen