Subject: Re: [MMUSIC] Comments on ABNF in 4566bis

From: Paul Kyzivat <[email-masked]>
Date: Mon, 01 Dec 2014 11:45:29 -0500

Collin,

Thanks for reviewing this. I have some followup questions for you inline.

On 11/25/14 7:34 AM, Colin Perkins wrote:
> Hi,
>
> The chairs asked me to review the ABNF in rfc4566bis. This looks to be
> going in the right direction. Some comments:

> *a=cat:*
> - This attribute was used with SAP [RFC2974] to categorise session
> announcements, for example “a=cat:sport.football”. There was never a
> formal definition beyond a dot-separated string, and intentionally no
> central registry of categories.
> - Should likely have a not to say this is obsolete.
> - Syntax should likely be non-ws-string

I'm ok with this if nobody objects.

> *a=keywds:*
> - Like a=cat:, this was intended for use with SAP. I’m not aware that it
> was ever implemented.
> - Should likely have a not to say this is obsolete.
> - Syntax should likely be: “keywords = text”

I'm ok with this if nobody objects.

> *a=tool:*
> - Something like HTTP user agent string
> - Syntax should likely be: “tool-name-and-version = text”

WFM

> *a=ptime: *and *a=maxptime:*
> - Are these always integers?

There is a separate thread on this.

> *a=rtpmap:*
> - payload-type is an integer in the range 0-127 in RTP
> - encoding-name is a MIME subtype, and should have the syntax to match this
> - is clock-rate always an integer?

If there is no way that larger values could ever be used then I'm fine 
with calling out this restriction. I'll probably do it in text rather 
than in ABNF.

> *a=type:*
> - I assume a registry was intended, but it’s not clear there’s any need now

Do you mean that you don't think we need a mechanism to define further 
values? Or that it would be sufficient to do so with another update to 
this document?

Do you know if these names were intended to be case sensitive? That is 
an important distinction to make. And whatever choice is made will 
potentially have backward compatibility problems for somebody.

> *a=charset:*
> - This is a name from the registry at
> http://www.iana.org/assignments/character-sets/character-sets.xhtml and
> needs to follow that syntax

In this and other cases where what goes in the SDP is a reference to 
something defined in a registry, I am inclined to give a simplified 
syntax that might be a superset of what is permitted in the registry. It 
doesn't matter a whole lot if it allows some invalid values, because 
such names will never be in the registry.

This will help implementers. And when the exact formal definition isn't 
available in ABNF, or is very complex, it can also ease formal checking 
of the SDP ABNF.

Given that explanation, is there anything wrong with what I have?

> *a=sdplang:* and *a=lang:*
> - Should reference the RFC5646 definition

Same comment as charset.

> *a=quality:*
> - I thought the intent here was a real number, in the range 0…10

What I could find only discussed quality in the context of video media, 
and restricted the range to 0..10 in that case. But it didn't explicitly 
limit (or define) the use of quality for other media. It seems 
reasonable to me that the same range would apply to any media where 
quality applies, but I wasn't sure.

Also, should the values here be restricted to integral values, or should 
fractional values be allowed?

BTW - I just noticed I have an error in my ABNF: I limit the 
quality-value to an integer, which excludes zero. So I need to change 
the abnf in one way or another.

> *a=fmtp:*
> - The format parameters are MIME media type parameters, and need to
> reflect their syntax.

My understanding is that the values are whatever was in the <fmt> field 
of the associated m-line. What is valid there is defined for each 
<proto> field. For the RTP variants, it is a payload type. For UDP it is 
a media (sub)type. But we can't know in general what if might be for 
other <proto>s, since new ones could be defined in the future.

The m-line syntax defines the fmt as a token. So I figured that the same 
definition should be used here.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Tue, 02 Dec 2014 09:29:25 +1100

Hello,

> I'm ok with this if nobody objects.

[CNG] It seems at least someone is using it: 
http://www.gwg.nga.mil/misb/docs/rp/RP1302.pdf

Regards, Christian

---

From: Colin Perkins <[email-masked]>
Date: Mon, 1 Dec 2014 23:39:46 +0000

Paul,

On 1 Dec 2014, at 16:45, Paul Kyzivat <[email-masked]> wrote:
> If there is no way that larger values could ever be used then I'm fine with calling out this restriction. I’ll probably do it in text rather than in ABNF.

