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

From: "Dale Worley" <[email-masked]>
Date: Thu, 02 Jul 2009 13:49:41 -0400

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 02 Jul 2009 14:39:45 -0400

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:

    hi-entry = hi-targeted-to-uri hi-param-list

    hi-param-list = *(SEMI hi-option) SEMI hi-index *(hi-option)

    hi-option = hi-target / hi-aor / hi-extension

    hi-aor = "aor"

	Thanks,
	Paul

Dale Worley wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: "Dale Worley" <[email-masked]>
Date: Tue, 07 Jul 2009 15:44:58 -0400

> requirement. Its possible that relaxing it might lead to interop problems.

Actually, I don't think that RFC 4244 has an ordering requirement.  Look
at the BNF in section 4.1:

          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-extension

          hi-index = "index" EQUAL 1*DIGIT *(DOT 1*DIGIT)

>     hi-extension = generic-param

IMHO, though that is possible, it is not a good idea.  In general,
implementations do not enforce such restrictions in the parser even when
it is possible to do so, so such BNF doesn't correspond closely to the
implementation.  And BNF like this is more complex, making it easier to
make errors in both the BNF and its implementation.  (E.g., the above
rule for "hi-param-list" is missing an instance of "SEMI".)

Dale

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 9 Jul 2009 16:30:10 -0500

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.

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

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

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.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] 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:
> 
> > Regarding the BNF for the History-Info header (section 4.1 in the 
> > draft version of -02):
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 09 Jul 2009 18:31:10 -0400

> Paul: in RFC4244 there was NO ordering requirement.

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

> - 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.

> 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.

> that there can be only 0 or 1 of each of hi-target and hi-aor.

I agree.

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 9 Jul 2009 18:39:18 -0500

Ok, cool: we have agreement.

I'll put a note to help the reader. 

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Thursday, July 09, 2009 15:31
> To: Audet, Francois (SC100:3055)
> Cc: Worley, Dale (BL60:9D30); SIPCORE; Barnes, Mary (RICH2:AR00)
> 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.
> 
> 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
> 
> ordering 
> >> 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:
> >>

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 11 Jul 2009 15:01:14 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul Kyzivat
> Sent: Thursday, July 09, 2009 6:31 PM
>

RFC 3261, section 7.3.1 on Header Field Format, Page 32:

   Even though an arbitrary number of parameter pairs may be attached to
   a header field value, any given parameter-name MUST NOT appear more
   than once.

-hadriel