Subject: Re: [MMUSIC] "field" versus "line" terminology in draft-ietf-mmusic-rfc4566bis-14

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 24 Mar 2015 14:14:50 +0000

Hi Keith

I agree with your suggestion. I will implement this in the next revision.

-acbegen

-----Original Message-----
From: <DRAGE>, "Keith   (Keith)"
Date: Friday, February 20, 2015 at 2:10 PM
To: "[email-masked]"
Subject: [MMUSIC] "field" versus "line" terminology in	draft-ietf-mmusic-rfc4566bis-14

>We were investigating what terminology we should be using for describing an SDP line and found that 4566bis (and presumably RFC 4566) are not particularly consistent.
>
>We find both:
>
>"m=" line
>"c=" field
>
>I note that early in section 5 we have the text:
>
><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 imples that a line can have multiple fields separated by a space.
>
>When we get to the description of the "o=" in section 5.2 we have text:
>
>   The "o=" field gives the originator of the session (her username and
>   the address of the user's host) plus a session identifier and version
>   number:
>
>But the ABNF defines
>
>   origin-field =       %s"o" "=" username SP sess-id SP sess-version SP
>   nettype SP addrtype SP unicast-address CRLF
>
>Implying from the earlier definition that the line consists of multiple fields.
>
>Perhaps we should apply the term "line" throughout unless we explicitly mean the specific part of a line identified as a "field".
>
>Regards
>
>Keith
>_______________________________________________
>mmusic mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mmusic