The payload type is a 7-bit field in the RTP header, so definitely cannot be outside this range. Writing this in the text makes sense.

> Do you mean that you don't think we need a mechanism to define further values? Or that it would be sufficient to do so with another update to this document?

This list hasn’t changed in RFC 2327 in 1998. I think it’s safe to leave updates to a future revision of this document.

> Do you know if these names were intended to be case sensitive? That is an important distinction to make. And whatever choice is made will potentially have backward compatibility problems for somebody.

I expect the general rule at the start of Section 5 (top of page 8) applies:

   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.

Hence, this is case significant.

>> http://www.iana.org/assignments/character-sets/character-sets.xhtml and needs to follow that syntax
> 
> In this and other cases where what goes in the SDP is a reference to something defined in a registry, I am inclined to give a simplified syntax that might be a superset of what is permitted in the registry. It doesn't matter a whole lot if it allows some invalid values, because such names will never be in the registry.
> 
> This will help implementers. And when the exact formal definition isn't available in ABNF, or is very complex, it can also ease formal checking of the SDP ABNF.
> 

Why not reference the correct ABNF from RFC 2978? I don’t understand the desire to put something incorrect here. 

>> - Should reference the RFC5646 definition

Same answer. There’s already a standard ABNF syntax for these, and this document should refer to it rather than trying to define something new.

> What I could find only discussed quality in the context of video media, and restricted the range to 0..10 in that case. But it didn't explicitly limit (or define) the use of quality for other media. It seems reasonable to me that the same range would apply to any media where quality applies, but I wasn't sure.
> 
> Also, should the values here be restricted to integral values, or should fractional values be allowed?

I always assumed fractional values were allowed, but you’d have to check with someone who’s implemented this.

> BTW - I just noticed I have an error in my ABNF: I limit the quality-value to an integer, which excludes zero. So I need to change the abnf in one way or another.
> 
>> *a=fmtp:*
> My understanding is that the values are whatever was in the <fmt> field of the associated m-line. What is valid there is defined for each <proto> field. For the RTP variants, it is a payload type. For UDP it is a media (sub)type. But we can't know in general what if might be for other <proto>s, since new ones could be defined in the future.
> 
> The m-line syntax defines the fmt as a token. So I figured that the same definition should be used here.

For RTP, you do know explicitly that the <format specific parameters> in the a=fmtp: line are MIME media subtype parameters, and need to conform to that syntax.

-- 
Colin Perkins
https://csperkins.org/

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 03 Dec 2014 13:07:08 -0500

> Why not reference the correct ABNF from RFC 2978? I don’t understand the desire to put something incorrect here.

I've looked again at 2978, and it is less than clear. It says:

    Each assigned name MUST uniquely identify a single charset.  All
    charset names MUST be suitable for use as the value of a MIME content
    type charset parameter and hence MUST conform to MIME parameter value
    syntax.  This applies even if the specific charset being registered
    is not suitable for use with the "text" media type.
    ...
    Finally, charsets being registered for use with the "text" media type
    MUST have a primary name that conforms to the more restrictive syntax
    of the charset field in MIME encoded-words [RFC-2047, RFC-2184] and
    MIME extended parameter values [RFC-2184].  A combined ABNF
    definition for such names is as follows:

      mime-charset = 1*mime-charset-chars
      ...

The final paragraph above seems to say that mime-charset only applies 
for charsets registered for use with "text", but based on the first 
paragraph this syntax could apply for all charset names.

And this syntax doesn't apply any limit to how long the names can be, 
while the IANA registry itself says:

    The character set names may be up to 40 characters taken from the
    printable characters of US-ASCII.  However, no distinction is made
    between use of upper and lower case letters.

I based my ABNF on that. But yes, I could reference mime-charset from 2978.

Note also that I currently reference "Preferred MIME Name", but have a 
note asking if I should instead be referencing "Name". These are 
references to column headings in the table in the registry, for lack of 
something better to reference. Looking again at the registry, I think I 
need instead to say:

OLD:

    The charset specified MUST be one of those registered with IANA, such
    as ISO-8859-1.  The character set identifier is a US-ASCII string and
    MUST be compared against the IANA identifiers using a case-
    insensitive comparison.  If the identifier is not recognised or not
    supported, all strings that are affected by it SHOULD be regarded as
    octet strings.

