[http-state] cookie server conformance

Peter Saint-Andre <stpeter@stpeter.im> Thu, 27 January 2011 02:40 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: http-state@core3.amsl.com
Delivered-To: http-state@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BFDE3A6906 for <http-state@core3.amsl.com>; Wed, 26 Jan 2011 18:40:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.576
X-Spam-Level:
X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pi8nAm88rv62 for <http-state@core3.amsl.com>; Wed, 26 Jan 2011 18:40:47 -0800 (PST)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 316323A6898 for <http-state@ietf.org>; Wed, 26 Jan 2011 18:40:47 -0800 (PST)
Received: from squire.local (dsl-251-175.dynamic-dsl.frii.net [216.17.251.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 095EF400F6; Wed, 26 Jan 2011 20:00:05 -0700 (MST)
Message-ID: <4D40DBD3.6070603@stpeter.im>
Date: Wed, 26 Jan 2011 19:43:31 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: Discuss HTTP State Management Mechanism <http-state@ietf.org>, Robert Sparks <rjsparks@nostrum.com>
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms060903000909060505040400"
Subject: [http-state] cookie server conformance
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <http-state.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-state>
List-Post: <mailto:http-state@ietf.org>
List-Help: <mailto:http-state-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jan 2011 02:40:48 -0000

During IESG review, Robert Sparks posted the following DISCUSS regarding
draft-ietf-httpstate-cookie:

   In 4.1.1 (Syntax) - Why is the specification part of this proposed
   standard allowing implementations to  violate the grammar defined by
   this standard? The SHOULD NOT in the first paragraph of this section
   must be a MUST NOT. If the intent is to make sure clients are
   liberal in what they accept because existing servers may generate
   non-conformant grammar, just say that (and if possible, point to
   what they might need to expect). If the intent is to allow servers
   that are compliant to generate messages not covered by this grammar,
   then the grammar is incorrect. If that's the case, the grammar
   should be extended to  allow the alternate behavior and the
   document's prose can say that servers SHOULD NOT use those parts of
   the grammar.

We've had some discussion between Robert, Adam, Jeff, and me to clarify
Robert's concerns. In essence, Robert is concerned that it's merely
implicit that a compliant server MUST NOT generate cookies that don't
conform to the well-behaved profile defined in Section 4. He derives
this conclusion from two pieces of evidence...

First, Section 1 of verson -21 states:

   To maximize interoperability with user agents, servers SHOULD limit
   themselves to the well-behaved profile defined in Section 4 when
   generating cookies.

Second, Section 4 states:

   Servers SHOULD NOT send Set-Cookie headers that fail to conform to
   the following grammar:

Therefore, we can conclude that if a server sends a Set-Cookie header
that violates the grammar, then it is non-conforming. However, we don't
come right out and say that.

To address Robert's concern and to make the constraints more explicit
(it's often problematic to let such things remain implicit), in the
off-list thread with Robert I formulated some proposed text, which I'd
like to share with the working group...

First, I proposed that we could modify Section 1 as follows:

   Compliant servers MUST limit themselves to the well-behaved profile
   defined in Section 4 when generating cookies.

Second, I proposed that we could then simplify Section 4 as follows:

   This section describes the syntax and semantics of a well-behaved
   profile of the Cookie and Set-Cookie headers.

I think that's a bit cleaner because it's not subject to as much
interpretation. However, the change from SHOULD to MUST is not
insignificant, so I think it's something that the working group needs to
discuss.

Your feedback is welcome.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/