Re: [sipcore] draft-barnes-sipcore-rfc4244bis

Francois Audet wrote:
> Dale, Paul,
> 
> Good catch.
> 
> The intent was not to impose an ordering requirement: the intent was
> to impose that the hi-index parameter be present.
> 
> Paul: in RFC4244 there was NO ordering requirement.

Yeah. Dale pointed that out. I just assumed it had been carried over.

> What we are trying to achieve with the ABNF is:
> 
> - No ordering requirement
> - There MUST be exactly ONE hi-index
> - There MUST be 0 or 1 hi-target parameter
> - There MUST be 0 or 1 hi-aor parameter
> - There MAY be any number of hi-extension

Its already a restriction that parameters (in general) may appear only 
once. It gets asked about from time to time. I forget where it says that.

So you might not even need to say it. Certainly most of the other header 
parameter syntaxes don't say it but clearly intend it.

But it probably would be helpful to put it in the text.

> I now see the current ABNF fails miserably to do this...
> But I don't think it's trivial to express in ABNF.

As I started to show, it is technically possible. But as Dale responded, 
and I generally agree, it does make the abnf complex. Also, once you 
introduce generic-param all bets are off, since syntactically you can 
match one occurrence against the explicit name and another occurrence 
against generic-param.

> So I think then that Dale's semantic is better, and we
> just need to clearly state that index must be present, and
> that there can be only 0 or 1 of each of hi-target and hi-aor.

I agree.

	Paul

>> -----Original Message-----
>> From: sipcore-bounces@ietf.org 
>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat
>> Sent: Thursday, July 02, 2009 11:40
>> To: Worley, Dale (BL60:9D30)
>> Cc: SIPCORE
>> Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis
>>
>> Dale,
>>
>> I agree with your concern about the BNF. A requirement about 
>> the ordering of the params is problematic.
>>
>> OTOH, this is a revision to an existing RFC which had that 
>> ordering requirement. Its possible that relaxing it might 
>> lead to interop problems.
>>
>> Perhaps the best one can do is put in a recommendation to 
>> make the index first.
>>
>> Regarding indicating that the index is required: it can be 
>> done in text, but it can also be done in the BNF, as follows:
>>
>>     History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry)
>>
>>     hi-entry = hi-targeted-to-uri hi-param-list
>>
>>     hi-targeted-to-uri = name-addr
>>
>>     hi-param-list = *(SEMI hi-option) SEMI hi-index *(hi-option)
>>
>>     hi-option = hi-target / hi-aor / hi-extension
>>
>>     hi-index = "index" EQUAL 1*DIGIT *("." 1*DIGIT)
>>
>>     hi-target = "rc" / "cc" / "mp" / "rt"
>>
>>     hi-aor = "aor"
>>
>>     hi-extension = generic-param
>>
>>
>> 	Thanks,
>> 	Paul
>>
>>
>> Dale Worley wrote:
>>> Regarding the BNF for the History-Info header (section 4.1 in the 
>>> draft version of -02):
>>>
>>> The current BNF requires that the "index" parameter appear 
>> immediately 
>>> after the URI, whereas other parameters appear after it:
>>>
>>>    History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry)
>>>
>>>    hi-entry = hi-targeted-to-uri SEMI hi-index *(SEMI hi-param)
>>>
>>>    hi-targeted-to-uri = name-addr
>>>
>>>    hi-index = "index" EQUAL 1*DIGIT *("." 1*DIGIT)
>>>
>>>    hi-param = hi-target/hi-aor/hi-extension
>>>
>>>    hi-target = "rc" / "cc" / "mp" / "rt"
>>>
>>>    hi-aor = "aor"
>>>
>>>    hi-extension = generic-param
>>>
>>> IMHO, this is not a good way to organize the grammar, as it 
>> makes it 
>>> difficult to generate hi-entry's with generic code (there 
>> needs to be 
>>> some way to constrain the "index" parameter to be first), 
>> and violates 
>>> the general rule that the order of parameters is not significant.
>>>
>>> I propose to adjust the BNF to:
>>>
>>>    History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry)
>>>
>>>    hi-entry = hi-targeted-to-uri *(SEMI hi-param)
>>>
>>>    hi-targeted-to-uri = name-addr
>>>
>>>    hi-param = hi-index / hi-target / hi-aor / hi-extension
>>>
>>>    hi-index = "index" EQUAL 1*DIGIT *("." 1*DIGIT)
>>>
>>>    hi-target = "rc" / "cc" / "mp" / "rt"
>>>
>>>    hi-aor = "aor"
>>>
>>>    hi-extension = generic-param
>>>
>>> Of course, the "index" parameter is still mandatory per the 
>> semantic 
>>> constraints listed earlier in section 4.1.
>>>
>>> I've also inserted into the hi-index BNF some spaces around the 
>>> instances of "/" for better readability.
>>>
>>> Dale
>>>
>>>
>>> _______________________________________________
>>> sipcore mailing list
>>> sipcore@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sipcore
>>>
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf.org
>> https://www.ietf.org/mailman/listinfo/sipcore
>>
> 