Subject: [sipcore] ABNF discussion on draft-ietf-subnot-etags

From: Dean Willis <[email-masked]>
Date: Tue, 21 Apr 2009 17:19:16 -0500

I'm looking at the proto writeup for subnot-etags, and doing the  
required validation of the ABNF using BAP.  I'm not Mr. Grammar  
(lately, even simple English escapes me), so double-check me please.

The draft says:

Suppress-If-Match   =  "Suppress-If-Match" ":" entity-tag / "*"

BAP canonicalizes this to:

Suppress-If-Match =  ( "Suppress-If-Match:" entity-tag ) / "*"
Note the added parentheses.

AFAIK, this is effectively a null-op; the canonical ABNF is equivalent  
to the original. But sometimes the priority of ABNF operators escapes  
me, hence I ask:  Anybody disagree?

Now for a matter of style: Would it be better to have the draft use  
the canonical form, since it relieves this poor reader's ambiguity?

Side note: BAP is cool!

See: http://tools.ietf.org/tools/bap/abnf.cgi
--
Dean

---

From: "Scott Lawrence" <[email-masked]>
Date: Tue, 21 Apr 2009 19:13:13 -0400

> me, hence I ask:  Anybody disagree?

I believe they are equivalent.

> the canonical form, since it relieves this poor reader's ambiguity?

I think that the draft form is clearer in the context of the existing
body of SIP specs, since that's the way all other header fields are
specified.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Apr 2009 19:13:49 -0400

Dean Willis wrote:
> required validation of the ABNF using BAP.  I'm not Mr. Grammar (lately, 
> even simple English escapes me), so double-check me please.
> 
> 
> The draft says:
> 

> me, hence I ask:  Anybody disagree?

I believe the cannonicalization is "correct" in that the two statements 
have the same meaning according to the rules of ABNF.

BUT, I think this exposes an error in the original text. I'm pretty sure 
what was intended was:

Suppress-If-Match =  "Suppress-If-Match:" ( entity-tag / "*" )

	Thanks,
	Paul

> Now for a matter of style: Would it be better to have the draft use the 
> canonical form, since it relieves this poor reader's ambiguity?
> 
> Side note: BAP is cool!
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Hisham Khartabil <[email-masked]>
Date: Wed, 22 Apr 2009 09:26:52 +1000

Don't the brackets make whatever is inside them optioanl?

2009/4/22 Paul Kyzivat <[email-masked]>:
>
>
> Dean Willis wrote:
>>
>> I'm looking at the proto writeup for subnot-etags, and doing the required
>> validation of the ABNF using BAP.  I'm not Mr. Grammar (lately, even simple
>> English escapes me), so double-check me please.
>>
>>
>> The draft says:
>>
>> AFAIK, this is effectively a null-op; the canonical ABNF is equivalent to
>> the original. But sometimes the priority of ABNF operators escapes me, hence
>> I ask:  Anybody disagree?
>
> I believe the cannonicalization is "correct" in that the two statements have
> the same meaning according to the rules of ABNF.
>

---

From: Tom Taylor <[email-masked]>
Date: Tue, 21 Apr 2009 19:36:19 -0400

Round brackets just group. Square brackets show options.

And I'd say Paul is right about the intent of the expression. A header field 
with no name, just an asterisk, as allowed by the current ABNF, won't parse in SIP.

---

From: Dean Willis <[email-masked]>
Date: Tue, 21 Apr 2009 20:47:25 -0500

On Apr 21, 2009, at 6:13 PM, Paul Kyzivat wrote:

>> AFAIK, this is effectively a null-op; the canonical ABNF is  
>> equivalent to the original. But sometimes the priority of ABNF  
>> operators escapes me, hence I ask:  Anybody disagree?
>
> I believe the cannonicalization is "correct" in that the two  
> statements have the same meaning according to the rules of ABNF.
>
> BUT, I think this exposes an error in the original text. I'm pretty  
> sure what was intended was:
>

Ok, from the canonical suggested by BAP, we could produce:

Suppress-If-Match:a34e56

or we could produce

*

and as Tom points out, a * by itself is not much use.

We WANT to be able to produce:

Suppress-If-Match:a34e56

or

Suppress-If-Match:*

