Re: #409: is parsing OBS-FOLD mandatory?

On Dec 11, 2012, at 7:48 PM, Mark Nottingham wrote:

> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/409>
> 
> """
> p1 2.5 Conformance and Error Handling says "...recipient MUST be able to parse any value that would match the ABNF rules..." yet 3.2.2 only make parsing obs-fold a SHOULD. Which is it?
> """
> 
> Roy made a proposed edit to remove the MUST NOT generate and change the SHOULD parse to a MUST parse.
>  <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2039>

No, the text still says "Senders MUST NOT generate ...".  I only changed
the SHOULD parse to a MUST parse, because that was not part of the prior
decision and is inconsistent with the ABNF requirement below.

> However, this has the effect of un-deprecating line folding; IIRC we added those requirements because folding is not interoperable. 

No, it has the effect of requiring that line-folding be parsed, which
is required for backwards compatibility with 2616 senders.  However,
I do not personally know of any senders that send obs-fold.

> My suggestion would be to change:
> 
> """
> If a received protocol element is processed, the recipient must be able to parse any value that would match the ABNF rules for that protocol element, excluding only those rules not applicable to the recipient's role.
> """
> 
> to:
> 
> """
> If a received protocol element is processed, the recipient MUST be able to parse any value that would match the ABNF rules for that protocol element, excluding only those rules not applicable to the recipient's role, and those rules whose names begin with "obs-" (e.g., obs-fold).
> """

Do we really want to exclude non-ASCII octets (obs-text) and older
date formats (obs-date)?  Do we demote them to SHOULD or MAY?

This change is fine with me, but it is a hard break from retaining
compatibility and we need to be absolutely sure we want to do that.

....Roy

Received on Wednesday, 12 December 2012 18:18:57 UTC