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

Re: question about implied LWS

From: Chris Newman <Chris.Newman@innosoft.com>
Date: Fri, 2 Oct 1998 21:14:40 +0100 (BST)
To: http-wg@hplb.hpl.hp.com
Cc: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>, "Jim Gettys (E-mail)" <jg@w3.org>
Message-Id: <Pine.SOL.3.95.981002125759.14822K-100000@elwood.innosoft.com>
On Tue, 29 Sep 1998, Paul Leach wrote:
> This seems to say that LWS is not allowed between adjacent quoted-strings.
> 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
> 
> 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.

I strongly recommend fixing this now.

RFC 822 is vague about where embedded linear-white-space can be inserted. 
There has been serious controversy in DRUMS about whether it's permitted
between the header field name and the ":", as well as if it's permitted
around the ":" in times or even between the digits.  In addition, many
clients deal poorly with the implicit whitespace between tokens. 
Technically, a media type of "text(hi) / (there) plain" is perfectly legal
in email and has to be interpreted as "text/plain".  This often doesn't
work in practice.

The DRUMS WG chose to drop the concept of implicit linear-white-space and
make it all explicit in the grammar, as well as to deprecate the use of
comments and/or whitespace in stupid places so the "generate" grammer
better matches reality.  The HTTP WG obviously doesn't have time to
rewrite the BNF, so making sure it's as clear as possible could save pain
and interoperability problems in the future.  Paul's suggestion is an
excellent step in the right direction.

		- Chris
Received on Tuesday, 6 October 1998 13:16:03 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:24 EDT