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

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 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-19.html#rfc.section.2.5>:

"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 
"obs-*".

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