So I think the proposed grammar as written by Paul here is right, the  
canonicalization proposed by BAP is wrong, and the original grammar is  
misleading as it reading it requires a specific understanding of ABNF  
operator scoping that isn't shared by BAP. Maybe BAP's scoping rules  
are wrong, or maybe Scott's and mine are wrong, but we don't benefit  
from the ambiguity when a more definitive syntax is available.

--
Dean

---

From: Adam Roach <[email-masked]>
Date: Tue, 21 Apr 2009 21:24:56 -0500

> Don't the brackets make whatever is inside them optioanl?

You're thinking of the *(foo) construct we use a lot in SIP, which means 
"one or more of foo". Without the "*", the parentheses are just a 
grouping operator.

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 21 Apr 2009 21:29:10 -0500

Adam Roach wrote:
> You're thinking of the *(foo) construct we use a lot in SIP, which 
> means "one or more of foo". Without the "*", the parentheses are just 
> a grouping operator.
>

Gack. I meant "zero or more of foo", not "one or more of foo". I clearly 
need to get to sleep now.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Apr 2009 09:01:46 -0400

I just took another look, because this ABNF still looked a bit odd.

To be consistent with the way other headers are defined in 3261, it 
ought to be specified as:

Suppress-If-Match =  "Suppress-If-Match" HCOLON ( entity-tag / "*" )

The difference being the treatment of whitespace.

While some think the allowance of whitespace in 3261 is more liberal 
than necessary, IMO its unwise to alter this piecemeal. Consistency 
across headers is important, so that generalized parsers can be 
constructed. If you don't make this change, then

	Suppress-If_Match:*

will be parsed as a suppress-if-match header, while

	Suppress-If_Match :*
	Suppress-If_Match: *
	Suppress-If_Match : *

Will all also be "valid" but parsed as 'extention-header'.

	Thanks,
	Paul

Dean Willis wrote:
> operator scoping that isn't shared by BAP. Maybe BAP's scoping rules are 
> wrong, or maybe Scott's and mine are wrong, but we don't benefit from 
> the ambiguity when a more definitive syntax is available.
> 
> -- 
> Dean
>

---

From: Adam Roach <[email-masked]>
Date: Wed, 22 Apr 2009 09:43:08 -0500

I agree with Paul.

/a

Paul Kyzivat wrote:
>> canonicalization proposed by BAP is wrong, and the original grammar 
>> is misleading as it reading it requires a specific understanding of 
>> ABNF operator scoping that isn't shared by BAP. Maybe BAP's scoping 
>> rules are wrong, or maybe Scott's and mine are wrong, but we don't 
>> benefit from the ambiguity when a more definitive syntax is available.
>>
>> -- 
>> Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 22 Apr 2009 14:10:12 -0500

> Will all also be "valid" but parsed as 'extention-header'.

Huh. According to the (evidently flawed) SIP parser in my head,  
"Suppress-If-Match      :*" is broken. But that goes to the  
excessively liberal treatment of whitespace in RFC 3261. I'll add  
HCOLON in -02.

--
Dean

---

From: "Dale Worley" <[email-masked]>
Date: Wed, 29 Apr 2009 17:49:02 -0400

> from the ambiguity when a more definitive syntax is available.

Uh, what?  The precedence rules for IETF ABNF are quite clearly spelled
out in section 10 of RFC 5234:

        3.10.  Operator Precedence
        
           The various mechanisms described above have the following precedence,
           from highest (binding tightest) at the top, to lowest (loosest) at
           the bottom:
        
              Rule name, prose-val, Terminal value
        
              Comment
        
              Value range
        
              Repetition
        
              Grouping, Optional
        
              Concatenation
        
              Alternative
        
           Use of the alternative operator, freely mixed with concatenations,
           can be confusing.
        
Indeed, in every ABNF notation that I've ever seen, concatenation binds
tighter than alternation.

Relative to what we intend, the original ABNF is wrong and needs to be
fixed.

Dale

---

From: Dean Willis <[email-masked]>
Date: Wed, 29 Apr 2009 21:30:48 -0500

> Relative to what we intend, the original ABNF is wrong and needs to be

That's what I was trying to say in a friendlier way . . .

--
Dean