Status of issue #30 (Implied LWS)

Based on list discussion and that in Dublin, the plan of record for  
closing issue #30 <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/ 
30> is:

   * Where it occurs, make implicit LWS in the BNF explicit
   * When doing so, discriminate between LWS that is allowed and "bad"  
or discouraged
   * Explicitly disallow LWS between header field-names and ":"

To this end, the editors have created a number of new BNF productions  
and associated text:

--->8---
All linear white space (LWS) in header field-values has the same  
semantics as SP. A recipient may replace any such linear white space  
with a single SP before interpreting the field value or forwarding the  
message downstream.
Historically, HTTP/1.1 header field values allow linear white space  
folding across multiple lines. However, this specification deprecates  
its use; senders must not produce messages that include LWS folding  
(i.e., use the obs-fold rule), except within the message/http media  
type (Section 9.3.1). Receivers should still parse folded linear white  
space.

This specification uses three rules to denote the use of linear white  
space; BWS ("Bad" White Space), OWS (Optional White Space), and RWS  
(Required White Space).

"Bad" white space is allowed by the BNF, but senders should not  
produce it in messages. Receivers must accept it in incoming messages.

Required white space is used when at least one linear white space  
character is required to separate field tokens. In all such cases, a  
single SP character should be used.

OWS            = *( [ obs-fold ] WSP )    ; "optional" white space
RWS            = 1*( [ obs-fold ] WSP )   ; "required" white space
BWS            = OWS                      ; "bad" white space
obs-fold       = CRLF
--->8---

The editors plan to have a draft incorporating these changes (as well  
as other ABNF-related changes) soon.


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

Received on Friday, 14 November 2008 00:45:53 UTC