NEW:

    The charset specified MUST be one of those registered in the IANA
    Character Sets registry
    (http://www.iana.org/assignments/character-sets), such
    as ISO-8859-1.  The character set identifier is a US-ASCII string and
    MUST be compared against identifiers from the "Name" or "Preferred
    MIME Name" field of the registry using a case-insensitive
    comparison.  If the identifier is not recognised or not supported,
    all strings that are affected by it SHOULD be regarded as octet
    strings.

I think this is needed because the identifiers in the "Preferred MIME 
Name" field are not repeated in the "Name" field, but both are allowed 
to be used in references.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 03 Dec 2014 13:29:47 -0500

> The payload type is a 7-bit field in the RTP header, so definitely cannot be outside this range. Writing this in the text makes sense.

ok

> This list hasn’t changed in RFC 2327 in 1998. I think it’s safe to leave updates to a future revision of this document.

ok

> Hence, this is case significant.

That is how I have the syntax written now.
So I'll leave it that way unless I get some other strong argument to 
change it.

> Why not reference the correct ABNF from RFC 2978? I don’t understand the desire to put something incorrect here.

I commented on this separately.

> Same answer. There’s already a standard ABNF syntax for these, and this document should refer to it rather than trying to define something new.

OK. I can do that.

> I always assumed fractional values were allowed, but you’d have to check with someone who’s implemented this.

I'm happy to do that if it isn't going to break anybody.

I *could* do it so that the fraction is only permitted if it is 
non-zero, as I proposed for another field. But that doesn't necessarily 
make things better if there are uses out there that include a zero 
fractional part.

> For RTP, you do know explicitly that the <format specific parameters> in the a=fmtp: line are MIME media subtype parameters, and need to conform to that syntax.

We aren't concerned with the <format specific parameters> here.
(The syntax of those is format specific.:-)

We are only concerned with the <fmt> parameter, which replicates one 
from the m-line.

For RTP m-lines this will always be an integer. But for the most part 
rtpmap is used instead of fmtp for RTP format specific parameters. There 
is text saying to use fmtp for codec-specific parameters. So I guess if 
fmtp is used with RTP then one would first need to use rtpmap to 
determine the codec, and then use rules defined by that codec to parse 
the format specific parameters.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 03 Dec 2014 13:32:16 -0500

> http://www.gwg.nga.mil/misb/docs/rp/RP1302.pdf

Interesting, and good to know.

	Thanks,
	Paul

---

From: Colin Perkins <[email-masked]>
Date: Thu, 4 Dec 2014 12:19:36 +0000

> On 12/1/14 6:39 PM, Colin Perkins wrote:
…snip…
> We are only concerned with the <fmt> parameter, which replicates one from the m-line.
> 
> For RTP m-lines this will always be an integer. But for the most part rtpmap is used instead of fmtp for RTP format specific parameters. There is text saying to use fmtp for codec-specific parameters. So I guess if fmtp is used with RTP then one would first need to use rtpmap to determine the codec, and then use rules defined by that codec to parse the format specific parameters.

RTP payload formats and their parameters are defined by a (MIME) media type registration. This registration includes a media type, subtype, and parameters. The media type (e.g., audio) goes in the <media> part of the m= line. The media subtype goes in the <encoding name> part of the a=rtpmap: line. The media parameters go in the <format specific parameters> part of the a=fmtp: line. This lets you specify a concrete ABNF for the <encoding name> and <format specific parameters> that is independent of the codec. 

-- 
Colin Perkins
https://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Thu, 4 Dec 2014 12:26:02 +0000

On 3 Dec 2014, at 18:07, Paul Kyzivat <[email-masked]> wrote:
> The final paragraph above seems to say that mime-charset only applies for charsets registered for use with "text", but based on the first paragraph this syntax could apply for all charset names.
> 
> And this syntax doesn't apply any limit to how long the names can be, while the IANA registry itself says:
> 
> Note also that I currently reference "Preferred MIME Name", but have a note asking if I should instead be referencing "Name". These are references to column headings in the table in the registry, for lack of something better to reference. Looking again at the registry, I think I need instead to say:
> 
> OLD:
> 
> I think this is needed because the identifiers in the "Preferred MIME Name" field are not repeated in the "Name" field, but both are allowed to be used in references.

I expect the charset community has common practices in this area. It might be worth asking the designated expert for the registry what’s the preferred field to match on, and how to reference the name syntax. Alternatively, the APPS area director can likely suggest a reviewer who can advise on the right thing to do.

-- 
Colin Perkins
https://csperkins.org/