Re: [MMUSIC] Comments on ABNF in 4566bis

[Paul Kyzivat <[e-mail]>]

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