Re: [MMUSIC] 4566bis outstanding issues

Trimming again.

On 7/7/14 12:16 PM, Ali C. Begen (abegen) wrote:
>
> On Jul 7, 2014, at 11:02 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
>
>> On 7/7/14 4:07 AM, Ali C. Begen (abegen) wrote:
>>> Hi Paul,
>>>
>>> OK, no one else seems to be paying attention to this. I have some comments inline and lets see whether we can reach an agreement:
>>
>> OK.
>>
>> I've trimmed to a few points to comment on...
>>
>>>>> On 6/6/14 5:19 PM, Ali C. Begen (abegen) wrote:
>>
>>>>>> 1) 4566bis needs to provide ABNF syntax for all of the attributes 4566 defined.
>>>>>> Comments: This was discussed again in a side meeting in London and there was not a consensus whether we actually needed this.
>>>>>
>>>>> IIRC the argument against doing this is that we might get it wrong.
>>>>>
>>>>> But IMO we should do it because if we can't get it right how can we expect readers to get it right?
>>>
>>> I personally don't wanna take on this task. It is a tedious task and I am not such an ABNF lover to get these definitions right. If you wanna volunteer, by all means, please do so.
>>
>> I'm willing to contribute to this, but won't have time until after the Toronto meeting.
>
> That is fine.
>
>> Also, I'm not intimately familiar with all of the attributes.
>
> Nobody is I am afraid.

There are a lots of people who at least *use* them, and so are familiar 
with them at that level. I don't "do" media, so when I'm trying to 
create examples I can get as far as "m=audio", and I know there should 
be an "a=rtpmap", but beyond that I need to find an example to copy.

>>> OK, this goes back to the issue #1. Personally, I suggest we do not define the abnfs for every sdp attribute in 4566, but then you have a good point. We can seek a format and provide a few good examples to show prospective authors.
>>>
>>> To do this, obviously as you said, we need to agree on that format. Has there been a proposal in the past or does anyone have a good proposal to start with?
>>
>> Not a formal one. There has been some discussion about this during review of individual attribute definitions. My take has been that there is not agreement.
>
> If you can recall, can you point us to that proposal and maybe briefly explain the disagreements as well?

I think it will take a lot of searching to find it. So I can't do so 
quickly/easily.

>> One question is whether the definition of a new attribute should:
>> 1) define the full syntax of the line (starting with "a="),
>> 2) should provide additional definitions of <attribute> (via "/=")
>> 3) should provide additional definitions of <att-field> and <att-value>
>>    (via "/=")
>> 4) provide definitions of the name and value that are consistent with
>>    <att-field> and <att-value> without formally extending the
>>    definitions of those.
>>
>> Note that 4566 loosely follows (4) but gives the definitions informally rather than via ABNF. So it gives no guidance on how to use ABNF for this. A number of drafts have chosen to follow (2). Some have started to do (1) but I don't know of any that ended up that way.
>>
>> A question I have raised is: if (2) or (3) is followed, does that mean that the draft doing so must be considered as "updating" 4566?
>
> I dont see why it should. Personally most of the attributes I defined followed (4). That seemed the easiest option.

I've been outnumbered on the discussions of this. ISTM that whenever I write

	attribute =/ something new

then I have at least extended the rfc that defines <attribute> and 
arguably have updated it. The reason it might be considered an update is 
that what I am defining implicitly includes the definition of 
<attribute> and thus probably all the abnf that includes the definition 
of <attribute>. To verify my new abnf, or to generate a parser, I need 
to create a combined abnf. And abnf doesn't have namespaces. So all the 
rulenames I newly define must be distinct from those defined with 
<attribute>.

And that is true for *every* extension. And for them to be compatible 
with one another they all must define rulenames that are unique among 
them all.

So effectively each one is an update.

It is subtly different if I follow (4), even if I use abnf to define the 
syntax for my new attribute, and even if I reuse rule definitions (like 
<token>) from the base sdp definition.

>> One thing that people sometimes forget when defining new attributes is that the syntax of the new attribute MUST also be valid when parsed by the "generic" attribute syntax. AFAIK there is no way in ABNF to specify that. I think that (4) comes closest.
>
> Yes, but this must be checked during the last call by actual humans not some abnf parser.

For now that is true. I have found such errors while doing SDP 
directorate reviews.

	Thanks,
	Paul

> -acbegen
>
>>
>> 	Thanks,
>> 	Paul
>>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>