Subject: draft-ietf-httpbis-p1-messaging-16 1.2.1 ABNF Extension: #rule – Invalid example?

From: Håkan <[email-masked]>
Date: Tue, 25 Oct 2011 22:19:13 +0200

Hi.

I'm new to all this, so I'm sorry if I'm not following protocol (not sure if
I should open an Issue Ticket or start by mailing the group first)

I've found examples that do not add up in p1-messaging 1.2.1.  ABNF
Extension: #rule

>   For compatibility with legacy list rules, recipients SHOULD accept
>   empty list elements.  In other words, consumers would follow the list
>   productions:
>
>     #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ]
>
>     1#element => *( "," OWS ) element *( OWS "," [ OWS element ] )
...
>  For example, given these ABNF productions:
>
>     example-list      = 1#example-list-elmt
>     example-list-elmt = token ; see Section 3.2.3
>
>   Then these are valid values for example-list (not including the
>   double quotes, which are present for delimitation only):
>
>     "foo,bar"
>     " foo ,bar,"
>     "  foo , ,bar,charlie   "
>     "foo ,bar,   charlie "

token is defined as 1*tchar and tchar is one character from a set of visible
character. Since space is not a tchar, token cannot contain a space.

In the second example " foo, bar,", since token cannot contain spaces, I
cant see how a space can be the first character. Given that I've read the
ABNF correctly, the only allowable first character is "," or a tchar. The
only way a space can come before token is if it's following a comma ",". So
this would be valid: ", foo ,bar,"
The same problem exists in example 3 as well,

If we look at example 3 and example 4 they end with spaces. That's not
allowed. According to the rules they may only end on a tchar or ",".

I'm guessing the rules are correct, so the first and last spaces in example
2-4 should be removed.
     "foo,bar"
     "foo ,bar,"
     "foo , ,bar,charlie"
     "foo ,bar,   charlie"

I hope I didn't get this completely wrong.

Håkan Canberger

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 26 Oct 2011 09:51:05 +1100

Hi Håkan,

Sending an e-mail to the list is fine. Our resident ABNF experts will have a look and get back to you as soon as possible. Thanks for taking the time to send feedback.

Cheers,

On 26/10/2011, at 7:19 AM, Håkan wrote:

> Hi.
> 
> I'm new to all this, so I'm sorry if I'm not following protocol (not sure if I should open an Issue Ticket or start by mailing the group first)
> 
> 
> I've found examples that do not add up in p1-messaging 1.2.1.  ABNF Extension: #rule
> 
> token is defined as 1*tchar and tchar is one character from a set of visible character. Since space is not a tchar, token cannot contain a space.
> 
> In the second example " foo, bar,", since token cannot contain spaces, I cant see how a space can be the first character. Given that I've read the ABNF correctly, the only allowable first character is "," or a tchar. The only way a space can come before token is if it's following a comma ",". So this would be valid: ", foo ,bar,"
> If we look at example 3 and example 4 they end with spaces. That's not allowed. According to the rules they may only end on a tchar or ",".
> 
> I'm guessing the rules are correct, so the first and last spaces in example 2-4 should be removed.
>      "foo,bar"
>      "foo ,bar,"
>      "foo , ,bar,charlie"
>      "foo ,bar,   charlie"
> 
> 

--
Mark Nottingham   http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Wed, 26 Oct 2011 10:35:28 +0200

> Hi.

Welcome to the Working Group.

> I'm new to all this, so I'm sorry if I'm not following protocol (not
> sure if I should open an Issue Ticket or start by mailing the group first)

Mailing to the list is the correct thing to do.

> token is defined as 1*tchar and tchar is one character from a set of
> visible character. Since space is not a tchar, token cannot contain a space.

Yes.

> cant see how a space can be the first character. Given that I've read
> the ABNF correctly, the only allowable first character is "," or a
> tchar. The only way a space can come before token is if it's following a
> comma ",". So this would be valid: ", foo ,bar,"

No. SP isn't part of token, but it *is* part of OWS.

Best regards, Julian

---

From: Håkan <[email-masked]>
Date: Wed, 26 Oct 2011 14:12:04 +0200

>No. SP isn't part of token, but it *is* part of OWS.

Agree, but OWS do not start  #element or 1#element, hence a space cannot be
the first character.
And OWS cannot end a #element or 1#element so a space cannot be the last
character.

/Håkan

---

From: Julian Reschke <[email-masked]>
Date: Wed, 26 Oct 2011 14:21:27 +0200

On 2011-10-26 14:12, Håkan wrote:
> Agree, but OWS do not start  #element or 1#element, hence a space cannot
> be the first character.

Spaces aren't part of the elements, they are part of OWS which is 
allowed between the elements and the list separator.

Best regards, Julian

---

From: Håkan <[email-masked]>
Date: Wed, 26 Oct 2011 15:08:04 +0200

On Wed, Oct 26, 2011 at 14:21, Julian Reschke <[email-masked]> wrote:

> Spaces aren't part of the elements, they are part of OWS which is allowed
> between the elements and the list separator.
>
> Agree with that too. Spaces are allowed BETWEEN the elements and list
separator. But spaces are not allowed BEFORE the first list separator or
element, and spaces are not allowed AFTER the last list separator or
element, according to the list rules. But the example "  foo , ,bar,charlie
" states it's allowed.

The rules would have to look something like this to allow OWS before and
after (not a real attempt to produce correct rules, just to illustrate my
point):

#element => [  *OWS ( "," / element ) *( OWS "," [ OWS element ] ) *OWS ]
1#element => *OWS *( "," OWS ) element *( OWS "," [ OWS element ] ) *OWS

/Håkan

---

From: Julian Reschke <[email-masked]>
Date: Wed, 26 Oct 2011 15:17:25 +0200

On 2011-10-26 15:08, Håkan wrote:
> element, according to the list rules. But the example "  foo ,
> ,bar,charlie " states it's allowed.
>
> after (not a real attempt to produce correct rules, just to illustrate
> my point):
>

Ack.

Those are allowed because of the header-field ABNF:

   header-field   = field-name ":" OWS field-value BWS

...but I agree that the prose around the examples needs to say that...

Best regards, Julian

---

From: Håkan <[email-masked]>
Date: Wed, 26 Oct 2011 17:54:15 +0200

On Wed, Oct 26, 2011 at 15:17, Julian Reschke <[email-masked]> wrote:

> Either that or, in order to isolate the examples to lists only, remove the
prefix/suffix spaces in the examples. The 1.2.1 section is near the top of
the document, in a section that talks about syntax. Headers have not been
introduced and since headers are not needed to understand the syntax around
lists I think it only introduces unnecessary complexity to include headers.

So what's the next step? Open an issue?

/Håkan

---

From: Julian Reschke <[email-masked]>
Date: Wed, 26 Oct 2011 18:20:42 +0200

On 2011-10-26 17:54, Håkan wrote:
> ...
> Either that or, in order to isolate the examples to lists only, remove
> the prefix/suffix spaces in the examples. The 1.2.1 section is near the
> top of the document, in a section that talks about syntax. Headers have
> not been introduced and since headers are not needed to understand the
> syntax around lists I think it only introduces unnecessary complexity to
> include headers.
>

No, we don't need an issue for this; it's purely editorial and also on 
my TODO list already.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 27 Oct 2011 22:42:07 +0200

On 2011-10-26 17:54, Håkan wrote:
>
>
> On Wed, Oct 26, 2011 at 15:17, Julian Reschke <[email-masked]
> <mailto:[email-masked]>> wrote:
>

Right.

Fixed in <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1462>.

Thanks for the bug report.

Best regards, Julian