W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2012

#361: ABNF requirements for recipients [was: #307 untangle Cache-Control ABNF]

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 19 Jun 2012 09:57:13 +0200
Message-ID: <4FE030D9.1010709@gmx.de>
To: Mark Nottingham <mnot@mnot.net>
CC: HTTP Working Group <ietf-http-wg@w3.org>
On 2012-06-19 09:40, Mark Nottingham wrote:
> I think the underlying issue here is that we don't explicitly require recipients to be able to parse ABNF-conformant messages, even though we require senders to generate them.
> I've created <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/361> to track. One we figure that out, these details of #307 should become clear.
> ...

Thanks for that.

I believe that's a case where we started with something consistent 
(2616), and added a normative requirement (for the sending side) to 
clarify things, just to make the other case (recipients) less clear.

We currently have in 

"Senders MUST NOT generate protocol elements that do not match the 
grammar defined by the ABNF rules for those protocol elements.

Unless otherwise noted, recipients MAY attempt to recover a usable 
protocol element from an invalid construct. HTTP does not define 
specific error handling mechanisms except when they have a direct impact 
on security, since different applications of the protocol require 
different error handling strategies. For example, a Web browser might 
wish to transparently recover from a response where the Location header 
field doesn't parse according to the ABNF, whereas a systems control 
client might consider any form of error recovery to be dangerous."

So, for consistency, we should insert:

"Recipients MUST accept all protocol elements matching the ABNF rules 
defined for them."

Maybe we need "Unless otherwise noted" because of some special cases for 

We should also make the placement of this section consistent; in the 
other sections we have the equivalent text in Section 1.

Best regards, Julian
Received on Tuesday, 19 June 2012 07:57:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:02 UTC