W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 1998

Fwd: question about implied LWS

From: Jim Gettys <jg@pa.dec.com>
Date: Tue, 3 Nov 1998 11:21:40 -0800
Message-Id: <9811031921.AA30204@pachyderm.pa.dec.com>
To: http-wg@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/140
This should have gone to the mailing list, but didn't.

Seems like a simpler solution.
				- Jim

> From: Paul Leach <paulle@microsoft.com>
> Date: Mon, 5 Oct 1998 11:28:03 -0700
> To: "Roy Fielding (E-mail)" <fielding@avron.ics.uci.edu>
> Cc: "Jim Gettys (E-mail)" <jg@w3.org>
> Subject: FW: FW: question about implied LWS
> -----
> Despite the fact that I didn't ask the question I intended to ask (whicy was
> whether LWS is allowed between quoted-strings and separators) you answered
> the question I intended to ask.
> 
> Looking at my suggestion again, I think a simpler fix is to change the
> underlined instance of "tokens" in the paragraph below to "words".
> 
> implied *LWS
> The grammar described by this specification is word-based. Except where
> noted otherwise, linear white space (LWS) can be included between any two
> adjacent words (token or quoted-string), and between adjacent tokens and
>                                                               ======
> separators, without changing the interpretation of a field. At least one
> delimiter (LWS and/or separators) MUST exist between any two tokens (for the
> definition of "token" below), since they would otherwise be interpreted as a
> single token.
> 
> Jim, can you mark this as an editorial issue?
> 
> -----Original Message-----
> From: Roy T. Fielding [mailto:fielding@kiwi.ics.uci.edu]
> Sent: Saturday, October 03, 1998 11:11 PM
> To: Paul Leach
> Subject: Re: FW: question about implied LWS
> 
> >Section 2.2 on "basic rules" says:
> >
> >implied *LWS
> >The grammar described by this specification is word-based. Except where
> >noted otherwise, linear white space (LWS) can be included between any two
> >adjacent words (token or quoted-string), and between adjacent tokens and
> >separators, without changing the interpretation of a field. At least one
> >delimiter (LWS and/or separators) MUST exist between any two tokens (for
> the
> >definition of "token" below), since they would otherwise be interpreted as
> a
> >single token.
> >
> >This seems to say that LWS is not allowed between adjacent quoted-strings.
> 
> Adjacent quoted-strings are adjacent words, so it doesn't say that.
> 
> >Was that intended? I assume not, but I could be wrong.
> >
> >If not, I think it would be clearer to add the following production to the
> >basic rules
> >	word = token | quoted-string | separator
> >and then change the section on implied LWS to say
> 
> That adds a rule saying you can put LWS between quoted strings and
> separators.
> AFAIK that is okay too, since everywhere that actually restricts LWS
> should be specific about restricting it.
> 
> >implied *LWS
> >The grammar described by this specification is word-based. Except where
> >noted otherwise, linear white space (LWS) can be included between any two
> >adjacent words (see below for the definition of "word") without changing
> the
> >interpretation of a field. At least one delimiter (LWS and/or separators)
> >MUST exist between any two tokens (for the definition of "token" below),
> >since they would otherwise be interpreted as a single token.
> 
> Fine with me.
> 
> ....Roy

attached mail follows:


Despite the fact that I didn't ask the question I intended to ask (whicy was
whether LWS is allowed between quoted-strings and separators) you answered
the question I intended to ask.

Looking at my suggestion again, I think a simpler fix is to change the
underlined instance of "tokens" in the paragraph below to "words".

implied *LWS
The grammar described by this specification is word-based. Except where
noted otherwise, linear white space (LWS) can be included between any two
adjacent words (token or quoted-string), and between adjacent tokens and
                                                              ======
separators, without changing the interpretation of a field. At least one
delimiter (LWS and/or separators) MUST exist between any two tokens (for the
definition of "token" below), since they would otherwise be interpreted as a
single token.

Jim, can you mark this as an editorial issue?

-----Original Message-----
From: Roy T. Fielding [mailto:fielding@kiwi.ics.uci.edu] 
Sent: Saturday, October 03, 1998 11:11 PM
To: Paul Leach
Subject: Re: FW: question about implied LWS 


>Section 2.2 on "basic rules" says:
>
>implied *LWS
>The grammar described by this specification is word-based. Except where
>noted otherwise, linear white space (LWS) can be included between any two
>adjacent words (token or quoted-string), and between adjacent tokens and
>separators, without changing the interpretation of a field. At least one
>delimiter (LWS and/or separators) MUST exist between any two tokens (for
the
>definition of "token" below), since they would otherwise be interpreted as
a
>single token. 
>
>This seems to say that LWS is not allowed between adjacent quoted-strings.

Adjacent quoted-strings are adjacent words, so it doesn't say that.

>Was that intended? I assume not, but I could be wrong.
>
>If not, I think it would be clearer to add the following production to the
>basic rules
>	word = token | quoted-string | separator
>and then change the section on implied LWS to say

That adds a rule saying you can put LWS between quoted strings and
separators.
AFAIK that is okay too, since everywhere that actually restricts LWS
should be specific about restricting it.

>implied *LWS
>The grammar described by this specification is word-based. Except where
>noted otherwise, linear white space (LWS) can be included between any two
>adjacent words (see below for the definition of "word") without changing
the
>interpretation of a field. At least one delimiter (LWS and/or separators)
>MUST exist between any two tokens (for the definition of "token" below),
>since they would otherwise be interpreted as a single token.

Fine with me.

....Roy
Received on Tuesday, 3 November 1998 11:23:54 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:05 UTC