From hbambas@mozilla.com Mon May 3 11:55:00 2010 Return-Path: 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 F28C23A697D for ; Mon, 3 May 2010 11:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.35 X-Spam-Level: ** X-Spam-Status: No, score=2.35 tagged_above=-999 required=5 tests=[BAYES_60=1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, HTML_MESSAGE=0.001] 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 CBTDDh+VOnz5 for ; Mon, 3 May 2010 11:54:58 -0700 (PDT) Received: from smtp2.vol.cz (smtp2.vol.cz [195.250.128.75]) by core3.amsl.com (Postfix) with ESMTP id 11A293A6886 for ; Mon, 3 May 2010 11:54:57 -0700 (PDT) Received: from [192.168.0.18] (a40-prg1-17-91.static.adsl.vol.cz [88.146.67.91]) by smtp.volny.cz (Postfix) with ESMTP id 04ECE28A2B for ; Mon, 3 May 2010 20:54:39 +0200 (CEST) Message-ID: <4BDF1BEF.6000701@mozilla.com> Date: Mon, 03 May 2010 20:54:39 +0200 From: Honza Bambas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2 MIME-Version: 1.0 To: http-state@ietf.org Content-Type: multipart/alternative; boundary="------------030604010807030604040407" X-Mailman-Approved-At: Mon, 03 May 2010 13:29:27 -0700 Subject: [http-state] Missing specification in RFC 2617, cannot use a user name nor a password in encoding different from ISO-8859-1 X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2010 18:56:30 -0000 This is a multi-part message in MIME format. --------------030604010807030604040407 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit There has been observed that many server appliances allow setup of user names and passwords with characters that cannot be represented with ISO-8859-1. Client implementations that have problems to communicate with such servers properly, obeying RFCs, because of missing specification of character encoding of a user name and a password in both 'basic' and 'digest' authentication scheme. Specially building of the Authorization header and its username= directive value and building of A1 string. As for the username= directive value: it is by definition a 'quoted-string' that is unable to carry any information about its character encoding. I have found any explicit information in RFC 2617 about a required character encoding for it. RFC 2047 encoding cannot be used because "an 'encoded-word' MUST NOT appear within a 'quoted-string'" per RFC 2047 and on the other hand, per RFC 2616, "words of *TEXT (which 'quoted-string' consist of) MAY contain characters from character sets other than ISO-8859-1 only when encoded according to the rules of RFC 2047". A dead end. As for A1 value: it's not said anywhere in what byte representation the user name, password and realm should be read when establishing the A1 octet array. The same problem applies to basic authentication where a base64 string is built to carry the username:password pair, but it is not said anywhere in what character encoding or generally an encoding the source for base64 has to be. For example of violation: Apache configuration utility program for configuring digest authentication database is taking the user name and the password directly as an argument from a terminal, in, often but not generally, UTF-8 encoding, pushing it to a hash function directly without any further translation. The client side then should build A1 string on it's side from UTF-8 encoded octet arrays. The authentication mod seems to take the usename= directive value, used to create the A1 string, "as is", in a byte representation sent by the client. But, there is no way for the client to know, what encoding should be used when generating the headers. My question is: should we disallow acceptance of a user name or password input in encoding different from ISO-8859-1 on the client side (independently on a server being setup for it, in any way) or should there be defined an extension to RFC 2617 allowing communication of the encoding between the client and the server? For reference there are Mozilla platform bugs https://bugzilla.mozilla.org/show_bug.cgi?id=546330 and https://bugzilla.mozilla.org/show_bug.cgi?id=41489. Sincerely, Honza Bambas --------------030604010807030604040407 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit There has been observed that many server appliances allow setup of user names and passwords with characters that cannot be represented with ISO-8859-1.  Client implementations that have problems to communicate with such servers properly, obeying RFCs, because of missing specification of character encoding of a user name and a password in both 'basic' and 'digest' authentication scheme.  Specially building of the Authorization header and its username= directive value and building of A1 string.

As for the username= directive value: it is by definition a 'quoted-string' that is unable to carry any information about its character encoding.  I have found any explicit information in RFC 2617 about a required character encoding for it.  RFC 2047 encoding cannot be used because "an 'encoded-word' MUST NOT appear within a 'quoted-string'" per RFC 2047 and on the other hand, per RFC 2616, "words of *TEXT (which 'quoted-string' consist of) MAY contain characters from character sets other than ISO-8859-1 only when encoded according to the rules of RFC 2047".  A dead end.

As for A1 value: it's not said anywhere in what byte representation the user name, password and realm should be read when establishing the A1 octet array.  The same problem applies to basic authentication where a base64 string is built to carry the username:password pair, but it is not said anywhere in what character encoding or generally an encoding the source for base64 has to be.

For example of violation: Apache configuration utility program for configuring digest authentication database is taking the user name and the password directly as an argument from a terminal, in, often but not generally, UTF-8 encoding, pushing it to a hash function directly without any further translation.  The client side then should build A1 string on it's side from UTF-8 encoded octet arrays.  The authentication mod seems to take the usename= directive value, used to create the A1 string, "as is", in a byte representation sent by the client.  But, there is no way for the client to know, what encoding should be used when generating the headers.


My question is: should we disallow acceptance of a user name or password input in encoding different from ISO-8859-1 on the client side (independently on a server being setup for it, in any way) or should there be defined an extension to RFC 2617 allowing communication of the encoding between the client and the server?

For reference there are Mozilla platform bugs https://bugzilla.mozilla.org/show_bug.cgi?id=546330 and https://bugzilla.mozilla.org/show_bug.cgi?id=41489.

Sincerely,
Honza Bambas

--------------030604010807030604040407-- From ietf@adambarth.com Mon May 3 14:19:32 2010 Return-Path: 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 A75F13A693F for ; Mon, 3 May 2010 14:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[AWL=-0.627, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 iGG60lTN2N1N for ; Mon, 3 May 2010 14:19:31 -0700 (PDT) Received: from mail-ew0-f178.google.com (mail-ew0-f178.google.com [209.85.219.178]) by core3.amsl.com (Postfix) with ESMTP id 51A5F3A695A for ; Mon, 3 May 2010 14:19:30 -0700 (PDT) Received: by ewy26 with SMTP id 26so223167ewy.13 for ; Mon, 03 May 2010 14:19:12 -0700 (PDT) Received: by 10.213.70.205 with SMTP id e13mr2816282ebj.84.1272921551871; Mon, 03 May 2010 14:19:11 -0700 (PDT) Received: from mail-iw0-f187.google.com (mail-iw0-f187.google.com [209.85.223.187]) by mx.google.com with ESMTPS id 15sm3282639ewy.0.2010.05.03.14.19.09 (version=SSLv3 cipher=RC4-MD5); Mon, 03 May 2010 14:19:11 -0700 (PDT) Received: by iwn17 with SMTP id 17so161711iwn.19 for ; Mon, 03 May 2010 14:19:07 -0700 (PDT) Received: by 10.231.190.138 with SMTP id di10mr3556254ibb.48.1272921547774; Mon, 03 May 2010 14:19:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.79.207 with HTTP; Mon, 3 May 2010 14:12:11 -0700 (PDT) In-Reply-To: <4BDF1BEF.6000701@mozilla.com> References: <4BDF1BEF.6000701@mozilla.com> From: Adam Barth Date: Mon, 3 May 2010 14:12:11 -0700 Message-ID: To: Honza Bambas Content-Type: multipart/alternative; boundary=0016367b6ceaae9fc80485b724c4 Cc: http-state@ietf.org Subject: Re: [http-state] Missing specification in RFC 2617, cannot use a user name nor a password in encoding different from ISO-8859-1 X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2010 21:19:32 -0000 --0016367b6ceaae9fc80485b724c4 Content-Type: text/plain; charset=ISO-8859-1 Hi Honza, Thanks for your message, but I think you might have meant to send it to another mailing list. Perhaps ietf-http-wg@w3.org? This working group is about cookies, not about HTTP authentication. Kind regards, Adam On Mon, May 3, 2010 at 11:54 AM, Honza Bambas wrote: > There has been observed that many server appliances allow setup of user > names and passwords with characters that cannot be represented with > ISO-8859-1. Client implementations that have problems to communicate with > such servers properly, obeying RFCs, because of missing specification of > character encoding of a user name and a password in both 'basic' and > 'digest' authentication scheme. Specially building of the Authorization > header and its username= directive value and building of A1 string. > > As for the username= directive value: it is by definition a 'quoted-string' > that is unable to carry any information about its character encoding. I > have found any explicit information in RFC 2617 about a required character > encoding for it. RFC 2047 encoding cannot be used because "an > 'encoded-word' MUST NOT appear within a 'quoted-string'" per RFC 2047 and on > the other hand, per RFC 2616, "words of *TEXT (which 'quoted-string' > consist of) MAY contain characters from character sets other than ISO-8859-1 > only when encoded according to the rules of RFC 2047". A dead end. > > As for A1 value: it's not said anywhere in what byte representation the > user name, password and realm should be read when establishing the A1 octet > array. The same problem applies to basic authentication where a base64 > string is built to carry the username:password pair, but it is not said > anywhere in what character encoding or generally an encoding the source for > base64 has to be. > > For example of violation: Apache configuration utility program for > configuring digest authentication database is taking the user name and the > password directly as an argument from a terminal, in, often but not > generally, UTF-8 encoding, pushing it to a hash function directly without > any further translation. The client side then should build A1 string on > it's side from UTF-8 encoded octet arrays. The authentication mod seems to > take the usename= directive value, used to create the A1 string, "as is", in > a byte representation sent by the client. But, there is no way for the > client to know, what encoding should be used when generating the headers. > > > My question is: should we disallow acceptance of a user name or password > input in encoding different from ISO-8859-1 on the client side > (independently on a server being setup for it, in any way) or should there > be defined an extension to RFC 2617 allowing communication of the encoding > between the client and the server? > > For reference there are Mozilla platform bugs > https://bugzilla.mozilla.org/show_bug.cgi?id=546330 and > https://bugzilla.mozilla.org/show_bug.cgi?id=41489. > > Sincerely, > Honza Bambas > > > _______________________________________________ > http-state mailing list > http-state@ietf.org > https://www.ietf.org/mailman/listinfo/http-state > > --0016367b6ceaae9fc80485b724c4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Honza,

Thanks for your message, but I thin= k you might have meant to send it to another mailing list. =A0Perhaps=A0ietf-http-wg@w3.org? =A0This workin= g group is about cookies, not about HTTP authentication.

Kind regards,
Adam


On Mon, May 3, 2010 at 11:54 AM, Honza Bambas <hbambas@mozilla.co= m> wrote:
=20
There has been observed that many server appliances allow setup of user names and passwords with characters that cannot be represented with ISO-8859-1.=A0 Client implementations that have problems to communicate with such servers properly, obeying RFCs, because of missing specification of character encoding of a user name and a password in both 'basic' and 'digest' aut= hentication scheme.=A0 Specially building of the Authorization header and its username=3D directive value and building of A1 string.

As for the username=3D directive value: it is by definition a 'quoted-string' that is unable to carry any information about its character encoding.=A0 I have found any explicit information in RFC 2617 about a required character encoding for it.=A0 RFC 2047 encoding cannot be used because "an 'encoded-word' MUST NOT appear within a 'quote= d-string'" per RFC 2047 and on the other hand, per RFC 2616, "words<= /span> of *TEXT (which 'quoted-string' consist of) MAY contain characters = from character sets other than ISO-8859-1 only when encoded according to the rules of RFC 2047".=A0 A dead end.

As for A1 value: it's not said anywhere in what byte representation the user name, password and realm should be read when establishing the A1 octet array.=A0 The same problem applies to basic authentication where a base64 string is built to carry the username:password pair, but it is not said anywhere in what character encoding or generally an encoding the source for base64 has to be.

For example of violation: Apache configuration utility program for configuring digest authentication database is taking the user name and the password directly as an argument from a terminal, in, often but not generally, UTF-8 encoding, pushing it to a hash function directly without any further translation.=A0 The client side then should build A1 string on it's side from UTF-8 encoded octet arrays.=A0 The authentication mod seems to take the usename=3D directive value, used to create the A1 string, "as is&q= uot;, in a byte representation sent by the client.=A0 But, there is no way for the client to know, what encoding should be used when generating the headers.


My question is: should we disallow acceptance of a user name or password input in encoding different from ISO-8859-1 on the client side (independently on a server being setup for it, in any way) or should there be defined an extension to RFC 2617 allowing communication of the encoding between the client and the server?

For reference there are Mozilla platform bugs https://bugzilla.mozilla.org/show_bug.cgi?id=3D546330 and https://bugzilla.mozilla.org/show_bug.cgi?id=3D41489.

Sincerely,
Honza Bambas


_______________________________________________
http-state mailing list
http-state@ietf.org
https://www.ietf.org/mailman/listinfo/http-state


--0016367b6ceaae9fc80485b724c4-- From julian.reschke@gmx.de Mon May 3 23:58:25 2010 Return-Path: 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 259533A6927 for ; Mon, 3 May 2010 23:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.128 X-Spam-Level: X-Spam-Status: No, score=-2.128 tagged_above=-999 required=5 tests=[AWL=-2.129, BAYES_50=0.001] 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 umZCS1jqxkiX for ; Mon, 3 May 2010 23:58:24 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id B61F83A6A7F for ; Mon, 3 May 2010 23:58:20 -0700 (PDT) Received: (qmail invoked by alias); 04 May 2010 06:58:02 -0000 Received: from p508FD9F6.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.217.246] by mail.gmx.net (mp014) with SMTP; 04 May 2010 08:58:02 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/SjeosIV/SDUc03UxtdGN3AY6opT2sEbsLiWOdL6 vX7ROMiGQVmpz9 Message-ID: <4BDFC569.7070900@gmx.de> Date: Tue, 04 May 2010 08:57:45 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Adam Barth References: <4BDF1BEF.6000701@mozilla.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Honza Bambas , HTTP Working Group , http-state@ietf.org Subject: Re: [http-state] Missing specification in RFC 2617, cannot use a user name nor a password in encoding different from ISO-8859-1 X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 06:58:25 -0000 On 03.05.2010 23:12, Adam Barth wrote: > Hi Honza, > > Thanks for your message, but I think you might have meant to send it to > another mailing list. Perhaps ietf-http-wg@w3.org > ? This working group is about cookies, not > about HTTP authentication. > > Kind regards, > Adam > ... The HTTPbis WG isn't revising the scheme definitions of RFC 2617 (at this point); but of course it's fine to discuss auth related issues on that mailing list. This topic comes up every now and then (lately in Mozilla and Chromium bugs). As far as I understand, Basic authentication *could* be improved by adding a new auth-param, selecting a preferred encoding. In theory, this could be deployed in a backwards-compatible way; old clients will (well, should) just ignore it, new clients can switch to a different encoding. What's needed is a spec, plus volunteers to implement this in at least one server framework and a few UAs. Best regards, Julian From Jeff.Hodges@KingsMountain.com Sat May 8 16:01:17 2010 Return-Path: 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 0C7CE3A67EC for ; Sat, 8 May 2010 16:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.181 X-Spam-Level: X-Spam-Status: No, score=0.181 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] 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 CHIN3T45+6lZ for ; Sat, 8 May 2010 16:01:16 -0700 (PDT) Received: from outbound-mail-313.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id 0F2DB3A67D3 for ; Sat, 8 May 2010 16:01:15 -0700 (PDT) Received: (qmail 23602 invoked by uid 0); 8 May 2010 23:01:04 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 8 May 2010 23:01:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=vrvWgSo/1eBmll+0HR9e9yffeD/MeJ3KyFHDIFdqwQJO05V5z/hFH7Y3sOusn+rv1ZQ7mq6Xsl8rl4FBamqtj26+YgSuCNeB2Ry8fgT+N74LA3KmP0lRLo2G0IgbYB02; Received: from c-67-161-32-29.hsd1.ca.comcast.net ([67.161.32.29] helo=[192.168.11.11]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OAt15-0000Sk-Vd; Sat, 08 May 2010 17:01:04 -0600 Message-ID: <4BE5ED2D.8050303@KingsMountain.com> Date: Sat, 08 May 2010 16:01:01 -0700 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Peter Saint-Andre , IETF HTTP State WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 67.161.32.29 authed with jeff.hodges+kingsmountain.com} Subject: [http-state] WG Last Call for draft-ietf-httpstate-cookie-08 ? X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 May 2010 23:01:17 -0000 dam issued draft-ietf-httpstate-cookie-08 on 23-Apr with all issues in the tracker closed.. http://trac.tools.ietf.org/wg/httpstate/trac/query?component=cookie So, we think we're ready for Working Group Last Call on this spec. Peter, do you agree? Will two weeks be long enough to give folks time for another detailed review? thanks, =JeffH From mjs@apple.com Mon May 10 02:31:48 2010 Return-Path: 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 8881E3A6825 for ; Mon, 10 May 2010 02:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.323 X-Spam-Level: X-Spam-Status: No, score=-104.323 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 pepP0hQKQ-HJ for ; Mon, 10 May 2010 02:31:47 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id CD4B03A67F8 for ; Mon, 10 May 2010 02:31:47 -0700 (PDT) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out3.apple.com (Postfix) with ESMTP id DDFCC91ECB43 for ; Mon, 10 May 2010 02:31:36 -0700 (PDT) X-AuditID: 11807134-b7b33ae000001768-50-4be7d278ddd6 Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay14.apple.com (Apple SCV relay) with SMTP id A4.A3.05992.872D7EB4; Mon, 10 May 2010 02:31:36 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_m1Xx8FSm0MHOekiASf5ICQ)" Received: from [10.0.1.5] ([69.181.42.237]) by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0L2700KDG6GOIP40@elliott.apple.com> for http-state@ietf.org; Mon, 10 May 2010 02:31:36 -0700 (PDT) From: Maciej Stachowiak In-reply-to: <4BE5ED2D.8050303@KingsMountain.com> Date: Mon, 10 May 2010 02:31:35 -0700 Message-id: References: <4BE5ED2D.8050303@KingsMountain.com> To: =JeffH X-Mailer: Apple Mail (2.1078) X-Brightmail-Tracker: AAAAAQAAAZE= Cc: IETF HTTP State WG Subject: Re: [http-state] WG Last Call for draft-ietf-httpstate-cookie-08 ? X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 09:31:48 -0000 --Boundary_(ID_m1Xx8FSm0MHOekiASf5ICQ) Content-type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-transfer-encoding: 7BIT On May 8, 2010, at 4:01 PM, =JeffH wrote: > > > dam issued draft-ietf-httpstate-cookie-08 on 23-Apr with all issues > in the tracker closed.. > > http://trac.tools.ietf.org/wg/httpstate/trac/query?component=cookie > > So, we think we're ready for Working Group Last Call on this spec. > > Peter, do you agree? > > Will two weeks be long enough to give folks time for another > detailed review? Given the draft's complexity and tangled web of legacy constraints, I would suggest at least a month for Last Call review, if not more. Regards, Maciej --Boundary_(ID_m1Xx8FSm0MHOekiASf5ICQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable
<chair>

dam issued = draft-ietf-httpstate-cookie-08 on 23-Apr with all issues in the tracker = closed..

 http://trac.tools.ietf.org/wg/httpstate/trac/query?component=3Dcookie=

So, we think we're ready for Working Group Last Call on this = spec.

Peter, do you agree?

Will two weeks be long enough = to give folks time for another detailed review?

Give= n the draft's complexity and tangled web of legacy constraints, I would = suggest at least a month for Last Call review, if not = more.

Regards,
Maciej

= --Boundary_(ID_m1Xx8FSm0MHOekiASf5ICQ)-- From julian.reschke@gmx.de Mon May 10 02:42:45 2010 Return-Path: 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 3FC2A3A67C0 for ; Mon, 10 May 2010 02:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[AWL=-1.612, BAYES_05=-1.11] 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 hMZ29+KXIjn8 for ; Mon, 10 May 2010 02:42:44 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 1876B3A6816 for ; Mon, 10 May 2010 02:42:43 -0700 (PDT) Received: (qmail invoked by alias); 10 May 2010 09:42:29 -0000 Received: from p508FECAD.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.236.173] by mail.gmx.net (mp057) with SMTP; 10 May 2010 11:42:29 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/OBb03aHDOFe6ZGFg//enSxwjE2XHN+lkZDK+me1 Hbq+WF7FbFleiR Message-ID: <4BE7D4FE.1020403@gmx.de> Date: Mon, 10 May 2010 11:42:22 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Maciej Stachowiak References: <4BE5ED2D.8050303@KingsMountain.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: =JeffH , IETF HTTP State WG Subject: Re: [http-state] WG Last Call for draft-ietf-httpstate-cookie-08 ? X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 09:42:45 -0000 On 10.05.2010 11:31, Maciej Stachowiak wrote: > ... > Given the draft's complexity and tangled web of legacy constraints, I > would suggest at least a month for Last Call review, if not more. > ... I agree that this needs good review :-) That being said, this would be the WG LC; there'll be another IETF-wide Last Call later on. Best regards, Julian From stpeter@stpeter.im Mon May 10 08:47:25 2010 Return-Path: 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 4A09B28C1C4 for ; Mon, 10 May 2010 08:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599] 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 rdbM6Rs2c-bN for ; Mon, 10 May 2010 08:47:24 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id D2E9428C19E for ; Mon, 10 May 2010 08:47:23 -0700 (PDT) Received: from dhcp-64-101-72-158.cisco.com (dhcp-64-101-72-158.cisco.com [64.101.72.158]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 55CC340E14; Mon, 10 May 2010 09:47:12 -0600 (MDT) Message-ID: <4BE82A7F.3020208@stpeter.im> Date: Mon, 10 May 2010 09:47:11 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: =JeffH References: <4BE5ED2D.8050303@KingsMountain.com> In-Reply-To: <4BE5ED2D.8050303@KingsMountain.com> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060309020107080705040906" Cc: IETF HTTP State WG Subject: Re: [http-state] WG Last Call for draft-ietf-httpstate-cookie-08 ? X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 15:47:25 -0000 This is a cryptographically signed message in MIME format. --------------ms060309020107080705040906 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 5/8/10 5:01 PM, =3DJeffH wrote: > >=20 > dam issued draft-ietf-httpstate-cookie-08 on 23-Apr with all issues in > the tracker closed.. >=20 > http://trac.tools.ietf.org/wg/httpstate/trac/query?component=3Dcookie= >=20 > So, we think we're ready for Working Group Last Call on this spec. >=20 > Peter, do you agree? That seems reasonable to me. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms060309020107080705040906 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDUxMDE1NDcxMVowIwYJKoZIhvcNAQkEMRYEFCEm37IC5fS8I4UxBtml MKfzfVaCMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAjjZ9Lx6keDcuc0owylOxiBj4cwZ8oIGmucZOSm+i mTUzH64der4VOgFqHPNlZcGAt72aAaAFQqhtJGHx+r1SptuhUjAjdSnQPn5tW28lfUPCrI3a 2y67lqgMjIfg4FIy0ns6Aa40R94wpMzOv90kOLESryJ2UqbbFOh3L+PRLViQ13fCrASp/z/d DXlzBhWG7mKYf4c9hMRjnIPbtESbxdgltZuYHWuj8a3Iknfzc0NjL1wz3loeTtT3IeAuNOfI 7WQltPd2RZAcQx/Ssgsee3M3N9CPMuel7Ts2CP65dGstw1rEpbw/TVaE2SI1Cl7XtnZh9RNg 2RBdmJcwHjzjJgAAAAAAAA== --------------ms060309020107080705040906-- From Jeff.Hodges@KingsMountain.com Mon May 10 09:09:20 2010 Return-Path: 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 72F133A6826 for ; Mon, 10 May 2010 09:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.219 X-Spam-Level: X-Spam-Status: No, score=0.219 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] 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 zIIw43riA0hm for ; Mon, 10 May 2010 09:09:19 -0700 (PDT) Received: from outbound-mail-01.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id B48A13A67CC for ; Mon, 10 May 2010 09:09:19 -0700 (PDT) Received: (qmail 23005 invoked by uid 0); 10 May 2010 16:09:08 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 10 May 2010 16:09:08 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=7WIEDAWKZgSRcCN5QN8LPGLok+LeZCAD2ZkOywAI0F6aRrAfijdZb/Me3zE/WS1QuBIcSA8yei+8XhkxdKGrFMOHkVauLTKEZ8K9GtQVf5edgtU0KjXCfiZfLT677uvZ; Received: from c-67-161-32-29.hsd1.ca.comcast.net ([67.161.32.29] helo=[192.168.11.11]) by box514.bluehost.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OBVXY-00034V-DA for http-state@ietf.org; Mon, 10 May 2010 10:09:08 -0600 Message-ID: <4BE82FA1.9040407@KingsMountain.com> Date: Mon, 10 May 2010 09:09:05 -0700 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: IETF HTTP State WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 67.161.32.29 authed with jeff.hodges+kingsmountain.com} Subject: Re: [http-state] WG Last Call for draft-ietf-httpstate-cookie-08 ? X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 16:09:20 -0000 Will declaring a WG LC that begins this week and closes on Mon 31-May work for folks? thanks, =JeffH From stpeter@stpeter.im Mon May 10 10:58:26 2010 Return-Path: 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 E94903A6C02 for ; Mon, 10 May 2010 10:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599] 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 rjRmg88qKKTq for ; Mon, 10 May 2010 10:58:26 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 04DF828B23E for ; Mon, 10 May 2010 10:57:44 -0700 (PDT) Received: from dhcp-64-101-72-158.cisco.com (dhcp-64-101-72-158.cisco.com [64.101.72.158]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8EFC540E3E for ; Mon, 10 May 2010 11:57:32 -0600 (MDT) Message-ID: <4BE8490B.40905@stpeter.im> Date: Mon, 10 May 2010 11:57:31 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: http-state@ietf.org References: <4BE82FA1.9040407@KingsMountain.com> In-Reply-To: <4BE82FA1.9040407@KingsMountain.com> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040109020706000607080707" Subject: Re: [http-state] WG Last Call for draft-ietf-httpstate-cookie-08 ? X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 17:58:27 -0000 This is a cryptographically signed message in MIME format. --------------ms040109020706000607080707 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 5/10/10 10:09 AM, =3DJeffH wrote: > Will declaring a WG LC that begins this week and closes on Mon 31-May > work for folks? +1, that should provide enough time to review a 37-page document... --------------ms040109020706000607080707 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDUxMDE3NTczMVowIwYJKoZIhvcNAQkEMRYEFNdmpxKBfur7t7sEt5wg wTCcuEo4MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEADBqYY2cZcoaf7WYd8mKVrVvXvlCP8ORZGwbQpzmV Vz3qiShdO5Y7rtSPCSukT5MPtznS7EqFQoWZDm8hP0vcyFXIT9bRUEqk/tnV0zZsdEZTCpHt 4/nJC8HVBoWsiywaDNllXxEbEsyajleN1upNvZ87tdMkeTKqVdfC5sGJaOZg8h3PthJjHCDW VDwq+Eg+ULJ9FP4XjoKjVyGUQSVCMgaVSfdwbskzguvHaRWCjqw25B30lKMV41F9VglM8nvb wsX2RunD0HxffrcklSlbmE/Qd16BsifWKetVH6bVdSxOOF1fOG1nHMtCTAEGOsL1H8sAsUdU yaLkID4uL5zHvAAAAAAAAA== --------------ms040109020706000607080707-- From Jeff.Hodges@KingsMountain.com Tue May 11 09:22:15 2010 Return-Path: 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 A57463A6A49 for ; Tue, 11 May 2010 09:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.242 X-Spam-Level: X-Spam-Status: No, score=0.242 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] 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 tr+OnyvtTQsk for ; Tue, 11 May 2010 09:22:07 -0700 (PDT) Received: from outbound-mail-158.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id B4B483A691B for ; Tue, 11 May 2010 09:21:43 -0700 (PDT) Received: (qmail 16054 invoked by uid 0); 11 May 2010 16:21:32 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 11 May 2010 16:21:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=TSEDY3qBxnvKoi7CtdnQVqPYCPIbrDIKLP68+J4EO0ZxHa+ZOhtlJ35B31+1FK425FKoj1DZECz9MvKuFsLVoB+7IMdZOrzp5aYTdC1IrhXqlZaRSRi44l63TNLi0BQj; Received: from c-67-161-32-29.hsd1.ca.comcast.net ([67.161.32.29] helo=[192.168.11.11]) by box514.bluehost.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OBsD6-0000FF-2m for http-state@ietf.org; Tue, 11 May 2010 10:21:32 -0600 Message-ID: <4BE98409.8000209@KingsMountain.com> Date: Tue, 11 May 2010 09:21:29 -0700 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: IETF HTTP State WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 67.161.32.29 authed with jeff.hodges+kingsmountain.com} Subject: [http-state] Initiating WG Last Call: draft-ietf-httpstate-cookie-08 X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 16:22:15 -0000 The purpose of this message is to initiate an HTTPSTATE Working Group Last Call on the "HTTP State Management Mechanism" Internet Draft. WHAT DOCUMENT? The document in last call is: draft-ietf-httpstate-cookie-08 Issue tracker at: WHAT IS A LAST CALL FOR? The purpose of the Working Group Last Call (WGLC) is to ensure that the working group has reached consensus on the document, believes that all the known outstanding issues have been addressed, and is ready to put the document forward for consideration as an RFC at Proposed Standard maturity level. During the last call, any comments on the documents are collected and discussed on the http-state@ietf.org mailing list. HOW LONG DOES IT LAST? The last call starts today and will last approximately three weeks. It will end on Monday, 31-May-2010 2359h PDT (UTC: Tuesday, June 1, 2010 at 0659h). WHAT'S THE NEXT STEP? After the last call completes, there are three possible outcomes: 1) No changes are required and we request our ADs to put forward the document to the IESG for proposed standard status. 2) Minor changes agreed to on the list are required, and the document is revised. We then ask our ADs to put forward the revised document to the IESG for proposed standard status. 3) Major issues are raised and no consensus is reached on the list. In this case, we slink back and discuss things until consensus is reached, at which time another working group last call will be issued. Assuming we achieve outcome 1) or 2), and that the ADs agree with our assessment, the next stop for the document is with the IESG. The IESG reads it and may approve the documents (with or without changes), or send the document back to the working group to have major issues addressed. If the first outcome happens, the document is put forward for a two-week IETF-wide Last Call, and after successful completion the document is published as an RFC at proposed standard maturity level. If the second outcome happens, we go back and address the issues, putting the document forward again when we believe we're ready. WHAT SHOULD I DO? You should read the document, making sure that 1) there are no problems or deficiencies or outstanding issues that need to be resolved; and 2) that there are no typos, formatting problems, grammatical errors, etc. Any substantive problems you find, you should send to the list. Any minor problems (typos, etc.) you may send to the list or just to the authors. If, for some reason, you have comments you don't want to send to the entire list, you may send them to me. Read, enjoy, and send your comments in! From eric_bianchetti@yahoo.com Tue May 11 19:13:49 2010 Return-Path: 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 9BA1228C0EA for ; Tue, 11 May 2010 19:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 iQy5CBrRKar7 for ; Tue, 11 May 2010 19:13:47 -0700 (PDT) Received: from web52405.mail.re2.yahoo.com (web52405.mail.re2.yahoo.com [206.190.48.168]) by core3.amsl.com (Postfix) with SMTP id 6C09F28C0F0 for ; Tue, 11 May 2010 19:13:33 -0700 (PDT) Received: (qmail 3158 invoked by uid 60001); 12 May 2010 02:13:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1273630399; bh=BpLSqVVsTQ08UBuHnkGRT0+d0obVHcsh8c0Qk1ZfCPY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=UlIW0d/HSYk6o7KRTVPEjOzdnBZtZurNRGsoEf/+N2vE46GsL+mbIt6ffX1P8vc3/bO9qE7MxGxcN3GvONpEa4dT23ylDGYicyFGMW4EvuYwf3x47LsZyoUDDNaIER1eZNTizXWv4rHNpM1o5HePPjPr9oGk7JT2L8ibjsXf93I= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=T6COd2cU3rsnRcsMpyW90eAXlwNdMz/rB6bLYXO705j8IsSEF6303ccPOXZcT15YUPa4jB6jC4PZGqUd8YqAVpI0HTYQA2VZ9XNhNN21MZa5/mYyGUA/SiXZgs251LuHFOuLGD0ljbfm9EDBd8lZIe4fMBQUvjy0qU5RYtwhSW8=; Message-ID: <925646.97496.qm@web52405.mail.re2.yahoo.com> X-YMail-OSG: pXaVMQgVM1nmMPGwgQkUhKh8bMbMCc7KYeFVgeRYozyvty6 xorGVvORLU8FByFmuV0y2P63DoCLQrapYyYRIATgFD7aO62sG.x9RnvaYgua nVd4qM1Uz39Y1oI5dy5.pXJQ.tbY4ndIL2gBD6ASxUHXLLjyuoXIBvzXYeRe oZi3mFaL28VNh133mD1WhJ4ISwoRBSVZWycam1jVJdcfihLhEAAC4l.EKZpr kzxImCUJs93PD9M8yQ5GXzaFTHGzDR4XrA93.qvBJQ2WfMaw5Pld8_j.gmY_ qA7jwds7umQO3k.l5iJyQmGJrvuumemkgLvoavfKWKpYF.bJy2CT45DpNZbd dw2gOVL8abqtqRAVTki5n29js Received: from [58.137.5.55] by web52405.mail.re2.yahoo.com via HTTP; Tue, 11 May 2010 19:13:19 PDT X-Mailer: YahooMailRC/374.4 YahooMailWebService/0.8.103.269680 References: Date: Tue, 11 May 2010 19:13:19 -0700 (PDT) From: eric bianchetti To: http-state@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [http-state] http-state Digest, Vol 13, Issue 4 X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 02:13:49 -0000 Hello,=0A=0AMaybe it's because my level of english; but to me both of the f= ollowing sentences are contradicting (if a server SHOULD NOT do soemthing, = why then speak of what might happend if they do that thing?) : =0A=0A4.1.1.= =A0 Syntax=0A.....=0A=A0=0AServers SHOULD NOT include two Set-Cookie header= fields in the same=0A=A0=A0 response with the same cookie-name.=0A=0A=A0= =0A.....=0A=A0=0AIf a server sends multiple responses containing Set-Cookie= headers=0A=A0=A0 concurrently to the user agent (e.g., when communicating = with the=0A=A0=A0 user agent over multiple sockets), these responses create= a "race=0A=A0=A0 condition" that can lead to unpredictable behavior.=0A=0A= =A0=0AMy opinion (as not english native) is a reformulation, or even the su= ppression of the second sentence , would give more clarity.=0A=A0=0ABest re= gards=0A=A0=0A=0A=0A=0A----- Original Message ----=0AFrom: "http-state-requ= est@ietf.org" =0ATo: http-state@ietf.org=0ASen= t: Wed, May 12, 2010 2:00:13 AM=0ASubject: http-state Digest, Vol 13, Issue= 4=0A=0AIf you have received this digest without all the individual message= =0Aattachments you will need to update your digest options in your list=0As= ubscription.=A0 To do so, go to =0A=0Ahttps://www.ietf.org/mailman/listinfo= /http-state=0A=0AClick the 'Unsubscribe or edit options' button, log in, an= d set "Get=0AMIME or Plain Text Digests?" to MIME.=A0 You can set this opti= on=0Aglobally for all the list digests you receive at this point.=0A=0A=0A= =0ASend http-state mailing list submissions to=0A=A0=A0=A0 mailto:http-stat= e@ietf.org=0A=0ATo subscribe or unsubscribe via the World Wide Web, visit= =0A=A0=A0=A0 https://www.ietf.org/mailman/listinfo/http-state=0Aor, via ema= il, send a message with subject or body 'help' to=0A=A0=A0=A0 mailto:http-s= tate-request@ietf.org=0A=0AYou can reach the person managing the list at=0A= =A0=A0=A0 mailto:http-state-owner@ietf.org=0A=0AWhen replying, please edit = your Subject line so it is more specific=0Athan "Re: Contents of http-state= digest..."=0A=0A=0AToday's Topics:=0A=0A=A0 1. Initiating WG Last Call: dr= aft-ietf-httpstate-cookie-08 (=3DJeffH)=0A=0A=0A---------------------------= -------------------------------------------=0A=0AMessage: 1=0ADate: Tue, 11= May 2010 09:21:29 -0700=0AFrom: =3DJeffH = =0ASubject: [http-state] Initiating WG Last Call:=0A=A0=A0=A0 draft-ietf-ht= tpstate-cookie-08=0ATo: IETF HTTP State WG =0AMessage-= ID: <4BE98409.8000209@KingsMountain.com>=0AContent-Type: text/plain; charse= t=3DISO-8859-1; format=3Dflowed=0A=0AThe purpose of this message is to init= iate an HTTPSTATE=0AWorking Group Last Call on the "HTTP State Management= =0AMechanism" Internet Draft.=0A=0A=0AWHAT DOCUMENT?=0A=0AThe document in l= ast call is:=0A=0A=A0 draft-ietf-httpstate-cookie-08=0A=0A=A0 =0A=0A=A0 =0A=0A=0A=A0 Issue tracker at:=0A= =0A=A0 =0A=0A=0AWHAT IS A LAST CALL FOR?=0A=0AThe purpose of the Working Group = Last Call (WGLC) is to=0Aensure that the working group has reached consensu= s on the=0Adocument, believes that all the known outstanding issues=0Ahave = been addressed, and is ready to put the document=0Aforward for consideratio= n as an RFC at Proposed Standard=0Amaturity level.=0A=0ADuring the last cal= l, any comments on the documents are=0Acollected and discussed on the http-= state@ietf.org=0Amailing list.=0A=0A=0AHOW LONG DOES IT LAST?=0A=0AThe last= call starts today and will last approximately=0Athree weeks. It will end o= n Monday, 31-May-2010 2359h PDT=0A(UTC: Tuesday, June 1, 2010 at 0659h).=0A= =0A=0AWHAT'S THE NEXT STEP?=0A=0AAfter the last call completes, there are t= hree possible=0Aoutcomes:=0A=0A1) No changes are required and we request ou= r ADs to put=0Aforward the document to the IESG for proposed standard=0Asta= tus.=0A=0A2) Minor changes agreed to on the list are required, and=0Athe do= cument is revised. We then ask our ADs to put=0Aforward the revised documen= t to the IESG for proposed=0Astandard status.=0A=0A3) Major issues are rais= ed and no consensus is reached on=0Athe list. In this case, we slink back a= nd discuss things=0Auntil consensus is reached, at which time another worki= ng=0Agroup last call will be issued.=0A=0AAssuming we achieve outcome 1) or= 2), and that the ADs=0Aagree with our assessment, the next stop for the do= cument=0Ais with the IESG. The IESG reads it and may approve the=0Adocument= s (with or without changes), or send the document=0Aback to the working gro= up to have major issues addressed.=0A=0AIf the first outcome happens, the d= ocument is put forward=0Afor a two-week IETF-wide Last Call, and after succ= essful=0Acompletion the document is published as an RFC at proposed=0Astand= ard maturity level.=0A=0AIf the second outcome happens, we go back and addr= ess=0Athe issues, putting the document forward again when we=0Abelieve we'r= e ready.=0A=0A=0AWHAT SHOULD I DO?=0A=0AYou should read the document, makin= g sure that 1) there=0Aare no problems or deficiencies or outstanding issue= s that=0Aneed to be resolved; and 2) that there are no typos,=0Aformatting = problems, grammatical errors, etc.=0A=0AAny substantive problems you find, = you should send to the=0Alist. Any minor problems (typos, etc.) you may sen= d to the=0Alist or just to the authors. If, for some reason, you have=0Acom= ments you don't want to send to the entire list, you may=0Asend them to me.= =0A=0ARead, enjoy, and send your comments in!=0A=0A=0A=0A------------------= ------------=0A=0A_______________________________________________=0Ahttp-st= ate mailing list=0Ahttp-state@ietf.org=0Ahttps://www.ietf.org/mailman/listi= nfo/http-state=0A=0A=0AEnd of http-state Digest, Vol 13, Issue 4=0A********= *********************************=0A=0A=0A=0A From ietf@adambarth.com Tue May 11 19:17:41 2010 Return-Path: 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 CB78428C0EE for ; Tue, 11 May 2010 19:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.253 X-Spam-Level: X-Spam-Status: No, score=-1.253 tagged_above=-999 required=5 tests=[AWL=0.724, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 1KzMDBN7N4lJ for ; Tue, 11 May 2010 19:17:40 -0700 (PDT) Received: from mail-qy0-f184.google.com (mail-qy0-f184.google.com [209.85.221.184]) by core3.amsl.com (Postfix) with ESMTP id CFB6728C0F6 for ; Tue, 11 May 2010 19:17:22 -0700 (PDT) Received: by qyk14 with SMTP id 14so4816860qyk.17 for ; Tue, 11 May 2010 19:17:09 -0700 (PDT) Received: by 10.224.85.148 with SMTP id o20mr3856989qal.65.1273630628899; Tue, 11 May 2010 19:17:08 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by mx.google.com with ESMTPS id 22sm4419768qyk.2.2010.05.11.19.17.06 (version=SSLv3 cipher=RC4-MD5); Tue, 11 May 2010 19:17:07 -0700 (PDT) Received: by vws13 with SMTP id 13so339806vws.31 for ; Tue, 11 May 2010 19:17:06 -0700 (PDT) Received: by 10.220.63.4 with SMTP id z4mr4980870vch.99.1273630626162; Tue, 11 May 2010 19:17:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.90.74 with HTTP; Tue, 11 May 2010 19:16:46 -0700 (PDT) In-Reply-To: <925646.97496.qm@web52405.mail.re2.yahoo.com> References: <925646.97496.qm@web52405.mail.re2.yahoo.com> From: Adam Barth Date: Tue, 11 May 2010 19:16:46 -0700 Message-ID: To: eric bianchetti Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: http-state@ietf.org Subject: Re: [http-state] http-state Digest, Vol 13, Issue 4 X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 02:17:42 -0000 Sometimes people do things they shouldn't... You might find http://www.ietf.org/rfc/rfc2119.txt helpful. Adam On Tue, May 11, 2010 at 7:13 PM, eric bianchetti wrote: > Hello, > > Maybe it's because my level of english; but to me both of the following s= entences are contradicting (if a server SHOULD NOT do soemthing, why then s= peak of what might happend if they do that thing?) : > > 4.1.1.=A0 Syntax > ..... > > Servers SHOULD NOT include two Set-Cookie header fields in the same > =A0=A0 response with the same cookie-name. > > > ..... > > If a server sends multiple responses containing Set-Cookie headers > =A0=A0 concurrently to the user agent (e.g., when communicating with the > =A0=A0 user agent over multiple sockets), these responses create a "race > =A0=A0 condition" that can lead to unpredictable behavior. > > > My opinion (as not english native) is a reformulation, or even the suppre= ssion of the second sentence , would give more clarity. > > Best regards > > > > > ----- Original Message ---- > From: "http-state-request@ietf.org" > To: http-state@ietf.org > Sent: Wed, May 12, 2010 2:00:13 AM > Subject: http-state Digest, Vol 13, Issue 4 > > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription.=A0 To do so, go to > > https://www.ietf.org/mailman/listinfo/http-state > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME.=A0 You can set this option > globally for all the list digests you receive at this point. > > > > Send http-state mailing list submissions to > =A0=A0=A0 mailto:http-state@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > =A0=A0=A0 https://www.ietf.org/mailman/listinfo/http-state > or, via email, send a message with subject or body 'help' to > =A0=A0=A0 mailto:http-state-request@ietf.org > > You can reach the person managing the list at > =A0=A0=A0 mailto:http-state-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of http-state digest..." > > > Today's Topics: > > =A0 1. Initiating WG Last Call: draft-ietf-httpstate-cookie-08 (=3DJeffH) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 11 May 2010 09:21:29 -0700 > From: =3DJeffH > Subject: [http-state] Initiating WG Last Call: > =A0=A0=A0 draft-ietf-httpstate-cookie-08 > To: IETF HTTP State WG > Message-ID: <4BE98409.8000209@KingsMountain.com> > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed > > The purpose of this message is to initiate an HTTPSTATE > Working Group Last Call on the "HTTP State Management > Mechanism" Internet Draft. > > > WHAT DOCUMENT? > > The document in last call is: > > =A0 draft-ietf-httpstate-cookie-08 > > =A0 > > =A0 > > > =A0 Issue tracker at: > > =A0 > > > WHAT IS A LAST CALL FOR? > > The purpose of the Working Group Last Call (WGLC) is to > ensure that the working group has reached consensus on the > document, believes that all the known outstanding issues > have been addressed, and is ready to put the document > forward for consideration as an RFC at Proposed Standard > maturity level. > > During the last call, any comments on the documents are > collected and discussed on the http-state@ietf.org > mailing list. > > > HOW LONG DOES IT LAST? > > The last call starts today and will last approximately > three weeks. It will end on Monday, 31-May-2010 2359h PDT > (UTC: Tuesday, June 1, 2010 at 0659h). > > > WHAT'S THE NEXT STEP? > > After the last call completes, there are three possible > outcomes: > > 1) No changes are required and we request our ADs to put > forward the document to the IESG for proposed standard > status. > > 2) Minor changes agreed to on the list are required, and > the document is revised. We then ask our ADs to put > forward the revised document to the IESG for proposed > standard status. > > 3) Major issues are raised and no consensus is reached on > the list. In this case, we slink back and discuss things > until consensus is reached, at which time another working > group last call will be issued. > > Assuming we achieve outcome 1) or 2), and that the ADs > agree with our assessment, the next stop for the document > is with the IESG. The IESG reads it and may approve the > documents (with or without changes), or send the document > back to the working group to have major issues addressed. > > If the first outcome happens, the document is put forward > for a two-week IETF-wide Last Call, and after successful > completion the document is published as an RFC at proposed > standard maturity level. > > If the second outcome happens, we go back and address > the issues, putting the document forward again when we > believe we're ready. > > > WHAT SHOULD I DO? > > You should read the document, making sure that 1) there > are no problems or deficiencies or outstanding issues that > need to be resolved; and 2) that there are no typos, > formatting problems, grammatical errors, etc. > > Any substantive problems you find, you should send to the > list. Any minor problems (typos, etc.) you may send to the > list or just to the authors. If, for some reason, you have > comments you don't want to send to the entire list, you may > send them to me. > > Read, enjoy, and send your comments in! > > > > ------------------------------ > > _______________________________________________ > http-state mailing list > http-state@ietf.org > https://www.ietf.org/mailman/listinfo/http-state > > > End of http-state Digest, Vol 13, Issue 4 > ***************************************** > > > > > _______________________________________________ > http-state mailing list > http-state@ietf.org > https://www.ietf.org/mailman/listinfo/http-state > From eric_bianchetti@yahoo.com Wed May 12 19:26:28 2010 Return-Path: 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 342173A6977 for ; Wed, 12 May 2010 19:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 jYlpJBz-xdo9 for ; Wed, 12 May 2010 19:26:26 -0700 (PDT) Received: from web52408.mail.re2.yahoo.com (web52408.mail.re2.yahoo.com [206.190.48.171]) by core3.amsl.com (Postfix) with SMTP id 3C2A83A6862 for ; Wed, 12 May 2010 19:26:26 -0700 (PDT) Received: (qmail 41583 invoked by uid 60001); 13 May 2010 02:26:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1273717573; bh=3dZ7u1oSvnFrCV1uhgb8I5hKprOfJKqKt+syVzdC2Ls=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=kT7i0nVHTI67rvzJy1anka/gIgbTS07dJYKHho/ubSHoauK6Vox4DFaz0iAWX4+skgh/1Ub7tb0QzPuV+y9KFnxJ/pVslwIsGlDcFeXooas80s/hRul7MjnfMNgnDTIO6BcoaORIMJh2Nm9zum5nexy31xcreRpqNOu+FxQY5uY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=jZL7GYdAvbUgyTCWHiwNL/XXSa8f8AKqZpEfgSkOAAAzerd1yabv81THhL+0GP6CbJKTof47TEclgsHrKts374NoKylgCZaS3ge1K7yoLG391DNGrgnfQZbfZDcF6QZxY6ZkaeNITMhsUIIpYcyHKHyoUqRKkFDO7KlTuCk9hms=; Message-ID: <651741.41093.qm@web52408.mail.re2.yahoo.com> X-YMail-OSG: O7oylXoVM1mymEWfgfaQEtRnSGnHrw9E3eMUVpHd3lujCeV Qo07xel6ZGCpn7dAnMRRrs6hjMnlf0RM_OyYJHbgsXP.ZnIHda2UAT72rA6e .u61TBYyBnPXROXUbpfvoIPf1kTW5dxEmQeZiNK4s92iyG8lkDSg.pvyoaIc 5PBcKCPtrMOqaJTL4kCZ_HJmUYKkwiK671iICK2TalaAU9IgM_aEPW0ydYU_ 1jlDNJ71XRdXbfOgbWbCfEEm3Q9D8.B1DwcFFpkFH.KjhUnKGrPHFhjg2r.z 6TqvJtz_9XwLAk.09yR7k_LVA_H.I3A4q9XeP33wtzKX7p5ydMj6vBAXV Received: from [58.181.165.135] by web52408.mail.re2.yahoo.com via HTTP; Wed, 12 May 2010 19:26:13 PDT X-Mailer: YahooMailRC/374.4 YahooMailWebService/0.8.103.269680 References: Date: Wed, 12 May 2010 19:26:13 -0700 (PDT) From: eric bianchetti To: http-state@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [http-state] http-state Digest, Vol 13, Issue 5 X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 02:26:28 -0000 hello Adam,=0A=0Amy point was not about the use of SHOULD and SHOULD NOT; b= ut was about the confusion (or potential confusion for non native english w= ho still are the majority of the human being) to have 2 paragraphs refering= to the very same problem being at different places.=0A=0AAllow me to illus= trate what I might suggest : =0A=0Ainstead of :=0A=0A=0A4.1.1.? Syntax=0A= =A0.....=0A=0A=A0Servers SHOULD NOT include two Set-Cookie header fields in= the same=0A=A0?? response with the same cookie-name.=0A=0A=0A=A0.....=0A= =0A=A0If a server sends multiple responses containing Set-Cookie headers=0A= =A0concurrently to the user agent (e.g., when communicating with the=0A=A0u= ser agent over multiple sockets), these responses create a "race=0A=A0condi= tion" that can lead to unpredictable behavior.=0A=0A=0AI would suggest : = =0A=0A4.1.1.? Syntax=0A=A0.....=0A=0A=A0Servers SHOULD NOT include two Set-= Cookie header fields in the same=0A=A0response with the same cookie-name.= =0A=0AIf a server sends multiple responses containing Set-Cookie headers=0A= =A0concurrently to the user agent (e.g., when communicating with the=0A=A0u= ser agent over multiple sockets), these responses create a "race=0A=A0condi= tion" that can lead to unpredictable behavior.=0A=0A=0AMean the 2 paragraph= s one after the other. It would increase the readability/understanding/focu= s of people reading the RFC , said people being non native english (as I am= ) . Or eventually grouping them (but it would mean some rewriting, so mean = waste of precious time) into one paragraph.=0A=0AI do understand that is qu= ite nitpicking, at the same level as to argue for a missing or misplaced = =A0coma; a cosmetic suggestion only. So if discarded I would obviously unde= rstand why. :)=0A=0ABest regards=0A=0AEric=0A=0A:16:46 -0700=0AFrom: Adam B= arth =0ASubject: Re: [http-state] http-state Digest, Vo= l 13, Issue 4=0ATo: eric bianchetti =0ACc: http-= state@ietf.org=0AMessage-ID:=0A=A0=A0=A0 =0AContent-Type: text/plain; charset=3DISO-8859= -1=0A=0ASometimes people do things they shouldn't...=0A=0AYou might find ht= tp://www.ietf.org/rfc/rfc2119.txt helpful.=0A=0AAdam=0A=0A=0AOn Tue, May 11= , 2010 at 7:13 PM, eric bianchetti=0A wrote:=0A>= Hello,=0A>=0A> Maybe it's because my level of english; but to me both of t= he following sentences are contradicting (if a server SHOULD NOT do soemthi= ng, why then speak of what might happend if they do that thing?) :=0A>=0A> = 4.1.1.? Syntax=0A> .....=0A>=0A> Servers SHOULD NOT include two Set-Cookie = header fields in the same=0A> ?? response with the same cookie-name.=0A>=0A= >=0A> .....=0A>=0A> If a server sends multiple responses containing Set-Coo= kie headers=0A> ?? concurrently to the user agent (e.g., when communicating= with the=0A> ?? user agent over multiple sockets), these responses create = a "race=0A> ?? condition" that can lead to unpredictable behavior.=0A>=0A>= =0A> My opinion (as not english native) is a reformulation, or even the sup= pression of the second sentence , would give more clarity.=0A>=0A> Best reg= ards=0A>=0A=0A=0A=0A From ietf@adambarth.com Wed May 12 21:00:20 2010 Return-Path: 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 B360C3A6834 for ; Wed, 12 May 2010 21:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.016 X-Spam-Level: X-Spam-Status: No, score=0.016 tagged_above=-999 required=5 tests=[AWL=-0.607, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] 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 ANjzbo9g1I7h for ; Wed, 12 May 2010 21:00:19 -0700 (PDT) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by core3.amsl.com (Postfix) with ESMTP id 8EE253A67EF for ; Wed, 12 May 2010 21:00:18 -0700 (PDT) Received: by qyk11 with SMTP id 11so1112466qyk.13 for ; Wed, 12 May 2010 21:00:06 -0700 (PDT) Received: by 10.224.73.27 with SMTP id o27mr5723435qaj.177.1273723205861; Wed, 12 May 2010 21:00:05 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by mx.google.com with ESMTPS id 6sm1273291qwd.3.2010.05.12.21.00.03 (version=SSLv3 cipher=RC4-MD5); Wed, 12 May 2010 21:00:04 -0700 (PDT) Received: by vws13 with SMTP id 13so817206vws.31 for ; Wed, 12 May 2010 21:00:03 -0700 (PDT) Received: by 10.220.123.67 with SMTP id o3mr6166657vcr.56.1273723203078; Wed, 12 May 2010 21:00:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.90.74 with HTTP; Wed, 12 May 2010 20:59:43 -0700 (PDT) In-Reply-To: <651741.41093.qm@web52408.mail.re2.yahoo.com> References: <651741.41093.qm@web52408.mail.re2.yahoo.com> From: Adam Barth Date: Wed, 12 May 2010 20:59:43 -0700 Message-ID: To: eric bianchetti Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: http-state@ietf.org Subject: Re: [http-state] http-state Digest, Vol 13, Issue 5 X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 04:00:20 -0000 Done. On Wed, May 12, 2010 at 7:26 PM, eric bianchetti wrote: > hello Adam, > > my point was not about the use of SHOULD and SHOULD NOT; but was about th= e confusion (or potential confusion for non native english who still are th= e majority of the human being) to have 2 paragraphs refering to the very sa= me problem being at different places. > > Allow me to illustrate what I might suggest : > > instead of : > > > 4.1.1.? Syntax > =A0..... > > =A0Servers SHOULD NOT include two Set-Cookie header fields in the same > =A0?? response with the same cookie-name. > > > =A0..... > > =A0If a server sends multiple responses containing Set-Cookie headers > =A0concurrently to the user agent (e.g., when communicating with the > =A0user agent over multiple sockets), these responses create a "race > =A0condition" that can lead to unpredictable behavior. > > > I would suggest : > > 4.1.1.? Syntax > =A0..... > > =A0Servers SHOULD NOT include two Set-Cookie header fields in the same > =A0response with the same cookie-name. > > If a server sends multiple responses containing Set-Cookie headers > =A0concurrently to the user agent (e.g., when communicating with the > =A0user agent over multiple sockets), these responses create a "race > =A0condition" that can lead to unpredictable behavior. > > > Mean the 2 paragraphs one after the other. It would increase the readabil= ity/understanding/focus of people reading the RFC , said people being non n= ative english (as I am) . Or eventually grouping them (but it would mean so= me rewriting, so mean waste of precious time) into one paragraph. > > I do understand that is quite nitpicking, at the same level as to argue f= or a missing or misplaced =A0coma; a cosmetic suggestion only. So if discar= ded I would obviously understand why. :) > > Best regards > > Eric > > :16:46 -0700 > From: Adam Barth > Subject: Re: [http-state] http-state Digest, Vol 13, Issue 4 > To: eric bianchetti > Cc: http-state@ietf.org > Message-ID: > =A0=A0=A0 > Content-Type: text/plain; charset=3DISO-8859-1 > > Sometimes people do things they shouldn't... > > You might find http://www.ietf.org/rfc/rfc2119.txt helpful. > > Adam > > > On Tue, May 11, 2010 at 7:13 PM, eric bianchetti > wrote: >> Hello, >> >> Maybe it's because my level of english; but to me both of the following = sentences are contradicting (if a server SHOULD NOT do soemthing, why then = speak of what might happend if they do that thing?) : >> >> 4.1.1.? Syntax >> ..... >> >> Servers SHOULD NOT include two Set-Cookie header fields in the same >> ?? response with the same cookie-name. >> >> >> ..... >> >> If a server sends multiple responses containing Set-Cookie headers >> ?? concurrently to the user agent (e.g., when communicating with the >> ?? user agent over multiple sockets), these responses create a "race >> ?? condition" that can lead to unpredictable behavior. >> >> >> My opinion (as not english native) is a reformulation, or even the suppr= ession of the second sentence , would give more clarity. >> >> Best regards >> > > > > > _______________________________________________ > http-state mailing list > http-state@ietf.org > https://www.ietf.org/mailman/listinfo/http-state > From mikewse@hotmail.com Mon May 17 09:09:34 2010 Return-Path: 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 EC13D28C197 for ; Mon, 17 May 2010 09:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.352 X-Spam-Level: **** X-Spam-Status: No, score=4.352 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FORGED_HOTMAIL_RCVD2=1.502, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1] 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 EPtbjsFe-D5K for ; Mon, 17 May 2010 09:09:32 -0700 (PDT) Received: from smtprelay-b12.telenor.se (smtprelay-b12.telenor.se [62.127.194.21]) by core3.amsl.com (Postfix) with ESMTP id B568E3A6D83 for ; Mon, 17 May 2010 09:05:57 -0700 (PDT) Received: from ipb2.telenor.se (ipb2.telenor.se [195.54.127.165]) by smtprelay-b12.telenor.se (Postfix) with ESMTP id B248ECED7 for ; Mon, 17 May 2010 18:05:47 +0200 (CEST) X-SMTPAUTH-B2: [b478723] X-SENDER-IP: [83.227.224.93] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq11AM8F8UtT4+BdPGdsb2JhbACBBIZagRSJBYwBDAEBAQE1LawHhxmJAYJZgjcEhmo X-IronPort-AV: E=Sophos;i="4.53,248,1272837600"; d="scan'208";a="75798542" Received: from ua-83-227-224-93.cust.bredbandsbolaget.se (HELO mikedeskxp) ([83.227.224.93]) by ipb2.telenor.se with ESMTP; 17 May 2010 18:05:47 +0200 From: "Mike Wilson" To: Date: Mon, 17 May 2010 18:03:57 +0200 Message-ID: <009601caf5da$8f0d0030$0a01a8c0@mikedeskxp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acr12o5LXFw11dZKTbWKKKN7lNvH8g== Subject: [http-state] identifying "windows" and cookie scope X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 16:09:35 -0000 Below I describe a couple of related issues and solutions. Feel free to split into separate threads if desired. Identifying browser windows --------------------------- A long-time challenge for web application developers is to make consistent handling of session state when multiple open windows or tabs are used. The session state is typically referenced through a cookie shared by all the tabs which then causes side effects if the user tries to perform different operations in the different tabs. There are numerous sources that discuss this problem, here's one random link: http://www.mail-archive.com/users@myfaces.apache.org/msg50204.html And here's a post on whatwg suggesting to mitigate this problem by adding a new HTTP header containing a generated unique window identifier: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-February/024979.htm l Whatever solution may be most appropriate, this is a problem that would benefit a lot from being addressed by browsers. Scope of cookie store --------------------- In previous cookie specs there haven't been much mention about the cookie store. It is good to see in the new drafts that this is now somewhat more defined, in that one user agent is supposed to have exactly one cookie store (do I read this correctly?). To enhance this definition even further it would be nice with a better specification of "user agent". For the web browser scenario possible interpretations could range from having one shared cookie store for all browser implementations on the system, down to having one cookie store per tab. FWIW, Internet Explorer (all the way up to version 8) is perceived as having one cookie store shared between processes for persistent cookies, while having one cookie store per process for non-persistent cookies. It would thus fail the "one cookie store" definition whichever way user agent is defined. I'm not sure where is the best place to define (or explicitly not define) this, but I wanted to bring it to your attention and hope this is a good place to discuss it. Using scoped cookie to identify browser window ---------------------------------------------- IE's non-persistent-cookie-store-per-process feature can be used to mimic the "state per window" (not tab) discussed initially in this mail. To instead allow a standard solution for this, not adding new headers, we could instead extend cookies to allow an explicit Scope attribute: Set-Cookie: ... Scope=browsing_context; ... that would cause the user agent to only send this cookie for the specified scope (here: browsing context = window or tab) that received it. The Scope parameter could be a general mechanism specified by the cookie spec, possibly with allowed values specified in other specs more applicable to each host environment. Would any of this be interesting to look at within the current, or a future, http-state charter? Best regards Mike Wilson From Joshua.Davies@travelocity.com Mon May 17 09:28:16 2010 Return-Path: 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 7191428C148 for ; Mon, 17 May 2010 09:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.998 X-Spam-Level: X-Spam-Status: No, score=-103.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 ZS8zKLEtIYBv for ; Mon, 17 May 2010 09:28:14 -0700 (PDT) Received: from sgtulmg01-out.sabre.com (sgtulmg01-out.sabre.com [151.193.220.17]) by core3.amsl.com (Postfix) with ESMTP id E471528C174 for ; Mon, 17 May 2010 09:20:36 -0700 (PDT) X-ExtLoop1: From 10.12.64.16 X-IronPort-AV: E=Sophos;i="4.53,248,1272862800"; d="scan'208,217";a="701925485" Received: from unknown (HELO sghdqbh01.Global.ad.sabre.com) ([10.12.64.16]) by sgtulmg01-out.sabre.com with ESMTP; 17 May 2010 11:20:28 -0500 Received: from sgtulmsp06.Global.ad.sabre.com ([10.12.64.145]) by sghdqbh01.Global.ad.sabre.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 May 2010 11:20:01 -0500 Received: from localhost.localdomain ([10.16.53.30]) by sgtulmsp06.Global.ad.sabre.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 May 2010 11:19:55 -0500 Message-ID: <4BF16C45.6000809@travelocity.com> Date: Mon, 17 May 2010 11:18:13 -0500 From: Joshua Davies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: http-state@ietf.org References: <009601caf5da$8f0d0030$0a01a8c0@mikedeskxp> In-Reply-To: <009601caf5da$8f0d0030$0a01a8c0@mikedeskxp> Content-Type: multipart/alternative; boundary="------------060902090403020500090607" X-OriginalArrivalTime: 17 May 2010 16:19:55.0568 (UTC) FILETIME=[C97FB300:01CAF5DC] Subject: Re: [http-state] identifying "windows" and cookie scope X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 16:28:16 -0000 This is a multi-part message in MIME format. --------------060902090403020500090607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This would be a huge help for e-commerce sites... although the "open link in new tab/window" would almost always fail in this case, since the cookies associated with the original browsing context wouldn't be sent. Alternatively, what about an "instance" parameter: Set-Cookie: ... Instance=2; ... ? The user agent could just keep track of how many browsing contexts it had established to a specific domain (which seems like a pretty light burden on the user agent), and associate an "Instance" number with each one. If a web application was "tab-specific", it could keep track of Instance numbers, but a more stateless application could just ignore this parameter and there'd be no backwards-compatibility issue. I'd really like to see this standardized and will immediately offer a Firefox patch implementing such a feature if and when it is - not being able to keep track of multiple tabs/windows is a big problem for us. On 05/17/2010 11:03 AM, Mike Wilson wrote: > Below I describe a couple of related issues and solutions. Feel > free to split into separate threads if desired. > > > Identifying browser windows > --------------------------- > A long-time challenge for web application developers is to make > consistent handling of session state when multiple open windows > or tabs are used. The session state is typically referenced > through a cookie shared by all the tabs which then causes side > effects if the user tries to perform different operations in > the different tabs. There are numerous sources that discuss this > problem, here's one random link: > http://www.mail-archive.com/users@myfaces.apache.org/msg50204.html > > And here's a post on whatwg suggesting to mitigate this problem > by adding a new HTTP header containing a generated unique window > identifier: > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-February/024979.htm > l > > Whatever solution may be most appropriate, this is a problem > that would benefit a lot from being addressed by browsers. > > > Scope of cookie store > --------------------- > In previous cookie specs there haven't been much mention about > the cookie store. It is good to see in the new drafts that this > is now somewhat more defined, in that one user agent is supposed > to have exactly one cookie store (do I read this correctly?). > > To enhance this definition even further it would be nice with a > better specification of "user agent". For the web browser > scenario possible interpretations could range from having one > shared cookie store for all browser implementations on the > system, down to having one cookie store per tab. > > FWIW, Internet Explorer (all the way up to version 8) is > perceived as having one cookie store shared between processes > for persistent cookies, while having one cookie store per process > for non-persistent cookies. It would thus fail the "one cookie > store" definition whichever way user agent is defined. > > I'm not sure where is the best place to define (or explicitly not > define) this, but I wanted to bring it to your attention and hope > this is a good place to discuss it. > > > Using scoped cookie to identify browser window > ---------------------------------------------- > IE's non-persistent-cookie-store-per-process feature can be used > to mimic the "state per window" (not tab) discussed initially in > this mail. > > To instead allow a standard solution for this, not adding new > headers, we could instead extend cookies to allow an explicit > Scope attribute: > > Set-Cookie: ... Scope=browsing_context; ... > > that would cause the user agent to only send this cookie for the > specified scope (here: browsing context = window or tab) that > received it. > > The Scope parameter could be a general mechanism specified by the > cookie spec, possibly with allowed values specified in other > specs more applicable to each host environment. > > > Would any of this be interesting to look at within the current, or > a future, http-state charter? > > Best regards > Mike Wilson > > _______________________________________________ > http-state mailing list > http-state@ietf.org > https://www.ietf.org/mailman/listinfo/http-state > --------------060902090403020500090607 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
This would be a huge help for e-commerce sites... although the "open link in new tab/window" would almost always fail in this case, since the cookies associated with the original browsing context wouldn't be sent.  Alternatively, what about an "instance" parameter:

  Set-Cookie: ... Instance=2; ...
?  The user agent could just keep track of how many browsing contexts it had established to a specific domain (which seems like a pretty light burden on the user agent), and associate an "Instance" number with each one.  If a web application was "tab-specific", it could keep track of Instance numbers, but a more stateless application could just ignore this parameter and there'd be no backwards-compatibility issue.

I'd really like to see this standardized and will immediately offer a Firefox patch implementing such a feature if and when it is - not being able to keep track of multiple tabs/windows is a big problem for us.

On 05/17/2010 11:03 AM, Mike Wilson wrote:
Below I describe a couple of related issues and solutions. Feel
free to split into separate threads if desired.


Identifying browser windows
---------------------------
A long-time challenge for web application developers is to make
consistent handling of session state when multiple open windows 
or tabs are used. The session state is typically referenced
through a cookie shared by all the tabs which then causes side 
effects if the user tries to perform different operations in 
the different tabs. There are numerous sources that discuss this
problem, here's one random link:
http://www.mail-archive.com/users@myfaces.apache.org/msg50204.html

And here's a post on whatwg suggesting to mitigate this problem
by adding a new HTTP header containing a generated unique window 
identifier:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-February/024979.htm
l

Whatever solution may be most appropriate, this is a problem
that would benefit a lot from being addressed by browsers.


Scope of cookie store
---------------------
In previous cookie specs there haven't been much mention about
the cookie store. It is good to see in the new drafts that this
is now somewhat more defined, in that one user agent is supposed
to have exactly one cookie store (do I read this correctly?).

To enhance this definition even further it would be nice with a
better specification of "user agent". For the web browser 
scenario possible interpretations could range from having one
shared cookie store for all browser implementations on the 
system, down to having one cookie store per tab.

FWIW, Internet Explorer (all the way up to version 8) is 
perceived as having one cookie store shared between processes 
for persistent cookies, while having one cookie store per process
for non-persistent cookies. It would thus fail the "one cookie 
store" definition whichever way user agent is defined.

I'm not sure where is the best place to define (or explicitly not 
define) this, but I wanted to bring it to your attention and hope 
this is a good place to discuss it.


Using scoped cookie to identify browser window
----------------------------------------------
IE's non-persistent-cookie-store-per-process feature can be used
to mimic the "state per window" (not tab) discussed initially in
this mail.

To instead allow a standard solution for this, not adding new 
headers, we could instead extend cookies to allow an explicit 
Scope attribute:

  Set-Cookie: ... Scope=browsing_context; ...

that would cause the user agent to only send this cookie for the
specified scope (here: browsing context  = window or tab) that 
received it.

The Scope parameter could be a general mechanism specified by the
cookie spec, possibly with allowed values specified in other
specs more applicable to each host environment.


Would any of this be interesting to look at within the current, or 
a future, http-state charter?

Best regards
Mike Wilson

_______________________________________________
http-state mailing list
http-state@ietf.org
https://www.ietf.org/mailman/listinfo/http-state
  
--------------060902090403020500090607-- From daniel@haxx.se Mon May 17 10:39:13 2010 Return-Path: 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 449663A689D for ; Mon, 17 May 2010 10:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[AWL=-1.129, BAYES_50=0.001, HELO_EQ_SE=0.35] 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 RBrNs7vR1sRp for ; Mon, 17 May 2010 10:39:12 -0700 (PDT) Received: from giant.haxx.se (giant.haxx.se [83.168.254.42]) by core3.amsl.com (Postfix) with ESMTP id 16B043A67D3 for ; Mon, 17 May 2010 10:39:11 -0700 (PDT) Received: from giant.haxx.se (giant.haxx.se [83.168.254.42]) by giant.haxx.se (8.14.3/8.14.3/Debian-9) with ESMTP id o4HHctYi028157; Mon, 17 May 2010 19:38:55 +0200 Date: Mon, 17 May 2010 19:38:55 +0200 (CEST) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Mike Wilson In-Reply-To: <009601caf5da$8f0d0030$0a01a8c0@mikedeskxp> Message-ID: References: <009601caf5da$8f0d0030$0a01a8c0@mikedeskxp> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: HTTP-state mailing list Subject: Re: [http-state] identifying "windows" and cookie scope X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 17:39:13 -0000 On Mon, 17 May 2010, Mike Wilson wrote: > In previous cookie specs there haven't been much mention about the cookie > store. It is good to see in the new drafts that this is now somewhat more > defined, in that one user agent is supposed to have exactly one cookie store > (do I read this correctly?). I certainly do not read it like that. A user agent is said to store the cookies in "a" cookie store, but there's nothing that forces that cookie store to be the same cookie store as when the user agent gets other resources (although of course it should use the same if it wants to remain in the same http state). Certainly different users on the same machine for example will use different cookie stores? -- / daniel.haxx.se From bil@corry.biz Mon May 17 11:02:38 2010 Return-Path: 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 141DB3A69D2 for ; Mon, 17 May 2010 11:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=-3.207, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] 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 nu1Ee9Sqp7aZ for ; Mon, 17 May 2010 11:02:36 -0700 (PDT) Received: from mail.mindio.com (app1.bc.anu.net [193.189.141.126]) by core3.amsl.com (Postfix) with ESMTP id 1C9253A697F for ; Mon, 17 May 2010 11:02:36 -0700 (PDT) Received: from [127.0.0.1] (c-69-181-67-65.hsd1.ca.comcast.net [69.181.67.65]) by mail.mindio.com (Postfix) with ESMTP id 072CE24453A; Mon, 17 May 2010 13:02:25 -0500 (CDT) Message-ID: <4BF184A7.5060207@corry.biz> Date: Mon, 17 May 2010 11:02:15 -0700 From: Bil Corry User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Joshua Davies References: <009601caf5da$8f0d0030$0a01a8c0@mikedeskxp> <4BF16C45.6000809@travelocity.com> In-Reply-To: <4BF16C45.6000809@travelocity.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: http-state@ietf.org Subject: Re: [http-state] identifying "windows" and cookie scope X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 18:02:38 -0000 Joshua Davies wrote on 5/17/2010 9:18 AM: > This would be a huge help for e-commerce sites... although the "open > link in new tab/window" would almost always fail in this case, since the > cookies associated with the original browsing context wouldn't be sent. > Alternatively, what about an "instance" parameter: > > Set-Cookie: ... Instance=2; ... > > ? The user agent could just keep track of how many browsing contexts it > had established to a specific domain (which seems like a pretty light > burden on the user agent), and associate an "Instance" number with each > one. If a web application was "tab-specific", it could keep track of > Instance numbers, but a more stateless application could just ignore > this parameter and there'd be no backwards-compatibility issue. I'm not crazy about sequential instance numbers, but it would be useful if the server could assign an instance ID to the UA, which the UA then returns in a header with each request. Opening a new window/tab/etc would cause the UA to send an empty instance header for that instance until the server assigns one to it. Then for your instance cookies, you'd just need a flag, InstanceOnly, that instructs the UA to only send the cookie with that instance. I haven't given it much thought, but such a system might help mitigate CSRF. This instance system would have additional benefits too, allowing an easy way for Yngve's Cache Context[1] to work, and an easy way for my LOGOUT rel extension proposal to work[2]. I could also see it tying into CSP[3], allowing the server to restrict the domains/IPs that the instance can communicate with (e.g. the instance is locked down to a single domain, the user types www.somesite.tld in the address bar, the UA then warns the user that they are leaving the instance for www.mybank.tld, the user then is directed to www.somesite.tld under a blank instance ID, their cache is emptied via Cache Context and the site www.mybank.tld receives the logout ping). In any event, this will have to be something we work on after we recharter; our current charter prohibits new functionality being added. - Bil [1] http://tools.ietf.org/html/draft-pettersen-cache-context [2] http://wiki.whatwg.org/wiki/RelExtensions (scroll down to 'logout') [3] http://people.mozilla.org/~bsterne/content-security-policy/ From ietf@adambarth.com Mon May 17 11:06:36 2010 Return-Path: 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 B38A73A697F for ; Mon, 17 May 2010 11:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.108 X-Spam-Level: X-Spam-Status: No, score=0.108 tagged_above=-999 required=5 tests=[AWL=-0.515, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] 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 2cpMyIQeP6UE for ; Mon, 17 May 2010 11:06:36 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id BA87D3A686C for ; Mon, 17 May 2010 11:06:35 -0700 (PDT) Received: by fxm16 with SMTP id 16so3906999fxm.31 for ; Mon, 17 May 2010 11:06:24 -0700 (PDT) Received: by 10.223.17.197 with SMTP id t5mr1870506faa.84.1274119583636; Mon, 17 May 2010 11:06:23 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id 7sm26855677far.18.2010.05.17.11.06.21 (version=SSLv3 cipher=RC4-MD5); Mon, 17 May 2010 11:06:22 -0700 (PDT) Received: by iwn42 with SMTP id 42so625488iwn.31 for ; Mon, 17 May 2010 11:06:19 -0700 (PDT) Received: by 10.231.157.203 with SMTP id c11mr646821ibx.14.1274119579813; Mon, 17 May 2010 11:06:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.150.207 with HTTP; Mon, 17 May 2010 11:05:59 -0700 (PDT) In-Reply-To: References: <009601caf5da$8f0d0030$0a01a8c0@mikedeskxp> From: Adam Barth Date: Mon, 17 May 2010 11:05:59 -0700 Message-ID: To: Daniel Stenberg Content-Type: text/plain; charset=ISO-8859-1 Cc: HTTP-state mailing list Subject: Re: [http-state] identifying "windows" and cookie scope X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 18:06:36 -0000 On Mon, May 17, 2010 at 10:38 AM, Daniel Stenberg wrote: > On Mon, 17 May 2010, Mike Wilson wrote: >> In previous cookie specs there haven't been much mention about the cookie >> store. It is good to see in the new drafts that this is now somewhat more >> defined, in that one user agent is supposed to have exactly one cookie store >> (do I read this correctly?). > > I certainly do not read it like that. A user agent is said to store the > cookies in "a" cookie store, but there's nothing that forces that cookie > store to be the same cookie store as when the user agent gets other > resources (although of course it should use the same if it wants to remain > in the same http state). Certainly different users on the same machine for > example will use different cookie stores? Yes, that's the intent. We an add some text to make this clearer if you like. Adam From ietf@adambarth.com Mon May 17 11:07:31 2010 Return-Path: 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 19BD73A6A79 for ; Mon, 17 May 2010 11:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.244 X-Spam-Level: X-Spam-Status: No, score=-0.244 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] 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 21KHyaWEqKvl for ; Mon, 17 May 2010 11:07:29 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id B8DA13A6A80 for ; Mon, 17 May 2010 11:07:27 -0700 (PDT) Received: by pxi19 with SMTP id 19so2981035pxi.31 for ; Mon, 17 May 2010 11:07:17 -0700 (PDT) Received: by 10.142.66.11 with SMTP id o11mr3682658wfa.121.1274119275884; Mon, 17 May 2010 11:01:15 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by mx.google.com with ESMTPS id x35sm1655204wfh.6.2010.05.17.11.01.14 (version=SSLv3 cipher=RC4-MD5); Mon, 17 May 2010 11:01:14 -0700 (PDT) Received: by gwb19 with SMTP id 19so2861952gwb.31 for ; Mon, 17 May 2010 11:01:13 -0700 (PDT) Received: by 10.231.157.4 with SMTP id z4mr626233ibw.32.1274119273084; Mon, 17 May 2010 11:01:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.150.207 with HTTP; Mon, 17 May 2010 11:00:53 -0700 (PDT) In-Reply-To: <009601caf5da$8f0d0030$0a01a8c0@mikedeskxp> References: <009601caf5da$8f0d0030$0a01a8c0@mikedeskxp> From: Adam Barth Date: Mon, 17 May 2010 11:00:53 -0700 Message-ID: To: Mike Wilson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: http-state@ietf.org Subject: Re: [http-state] identifying "windows" and cookie scope X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 18:07:31 -0000 [reordered...] On Mon, May 17, 2010 at 9:03 AM, Mike Wilson wrote: > Would any of this be interesting to look at within the current, or > a future, http-state charter? It's probably better to address issues that require new syntax or semantics in phase two of our work. In the current phase, we're working on specifying current behavior accurately. > Below I describe a couple of related issues and solutions. Feel > free to split into separate threads if desired. > > Identifying browser windows > --------------------------- > A long-time challenge for web application developers is to make > consistent handling of session state when multiple open windows > or tabs are used. The session state is typically referenced > through a cookie shared by all the tabs which then causes side > effects if the user tries to perform different operations in > the different tabs. There are numerous sources that discuss this > problem, here's one random link: > http://www.mail-archive.com/users@myfaces.apache.org/msg50204.html > > And here's a post on whatwg suggesting to mitigate this problem > by adding a new HTTP header containing a generated unique window > identifier: > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-February/024979.= htm > l > > Whatever solution may be most appropriate, this is a problem > that would benefit a lot from being addressed by browsers. There are some new features in HTML5 (e.g., sessionStorage) that might help address this issue. It's unclear whether it makes sense to tie this sort of mechanism into the cookie store. As an example, to use cookies securely in web browsers, you also need some sort of mechanism to defend against CSRF. There are a number of defenses for CSRF, and some of them can also be used to identify browser windows (e.g., you can encode that information into the secret tokens). > Scope of cookie store > --------------------- > In previous cookie specs there haven't been much mention about > the cookie store. It is good to see in the new drafts that this > is now somewhat more defined, in that one user agent is supposed > to have exactly one cookie store (do I read this correctly?). > > To enhance this definition even further it would be nice with a > better specification of "user agent". For the web browser > scenario possible interpretations could range from having one > shared cookie store for all browser implementations on the > system, down to having one cookie store per tab. > > FWIW, Internet Explorer (all the way up to version 8) is > perceived as having one cookie store shared between processes > for persistent cookies, while having one cookie store per process > for non-persistent cookies. It would thus fail the "one cookie > store" definition whichever way user agent is defined. > > I'm not sure where is the best place to define (or explicitly not > define) this, but I wanted to bring it to your attention and hope > this is a good place to discuss it. The spec is intentionally vague on this point. Existing user agents have a variety of behaviors here. For example, many browsers have a "privacy mode" that uses a separate cookie store from the rest of the tabs. I'm not sure there's a reason the spec should restrict innovation in this space. It doesn't have much bearing on the semantics of the Cookie and Set-Cookie headers. > Using scoped cookie to identify browser window > ---------------------------------------------- > IE's non-persistent-cookie-store-per-process feature can be used > to mimic the "state per window" (not tab) discussed initially in > this mail. > > To instead allow a standard solution for this, not adding new > headers, we could instead extend cookies to allow an explicit > Scope attribute: > > =A0Set-Cookie: ... Scope=3Dbrowsing_context; ... > > that would cause the user agent to only send this cookie for the > specified scope (here: browsing context =A0=3D window or tab) that > received it. > > The Scope parameter could be a general mechanism specified by the > cookie spec, possibly with allowed values specified in other > specs more applicable to each host environment. This sounds like an interesting idea. In a future version of the cookie protocol, we should consider a cookie scope akin to the scope used by sessionStorage in HTML5. Ideally, we'd find a way of defining a scope that helps mitigate CSRF vulnerabilities at the same time. Adam From mikewse@hotmail.com Mon May 17 14:26:02 2010 Return-Path: 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 88D4E3A68F1 for ; Mon, 17 May 2010 14:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.103 X-Spam-Level: *** X-Spam-Status: No, score=3.103 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_50=0.001, FORGED_HOTMAIL_RCVD2=1.502, HELO_EQ_SE=0.35] 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 cvtLQCtyNP1m for ; Mon, 17 May 2010 14:26:01 -0700 (PDT) Received: from smtprelay-h22.telenor.se (smtprelay-h22.telenor.se [195.54.99.197]) by core3.amsl.com (Postfix) with ESMTP id F05193A69A4 for ; Mon, 17 May 2010 14:25:47 -0700 (PDT) Received: from ipb1.telenor.se (ipb1.telenor.se [195.54.127.164]) by smtprelay-h22.telenor.se (Postfix) with ESMTP id F10CEC302 for ; Mon, 17 May 2010 23:25:38 +0200 (CEST) X-SMTPAUTH-B2: [b478723] X-SENDER-IP: [83.227.224.93] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AglzAIJR8UtT4+BdPGdsb2JhbACBBIZagRSVBQwBAQEBNS2sSYc9iQGCWYI3BIZq X-IronPort-AV: E=Sophos;i="4.53,249,1272837600"; d="scan'208";a="77023966" Received: from ua-83-227-224-93.cust.bredbandsbolaget.se (HELO mikedeskxp) ([83.227.224.93]) by ipb1.telenor.se with ESMTP; 17 May 2010 23:25:38 +0200 From: "Mike Wilson" To: "'Adam Barth'" Date: Mon, 17 May 2010 23:25:37 +0200 Message-ID: <00dc01caf607$7ebfbf60$0a01a8c0@mikedeskxp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acr16vhGu+m4F32dTF+qRmtiFHTtAAAGWOvg Cc: http-state@ietf.org Subject: Re: [http-state] identifying "windows" and cookie scope X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 21:26:02 -0000 Adam Barth wrote: > On Mon, May 17, 2010 at 9:03 AM, Mike Wilson wrote: > > Would any of this be interesting to look at within the current, or > > a future, http-state charter? >=20 > It's probably better to address issues that require new syntax or > semantics in phase two of our work. In the current phase, we're > working on specifying current behavior accurately. That's fine. > > Identifying browser windows > > --------------------------- > > A long-time challenge for web application developers is to make > > consistent handling of session state when multiple open windows > > or tabs are used. The session state is typically referenced > > through a cookie shared by all the tabs which then causes side > > effects if the user tries to perform different operations in > > the different tabs. There are numerous sources that discuss this > > problem, here's one random link: > > http://www.mail-archive.com/users@myfaces.apache.org/msg50204.html > > > > And here's a post on whatwg suggesting to mitigate this problem > > by adding a new HTTP header containing a generated unique window > > identifier: > >=20 > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-Febru > ary/024979.htm > > l > > > > Whatever solution may be most appropriate, this is a problem > > that would benefit a lot from being addressed by browsers. >=20 > There are some new features in HTML5 (e.g., sessionStorage) that might > help address this issue. It's unclear whether it makes sense to tie > this sort of mechanism into the cookie store. Yes, but sessionStorage needs script and by bringing this up here I'm=20 trying to address server-centric apps. I brought these topics up at the WHATWG list a year ago [1], and was directed here, though at the time I couldn't find an active charter. > As an example, to use cookies securely in web browsers, you also need > some sort of mechanism to defend against CSRF. There are a number of > defenses for CSRF, and some of them can also be used to identify > browser windows (e.g., you can encode that information into the secret > tokens). I'm guessing these solutions are POST only? I think it is important to find good state support for GET requests as well. > > Scope of cookie store > > --------------------- > > In previous cookie specs there haven't been much mention about > > the cookie store. It is good to see in the new drafts that this > > is now somewhat more defined, in that one user agent is supposed > > to have exactly one cookie store (do I read this correctly?). > > > > To enhance this definition even further it would be nice with a > > better specification of "user agent". For the web browser > > scenario possible interpretations could range from having one > > shared cookie store for all browser implementations on the > > system, down to having one cookie store per tab. > > > > FWIW, Internet Explorer (all the way up to version 8) is > > perceived as having one cookie store shared between processes > > for persistent cookies, while having one cookie store per process > > for non-persistent cookies. It would thus fail the "one cookie > > store" definition whichever way user agent is defined. > > > > I'm not sure where is the best place to define (or explicitly not > > define) this, but I wanted to bring it to your attention and hope > > this is a good place to discuss it. >=20 > The spec is intentionally vague on this point. Existing user agents > have a variety of behaviors here. For example, many browsers have a > "privacy mode" that uses a separate cookie store from the rest of the > tabs. >=20 > I'm not sure there's a reason the spec should restrict innovation in > this space. It doesn't have much bearing on the semantics of the > Cookie and Set-Cookie headers. Either way I think it would be nice with a written statement as how the cookie store relates to the user agent, ie "explicitly not=20 defined". But maybe this belongs in HTML5 along with other browser behaviour. > > Using scoped cookie to identify browser window > > ---------------------------------------------- > > IE's non-persistent-cookie-store-per-process feature can be used > > to mimic the "state per window" (not tab) discussed initially in > > this mail. > > > > To instead allow a standard solution for this, not adding new > > headers, we could instead extend cookies to allow an explicit > > Scope attribute: > > > > =A0Set-Cookie: ... Scope=3Dbrowsing_context; ... > > > > that would cause the user agent to only send this cookie for the > > specified scope (here: browsing context =A0=3D window or tab) that > > received it. > > > > The Scope parameter could be a general mechanism specified by the > > cookie spec, possibly with allowed values specified in other > > specs more applicable to each host environment. >=20 > This sounds like an interesting idea. In a future version of the > cookie protocol, we should consider a cookie scope akin to the scope > used by sessionStorage in HTML5. Ideally, we'd find a way of defining > a scope that helps mitigate CSRF vulnerabilities at the same time. Great, let's return to this when the WG finds it suitable. I should also mention that it may be interesting to provide additional scope levels in addition to user_agent and browsing_context. Best regards Mike Wilson [1] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-June/020423.html= From mikewse@hotmail.com Mon May 17 14:39:50 2010 Return-Path: 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 1FDDE3A6BA7 for ; Mon, 17 May 2010 14:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.978 X-Spam-Level: * X-Spam-Status: No, score=1.978 tagged_above=-999 required=5 tests=[AWL=1.125, BAYES_50=0.001, FORGED_HOTMAIL_RCVD2=1.502, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1] 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 HgOrcx0KrPi2 for ; Mon, 17 May 2010 14:39:48 -0700 (PDT) Received: from smtprelay-h21.telenor.se (smtprelay-h21.telenor.se [195.54.99.196]) by core3.amsl.com (Postfix) with ESMTP id 6AB4A3A6B9E for ; Mon, 17 May 2010 14:39:46 -0700 (PDT) Received: from ipb2.telenor.se (ipb2.telenor.se [195.54.127.165]) by smtprelay-h21.telenor.se (Postfix) with ESMTP id 04E0EC5DA for ; Mon, 17 May 2010 23:39:36 +0200 (CEST) X-SMTPAUTH-B2: [b478723] X-SENDER-IP: [83.227.224.93] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AglzAI5U8UtT4+BdPGdsb2JhbACBBIZagRSVBQwBAQEBNS2sSYdAiQGCXII0BA X-IronPort-AV: E=Sophos;i="4.53,249,1272837600"; d="scan'208";a="75921979" Received: from ua-83-227-224-93.cust.bredbandsbolaget.se (HELO mikedeskxp) ([83.227.224.93]) by ipb2.telenor.se with ESMTP; 17 May 2010 23:39:36 +0200 From: "Mike Wilson" To: "'Bil Corry'" , "'Joshua Davies'" Date: Mon, 17 May 2010 23:39:35 +0200 Message-ID: <00dd01caf609$723c6660$0a01a8c0@mikedeskxp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4BF184A7.5060207@corry.biz> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acr16x5sYZOMqQVfTxyz8u8Z6OcVEwAHL26g Cc: http-state@ietf.org Subject: Re: [http-state] identifying "windows" and cookie scope X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 21:39:50 -0000 Bil Corry wrote: > Joshua Davies wrote on 5/17/2010 9:18 AM: > > This would be a huge help for e-commerce sites... although the "open > > link in new tab/window" would almost always fail in this > case, since the > > cookies associated with the original browsing context > wouldn't be sent. > > Alternatively, what about an "instance" parameter: > > > > Set-Cookie: ... Instance=2; ... > > > > ? The user agent could just keep track of how many > browsing contexts it > > had established to a specific domain (which seems like a > pretty light > > burden on the user agent), and associate an "Instance" > number with each > > one. If a web application was "tab-specific", it could > keep track of > > Instance numbers, but a more stateless application could just ignore > > this parameter and there'd be no backwards-compatibility issue. > > I'm not crazy about sequential instance numbers, but it would > be useful if the server could assign an instance ID to the > UA, which the UA then returns in a header with each request. > Opening a new window/tab/etc would cause the UA to send an > empty instance header for that instance until the server > assigns one to it. > > Then for your instance cookies, you'd just need a flag, > InstanceOnly, that instructs the UA to only send the cookie > with that instance. I haven't given it much thought, but > such a system might help mitigate CSRF. > > This instance system would have additional benefits too, > allowing an easy way for Yngve's Cache Context[1] to work, > and an easy way for my LOGOUT rel extension proposal to > work[2]. I could also see it tying into CSP[3], allowing the > server to restrict the domains/IPs that the instance can > communicate with (e.g. the instance is locked down to a > single domain, the user types www.somesite.tld in the address > bar, the UA then warns the user that they are leaving the > instance for www.mybank.tld, the user then is directed to > www.somesite.tld under a blank instance ID, their cache is > emptied via Cache Context and the site www.mybank.tld > receives the logout ping). > > In any event, this will have to be something we work on after > we recharter; our current charter prohibits new functionality > being added. Yes, "new tab" is one of the challenges to get this working smoothly. Yet another alternative is to send along the parent tab's scoped cookies with names "parent-prefixed" in some unique way on the main request for the new tab. Best regards Mike Wilson > - Bil > > [1] http://tools.ietf.org/html/draft-pettersen-cache-context > [2] http://wiki.whatwg.org/wiki/RelExtensions (scroll down to > 'logout') > [3] http://people.mozilla.org/~bsterne/content-security-policy/ > _______________________________________________ > http-state mailing list > http-state@ietf.org > https://www.ietf.org/mailman/listinfo/http-state > From derhoermi@gmx.net Wed May 26 10:23:36 2010 Return-Path: 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 75B493A68B2 for ; Wed, 26 May 2010 10:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 Nd4NN-eQqzey for ; Wed, 26 May 2010 10:23:33 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 0179A3A69AE for ; Wed, 26 May 2010 10:23:18 -0700 (PDT) Received: (qmail invoked by alias); 26 May 2010 17:23:05 -0000 Received: from dslb-094-222-156-193.pools.arcor-ip.net (EHLO hive) [94.222.156.193] by mail.gmx.net (mp070) with SMTP; 26 May 2010 19:23:05 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX18PdAdZ7OsPYHE3GHl63UNtO1kGySynWSUxZHyAdD c1YRi8MJcZ8edY From: Bjoern Hoehrmann To: http-state@ietf.org Date: Wed, 26 May 2010 19:22:58 +0200 Message-ID: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Subject: [http-state] Comments on draft-ietf-httpstate-cookie-08.txt (1 - 4.1.2.) X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 17:23:37 -0000 Hi, Some comments on draft-ietf-httpstate-cookie-08.txt: In section 1 the draft says "an HTTP server can store name/value pairs"; this should be rephrased to clearly indicate that the Set-Cookie is a mere request and the client is free to ignore it. Similarily, in the same paragraph "the user agent uses the metadata to determine whether to return the name/value pairs in the Cookie header" should be clarified that the metadata that is part of the cookie is but one thing among many to base the decision on. A possible rewording would be: This document defines the HTTP Cookie and Set-Cookie headers. Using the Set-Cookie header, an HTTP server can pass name/value pairs and associated metadata (called cookies) to a user agent. When the user agent makes subsequent requests to the server, the user agent uses the metadata and other information to determine whether to return the name/value pairs in the Cookie header. Later in the section, there should be a bibliographic reference for the "Netscape cookie specification". In the same paragraph "However, none of these documents describe how the Cookie and Set-Cookie headers are actually used on the Internet" is rather unclear and does not appear to do the relevant documents justice. As reader I am left wondering if the intend is to say they did not attempt to do so, or were incomplete, or what else is wrong with them. In section 2.2 the imported rules should be phrased as grammar to make them easer to scan and read, i.e., e.g. ALPHA = ; A-Z / a-z ... Further down "Multiple OWS characters that occur within field-content SHOULD be replaced with a single SP before interpreting the field value or forwarding the message downstream"; the "field-content" is confusing here, I read it as production, but then the document does not define the production; this could be fixed by adding a reference to the HTTP speci- fication which defines it, or by turning it into "HTTP message-header field-content"; adding a reference is probably better. It is unclear to me that intermediaries actually modify the headers like that; has this been tested? In section 2.3 we have "The terms request-host and request-uri refer to the values the user agent would send to the server as, respectively, the host (but not port) and the absoluteURI (http_URL) of the HTTP Request-Line." I am not entirely sure how to read that; for example, the "host" would be part of "absoluteURI" if it is sent in the Request-Line, and sending an absoluteURI there is unusual (unless talking to a proxy). Also, the reference to http_URL is probably incorrect if "https" URLs are also permissable. Section 3 starts with "We outline here ..."; words like "we" should be avoided in technical specifications, one reason being that they may be different to translate, another that it is unclear who "we" really is. Later in the section, "The origin server MAY send the user agent a Set-Cookie response header with the same or different information, or it MAY send no Set-Cookie header at all." It is unclear what "same" refers to here. It sounds like this might refer to servers setting the same cookie over and over again even if the client is already sending it back but that does not become clear from the paragraph. At the end of section 3 it should be pointed out that the do-not-fold rule is inconsistent with RFC 2616. In section 3.1 it might be a good idea to use different amounts of white space between protocol text and explanatory text depending on which text belongs to which communication. (For example, with "Notice that the server uses the Secure and HttpOnly attributes" I read back what the example was because I had not noticed those attributes, and they are not there because the text is discussing the following example). With "If the server wishes the user agent to persist the cookie over multiple sessions" it might make sense to clarify what is meant by a session here, for example, "(for instance, web browsers usually end a session when the browser application is closed)". In section 4 I think "some of the most esoteric semantics" needs to be rephrased (what is meant by "esoteric", and "most esoteric" is hard to parse; "semantics" is probably also problematic here). In general, it does not become clear how the specification might be modified in the future, other than that there is some "cruft" that might be dropped. I note that with the grammar in 4.1.1 there can be some confusion with respect to the RFC 2616 BNF variant and the standard ABNF language; of particular concern is the "implied *LWS" rule in RFC 2616; there should be a note of the grammar differences, if any, here, or maybe earler in the document. The grammar makes reference to "abs_path", but does not define what it is. I am not sure what qualifies as "attribute" in "Servers SHOULD NOT include two attributes with the same name." and there should be a rationale for this somewhat surprising rule. In "Servers SHOULD NOT include two Set-Cookie header fields" make that "two or more" or possibly better "Servers SHOULD include at most one". With '"Opaque" implies that the content is of interest and relevance only to the origin server.' I do not think "implies" is the right word here, "means" seems more appropriate. I also find the statement mis- leading, if I have some script code running as part of a web page that processes the cookie, that should be fine but contradicts the statement. The point about the race condition and time_t appear to be out of place in this section, that is more something for the security considerations or a separate "Compatibility considerations" section. The point with the race condition could also use an answer to "so what". In section 4.1.2 "When the user agent receives a Set-Cookie header, the user agent stores the cookie in its cookie store." This should probably introduce the "cookie store" before it takes it for granted (like, a user agent has a cookie store, and when it receives cookies, then it stores them inside it). Alternatively, it would suffice to say that it simply stores them (and passes them along later). regards, -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de Am Badedeich 7 Telefon: +49(0)160/4415681 http://www.bjoernsworld.de 25899 Dagebll PGP Pub. KeyID: 0xA4357E78 http://www.websitedev.de/ From ietf@adambarth.com Wed May 26 13:46:04 2010 Return-Path: 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 678063A69E2 for ; Wed, 26 May 2010 13:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622] 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 QSZRQK+Yp2nz for ; Wed, 26 May 2010 13:46:03 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 27A243A6891 for ; Wed, 26 May 2010 13:45:59 -0700 (PDT) Received: by vws14 with SMTP id 14so2623499vws.31 for ; Wed, 26 May 2010 13:45:48 -0700 (PDT) Received: by 10.229.250.81 with SMTP id mn17mr2032687qcb.182.1274906747817; Wed, 26 May 2010 13:45:47 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by mx.google.com with ESMTPS id v37sm310409qce.18.2010.05.26.13.45.44 (version=SSLv3 cipher=RC4-MD5); Wed, 26 May 2010 13:45:46 -0700 (PDT) Received: by gwj15 with SMTP id 15so2549238gwj.31 for ; Wed, 26 May 2010 13:45:44 -0700 (PDT) Received: by 10.231.178.135 with SMTP id bm7mr8097741ibb.73.1274906742429; Wed, 26 May 2010 13:45:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.60.4 with HTTP; Wed, 26 May 2010 13:45:22 -0700 (PDT) In-Reply-To: References: From: Adam Barth Date: Wed, 26 May 2010 13:45:22 -0700 Message-ID: To: Bjoern Hoehrmann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: http-state@ietf.org Subject: Re: [http-state] Comments on draft-ietf-httpstate-cookie-08.txt (1 - 4.1.2.) X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 20:46:04 -0000 Thanks for your comments. I've accepted the majority of your recommendations. Details inline. Adam On Wed, May 26, 2010 at 10:22 AM, Bjoern Hoehrmann wrot= e: > =A0Some comments on draft-ietf-httpstate-cookie-08.txt: > > In section 1 the draft says "an HTTP server can store name/value pairs"; > this should be rephrased to clearly indicate that the Set-Cookie is a > mere request and the client is free to ignore it. Similarily, in the > same paragraph "the user agent uses the metadata to determine whether to > return the name/value pairs in the Cookie header" should be clarified > that the metadata that is part of the cookie is but one thing among many > to base the decision on. A possible rewording would be: > > =A0 This document defines the HTTP Cookie and Set-Cookie headers. =A0Usin= g > =A0 the Set-Cookie header, an HTTP server can pass name/value pairs and > =A0 associated metadata (called cookies) to a user agent. =A0When the use= r > =A0 agent makes subsequent requests to the server, the user agent uses > =A0 the metadata and other information to determine whether to return the > =A0 name/value pairs in the Cookie header. Done. > Later in the section, there should be a bibliographic reference for the > "Netscape cookie specification". I'd be happy to add this if you let me know what citation you think we should use here. The problem is that I don't know of a canonical URL to cite now that the original Netscape site is defunct. > In the same paragraph "However, none of > these documents describe how the Cookie and Set-Cookie headers are > actually used on the Internet" is rather unclear and does not appear to > do the relevant documents justice. As reader I am left wondering if the > intend is to say they did not attempt to do so, or were incomplete, or > what else is wrong with them. That's just a statement of fact. I'm not sure what the intentions were of their creators, but (however we got here) we find ourselves in that situation. > In section 2.2 the imported rules should be phrased as grammar to make > them easer to scan and read, i.e., e.g. > > =A0ALPHA =3D ; A-Z / a-z > =A0... I looked a bunch of RFCs and this didn't appear to be that common. I'd be happy to do this if you can show me three relatively recent RFCs that use this pattern. > Further down "Multiple OWS characters that occur within field-content > SHOULD be replaced with a single SP before interpreting the field value > or forwarding the message downstream"; the "field-content" is confusing > here, I read it as production, but then the document does not define the > production; this could be fixed by adding a reference to the HTTP speci- > fication which defines it, or by turning it into "HTTP message-header > field-content"; adding a reference is probably better. > > It is unclear to me that intermediaries actually modify the headers like > that; has this been tested? I've removed that text. It's text from HTTPbis that isn't really relevant to how we use OWS in this document. > In section 2.3 we have "The terms request-host and request-uri refer to > the values the user agent would send to the server as, respectively, the > host (but not port) and the absoluteURI (http_URL) of the HTTP > Request-Line." I am not entirely sure how to read that; for example, the > "host" would be part of "absoluteURI" if it is sent in the Request-Line, > and sending an absoluteURI there is unusual (unless talking to a proxy). > Also, the reference to http_URL is probably incorrect if "https" URLs > are also permissable. I find it completely ridiculous that the specs make it so hard to say what URL and host we're sending a request to, which would seem to be the two most important things about an HTTP request. Hopefully someone will chime in with the magic incantation we're supposed to use here. > Section 3 starts with "We outline here ..."; words like "we" should be > avoided in technical specifications, one reason being that they may be > different to translate, another that it is unclear who "we" really is. Fixed. > Later in the section, "The origin server MAY send the user agent a > Set-Cookie response header with the same or different information, or it > MAY send no Set-Cookie header at all." It is unclear what "same" refers > to here. It sounds like this might refer to servers setting the same > cookie over and over again even if the client is already sending it back > but that does not become clear from the paragraph. It just means the server can send whatever it likes, including things that are the same or different from what it sent before or not sending things at all. > At the end of section 3 it should be pointed out that the do-not-fold > rule is inconsistent with RFC 2616. This is pointed out in HTTPbis. At worst, this inconsistency will exist for only a short time. > In section 3.1 it might be a good idea to use different amounts of white > space between protocol text and explanatory text depending on which text > belongs to which communication. (For example, with "Notice that the > server uses the Secure and HttpOnly attributes" I read back what the > example was because I had not noticed those attributes, and they are not > there because the text is discussing the following example). I fixed this by adding some introductory text instead of white space. > With "If the server wishes the user agent to persist the cookie over > multiple sessions" it might make sense to clarify what is meant by a > session here, for example, "(for instance, web browsers usually end a > session when the browser application is closed)". I've added quotes around the word sessions to indicate that this word as some meaning that will be discussed later. > In section 4 I think "some of the most esoteric semantics" needs to be > rephrased (what is meant by "esoteric", and "most esoteric" is hard to > parse; "semantics" is probably also problematic here). In general, it > does not become clear how the specification might be modified in the > future, other than that there is some "cruft" that might be dropped. I've removed the word "most" and added a forward reference to clarify what we mean here. We can't make clear how the protocol might change in the future because we don't know. :) > I note that with the grammar in 4.1.1 there can be some confusion with > respect to the RFC 2616 BNF variant and the standard ABNF language; of > particular concern is the "implied *LWS" rule in RFC 2616; there should > be a note of the grammar differences, if any, here, or maybe earler in > the document. We already say that: This specification uses the Augmented Backus-Naur Form (ABNF) notation of . > The grammar makes reference to "abs_path", but does not define what it > is. I've just made this . > I am not sure what qualifies as "attribute" in "Servers SHOULD NOT > include two attributes with the same name." I've added a definition. > and there should be a rationale for this somewhat surprising rule. Done. > In "Servers SHOULD NOT include two Set-Cookie header fields" make that > "two or more" or possibly better "Servers SHOULD include at most one". Done. > With '"Opaque" implies that the content is of interest and relevance > only to the origin server.' I do not think "implies" is the right word > here, "means" seems more appropriate. I also find the statement mis- > leading, if I have some script code running as part of a web page that > processes the cookie, that should be fine but contradicts the statement. I've removed this paragraph (which I think originated in 2109) and replaced it with the following: The semantics of the cookie-value are not defined by this document. > The point about the race condition and time_t appear to be out of place > in this section, that is more something for the security considerations > or a separate "Compatibility considerations" section. The point with the > race condition could also use an answer to "so what". This seems like an editorial issue. > In section 4.1.2 "When the user agent receives a Set-Cookie header, the > user agent stores the cookie in its cookie store." This should probably > introduce the "cookie store" before it takes it for granted (like, a > user agent has a cookie store, and when it receives cookies, then it > stores them inside it). Alternatively, it would suffice to say that it > simply stores them (and passes them along later). I've removed the concept of a cookie store from this section because it's not needed to explain what's going on. Adam From derhoermi@gmx.net Wed May 26 14:52:52 2010 Return-Path: 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 702D03A6966 for ; Wed, 26 May 2010 14:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 2fv2D8w1W0kW for ; Wed, 26 May 2010 14:52:50 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 391FB3A6A38 for ; Wed, 26 May 2010 14:52:49 -0700 (PDT) Received: (qmail invoked by alias); 26 May 2010 21:52:39 -0000 Received: from dslb-094-222-156-193.pools.arcor-ip.net (EHLO hive) [94.222.156.193] by mail.gmx.net (mp040) with SMTP; 26 May 2010 23:52:39 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX18YUPxHcl8YaOaSp7nrV0YGKi0Bk2wpqKzHFKmZDI o+sUW+b2TDB32V From: Bjoern Hoehrmann To: Adam Barth Date: Wed, 26 May 2010 23:52:30 +0200 Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: http-state@ietf.org Subject: Re: [http-state] Comments on draft-ietf-httpstate-cookie-08.txt (1 - 4.1.2.) X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 21:52:52 -0000 * Adam Barth wrote: >> Later in the section, there should be a bibliographic reference for the >> "Netscape cookie specification". > >I'd be happy to add this if you let me know what citation you think we >should use here. The problem is that I don't know of a canonical URL >to cite now that the original Netscape site is defunct. It does not have to include an address, something like 'Netscape Communications Corp., "Persistent Client State - HTTP Cookies"' would do. http://wp.netscape.com/newsref/std/cookie_spec.html should be the address, the Internet Archive has archived copies of it, and it should be fine to cite the Internet Archive address (at least I did do that in RFC 4329 for the JavaScript reference manual). >> In the same paragraph "However, none of >> these documents describe how the Cookie and Set-Cookie headers are >> actually used on the Internet" is rather unclear and does not appear to >> do the relevant documents justice. As reader I am left wondering if the >> intend is to say they did not attempt to do so, or were incomplete, or >> what else is wrong with them. > >That's just a statement of fact. I'm not sure what the intentions >were of their creators, but (however we got here) we find ourselves in >that situation. The text says "By contrast, this document attempts to specify the syntax and semantics of these headers as they are actually used on the Internet." That pretty much implies those specifications did not attempt to do that, which I do not think is a fact. >> In section 2.2 the imported rules should be phrased as grammar to make >> them easer to scan and read, i.e., e.g. >> >> ALPHA = ; A-Z / a-z >> ... > >I looked a bunch of RFCs and this didn't appear to be that common. >I'd be happy to do this if you can show me three relatively recent >RFCs that use this pattern. RFC 5536, RFC 5537, RFC 5538. The draft itself does this for other rules, like for `token`. >> In section 2.3 we have "The terms request-host and request-uri refer to >> the values the user agent would send to the server as, respectively, the >> host (but not port) and the absoluteURI (http_URL) of the HTTP >> Request-Line." I am not entirely sure how to read that; for example, the >> "host" would be part of "absoluteURI" if it is sent in the Request-Line, >> and sending an absoluteURI there is unusual (unless talking to a proxy). >> Also, the reference to http_URL is probably incorrect if "https" URLs >> are also permissable. > >I find it completely ridiculous that the specs make it so hard to say >what URL and host we're sending a request to, which would seem to be >the two most important things about an HTTP request. Hopefully >someone will chime in with the magic incantation we're supposed to use >here. That depends on how the algorithms later in the draft use the terms; it seems though instead of "request-host" they use "cannonicalized request- host" without defining what that is (there is a definition for a "ca- nonicalized host-name" which depends on "host-name"; perhaps that is supposed to be the "request-host" but I would have to debug the code to tell). >> Later in the section, "The origin server MAY send the user agent a >> Set-Cookie response header with the same or different information, or it >> MAY send no Set-Cookie header at all." It is unclear what "same" refers >> to here. It sounds like this might refer to servers setting the same >> cookie over and over again even if the client is already sending it back >> but that does not become clear from the paragraph. > >It just means the server can send whatever it likes, including things >that are the same or different from what it sent before or not sending >things at all. Well at the least add after "The origin server MAY send the user agent a Set-Cookie response header with the same or different information" some- thing like "as in the Cookie header it received in the request when re- sponding to it". Or better perhaps something like "The server may use the information in a cookie it receives to send a new Set-Cookie header or it may send no Set-Cookie header at all". >> At the end of section 3 it should be pointed out that the do-not-fold >> rule is inconsistent with RFC 2616. > >This is pointed out in HTTPbis. At worst, this inconsistency will >exist for only a short time. So long as RFC 2616 is a normative reference of this draft, it needs to call out contradictory requirements. >> I note that with the grammar in 4.1.1 there can be some confusion with >> respect to the RFC 2616 BNF variant and the standard ABNF language; of >> particular concern is the "implied *LWS" rule in RFC 2616; there should >> be a note of the grammar differences, if any, here, or maybe earler in >> the document. > >We already say that: > > This specification uses the Augmented Backus-Naur Form (ABNF) > notation of . I do not believe that is sufficient to avoid potential confusion es- pecially as grammar is importing rules from RFC 2616 (for which the implies LWS rule does not apply...) There should simply be a reminder that a different notation is used and that the implied lws rule applies neither to it nor the imported rules. >> With '"Opaque" implies that the content is of interest and relevance >> only to the origin server.' I do not think "implies" is the right word >> here, "means" seems more appropriate. I also find the statement mis- >> leading, if I have some script code running as part of a web page that >> processes the cookie, that should be fine but contradicts the statement. > >I've removed this paragraph (which I think originated in 2109) and >replaced it with the following: > > The semantics of the cookie-value are not defined by this > document. That is better. >> The point about the race condition and time_t appear to be out of place >> in this section, that is more something for the security considerations >> or a separate "Compatibility considerations" section. The point with the >> race condition could also use an answer to "so what". > >This seems like an editorial issue. Yes, I agree it is an editorial issue. -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de Am Badedeich 7 Telefon: +49(0)160/4415681 http://www.bjoernsworld.de 25899 Dagebll PGP Pub. KeyID: 0xA4357E78 http://www.websitedev.de/ From daniel@haxx.se Wed May 26 15:06:09 2010 Return-Path: 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 31EC23A6A26 for ; Wed, 26 May 2010 15:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_SE=0.35] 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 8fQNLZf03GEW for ; Wed, 26 May 2010 15:06:06 -0700 (PDT) Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by core3.amsl.com (Postfix) with ESMTP id 638003A6A2C for ; Wed, 26 May 2010 15:06:06 -0700 (PDT) Received: from giant.haxx.se (dast@giant.haxx.se [80.67.6.50]) by giant.haxx.se (8.14.3/8.14.3/Debian-9.1) with ESMTP id o4QM5tQ5001850; Thu, 27 May 2010 00:05:55 +0200 Date: Thu, 27 May 2010 00:05:55 +0200 (CEST) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Bjoern Hoehrmann In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.3.5 (giant.haxx.se [80.67.6.50]); Thu, 27 May 2010 00:05:56 +0200 (CEST) Cc: HTTP-state mailing list Subject: Re: [http-state] Comments on draft-ietf-httpstate-cookie-08.txt (1 - 4.1.2.) X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 22:06:09 -0000 On Wed, 26 May 2010, Bjoern Hoehrmann wrote: > It does not have to include an address, something like 'Netscape > Communications Corp., "Persistent Client State - HTTP Cookies"' would do. > http://wp.netscape.com/newsref/std/cookie_spec.html should be the address, > the Internet Archive has archived copies of it, and it should be fine to > cite the Internet Archive address (at least I did do that in RFC 4329 for > the JavaScript reference manual). The oldest reference archive.org has for that page seems to be http://web.archive.org/web/20020803110822/http://wp.netscape.com/newsref/std/cookie_spec.html but that's not the original URL for the spec. Back in 1999 I know it was hosted at http://www.netscape.com/newsref/std/cookie_spec.html then, but netscape.com has unfortunately blocked most of its contents from archive.org using robots.txt so it seems the above is now the oldest trace I can find. -- / daniel.haxx.se From derhoermi@gmx.net Wed May 26 15:14:03 2010 Return-Path: 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 8A8453A6A3C for ; Wed, 26 May 2010 15:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] 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 9utbTGNY9hJM for ; Wed, 26 May 2010 15:14:02 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id B09DD3A6A29 for ; Wed, 26 May 2010 15:14:01 -0700 (PDT) Received: (qmail invoked by alias); 26 May 2010 22:13:52 -0000 Received: from dslb-094-222-156-193.pools.arcor-ip.net (EHLO hive) [94.222.156.193] by mail.gmx.net (mp039) with SMTP; 27 May 2010 00:13:52 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX19XmbZ5f79XWal/2UPZV9n3QOrig8UOUjit+1bI4i nqawMzoMHIbngL From: Bjoern Hoehrmann To: Daniel Stenberg Date: Thu, 27 May 2010 00:13:42 +0200 Message-ID: <647rv5ttlmrpj7851hobefdbgafgtq00l4@hive.bjoern.hoehrmann.de> References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: HTTP-state mailing list Subject: Re: [http-state] Comments on draft-ietf-httpstate-cookie-08.txt (1 - 4.1.2.) X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 22:14:03 -0000 * Daniel Stenberg wrote: >The oldest reference archive.org has for that page seems to be > >http://web.archive.org/web/20020803110822/http://wp.netscape.com/newsref/std/cookie_spec.html > >but that's not the original URL for the spec. Back in 1999 I know it was >hosted at http://www.netscape.com/newsref/std/cookie_spec.html then, but >netscape.com has unfortunately blocked most of its contents from archive.org >using robots.txt so it seems the above is now the oldest trace I can find. Quite possible, it was also under `home` once... RFC 2965 has this: [Netscape] "Persistent Client State -- HTTP Cookies", available at , undated. Should not really matter either way though, so long as it's not just 'the so-called "Netscape cookie specification"'. -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de Am Badedeich 7 Telefon: +49(0)160/4415681 http://www.bjoernsworld.de 25899 Dagebll PGP Pub. KeyID: 0xA4357E78 http://www.websitedev.de/ From ietf@adambarth.com Wed May 26 16:03:58 2010 Return-Path: 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 BF4DA3A6A4F for ; Wed, 26 May 2010 16:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.118 X-Spam-Level: X-Spam-Status: No, score=-0.118 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FM_FORGED_GMAIL=0.622] 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 aRPh-78zUfdN for ; Wed, 26 May 2010 16:03:57 -0700 (PDT) Received: from mail-gx0-f220.google.com (mail-gx0-f220.google.com [209.85.217.220]) by core3.amsl.com (Postfix) with ESMTP id 8FEC83A6A4B for ; Wed, 26 May 2010 16:03:57 -0700 (PDT) Received: by gxk20 with SMTP id 20so4105741gxk.12 for ; Wed, 26 May 2010 16:03:45 -0700 (PDT) Received: by 10.100.243.18 with SMTP id q18mr11047157anh.166.1274915025684; Wed, 26 May 2010 16:03:45 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by mx.google.com with ESMTPS id a18sm2826052anl.3.2010.05.26.16.03.43 (version=SSLv3 cipher=RC4-MD5); Wed, 26 May 2010 16:03:43 -0700 (PDT) Received: by gyh4 with SMTP id 4so3618778gyh.31 for ; Wed, 26 May 2010 16:03:42 -0700 (PDT) Received: by 10.231.149.12 with SMTP id r12mr337430ibv.57.1274915003093; Wed, 26 May 2010 16:03:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.60.4 with HTTP; Wed, 26 May 2010 16:03:03 -0700 (PDT) In-Reply-To: References: From: Adam Barth Date: Wed, 26 May 2010 16:03:03 -0700 Message-ID: To: Bjoern Hoehrmann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: http-state@ietf.org Subject: Re: [http-state] Comments on draft-ietf-httpstate-cookie-08.txt (1 - 4.1.2.) X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 23:03:59 -0000 On Wed, May 26, 2010 at 2:52 PM, Bjoern Hoehrmann wrote= : >>> In the same paragraph "However, none of >>> these documents describe how the Cookie and Set-Cookie headers are >>> actually used on the Internet" is rather unclear and does not appear to >>> do the relevant documents justice. As reader I am left wondering if the >>> intend is to say they did not attempt to do so, or were incomplete, or >>> what else is wrong with them. >> >>That's just a statement of fact. =A0I'm not sure what the intentions >>were of their creators, but (however we got here) we find ourselves in >>that situation. > > The text says "By contrast, this document attempts to specify the > syntax and semantics of these headers as they are actually used on > the Internet." That pretty much implies those specifications did > not attempt to do that, which I do not think is a fact. I've removed the "by contrast." >>> In section 2.2 the imported rules should be phrased as grammar to make >>> them easer to scan and read, i.e., e.g. >>> >>> =A0ALPHA =3D ; A-Z / a-z >>> =A0... >> >>I looked a bunch of RFCs and this didn't appear to be that common. >>I'd be happy to do this if you can show me three relatively recent >>RFCs that use this pattern. > > RFC 5536, RFC 5537, RFC 5538. The draft itself does this for other > rules, like for `token`. Ok. I'll add this to my queue. >>> In section 2.3 we have "The terms request-host and request-uri refer to >>> the values the user agent would send to the server as, respectively, th= e >>> host (but not port) and the absoluteURI (http_URL) of the HTTP >>> Request-Line." I am not entirely sure how to read that; for example, th= e >>> "host" would be part of "absoluteURI" if it is sent in the Request-Line= , >>> and sending an absoluteURI there is unusual (unless talking to a proxy)= . >>> Also, the reference to http_URL is probably incorrect if "https" URLs >>> are also permissable. >> >>I find it completely ridiculous that the specs make it so hard to say >>what URL and host we're sending a request to, which would seem to be >>the two most important things about an HTTP request. =A0Hopefully >>someone will chime in with the magic incantation we're supposed to use >>here. > > That depends on how the algorithms later in the draft use the terms; it > seems though instead of "request-host" they use "cannonicalized request- > host" without defining what that is (there is a definition for a "ca- > nonicalized host-name" which depends on "host-name"; perhaps that is > supposed to be the "request-host" but I would have to debug the code to > tell). Host-name is a formal parameter which gets called with request-host as the actual parameter. You can canonicalize other sorts of hosts, if you like, besides those used in requests (hence the abstract). >>> Later in the section, "The origin server MAY send the user agent a >>> Set-Cookie response header with the same or different information, or i= t >>> MAY send no Set-Cookie header at all." It is unclear what "same" refers >>> to here. It sounds like this might refer to servers setting the same >>> cookie over and over again even if the client is already sending it bac= k >>> but that does not become clear from the paragraph. >> >>It just means the server can send whatever it likes, including things >>that are the same or different from what it sent before or not sending >>things at all. > > Well at the least add after "The origin server MAY send the user agent a > Set-Cookie response header with the same or different information" some- > thing like "as in the Cookie header it received in the request when re- > sponding to it". Or better perhaps something like "The server may use > the information in a cookie it receives to send a new Set-Cookie header > or it may send no Set-Cookie header at all". I'm not sure what that's buying us. It can use whatever it likes. >>> At the end of section 3 it should be pointed out that the do-not-fold >>> rule is inconsistent with RFC 2616. >> >>This is pointed out in HTTPbis. =A0At worst, this inconsistency will >>exist for only a short time. > > So long as RFC 2616 is a normative reference of this draft, it needs to > call out contradictory requirements. Fixed. >>> I note that with the grammar in 4.1.1 there can be some confusion with >>> respect to the RFC 2616 BNF variant and the standard ABNF language; of >>> particular concern is the "implied *LWS" rule in RFC 2616; there should >>> be a note of the grammar differences, if any, here, or maybe earler in >>> the document. >> >>We already say that: >> >> =A0 =A0 =A0 =A0This specification uses the Augmented Backus-Naur Form= (ABNF) >> =A0 =A0 =A0 =A0notation of . > > I do not believe that is sufficient to avoid potential confusion es- > pecially as grammar is importing rules from RFC 2616 (for which the > implies LWS rule does not apply...) There should simply be a reminder > that a different notation is used and that the implied lws rule applies > neither to it nor the imported rules. We don't want to alter the semantics of the imported rules. We wish to import them as languages, not as syntactic representations of those languages. The semantics of those terms are defined in their respective documents. Adam From derhoermi@gmx.net Wed May 26 17:08:57 2010 Return-Path: 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 86D863A6A62 for ; Wed, 26 May 2010 17:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.432 X-Spam-Level: X-Spam-Status: No, score=-0.432 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_50=0.001] 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 AtAnS6GY31Jc for ; Wed, 26 May 2010 17:08:56 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 7C6053A6A5A for ; Wed, 26 May 2010 17:08:55 -0700 (PDT) Received: (qmail invoked by alias); 27 May 2010 00:08:45 -0000 Received: from dslb-094-222-156-193.pools.arcor-ip.net (EHLO hive) [94.222.156.193] by mail.gmx.net (mp070) with SMTP; 27 May 2010 02:08:45 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1/pepcCENXpEt/6p6MiY8lWeHWWglsBkx5K0kM5Wl ADbMN010EAKuhi From: Bjoern Hoehrmann To: Adam Barth Date: Thu, 27 May 2010 02:08:35 +0200 Message-ID: <62brv55r2anbdt8ov0ro5dfn73u1ggdlhg@hive.bjoern.hoehrmann.de> References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: http-state@ietf.org Subject: Re: [http-state] Comments on draft-ietf-httpstate-cookie-08.txt (1 - 4.1.2.) X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 00:08:57 -0000 * Adam Barth wrote: >On Wed, May 26, 2010 at 2:52 PM, Bjoern Hoehrmann wrote: >>>> In the same paragraph "However, none of >>>> these documents describe how the Cookie and Set-Cookie headers are >>>> actually used on the Internet" is rather unclear and does not appear to >>>> do the relevant documents justice. As reader I am left wondering if the >>>> intend is to say they did not attempt to do so, or were incomplete, or >>>> what else is wrong with them. >>> >>>That's just a statement of fact. I'm not sure what the intentions >>>were of their creators, but (however we got here) we find ourselves in >>>that situation. >> >> The text says "By contrast, this document attempts to specify the >> syntax and semantics of these headers as they are actually used on >> the Internet." That pretty much implies those specifications did >> not attempt to do that, which I do not think is a fact. > >I've removed the "by contrast." Let me put this another way. Would you be surprised if I could find some examples of current real-world settings where the information provided in those specifications is sufficient to "make them work"? If not, then we cannot keep the text as it is as it suggests there are none. The point is that the current text is overly dismissive and inaccurate and fails to adequately explain what is so wrong with those speciciations. I think it would be entirely sufficient to say, for instance, that at time of publication, those specifications are inadequate to interoper- ably implement the prevalent Set-Cookie/Cookie mechanism; or for that matter say something like "The Cookie and Set-Cookie headers have been defined in Netscape and 2109 and this specification replaces them with improved whatever based on implementation experience; 2965 defines the Cookie2 and Set-Cookie2 headers, those are unaffected by this draft". >> That depends on how the algorithms later in the draft use the terms; it >> seems though instead of "request-host" they use "cannonicalized request- >> host" without defining what that is (there is a definition for a "ca- >> nonicalized host-name" which depends on "host-name"; perhaps that is >> supposed to be the "request-host" but I would have to debug the code to >> tell). > >Host-name is a formal parameter which gets called with request-host as >the actual parameter. You can canonicalize other sorts of hosts, if >you like, besides those used in requests (hence the abstract). Right now the first occurrence of "host-name" is in "A canonicalized host-name is the host-name converted to ..." which proceeds without saying what a "host-name" is in the first place. The first occurrence of "canonicalized request-host" is in "If the domain-attribute is identical to the canonicalized request-host:" which proceeds without saying how a "canonicalized request-host" is different from just a "request-host". The draft needs to say "A host-name is ..." and "A canonicalized request-host is ...". >I'm not sure what that's buying us. It can use whatever it likes. Again, the current text is "The origin server is free to ignore the Cookie header or use its contents for an application-defined purpose. The origin server MAY send the user agent a Set-Cookie response header with the same or different information". I believe this is difficult to read as you have to jump back from "same information" to "header or contents" and have to equate those. >> I do not believe that is sufficient to avoid potential confusion es- >> pecially as grammar is importing rules from RFC 2616 (for which the >> implies LWS rule does not apply...) There should simply be a reminder >> that a different notation is used and that the implied lws rule applies >> neither to it nor the imported rules. > >We don't want to alter the semantics of the imported rules. We wish >to import them as languages, not as syntactic representations of those >languages. The semantics of those terms are defined in their >respective documents. The implied lws rule in RFC 2616 has been a source of considerable confusion as it implied optional white space where people do not ex- pect it and because some rules use it and some rules do not and that is not made clear through the grammar but rather through prose and thus easy to miss. The draft builds on RFC 2616 but unlike most other extension header specifications does not re-use the grammar notation defined in RFC 2616 but a very slightly different notation, and then the draft imports rules from RFC 2616 where one has to pay very close attention to those notational differences and the surrounding prose to read the grammar correctly. I do not care much how, but I do think the draft needs to draw attention to this to avoid confusion. -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de Am Badedeich 7 Telefon: +49(0)160/4415681 http://www.bjoernsworld.de 25899 Dagebll PGP Pub. KeyID: 0xA4357E78 http://www.websitedev.de/ From ietf@adambarth.com Wed May 26 17:36:11 2010 Return-Path: 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 43D153A6A82 for ; Wed, 26 May 2010 17:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622] 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 K6fm4Z-tpE0g for ; Wed, 26 May 2010 17:36:10 -0700 (PDT) Received: from mail-gx0-f220.google.com (mail-gx0-f220.google.com [209.85.217.220]) by core3.amsl.com (Postfix) with ESMTP id 101A63A6A77 for ; Wed, 26 May 2010 17:36:09 -0700 (PDT) Received: by gxk20 with SMTP id 20so4190041gxk.12 for ; Wed, 26 May 2010 17:35:58 -0700 (PDT) Received: by 10.101.105.33 with SMTP id h33mr11528616anm.26.1274920558141; Wed, 26 May 2010 17:35:58 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by mx.google.com with ESMTPS id f6sm3214071anb.16.2010.05.26.17.35.56 (version=SSLv3 cipher=RC4-MD5); Wed, 26 May 2010 17:35:56 -0700 (PDT) Received: by gwj15 with SMTP id 15so2726885gwj.31 for ; Wed, 26 May 2010 17:35:55 -0700 (PDT) Received: by 10.231.125.87 with SMTP id x23mr7279576ibr.88.1274920555583; Wed, 26 May 2010 17:35:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.60.4 with HTTP; Wed, 26 May 2010 17:30:17 -0700 (PDT) In-Reply-To: <62brv55r2anbdt8ov0ro5dfn73u1ggdlhg@hive.bjoern.hoehrmann.de> References: <62brv55r2anbdt8ov0ro5dfn73u1ggdlhg@hive.bjoern.hoehrmann.de> From: Adam Barth Date: Wed, 26 May 2010 17:30:17 -0700 Message-ID: To: Bjoern Hoehrmann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: http-state@ietf.org Subject: Re: [http-state] Comments on draft-ietf-httpstate-cookie-08.txt (1 - 4.1.2.) X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 00:36:11 -0000 On Wed, May 26, 2010 at 5:08 PM, Bjoern Hoehrmann wrote= : > * Adam Barth wrote: >>On Wed, May 26, 2010 at 2:52 PM, Bjoern Hoehrmann wro= te: >>>>> In the same paragraph "However, none of >>>>> these documents describe how the Cookie and Set-Cookie headers are >>>>> actually used on the Internet" is rather unclear and does not appear = to >>>>> do the relevant documents justice. As reader I am left wondering if t= he >>>>> intend is to say they did not attempt to do so, or were incomplete, o= r >>>>> what else is wrong with them. >>>> >>>>That's just a statement of fact. =A0I'm not sure what the intentions >>>>were of their creators, but (however we got here) we find ourselves in >>>>that situation. >>> >>> The text says "By contrast, this document attempts to specify the >>> syntax and semantics of these headers as they are actually used on >>> the Internet." That pretty much implies those specifications did >>> not attempt to do that, which I do not think is a fact. >> >>I've removed the "by contrast." > > Let me put this another way. Would you be surprised if I could find some > examples of current real-world settings where the information provided > in those specifications is sufficient to "make them work"? The document says: [[ However, none of these documents describe how the Cookie and Set-Cookie headers are actually used on the Internet. ]] This statement is factually accurate: 1) The netscape cookie spec fails to describe reality because it talks about a date format that is very rarely used and what it says about the Domain attribute is complete hogwash. 2) RFC 2109 talks about a Version attribute, which is compete fantasy, and make a number of claims about the "," character which break the vast majority of servers. 3) RFC 2965 talks extensively about Set-Cookie2 and Cookie2, which aren't used by the vast majority of servers. > If not, then > we cannot keep the text as it is as it suggests there are none. The > point is that the current text is overly dismissive and inaccurate and > fails to adequately explain what is so wrong with those speciciations. I don't agree. The purpose of the text in the spec is to explain why the text in this document isn't consistent with those documents. Those documents do not reflect reality. This document is intended to reflect reality. > I think it would be entirely sufficient to say, for instance, that at > time of publication, those specifications are inadequate to interoper- > ably implement the prevalent Set-Cookie/Cookie mechanism; or for that > matter say something like "The Cookie and Set-Cookie headers have been > defined in Netscape and 2109 and this specification replaces them with > improved whatever based on implementation experience; 2965 defines the > Cookie2 and Set-Cookie2 headers, those are unaffected by this draft". Those statements would significantly less accurate than what's in the current draft. >>> That depends on how the algorithms later in the draft use the terms; it >>> seems though instead of "request-host" they use "cannonicalized request= - >>> host" without defining what that is (there is a definition for a "ca- >>> nonicalized host-name" which depends on "host-name"; perhaps that is >>> supposed to be the "request-host" but I would have to debug the code to >>> tell). >> >>Host-name is a formal parameter which gets called with request-host as >>the actual parameter. =A0You can canonicalize other sorts of hosts, if >>you like, besides those used in requests (hence the abstract). > > Right now the first occurrence of "host-name" is in "A canonicalized > host-name is the host-name converted to ..." which proceeds without > saying what a "host-name" is in the first place. Precisely. For example "f(x) =3D x + 1" doesn't proceed to say what "x" is in the first place. > The first occurrence > of "canonicalized request-host" is in "If the domain-attribute is > identical to the canonicalized request-host:" which proceeds without > saying how a "canonicalized request-host" is different from just a > "request-host". The draft needs to say "A host-name is ..." and "A > canonicalized request-host is ...". That's like say f(5) doesn't explain how that's different than 5. >>I'm not sure what that's buying us. =A0It can use whatever it likes. > > Again, the current text is "The origin server is free to ignore the > Cookie header or use its contents for an application-defined purpose. > The origin server MAY send the user agent a Set-Cookie response header > with the same or different information". I believe this is difficult > to read as you have to jump back from "same information" to "header > or contents" and have to equate those. I've changed this phrasing to: [[ The origin server is free to ignore the Cookie header or use its contents for an application-defined purpose. The origin server MAY send the us= er agent another Set-Cookie response header or it MAY send no Set-Cookie header at all. ]] >>> I do not believe that is sufficient to avoid potential confusion es- >>> pecially as grammar is importing rules from RFC 2616 (for which the >>> implies LWS rule does not apply...) There should simply be a reminder >>> that a different notation is used and that the implied lws rule applies >>> neither to it nor the imported rules. >> >>We don't want to alter the semantics of the imported rules. =A0We wish >>to import them as languages, not as syntactic representations of those >>languages. =A0The semantics of those terms are defined in their >>respective documents. > > The implied lws rule in RFC 2616 has been a source of considerable > confusion as it implied optional white space where people do not ex- > pect it and because some rules use it and some rules do not and that > is not made clear through the grammar but rather through prose and > thus easy to miss. The draft builds on RFC 2616 but unlike most other > extension header specifications does not re-use the grammar notation > defined in RFC 2616 but a very slightly different notation, and then > the draft imports rules from RFC 2616 where one has to pay very close > attention to those notational differences and the surrounding prose > to read the grammar correctly. I do not care much how, but I do think > the draft needs to draw attention to this to avoid confusion. Feel free to send me a diff with a proposed clarification. Adam From julian.reschke@gmx.de Thu May 27 00:49:51 2010 Return-Path: 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 678BB3A69EA for ; Thu, 27 May 2010 00:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[AWL=-5.600, BAYES_50=0.001, J_CHICKENPOX_43=0.6] 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 90Elbni9zuyG for ; Thu, 27 May 2010 00:49:49 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 6D13A3A6990 for ; Thu, 27 May 2010 00:49:48 -0700 (PDT) Received: (qmail invoked by alias); 27 May 2010 07:49:36 -0000 Received: from p508FFB57.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.251.87] by mail.gmx.net (mp057) with SMTP; 27 May 2010 09:49:36 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1//qytpL2f/nytlnau+v6bLCvFWi1mt/6SIXBFIhz BU+fZSBP974eQt Message-ID: <4BFE240A.4030905@gmx.de> Date: Thu, 27 May 2010 09:49:30 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Adam Barth References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: http-state@ietf.org Subject: Re: [http-state] Comments on draft-ietf-httpstate-cookie-08.txt (1 - 4.1.2.) X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 07:49:51 -0000 On 26.05.2010 22:45, Adam Barth wrote: > ... > On Wed, May 26, 2010 at 10:22 AM, Bjoern Hoehrmann wrote: >> Some comments on draft-ietf-httpstate-cookie-08.txt: > ... >> Later in the section, there should be a bibliographic reference for the >> "Netscape cookie specification". > > I'd be happy to add this if you let me know what citation you think we > should use here. The problem is that I don't know of a canonical URL > to cite now that the original Netscape site is defunct. > ... I agree that this needs a citation, even if we can't provide the original URI. Proposal: create something on purl.org (I know the RFC Editor is likely to accept that), and let it redirect to the best copy we can find. If that breaks, we still can update the purl. >> In the same paragraph "However, none of >> these documents describe how the Cookie and Set-Cookie headers are >> actually used on the Internet" is rather unclear and does not appear to >> do the relevant documents justice. As reader I am left wondering if the >> intend is to say they did not attempt to do so, or were incomplete, or >> what else is wrong with them. > > That's just a statement of fact. I'm not sure what the intentions > were of their creators, but (however we got here) we find ourselves in > that situation. That statement is kind of confusing to people who do not already know the history. Maybe it would make sense to cite [Kri2001] Kristol, D., HTTP Cookies: Standards, Privacy, and Politics, ACM Transactions on Internet Technology Vol. 1, #2, November 2001, . to give some more context. >> In section 2.2 the imported rules should be phrased as grammar to make >> them easer to scan and read, i.e., e.g. >> >> ALPHA = ; A-Z / a-z >> ... > > I looked a bunch of RFCs and this didn't appear to be that common. > I'd be happy to do this if you can show me three relatively recent > RFCs that use this pattern. Adam is right; not expanding the RFC 5234 base rules is quite common. > ... >> In section 2.3 we have "The terms request-host and request-uri refer to >> the values the user agent would send to the server as, respectively, the >> host (but not port) and the absoluteURI (http_URL) of the HTTP >> Request-Line." I am not entirely sure how to read that; for example, the >> "host" would be part of "absoluteURI" if it is sent in the Request-Line, >> and sending an absoluteURI there is unusual (unless talking to a proxy). >> Also, the reference to http_URL is probably incorrect if "https" URLs >> are also permissable. > > I find it completely ridiculous that the specs make it so hard to say > what URL and host we're sending a request to, which would seem to be > the two most important things about an HTTP request. Hopefully > someone will chime in with the magic incantation we're supposed to use > here. If you're willing to wait for httpbis, "Effective Request URI" might be the right thing (). > ... >> Later in the section, "The origin server MAY send the user agent a >> Set-Cookie response header with the same or different information, or it >> MAY send no Set-Cookie header at all." It is unclear what "same" refers >> to here. It sounds like this might refer to servers setting the same >> cookie over and over again even if the client is already sending it back >> but that does not become clear from the paragraph. > > It just means the server can send whatever it likes, including things > that are the same or different from what it sent before or not sending > things at all. I also have to point out that this use of MAY is irritating; just state that this is optional behavior. >> At the end of section 3 it should be pointed out that the do-not-fold >> rule is inconsistent with RFC 2616. > > This is pointed out in HTTPbis. At worst, this inconsistency will > exist for only a short time. HTTPbis currently says: "Note: The "Set-Cookie" header as implemented in practice (as opposed to how it is specified in [RFC2109]) can occur multiple times, but does not use the list syntax, and thus cannot be combined into a single line. (See Appendix A.2.3 of [Kri2001] for details.) Also note that the Set-Cookie2 header specified in [RFC2965] does not share this problem." -- So the Cookie spec has an additional requirement compared both to RFC 2616 and HTTPbis, and that should be pointed out (and explained!). > ... >> The grammar makes reference to "abs_path", but does not define what it >> is. > > I've just made this. Is this supposed to be the same as abs_path in RFC 2396? If it is, RFC 3986 has replaced this with path-absolute. More consistency with these specs would be good. > ... > I've removed the concept of a cookie store from this section because > it's not needed to explain what's going on. > ... It's good that you already improved the spec; can you please post this somewhere (not as new ID!), so people doing the LC review can check whether something has already been addressed? Best regards, Julian From julian.reschke@gmx.de Thu May 27 05:31:41 2010 Return-Path: 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 032343A6AD2 for ; Thu, 27 May 2010 05:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.139 X-Spam-Level: X-Spam-Status: No, score=-4.139 tagged_above=-999 required=5 tests=[AWL=-3.954, BAYES_40=-0.185] 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 1igY0btdFObx for ; Thu, 27 May 2010 05:31:38 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 78F813A6AC3 for ; Thu, 27 May 2010 05:31:37 -0700 (PDT) Received: (qmail invoked by alias); 27 May 2010 12:31:26 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.116]) [217.91.35.233] by mail.gmx.net (mp009) with SMTP; 27 May 2010 14:31:26 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+GeS56FWOGEfV3oS1/JzC8iepnJtKHvLcF4h4ybd Ln+9Deo0KK/ZEl Message-ID: <4BFE6616.1060409@gmx.de> Date: Thu, 27 May 2010 14:31:18 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: "http-state@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [http-state] RFC "updates" relations X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 12:31:41 -0000 Hi, when the new Cookie spec will be ready, it will obsolete RFC 2109. But so does RFC 2965. Maybe, when we get there, we should instruct the RFC Editor to remove the "2965->updates->2109" relation in order to avoid any confusion what the relevant spec for Set-Cookie is. Best regards, Julian From julian.reschke@gmx.de Thu May 27 05:33:21 2010 Return-Path: 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 18A773A6AD0 for ; Thu, 27 May 2010 05:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.028 X-Spam-Level: X-Spam-Status: No, score=-4.028 tagged_above=-999 required=5 tests=[AWL=-1.429, BAYES_00=-2.599] 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 wA+j2lWxI8rC for ; Thu, 27 May 2010 05:33:20 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 21C843A6AC3 for ; Thu, 27 May 2010 05:33:19 -0700 (PDT) Received: (qmail invoked by alias); 27 May 2010 12:33:09 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.116]) [217.91.35.233] by mail.gmx.net (mp068) with SMTP; 27 May 2010 14:33:09 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18dKMxm6E8dxGINBkwtKNBy/G5WG+I04Jvx0cN6bx 8Kt2BfVA5iq2hR Message-ID: <4BFE6682.10608@gmx.de> Date: Thu, 27 May 2010 14:33:06 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: "http-state@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [http-state] Lack of IANA Considerations X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 12:33:21 -0000 Hi, we need an IANA Considerations Section that instructs IANA to update the permanent header registrations for "Cookie" and "Set-Cookie". (Adam, I'll produce the necessary spec text if you want). Best regards, Julian From derhoermi@gmx.net Thu May 27 07:34:20 2010 Return-Path: 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 449C93A6B02 for ; Thu, 27 May 2010 07:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.324 X-Spam-Level: X-Spam-Status: No, score=-0.324 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_50=0.001] 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 Y6Jqk6eUWlg7 for ; Thu, 27 May 2010 07:34:14 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id D8E183A6905 for ; Thu, 27 May 2010 07:34:13 -0700 (PDT) Received: (qmail invoked by alias); 27 May 2010 14:34:03 -0000 Received: from dslb-094-222-156-193.pools.arcor-ip.net (EHLO hive) [94.222.156.193] by mail.gmx.net (mp006) with SMTP; 27 May 2010 16:34:03 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1/+Nup5toD+ropfJH3n6cSra315Dy8pTHJA+dxRb6 SbRKY/T/84Xu/C From: Bjoern Hoehrmann To: Adam Barth Date: Thu, 27 May 2010 16:33:52 +0200 Message-ID: References: <62brv55r2anbdt8ov0ro5dfn73u1ggdlhg@hive.bjoern.hoehrmann.de> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: http-state@ietf.org Subject: Re: [http-state] Comments on draft-ietf-httpstate-cookie-08.txt (1 - 4.1.2.) X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 14:34:20 -0000 * Adam Barth wrote: >I don't agree. The purpose of the text in the spec is to explain why >the text in this document isn't consistent with those documents. >Those documents do not reflect reality. This document is intended to >reflect reality. The purpose of an introductory section is to take the reader from where he is standing and explain to him where things will be going from there. Pointing out that the ten years old specification for the Set-Cookie2 and Cookie2 headers does not describe how the Set-Cookie and Cookie headers are used today does not do that, it rather misleads the reader. Telling the reader that even older specifications do not describe how the headers are used currently is not helpful either unless it is also explained how and to what degree things are different; what it says is "You know stuff about cookies. It's wrong or not, continue with the next three dozens of pages to find out." That leaves the reader constantly wondering. Drawing attention to the obvious should be avoided as readers would have to expend additional effort to confirm that what is being pointed out is indeed obvious -- and not some subtlety they've missed -- for no gain. If a specification replaces two older ones based on implementation ex- perience, then it is obvious that the older specifications do not re- flect current practise equally well. >> Right now the first occurrence of "host-name" is in "A canonicalized >> host-name is the host-name converted to ..." which proceeds without >> saying what a "host-name" is in the first place. > >Precisely. For example "f(x) = x + 1" doesn't proceed to say what "x" >is in the first place. In mathematics, function definitions require a specification of their domain and codomain; you would know what `x` is, namely a member of the domain of the function; but without specifying the domain you do not have a function. In the context of "hosts" the term "canonicalized" is overloaded with definitions, RFC 1123 for example defines it quite differently than draft-ietf-httpstate-cookie-08.txt. Further, the permissable range of values for `request-host` is larger than the apparent domain of the draft's `canonicalized` "function". For instance, the "host" can be an IP-Literal, but you cannot apply the ToASCII function to those -- they are outside its domain. So I've found no reason to assume that I am supposed to lookup "canonicalized request-host" under "A canonicalized host-name is". >> The implied lws rule in RFC 2616 has been a source of considerable >> confusion as it implied optional white space where people do not ex- >> pect it and because some rules use it and some rules do not and that >> is not made clear through the grammar but rather through prose and >> thus easy to miss. The draft builds on RFC 2616 but unlike most other >> extension header specifications does not re-use the grammar notation >> defined in RFC 2616 but a very slightly different notation, and then >> the draft imports rules from RFC 2616 where one has to pay very close >> attention to those notational differences and the surrounding prose >> to read the grammar correctly. I do not care much how, but I do think >> the draft needs to draw attention to this to avoid confusion. > >Feel free to send me a diff with a proposed clarification. If you require help to turn my sketch into proper text, you would need to tell what difficulty you are having. -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de Am Badedeich 7 Telefon: +49(0)160/4415681 http://www.bjoernsworld.de 25899 Dagebll PGP Pub. KeyID: 0xA4357E78 http://www.websitedev.de/ From ietf@adambarth.com Thu May 27 10:01:55 2010 Return-Path: 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 0718A3A6B55 for ; Thu, 27 May 2010 10:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 fHOfGj43HRgM for ; Thu, 27 May 2010 10:01:54 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 6771A3A68AE for ; Thu, 27 May 2010 10:01:54 -0700 (PDT) Received: by pxi19 with SMTP id 19so101901pxi.31 for ; Thu, 27 May 2010 10:01:40 -0700 (PDT) Received: by 10.114.251.23 with SMTP id y23mr9332379wah.42.1274979700258; Thu, 27 May 2010 10:01:40 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by mx.google.com with ESMTPS id f1sm6349870ibg.15.2010.05.27.10.01.37 (version=SSLv3 cipher=RC4-MD5); Thu, 27 May 2010 10:01:38 -0700 (PDT) Received: by yxn35 with SMTP id 35so15233yxn.31 for ; Thu, 27 May 2010 10:01:37 -0700 (PDT) Received: by 10.231.158.130 with SMTP id f2mr1764764ibx.40.1274979697254; Thu, 27 May 2010 10:01:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.60.4 with HTTP; Thu, 27 May 2010 10:01:17 -0700 (PDT) In-Reply-To: <4BFE6682.10608@gmx.de> References: <4BFE6682.10608@gmx.de> From: Adam Barth Date: Thu, 27 May 2010 10:01:17 -0700 Message-ID: To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Cc: "http-state@ietf.org" Subject: Re: [http-state] Lack of IANA Considerations X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 17:01:55 -0000 Thanks. I'd appreciate that. Adam On Thu, May 27, 2010 at 5:33 AM, Julian Reschke wrote: > Hi, > > we need an IANA Considerations Section that instructs IANA to update the > permanent header registrations for "Cookie" and "Set-Cookie". > > (Adam, I'll produce the necessary spec text if you want). > > Best regards, Julian > _______________________________________________ > http-state mailing list > http-state@ietf.org > https://www.ietf.org/mailman/listinfo/http-state > From julian.reschke@gmx.de Thu May 27 10:46:10 2010 Return-Path: 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 1B2363A685E for ; Thu, 27 May 2010 10:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.249 X-Spam-Level: X-Spam-Status: No, score=-1.249 tagged_above=-999 required=5 tests=[AWL=-1.250, BAYES_50=0.001] 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 Q7Xhkzk5WIso for ; Thu, 27 May 2010 10:46:09 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id DD53E3A680B for ; Thu, 27 May 2010 10:46:08 -0700 (PDT) Received: (qmail invoked by alias); 27 May 2010 17:45:56 -0000 Received: from p508FFB57.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.251.87] by mail.gmx.net (mp015) with SMTP; 27 May 2010 19:45:56 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+6/bRvwyi6RSsfg2C2PgRM1XJA9KrwwIzjizeCRG 9DyKwBGtS/GgNK Message-ID: <4BFEAFCF.1040504@gmx.de> Date: Thu, 27 May 2010 19:45:51 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Adam Barth References: <4BFE6682.10608@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "http-state@ietf.org" Subject: Re: [http-state] Lack of IANA Considerations X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 17:46:10 -0000 On 27.05.2010 19:01, Adam Barth wrote: > Thanks. I'd appreciate that. > > Adam Here we go - diff relative to -08.xml: 1391a1392,1416 > >
> > The permanent message header registry (see ) > should be updated with the following registrations: > > >
> Header field name: Cookie > Applicable protocol: http > Status: standard > Author/Change controller: IETF > Specification document: this specification () >
> >
> Header field name: Set-Cookie > Applicable protocol: http > Status: standard > Author/Change controller: IETF > Specification document: this specification () >
> >
> 1648a1674,1684 > > > Registration Procedures for Message Header Fields > > > > > > > > From derhoermi@gmx.net Fri May 28 12:17:26 2010 Return-Path: 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 151DB3A682D for ; Fri, 28 May 2010 12:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.259 X-Spam-Level: X-Spam-Status: No, score=-0.259 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_50=0.001] 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 hGzV7teN-BOV for ; Fri, 28 May 2010 12:17:24 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 9D99B3A6824 for ; Fri, 28 May 2010 12:17:20 -0700 (PDT) Received: (qmail invoked by alias); 28 May 2010 19:17:09 -0000 Received: from dslb-094-222-135-191.pools.arcor-ip.net (EHLO hive) [94.222.135.191] by mail.gmx.net (mp070) with SMTP; 28 May 2010 21:17:09 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX18iYjh/2CEiCspiXpkyLGaUAfC6VNl1dHC5+oclgD 7d1QfsPW+P7LT/ From: Bjoern Hoehrmann To: http-state@ietf.org Date: Fri, 28 May 2010 21:16:59 +0200 Message-ID: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Subject: [http-state] Comments on draft-ietf-httpstate-cookie-08.txt (4.1.2.2 - 5.2.6) X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 19:17:26 -0000 Hi, Some additional comments on draft-ietf-httpstate-cookie-08.txt: In section 4.1.2.2, "The user agent is not required to retain the cookie until the specified date has passed." `Max-Age` does not specify a date, it specifies a duration. Later in the section: "WARNING: Not all user agents support the Max-Age attribute. User agents that do not support the Max-Age attribute will ignore the attribute." I see no reason why this needs to be a "WARNING" rather than a note, and the text needs to clarify that support for the attribute is not optional but rather required. In section 4.1.2.3, 'For example, if the Domain attribute contains the value "example.com", the user agent will include the cookie in the ...'; "Contains" is the wrong word here, the value would have to be equivalent to it, not just contain it as substring. And "will" is also the wrong word. Later in the section, "(Note that a leading U+002E ("."), if present, is ignored even though that character is not permitted by the subdomain production in [RFC1034].)" This needs to be rephrased so it refers to the legal syntax of the attribute, otherwise it is unclear whether it is conforming to send it. The subsequent "Warning" needs to explain how and why the described be- haviour is erroneous. Later, "The user agent will reject cookies (refuse to store them in the cookie store) unless the Domain attribute specifies a scope for the cookie that would include the origin server. For example, the user agent will accept a Domain attribute ..." This needs to be rephrased, it starts out saying the whole cookie will be rejected, but then only re- fers to the Domain attribute being rejected. In section 4.1.2.4, "If the server omits the Path attribute, the user agent will use the directory of the request-uri's path component as the default value." It is not clear what the "directory" of a path component is, RFC 3986 for example does not define it. The second paragraph needs a forward reference to where the matching is explained. The forward reference in the third paragraph should be more precise, section 8 is rather long. I note that section 4.1.2.6 does not mention that some user agents do not support the attribute. I am not sure if it should. In section 4.2.1, "The user agent returns stored cookies ..." this should probably not use "return" but something like "pass" as the cookie may come from a different source than the server. (This also applies to section 4.2.2). "If the server conforms to the requirements in Section 4.1, the requirements in the Section 5 will cause the user agent to return a Cookie header that conforms to the following grammar" This seems some- what confused. If the user agent is free to send whatever it wants in the header, perhaps because the `Set-Cookie` it processed was invalid, then this should be clearly stated here, more so if it is required to. In section 5.1.1, "If the found-day-of-month flag is not set ..." Up to this point it has not been explained what this flag is. The same goes probably for all "flags". Definitions need to be added. The surprising requirements in this section need to be accompanied by some rationale, for example, accepting 1601 as year but not 1600 is surprising and so is the 68/69 boundary. In section 5.1.2 it needs to be explained what is supposed to happen if the normalization process fails, e.g. when ToASCII fails. There should be a reminder that using non-ASCII characters directly is prohibited. There needs to be a discussion, I am not sure this is the right place, on the handling of permissable HTTP "hosts" (non-DNS names, IP-Literals and IPv4 addresses, for instance); some questions are, is it intentional that the Domain attribute disallows setting the attribute to a IPv4 address, would a leading '.' in the attribute still be stripped, if such host specifications are disallowed, must all cookies coming from them be rejected? With a Set-Cookie from 127.0.0.1 with no Domain attribute, is it incorrect to imply Domain=127.0.0.1? (I don't care, the specification however needs to discuss those questions). In section 5.1.3, there is a reference to `abs_path` without explaining where it comes from (RFC 3986 no longer specifies that symbol). The draft needs to explain how to handle a Set-Cookie header in a reply to an `OPTIONS *` request. Right now it seems `uri-path` would be unde- fined in that case, but the draft does not say what the consequence is. There should be an explicit mention of the case, not just adjusted algo- rithms. In section 5.2, if the draft takes the position that HTTP header values are sequences of octets and not Unicode code points, then it needs to be explained at the beginning of this section how those octets are turned into characters (at least so long as it refers directly to the header and not some pre-processed value based on it, and so long it refers to characters instead of octets). In section 5.2.1 and subsequent sections the term "case-insensitively matches" is not defined; this should probably be defined in the termi- nology section. Also in 5.2.1, using "last" and "first" in the context of time strikes me as poor form. I doubt the draft should require implementations to use the "last" Date header, there are plenty of HTTP implementations where that is not possible as the headers are only accessible in folded form. Section 4.1.2.1 also should be updated to clearly express that even though the expiry time is set in an absolute form, it'll be handled as relative value, as that is rather surprising. regards, -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de Am Badedeich 7 Telefon: +49(0)160/4415681 http://www.bjoernsworld.de 25899 Dagebll PGP Pub. KeyID: 0xA4357E78 http://www.websitedev.de/ From ietf@adambarth.com Fri May 28 12:57:12 2010 Return-Path: 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 A56083A681F for ; Fri, 28 May 2010 12:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.583 X-Spam-Level: X-Spam-Status: No, score=-0.583 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622] 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 35R7TryB0OMR for ; Fri, 28 May 2010 12:57:11 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 4C0653A6806 for ; Fri, 28 May 2010 12:57:11 -0700 (PDT) Received: by gwj19 with SMTP id 19so1325471gwj.31 for ; Fri, 28 May 2010 12:56:58 -0700 (PDT) Received: by 10.231.185.86 with SMTP id cn22mr900792ibb.69.1275076618609; Fri, 28 May 2010 12:56:58 -0700 (PDT) Received: from mail-yw0-f173.google.com (mail-yw0-f173.google.com [209.85.211.173]) by mx.google.com with ESMTPS id t28sm12283935ibg.0.2010.05.28.12.56.56 (version=SSLv3 cipher=RC4-MD5); Fri, 28 May 2010 12:56:57 -0700 (PDT) Received: by ywh3 with SMTP id 3so1196193ywh.31 for ; Fri, 28 May 2010 12:56:55 -0700 (PDT) Received: by 10.42.2.201 with SMTP id 9mr874187icl.7.1275076615692; Fri, 28 May 2010 12:56:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.60.4 with HTTP; Fri, 28 May 2010 12:55:20 -0700 (PDT) In-Reply-To: References: From: Adam Barth Date: Fri, 28 May 2010 12:55:20 -0700 Message-ID: To: Bjoern Hoehrmann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: http-state@ietf.org Subject: Re: [http-state] Comments on draft-ietf-httpstate-cookie-08.txt (4.1.2.2 - 5.2.6) X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 19:57:12 -0000 On Fri, May 28, 2010 at 12:16 PM, Bjoern Hoehrmann wrot= e: > In section 4.1.2.2, "The user agent is not required to retain the cookie > until the specified date has passed." `Max-Age` does not specify a date, > it specifies a duration. Fixed. > Later in the section: "WARNING: Not all user agents support the Max-Age > attribute. User agents that do not support the Max-Age attribute will > ignore the attribute." I see no reason why this needs to be a "WARNING" > rather than a note, Changed to a NOTE. > and the text needs to clarify that support for the > attribute is not optional but rather required. That requirement is contained in the section entitled User Agent Requiremen= ts. > In section 4.1.2.3, 'For example, if the Domain attribute contains the > value "example.com", the user agent will include the cookie in the ...'; > "Contains" is the wrong word here, the value would have to be equivalent > to it, not just contain it as substring. Fixed. > And "will" is also the wrong word. What word do you suggest instead? > Later in the section, "(Note that a leading U+002E ("."), if present, > is ignored even though that character is not permitted by the subdomain > production in [RFC1034].)" This needs to be rephrased so it refers to > the legal syntax of the attribute, otherwise it is unclear whether it > is conforming to send it. I've changed this to the following: [[ Note that a leading U+002E ("."), if present, is ignored even though that character= is not permitted. ]] The "." is not permitted, but many places that talk about cookies believe in the cargo cult of a leading "." character, hence the note. > The subsequent "Warning" needs to explain how and why the described be- > haviour is erroneous. I don't understand this comment. It's a warning that some existing user agents behave incorrect w.r.t. the description that section. That behavior is erroneous: it is in error. > Later, "The user agent will reject cookies (refuse to store them in the > cookie store) unless the Domain attribute specifies a scope for the > cookie that would include the origin server. =A0For example, the user > agent will accept a Domain attribute ..." This needs to be rephrased, it > starts out saying the whole cookie will be rejected, but then only re- > fers to the Domain attribute being rejected. Fixed. > In section 4.1.2.4, "If the server omits the Path attribute, the user > agent will use the directory of the request-uri's path component as the > default value." It is not clear what the "directory" of a path component > is, RFC 3986 for example does not define it. I've put directory in quotes. The definition is in Section 5. > The second paragraph needs a forward reference to where the matching is > explained. The forward reference in the third paragraph should be more > precise, section 8 is rather long. I'm sure we need a forward reference. This is all just informative text an= yway. > I note that section 4.1.2.6 does not mention that some user agents do > not support the attribute. I am not sure if it should. There exist, of course, user agents with all manner of bugs and lack of support. We've only called out issues that are prevalent and/or particularly problematic. > In section 4.2.1, "The user agent returns stored cookies ..." this > should probably not use "return" but something like "pass" as the cookie > may come from a different source than the server. (This also applies to > section 4.2.2). Changed to "sends". > "If the server conforms to the requirements in Section 4.1, the > requirements in the Section 5 will cause the user agent to return a > Cookie header that conforms to the following grammar" This seems some- > what confused. If the user agent is free to send whatever it wants in > the header, perhaps because the `Set-Cookie` it processed was invalid, > then this should be clearly stated here, more so if it is required to. Section 4 does not contain any requirements on the user agent. All the user agent requirements are contained in Section 5. This sentence just states some consequences of those requirements. > In section 5.1.1, "If the found-day-of-month flag is not set ..." Up to > this point it has not been explained what this flag is. The same goes > probably for all "flags". Definitions need to be added. They don't mean anything other than what the text says. There's nothing to define. > The surprising requirements in this section need to be accompanied by > some rationale, for example, accepting 1601 as year but not 1600 is > surprising and so is the 68/69 boundary. The reason is just that's how the protocol works. It's odd, but that's how it works. > In section 5.1.2 it needs to be explained what is supposed to happen if > the normalization process fails, e.g. when ToASCII fails. Can you provide a test case that illustrates behavior that you think is not defined? > There should > be a reminder that using non-ASCII characters directly is prohibited. Who is prohibited from using non-ASCII characters for what? I don't understand your request. > There needs to be a discussion, I am not sure this is the right place, > on the handling of permissable HTTP "hosts" (non-DNS names, IP-Literals > and IPv4 addresses, for instance); some questions are, is it intentional > that the Domain attribute disallows setting the attribute to a IPv4 > address, would a leading '.' in the attribute still be stripped, if such > host specifications are disallowed, must all cookies coming from them be > rejected? With a Set-Cookie from 127.0.0.1 with no Domain attribute, is > it incorrect to imply Domain=3D127.0.0.1? (I don't care, the specificatio= n > however needs to discuss those questions). Can you provide a test case that illustrates behavior that you think is not defined? > In section 5.1.3, there is a reference to `abs_path` without explaining > where it comes from (RFC 3986 no longer specifies that symbol). Fixed. > The draft needs to explain how to handle a Set-Cookie header in a reply > to an `OPTIONS *` request. Right now it seems `uri-path` would be unde- > fined in that case, but the draft does not say what the consequence is. > There should be an explicit mention of the case, not just adjusted algo- > rithms. The draft says: [[ If the uri-path is empty or if first character of the uri-pa= th is not a U+002F ("/") character, output U+002F ("/") and skip t= he remaining steps. ]] Doesn't this fall under the case of the uri-path being empty? > In section 5.2, if the draft takes the position that HTTP header values > are sequences of octets and not Unicode code points, then it needs to be > explained at the beginning of this section how those octets are turned > into characters (at least so long as it refers directly to the header > and not some pre-processed value based on it, and so long it refers to > characters instead of octets). The octets are never turned into characters. > In section 5.2.1 and subsequent sections the term "case-insensitively > matches" is not defined; this should probably be defined in the termi- > nology section. I'll be happy to add this if you can provide the definition you'd like to see in the terminology section. > Also in 5.2.1, using "last" and "first" in the context of time strikes > me as poor form. Fixed. > I doubt the draft should require implementations to use the "last" Date > header, there are plenty of HTTP implementations where that is not > possible as the headers are only accessible in folded form. As far as I can tell, that's how the protocol works. Can you provide a test case that shows otherwise? > Section > 4.1.2.1 also should be updated to clearly express that even though the > expiry time is set in an absolute form, it'll be handled as relative > value, as that is rather surprising. There are lots of details explained in Section 5 that are not presented in Section 4. It's unclear why this particular detail merits inclusion. Adam From derhoermi@gmx.net Fri May 28 16:06:11 2010 Return-Path: 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 BE3613A6979 for ; Fri, 28 May 2010 16:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.263 X-Spam-Level: X-Spam-Status: No, score=0.263 tagged_above=-999 required=5 tests=[AWL=-0.696, BAYES_20=-0.74, TVD_FUZZY_SYMBOL=1.699] 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 X8JFhNIRm41W for ; Fri, 28 May 2010 16:06:09 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 56D653A697B for ; Fri, 28 May 2010 16:06:08 -0700 (PDT) Received: (qmail invoked by alias); 28 May 2010 23:05:57 -0000 Received: from dslb-094-222-135-191.pools.arcor-ip.net (EHLO hive) [94.222.135.191] by mail.gmx.net (mp055) with SMTP; 29 May 2010 01:05:57 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1/JwAYi+IvJYLPWtE3D0uIOrP+Lwb8nZFR+FYO+Dn g6WszdpXF84x1q From: Bjoern Hoehrmann To: Adam Barth Date: Sat, 29 May 2010 01:05:47 +0200 Message-ID: <9c8006lme07degqokchpkk0jq5vkt1njdu@hive.bjoern.hoehrmann.de> References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: http-state@ietf.org Subject: Re: [http-state] Comments on draft-ietf-httpstate-cookie-08.txt (4.1.2.2 - 5.2.6) X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 23:06:11 -0000 * Adam Barth wrote: >> Later in the section: "WARNING: Not all user agents support the Max-Age >> attribute. User agents that do not support the Max-Age attribute will >> ignore the attribute." I see no reason why this needs to be a "WARNING" >> rather than a note, > >Changed to a NOTE. > >> and the text needs to clarify that support for the >> attribute is not optional but rather required. > >That requirement is contained in the section entitled User Agent Requirements. The point is that the text does not say those user agents are non-con- forming, so the casual reader may well assume support is optional. It should say something like "Some older user agents do not support it", or whatever, so long as it is clear that they are not compliant. >> And "will" is also the wrong word. > >What word do you suggest instead? I don't have a ready proposal how to rephrase it, but the point is that they may not do so and still conform to the specification. >> The subsequent "Warning" needs to explain how and why the described be- >> haviour is erroneous. > >I don't understand this comment. It's a warning that some existing >user agents behave incorrect w.r.t. the description that section. >That behavior is erroneous: it is in error. A remedy would be to state in the note what the correct behavior is, rather than simply say it is wrong. Obviously the developers of the misbehaving user agents did not think it wrong. >> In section 4.1.2.4, "If the server omits the Path attribute, the user >> agent will use the directory of the request-uri's path component as the >> default value." It is not clear what the "directory" of a path component >> is, RFC 3986 for example does not define it. > >I've put directory in quotes. The definition is in Section 5. This probably works if you include the forward reference to the re- levant sub-section of section 5. >> "If the server conforms to the requirements in Section 4.1, the >> requirements in the Section 5 will cause the user agent to return a >> Cookie header that conforms to the following grammar" This seems some- >> what confused. If the user agent is free to send whatever it wants in >> the header, perhaps because the `Set-Cookie` it processed was invalid, >> then this should be clearly stated here, more so if it is required to. > >Section 4 does not contain any requirements on the user agent. All >the user agent requirements are contained in Section 5. This sentence >just states some consequences of those requirements. The text draws attention to a condition, either it matters that the server conforms to the requirements in section 4.1 for the user agent to meet the requirements in section 5, then it needs to be explained what the implications are of the server not doing so, or the user agent will behave according to the requirements in section 5 regardless of whether the server conforms to its requirements, then no attention should be drawn to the condition. >> In section 5.1.1, "If the found-day-of-month flag is not set ..." Up to >> this point it has not been explained what this flag is. The same goes >> probably for all "flags". Definitions need to be added. > >They don't mean anything other than what the text says. There's >nothing to define. There are two occurrences in the draft of `found-day-of-month`, the first is "If the found-day-of-month flag is not set and ..."; the other is in "Abort these steps and fail to parse if ... at least one of the found-day-of-month, found-month, found-year, or found-time flags is not set"; I translate that into: bool foundDayOfMonth; ... if (foundDayOfMonth && ...) { ... } ... if (!foundDayOfMonth || ...) { ... } The variable is read twice but never written to. You might try to read the draft after replacing all occurences of "found-day-of-month" with "squirrel0815"; that is, in effect, what I do. I could guess that maybe `found-day-of-month` is supposed to be set when the `day-of-month` sym- bol is used when parsing the input, but the draft does not say that, so my guess may very well be wrong. >> The surprising requirements in this section need to be accompanied by >> some rationale, for example, accepting 1601 as year but not 1600 is >> surprising and so is the 68/69 boundary. > >The reason is just that's how the protocol works. It's odd, but >that's how it works. I think it is unlikely that surprising requirements will be widely im- plemented unless the reasoning behind them is explained. For example, it seems unlikely to me that implementations will treat the year 69 as 1969 rather than 2069 just because the draft says so; they would rather assume this is an error as the 19XXs usually start with 1970. Similarily it seems quite reasonable to me that some implementations that cannot represent the year 1601 will simply fail to parse the date and then ig- nore the attribute, rather than succeed in parsing and then clamp it later, unless they are given a good reason to do otherwise. I also note that the draft fails to address handling impossible dates like the 31st of february, but that is obviously an error. >> In section 5.1.2 it needs to be explained what is supposed to happen if >> the normalization process fails, e.g. when ToASCII fails. > >Can you provide a test case that illustrates behavior that you think >is not defined? For instance, ToASCII(ToASCII(x)) fails for any `x`, and the draft does not discuss this failure. >> There should >> be a reminder that using non-ASCII characters directly is prohibited. > >Who is prohibited from using non-ASCII characters for what? I don't >understand your request. A `domain-value` cannot contain non-ASCII characters directly. >> There needs to be a discussion, I am not sure this is the right place, >> on the handling of permissable HTTP "hosts" (non-DNS names, IP-Literals >> and IPv4 addresses, for instance); some questions are, is it intentional >> that the Domain attribute disallows setting the attribute to a IPv4 >> address, would a leading '.' in the attribute still be stripped, if such >> host specifications are disallowed, must all cookies coming from them be >> rejected? With a Set-Cookie from 127.0.0.1 with no Domain attribute, is >> it incorrect to imply Domain=127.0.0.1? (I don't care, the specification >> however needs to discuss those questions). > >Can you provide a test case that illustrates behavior that you think >is not defined? I believe I did. >> The draft needs to explain how to handle a Set-Cookie header in a reply >> to an `OPTIONS *` request. Right now it seems `uri-path` would be unde- >> fined in that case, but the draft does not say what the consequence is. >> There should be an explicit mention of the case, not just adjusted algo- >> rithms. > >The draft says: > >[[ > If the uri-path is empty or if first character of the uri-path > is not a U+002F ("/") character, output U+002F ("/") and skip the > remaining steps. >]] > >Doesn't this fall under the case of the uri-path being empty? Since `uri-path` is "the path portion", and "*" is not a path, we do not know what `uri-path` is. >> In section 5.2, if the draft takes the position that HTTP header values >> are sequences of octets and not Unicode code points, then it needs to be >> explained at the beginning of this section how those octets are turned >> into characters (at least so long as it refers directly to the header >> and not some pre-processed value based on it, and so long it refers to >> characters instead of octets). > >The octets are never turned into characters. You eventually pass some of the octets to the ToASCII function which only accepts characters, not octets. So, either you do convert, or you cannot use ToASCII. >> In section 5.2.1 and subsequent sections the term "case-insensitively >> matches" is not defined; this should probably be defined in the termi- >> nology section. > >I'll be happy to add this if you can provide the definition you'd like >to see in the terminology section. There should be plenty of specifications to steal the text from, you could say "In this specification two strings are said to case-insen- sitively match each other if and only if they are equivalent under the i;ascii-casemap collation defined in RFC 4790". I am sure you can find more appropriate text. >> I doubt the draft should require implementations to use the "last" Date >> header, there are plenty of HTTP implementations where that is not >> possible as the headers are only accessible in folded form. > >As far as I can tell, that's how the protocol works. Can you provide >a test case that shows otherwise? A quick reading of the libwww-perl code suggests it does not use the "Date" header at all when determining the expiration time. Qt would seem to be another example. >> Section >> 4.1.2.1 also should be updated to clearly express that even though the >> expiry time is set in an absolute form, it'll be handled as relative >> value, as that is rather surprising. > >There are lots of details explained in Section 5 that are not >presented in Section 4. It's unclear why this particular detail >merits inclusion. It is common for cookie processing library to operate only on the values of the Set-Cookie and Cookie headers, not on whole request and response objects or the value of the headers plus the value of a Date header; for example, QNetworkCookie::parseCookies only takes a byte array as input. Obviously the requirement has not been anticipated or has been ignored. That should be sufficient reason to draw special attention to it. -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de Am Badedeich 7 Telefon: +49(0)160/4415681 http://www.bjoernsworld.de 25899 Dagebll PGP Pub. KeyID: 0xA4357E78 http://www.websitedev.de/ From yngve@opera.com Fri May 28 18:06:05 2010 Return-Path: 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 9C63D3A68DE for ; Fri, 28 May 2010 18:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] 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 K2prvdv3m0ZY for ; Fri, 28 May 2010 18:06:04 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id 9BB9D3A6A91 for ; Fri, 28 May 2010 18:06:03 -0700 (PDT) Received: from killashandra.oslo.osa (pat-tdc.opera.com [213.236.208.22]) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4T15owI028944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 29 May 2010 01:05:51 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes Date: Sat, 29 May 2010 03:05:58 +0200 To: "http-state@ietf.org" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Yngve Nysaeter Pettersen" Organization: Opera Software Message-ID: User-Agent: Opera Mail/10.53 (Win32) Subject: [http-state] Comments on draft-ietf-httpstate-cookie-08 X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: yngve@opera.com List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 May 2010 01:06:05 -0000 Hello all, Here are some more comments about the httpstate draft. * Sec 3 (overview) - "In subsequent requests, the user agent returns a Cookie request header to the origin server" Should this say that a client may send a Cookie header (if it decides to accept the Cookie)? (I also prefer "send" instead of "returns", alternatively "return the stored cookie in a Cookie header") - The section also mentions gateways,concerning changes to the Set-Cookie headers. Might it be useful to also specify that gateways must not insert Set-Cookie headers? * Sec 3.1 - Should the expiration example mention max-age? - Should "a expiration date" be changed to "a validity period" or words to that effect? * Sec 4.1.1 - "Servers SHOULD NOT include two Set-Cookie header fields in the same response with the same cookie-name." Should a caution about "unpredictable results" be added to this? * Sec 4.1.2.3 - For example, some user agents will reject Domain attributes of "com" or "co.uk". This seems to imply that there are agents that will accept a TLD as a valid domain (except ".local" from 2965, which is a special case). I'd rather have the section say that a domain attribute need to specify at least a second level domain. * sec 4.1.2.4 - %XX escaping and path compares. Maybe add a reference to the URI compare definition in 2616? * Sec 4.1.2.6 - Maybe an idea to mention that HttpOnly is a relatively new attribute, which may not be implemented by legacy clients? * sec 7.1 - Should this section have a recommendation to servers about graceful handling if the client does not send cookies? (Yes, it is mentioned generally further up) * Double Qoutes in the cookie-value field While not permitted by the Server side part of the spec, the draft seem to allow the double qoute character <"> (DQUOTE) anywhere in a cookie value, whether they are balanced, or not. This is IMO of significant concern since it breaks with how parameter values are defined and used in both MIME, HTTP, and RFC 2965, as (token | quoted-string), and may cause interoperability problems with clients and servers that support RFC 2965 (Opera supports 2965, and AFAIK the Apache Tomcat server also supports it). The handling of cookie values that are not tokens, and contain double quotes inside the value in a form that does not match the 2616 definition of quoted-string is according to my quick testing inconsistent between a few browsers (IE8, FF 3.6 and Opera 10.53), and AFAICT there is likely to be problem with Python based server-environments, like Django 1.1, which is the only one I have tested. Examples foo="""; IE: foo="""; FF: foo=""; Opera: discarded foo="xx"xx"; IE: foo="xx"xx"; FF: foo="xx"; Opera: discarded foo="xx"xx; IE: foo="xx"xx; FF: foo="xx"; Opera: foo="xx"; foo=",;"; IE: ; (Cookie terminated at the first semicolon, not the second, <> added for emphasis) FF: foo=",;"; Opera: foo=",;"; As for the server-side, when sending this header Cookie: name1="foo1; name2=bar"; name3=foo2"2; name4=bar"4; name5=foo to Django 1.1 or the Python 2.6 Cookie module, the result is the following set of cookies: name1="foo1; name2=bar" name3=foo2 name4=bar name5=foo In other words, when using quotes inside a value with any syntax other than quoted-string (which permit internal quoting if backslash escaping is used), the result does not just depend on the client the server is sending it to, it also depends on the script engine and its cookie parser. IMO the specification should specifically comment on these issues, and preferably allow clients to discard cookies with quotes that does not match the quoted-string syntax, as well as specifically tell servers not to use double quotes, except as quoted-string (if they absolutely want to break the spec's requirement of only using tokens). Perhaps one way to do that is to specifically say that the result of using quotes in this fashion is undefined? -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ******************************************************************** From derhoermi@gmx.net Sat May 29 05:51:11 2010 Return-Path: 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 034DD3A6AC1 for ; Sat, 29 May 2010 05:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.416 X-Spam-Level: X-Spam-Status: No, score=-1.416 tagged_above=-999 required=5 tests=[AWL=1.183, BAYES_00=-2.599] 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 Cf2o4Tdx8BwJ for ; Sat, 29 May 2010 05:51:09 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 58FC43A6AC6 for ; Sat, 29 May 2010 05:51:07 -0700 (PDT) Received: (qmail invoked by alias); 29 May 2010 12:50:55 -0000 Received: from dslb-094-222-135-191.pools.arcor-ip.net (EHLO hive) [94.222.135.191] by mail.gmx.net (mp024) with SMTP; 29 May 2010 14:50:55 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX19CDIUvmlhCWDgs82t5wk6ZlL+2ckR2ccKp8ae60c ag2oz3I4Je1ImZ From: Bjoern Hoehrmann To: yngve@opera.com Date: Sat, 29 May 2010 14:50:47 +0200 Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "http-state@ietf.org" Subject: Re: [http-state] Comments on draft-ietf-httpstate-cookie-08 X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 May 2010 12:51:11 -0000 * Yngve Nysaeter Pettersen wrote: >* Sec 4.1.2.3 > >- For example, some user agents will reject Domain attributes of "com" >or "co.uk". > >This seems to imply that there are agents that will accept a TLD as a >valid domain (except ".local" from 2965, which is a special case). I'd >rather have the section say that a domain attribute need to specify at >least a second level domain. As I understand it, there are a number of frameworks that will auto- matically use the server name, or failing that its address, as default value for the domain attribute. It does not strike me as a good idea to prohibit `Domain=localhost` for instance. -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de Am Badedeich 7 Telefon: +49(0)160/4415681 http://www.bjoernsworld.de 25899 Dagebll PGP Pub. KeyID: 0xA4357E78 http://www.websitedev.de/ From yngve@opera.com Sat May 29 07:48:26 2010 Return-Path: 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 3B6133A68A7 for ; Sat, 29 May 2010 07:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] 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 exynJv84E-nK for ; Sat, 29 May 2010 07:48:25 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id 8CB593A6820 for ; Sat, 29 May 2010 07:48:24 -0700 (PDT) Received: from acorna (30.169.202.84.customer.cdi.no [84.202.169.30]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4TEmAUJ010596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 29 May 2010 14:48:10 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Bjoern Hoehrmann" References: Date: Sat, 29 May 2010 16:48:02 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Yngve N. Pettersen (Developer Opera Software ASA)" Organization: Opera Software AS Message-ID: In-Reply-To: User-Agent: Opera Mail/10.53 (Win32) Cc: "http-state@ietf.org" Subject: Re: [http-state] Comments on draft-ietf-httpstate-cookie-08 X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 May 2010 14:48:26 -0000 On Sat, 29 May 2010 14:50:47 +0200, Bjoern Hoehrmann wrote: > * Yngve Nysaeter Pettersen wrote: >> * Sec 4.1.2.3 >> >> - For example, some user agents will reject Domain attributes of "com" >> or "co.uk". >> >> This seems to imply that there are agents that will accept a TLD as a >> valid domain (except ".local" from 2965, which is a special case). I'd >> rather have the section say that a domain attribute need to specify at >> least a second level domain. > > As I understand it, there are a number of frameworks that will auto- > matically use the server name, or failing that its address, as default > value for the domain attribute. It does not strike me as a good idea to > prohibit `Domain=localhost` for instance. The formal hostname for localhost would be "localhost.local", but in any case, in such a situation the hostname would also be non-dotted ("localhost") and it must exactly match the domain attribute (localhost). This kind of situation is handled by Opera. What I am (implicitly) referring to above is a situation where the domain attribute is not equal to the hostname, but domain-matches the hostname, *and* where the domain attribute is a *single* level (IOW a TLD). Those cases should not be allowed, even by a public suffix list. If somebody creates a server "com" (for example, setting a cookie for it will not (in Opera, and probably other browsers) cause the cookie to be valid for all the dot-com servers, since the cookie will be set for the implied FQDN "com.local". Come to think of it, is the single label (local intranet server) situation covered in the domain sematics? -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ******************************************************************** From ietf@adambarth.com Sat May 29 09:43:57 2010 Return-Path: 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 8943E3A683E for ; Sat, 29 May 2010 09:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.253 X-Spam-Level: X-Spam-Status: No, score=0.253 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622] 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 hq0XeNsAr7vr for ; Sat, 29 May 2010 09:43:57 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by core3.amsl.com (Postfix) with ESMTP id 9DD083A6847 for ; Sat, 29 May 2010 09:43:53 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so639171fga.13 for ; Sat, 29 May 2010 09:43:40 -0700 (PDT) Received: by 10.87.63.1 with SMTP id q1mr5184355fgk.38.1275151419822; Sat, 29 May 2010 09:43:39 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by mx.google.com with ESMTPS id d6sm6578887fga.8.2010.05.29.09.43.38 (version=SSLv3 cipher=RC4-MD5); Sat, 29 May 2010 09:43:39 -0700 (PDT) Received: by gwj19 with SMTP id 19so1823361gwj.31 for ; Sat, 29 May 2010 09:43:36 -0700 (PDT) Received: by 10.231.184.73 with SMTP id cj9mr2604627ibb.1.1275151416101; Sat, 29 May 2010 09:43:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.60.4 with HTTP; Sat, 29 May 2010 09:43:16 -0700 (PDT) In-Reply-To: References: From: Adam Barth Date: Sat, 29 May 2010 09:43:16 -0700 Message-ID: To: yngve@opera.com Content-Type: text/plain; charset=ISO-8859-1 Cc: "http-state@ietf.org" Subject: Re: [http-state] Comments on draft-ietf-httpstate-cookie-08 X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 May 2010 16:43:58 -0000 On Fri, May 28, 2010 at 6:05 PM, Yngve Nysaeter Pettersen wrote: > * Double Qoutes in the cookie-value field I think you're testing with an old version of Firefox. Can you try a nightly build? I believe the handling of double quotes in cookies values is consistent across the spec, IE, Firefox (nightly), and Chrome. Adam From ietf@adambarth.com Sat May 29 09:52:17 2010 Return-Path: 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 E47433A6889 for ; Sat, 29 May 2010 09:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.428 X-Spam-Level: X-Spam-Status: No, score=-0.428 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622] 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 XBrAuZ6DCZDG for ; Sat, 29 May 2010 09:52:17 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 0AD383A6884 for ; Sat, 29 May 2010 09:52:16 -0700 (PDT) Received: by gwj19 with SMTP id 19so1826566gwj.31 for ; Sat, 29 May 2010 09:52:04 -0700 (PDT) Received: by 10.101.105.39 with SMTP id h39mr2401905anm.19.1275151923947; Sat, 29 May 2010 09:52:03 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by mx.google.com with ESMTPS id t2sm19164147ani.8.2010.05.29.09.52.01 (version=SSLv3 cipher=RC4-MD5); Sat, 29 May 2010 09:52:02 -0700 (PDT) Received: by gyh4 with SMTP id 4so1829143gyh.31 for ; Sat, 29 May 2010 09:52:01 -0700 (PDT) Received: by 10.231.158.130 with SMTP id f2mr2578348ibx.40.1275151921106; Sat, 29 May 2010 09:52:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.60.4 with HTTP; Sat, 29 May 2010 09:51:41 -0700 (PDT) In-Reply-To: References: From: Adam Barth Date: Sat, 29 May 2010 09:51:41 -0700 Message-ID: To: yngve@opera.com Content-Type: text/plain; charset=ISO-8859-1 Cc: "http-state@ietf.org" Subject: Re: [http-state] Comments on draft-ietf-httpstate-cookie-08 X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 May 2010 16:52:18 -0000 I'll reply to your full email in detail later, but another note: On Fri, May 28, 2010 at 6:05 PM, Yngve Nysaeter Pettersen wrote: > IMO the specification should specifically comment on these issues, and > preferably allow clients to discard cookies with quotes that does not match > the quoted-string syntax, User agents already have the option to discard any cookie for any reason. Adding this text to the spec would be redundant. > as well as specifically tell servers not to use > double quotes, except as quoted-string (if they absolutely want to break the > spec's requirement of only using tokens). Add this text to the spec would be redundant because the spec already requires servers (at the SHOULD level) not to use quotes (either double or single) at all. More precisely, adding this text to the spec would be a contrary-to-duty imperative, which, generally speaking, are quite dubious logically. > Perhaps one way to do that is to > specifically say that the result of using quotes in this fashion is > undefined? Leaving things like this undefined hurts interoperability. Adam From yngve@opera.com Sat May 29 10:54:24 2010 Return-Path: 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 DFA723A6896 for ; Sat, 29 May 2010 10:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] 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 0nZLrswJqPsa for ; Sat, 29 May 2010 10:54:23 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id 8F5F83A6862 for ; Sat, 29 May 2010 10:54:23 -0700 (PDT) Received: from acorna (30.169.202.84.customer.cdi.no [84.202.169.30]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4THs83R013859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 29 May 2010 17:54:09 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Adam Barth" References: Date: Sat, 29 May 2010 19:54:00 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Yngve N. Pettersen (Developer Opera Software ASA)" Organization: Opera Software AS Message-ID: In-Reply-To: User-Agent: Opera Mail/10.53 (Win32) Cc: "http-state@ietf.org" Subject: Re: [http-state] Comments on draft-ietf-httpstate-cookie-08 X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 May 2010 17:54:25 -0000 On Sat, 29 May 2010 18:51:41 +0200, Adam Barth wrote: > I'll reply to your full email in detail later, but another note: > > On Fri, May 28, 2010 at 6:05 PM, Yngve Nysaeter Pettersen > wrote: >> IMO the specification should specifically comment on these issues, and >> preferably allow clients to discard cookies with quotes that does not >> match >> the quoted-string syntax, > > User agents already have the option to discard any cookie for any > reason. Adding this text to the spec would be redundant. I think it may still be useful to point out specific issues where such discarding policies are used automatically. My impression of that text is that it focus more on cleanup and user controlled filtering, rather than what policies the client may have implemented. I suspect that most administrators will read it that way too. For example, the draft specifically mentions public suffix as a reason why a client can discard a cookie. >> Perhaps one way to do that is to >> specifically say that the result of using quotes in this fashion is >> undefined? > > Leaving things like this undefined hurts interoperability. The situation for this particular value syntax is already undefined, and while it is a corner case, it can have unanticipated effects, particularly in combination with different cookie ordering algorithms. Putting the server administrators on notice about the issue should hopefully increase interoperability because they can then avoid the problematic cases. If we are going to document cookies as used on the Internet, then I think that includes pointing out the areas that should be avoided, particularly the ones where the results will be undefined. That should not just be done by how the syntax is defined, but also directly mentioning them. This information can be mentioned either as notes (or Notes) in the definitions themselves, or collected in a separate "Implementation pitfalls"-section. -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ******************************************************************** From daniel@haxx.se Sat May 29 11:16:08 2010 Return-Path: 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 5F79D3A685A for ; Sat, 29 May 2010 11:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=-2.663, BAYES_50=0.001, HELO_EQ_SE=0.35] 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 NqJyeaeyBtRu for ; Sat, 29 May 2010 11:16:04 -0700 (PDT) Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by core3.amsl.com (Postfix) with ESMTP id C6D0E3A6873 for ; Sat, 29 May 2010 11:15:57 -0700 (PDT) Received: from giant.haxx.se (dast@giant.haxx.se [80.67.6.50]) by giant.haxx.se (8.14.3/8.14.3/Debian-9.1) with ESMTP id o4TIFgdV016485; Sat, 29 May 2010 20:15:42 +0200 Date: Sat, 29 May 2010 20:15:42 +0200 (CEST) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Bjoern Hoehrmann In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.3.5 (giant.haxx.se [80.67.6.50]); Sat, 29 May 2010 20:15:42 +0200 (CEST) Cc: http-state@ietf.org Subject: Re: [http-state] Comments on draft-ietf-httpstate-cookie-08.txt (4.1.2.2 - 5.2.6) X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 May 2010 18:16:09 -0000 On Fri, 28 May 2010, Bjoern Hoehrmann wrote: > I doubt the draft should require implementations to use the "last" Date > header, there are plenty of HTTP implementations where that is not possible > as the headers are only accessible in folded form. Section 4.1.2.1 also > should be updated to clearly express that even though the expiry time is set > in an absolute form, it'll be handled as relative value, as that is rather > surprising. I agree. I don't think we've discussed this properly on the list. (Or if we did I might've missed it.) Why would the 'expires' attribute be treated relative like 5.2.1 describes? Expires is an absolute time, and I don't see why clients shouldn't try to use exactly that time in time comparisons. If the server/client clocks are off in any significant way, every response-with-cookies without Date: header would then be subject to flaws and I expect that a majority of cookie-sending server responses are done without Date: I also would expect that lots of implmentations treat that time as an absolute and not a relative unconditionally. Are the big-5 doing it this way? -- / daniel.haxx.se From yngve@opera.com Sat May 29 11:38:02 2010 Return-Path: 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 B62C33A6855 for ; Sat, 29 May 2010 11:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] 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 Em4fV9AeyFB6 for ; Sat, 29 May 2010 11:38:01 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id 310813A6803 for ; Sat, 29 May 2010 11:38:00 -0700 (PDT) Received: from acorna (30.169.202.84.customer.cdi.no [84.202.169.30]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4TIbgHj014544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 29 May 2010 18:37:43 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Bjoern Hoehrmann" , "Daniel Stenberg" References: Date: Sat, 29 May 2010 20:37:34 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Yngve N. Pettersen (Developer Opera Software ASA)" Organization: Opera Software AS Message-ID: In-Reply-To: User-Agent: Opera Mail/10.53 (Win32) Cc: http-state@ietf.org Subject: Re: [http-state] Comments on draft-ietf-httpstate-cookie-08.txt (4.1.2.2 - 5.2.6) X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 May 2010 18:38:02 -0000 On Sat, 29 May 2010 20:15:42 +0200, Daniel Stenberg wrote: > On Fri, 28 May 2010, Bjoern Hoehrmann wrote: > >> I doubt the draft should require implementations to use the "last" Date >> header, there are plenty of HTTP implementations where that is not >> possible as the headers are only accessible in folded form. Section >> 4.1.2.1 also should be updated to clearly express that even though the >> expiry time is set in an absolute form, it'll be handled as relative >> value, as that is rather surprising. > > I agree. I don't think we've discussed this properly on the list. (Or if > we did I might've missed it.) > > Why would the 'expires' attribute be treated relative like 5.2.1 > describes? Expires is an absolute time, and I don't see why clients > shouldn't try to use exactly that time in time comparisons. If the > server/client clocks are off in any significant way, every > response-with-cookies without Date: header would then be subject to > flaws and I expect that a majority of cookie-sending server responses > are done without Date: > > I also would expect that lots of implmentations treat that time as an > absolute and not a relative unconditionally. > > Are the big-5 doing it this way? Opera is using the Expires attribute as an absolute UTC date and time. Frankly, I think it should stay that way. Servers should keep their clock well in sync, so should clients, particularly since quite a few security features in SSL depends on a reasonably accurate clock. The situation where a slightly off clock can cause problems is for shortlived cookies, and those are better handled through maxage. My guess is that this has been adopted from the cache lifetime definitions in 2616 and 2616-bis. I have no idea whether other clients use relative time at present, but if they don't, then all the clients that could be adapted to it would already support maxage. -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ******************************************************************** From daniel@haxx.se Sat May 29 13:43:28 2010 Return-Path: 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 227173A6896 for ; Sat, 29 May 2010 13:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.424 X-Spam-Level: X-Spam-Status: No, score=-1.424 tagged_above=-999 required=5 tests=[AWL=-1.775, BAYES_50=0.001, HELO_EQ_SE=0.35] 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 RvFZfd8RpMVl for ; Sat, 29 May 2010 13:43:27 -0700 (PDT) Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by core3.amsl.com (Postfix) with ESMTP id B16193A680B for ; Sat, 29 May 2010 13:43:26 -0700 (PDT) Received: from giant.haxx.se (dast@giant.haxx.se [80.67.6.50]) by giant.haxx.se (8.14.3/8.14.3/Debian-9.1) with ESMTP id o4TKhFlB027075; Sat, 29 May 2010 22:43:15 +0200 Date: Sat, 29 May 2010 22:43:15 +0200 (CEST) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: "Yngve N. Pettersen (Developer Opera Software ASA)" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.3.5 (giant.haxx.se [80.67.6.50]); Sat, 29 May 2010 22:43:15 +0200 (CEST) Cc: http-state@ietf.org Subject: Re: [http-state] Comments on draft-ietf-httpstate-cookie-08.txt (4.1.2.2 - 5.2.6) X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 May 2010 20:43:28 -0000 On Sat, 29 May 2010, Yngve N. Pettersen (Developer Opera Software ASA) wrote: > The situation where a slightly off clock can cause problems is for > shortlived cookies, and those are better handled through maxage. Well, one could imagine a similar concept for maxage, like for the case where the server wants the cookie to be alive 10 seconds, but the mere transfer of the cookie to the client takes 5... I would expect most client implementations to consider the maxage time to start ticking the moment the cookie is actually parsed and not from the Date: of the http response. -- / daniel.haxx.se From ietf@adambarth.com Sun May 30 13:48:54 2010 Return-Path: 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 73F3A3A690C for ; Sun, 30 May 2010 13:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.02 X-Spam-Level: X-Spam-Status: No, score=0.02 tagged_above=-999 required=5 tests=[AWL=-0.603, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] 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 P7+Z9Y+oA35X for ; Sun, 30 May 2010 13:48:52 -0700 (PDT) Received: from mail-yw0-f182.google.com (mail-yw0-f182.google.com [209.85.211.182]) by core3.amsl.com (Postfix) with ESMTP id 5D0C73A6848 for ; Sun, 30 May 2010 13:48:52 -0700 (PDT) Received: by ywh12 with SMTP id 12so2491592ywh.19 for ; Sun, 30 May 2010 13:48:38 -0700 (PDT) Received: by 10.101.133.9 with SMTP id k9mr3962108ann.43.1275252518553; Sun, 30 May 2010 13:48:38 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by mx.google.com with ESMTPS id n18sm26110225anl.2.2010.05.30.13.48.36 (version=SSLv3 cipher=RC4-MD5); Sun, 30 May 2010 13:48:37 -0700 (PDT) Received: by gyh4 with SMTP id 4so2337186gyh.31 for ; Sun, 30 May 2010 13:48:36 -0700 (PDT) Received: by 10.231.156.1 with SMTP id u1mr4535139ibw.46.1275252516345; Sun, 30 May 2010 13:48:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.60.4 with HTTP; Sun, 30 May 2010 13:48:16 -0700 (PDT) In-Reply-To: References: From: Adam Barth Date: Sun, 30 May 2010 13:48:16 -0700 Message-ID: To: yngve@opera.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "http-state@ietf.org" Subject: Re: [http-state] Comments on draft-ietf-httpstate-cookie-08 X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 May 2010 20:48:54 -0000 On Fri, May 28, 2010 at 6:05 PM, Yngve Nysaeter Pettersen wrote: > Here are some more comments about the httpstate draft. Thanks for your feedback. See below for detailed comments: > * Sec 3 (overview) > > =A0- "In subsequent requests, the user agent returns a Cookie request hea= der > to the origin server" > > Should this say that a client may send a Cookie header (if it decides to > accept the Cookie)? (I also prefer "send" instead of "returns", > alternatively "return the stored cookie in a Cookie header") I've changed this to "send." As this is just the overview, I've left it focusing on the common case, which is that the user agent does actually end up sending the cookie. > =A0- The section also mentions gateways,concerning changes to the Set-Coo= kie > headers. Might it be useful to also specify that gateways must not insert > Set-Cookie headers? Why must gateways not insert Set-Cookie headers? Granted, it might or might not be friendly behavior, but it seems ok from a protocol standpoint. > * Sec 3.1 > > - Should the expiration example mention max-age? These are just examples. I think its fine to focus on the common case. > - Should "a expiration date" be changed to "a validity period" or words t= o > that effect? Hum... The Expires attribute doesn't contain a period. It contains a date= ... > * Sec 4.1.1 > > - "Servers SHOULD NOT include two Set-Cookie header fields in the same > response with the same cookie-name." > > Should a caution about "unpredictable results" be added to this? The results are predictable, just nutty. > * Sec 4.1.2.3 > > - =A0 For example, some user agents will reject Domain attributes of "com= " or > "co.uk". > > This seems to imply that there are agents that will accept a TLD as a val= id > domain (except ".local" from 2965, which is a special case). I'd rather h= ave > the section say that a domain attribute need to specify at least a second > level domain. There are some user agents that will accept a TLD as a valid domain. I'd advise against building such a user agent, but not everyone will take my advice. > * sec 4.1.2.4 > > - %XX escaping and path compares. Maybe add a reference to the URI compar= e > definition in 2616? Can you provide a test case that demonstrates that %-escaping is relevant in this context? My testing shows that user agents ignore %-escaping in the Path attribute. Now, some user agents canonicalize %-escaping in URLs, but that's a matter best left to another working group, IMHO. > * Sec 4.1.2.6 > > - Maybe an idea to mention that HttpOnly is a relatively new attribute, > which may not be implemented by legacy clients? I believe HTTPOnly is broadly implemented among user agents for which you can detect whether it's implement. Note that for the vast majority of user agents, you can't tell whether they implement HTTPOnly, so we might as well act as if they did implement it. > * sec 7.1 > > =A0- Should this section have a recommendation to servers about graceful > handling if the client does not send cookies? (Yes, it is mentioned > generally further up) We could, but I don't think it would make much of a difference. > * Double Qoutes in the cookie-value field I've replied to this section earlier. Generally, this whole business of double-quote being a meaningful character in cookies values was a fantasy invented by RFC 2109. As far as I can tell, IE has never treated double-quote different from any other character in cookie values, which means that the vast majority of web sites will work fine if we don't either. The cargo cult of double-quotes being meaningful in cookie attributes has caused nothing but pain and misery in the world and should be shot. (Details below.) > While not permitted by the Server side part of the spec, the draft seem t= o > allow the double qoute character <"> (DQUOTE) anywhere in a cookie value, > whether they are balanced, or not. Indeed. > This is IMO of significant concern since it breaks with how parameter val= ues > are defined and used in both MIME, HTTP, and RFC 2965, as (token | > quoted-string), and may cause interoperability problems with clients and > servers that support RFC 2965 (Opera supports 2965, and AFAIK the Apache > Tomcat server also supports it). The syntax of the Set-Cookie header differs from the syntax of other things related to HTTP. That's just an unfortunate fact of life. If we were designing things to be beautiful from the start, we would probably do something different, but that's not how things work today. As for RFC 2965, we're not creating any problems that don't exist today. We're just writing down how the cookie protocol works. If Cookie2 had deployment problems, that's a topic for another time. > The handling of cookie values that are not tokens, and contain double quo= tes > inside the value in a form that does not match the 2616 definition of > quoted-string is according to my quick testing inconsistent between a few > browsers (IE8, FF 3.6 and Opera 10.53), Indeed. Cookie values are not quoted strings. > and AFAICT there is likely to be > problem with Python based server-environments, like Django 1.1, which is = the > only one I have tested. I suspect that Django 1.1 works fine in IE5, IE6, IE7, and IE8, which means it will work fine w.r.t. the spec's treatment of quotes in cookie values as (in this respect) the spec's behavior matches every version of IE I could dig up for testing. > As for the server-side, when sending this header > > =A0 Cookie: =A0name1=3D"foo1; name2=3Dbar"; name3=3Dfoo2"2; name4=3Dbar"4= ; name5=3Dfoo > > to Django 1.1 or the Python 2.6 Cookie module, the result is the followin= g > set of cookies: > > =A0 name1=3D"foo1; name2=3Dbar" > =A0 name3=3Dfoo2 > =A0 name4=3Dbar > =A0 name5=3Dfoo That's only an issue if Django sends a Set-Cookie header that generates that Cookie header. If somewhere there's a Django server that does send such a Set-Cookie header, the author of that server is likely expecting the Cookie header to parse that way because that's how it works for the majority of user agents. If they aren't expecting that parsing, they'll discover it as soon as they test their site with any version of IE. By contrast, if we adopt Opera's parsing of the Set-Cookie header, then we're much more likely to cause interoperability problems for sites that rely on the more common parsing. > In other words, when using quotes inside a value with any syntax other th= an > quoted-string (which permit internal quoting if backslash escaping is use= d), > the result does not just depend on the client the server is sending it to= , > it also depends on the script engine and its cookie parser. Indeed. Such is life. > IMO the specification should specifically comment on these issues, and > preferably allow clients to discard cookies with quotes that does not mat= ch > the quoted-string syntax, as well as specifically tell servers not to use > double quotes, except as quoted-string (if they absolutely want to break = the > spec's requirement of only using tokens). Perhaps one way to do that is t= o > specifically say that the result of using quotes in this fashion is > undefined? I replied to this paragraph earlier. Essentially, everything you're asking for is already provided by the current draft. On Sat, May 29, 2010 at 5:50 AM, Bjoern Hoehrmann wrote= : > * Yngve Nysaeter Pettersen wrote: >>* Sec 4.1.2.3 >> >>- =A0 For example, some user agents will reject Domain attributes of "com= " >>or "co.uk". >> >>This seems to imply that there are agents that will accept a TLD as a >>valid domain (except ".local" from 2965, which is a special case). I'd >>rather have the section say that a domain attribute need to specify at >>least a second level domain. > > As I understand it, there are a number of frameworks that will auto- > matically use the server name, or failing that its address, as default > value for the domain attribute. It does not strike me as a good idea to > prohibit `Domain=3Dlocalhost` for instance. The spec just works the same way user agents work today. If folks with such servers are living happy lives today, they'll continue to live happy lives. If they're living unhappy lives, then we're not doing them any additional harm. On Sat, May 29, 2010 at 7:48 AM, Yngve N. Pettersen (Developer Opera Software ASA) wrote: > Come to think of it, is the single label (local intranet server) situatio= n > covered in the domain sematics? Yes. Feel free to read the spec for details, but what happens (essentially) is that you can set a host-only cookie for intranet hosts but you cannot set a cookie without the host-only flag. On Sat, May 29, 2010 at 10:54 AM, Yngve N. Pettersen (Developer Opera Software ASA) wrote: > On Sat, 29 May 2010 18:51:41 +0200, Adam Barth wrote= : >> I'll reply to your full email in detail later, but another note: >> >> On Fri, May 28, 2010 at 6:05 PM, Yngve Nysaeter Pettersen >> wrote: >>> >>> IMO the specification should specifically comment on these issues, and >>> preferably allow clients to discard cookies with quotes that does not >>> match >>> the quoted-string syntax, >> >> User agents already have the option to discard any cookie for any >> reason. =A0Adding this text to the spec would be redundant. > > I think it may still be useful to point out specific issues where such > discarding policies are used automatically. My impression of that text is > that it focus more on cleanup and user controlled filtering, rather than > what policies the client may have implemented. I suspect that most > administrators will read it that way too. For example, the draft > specifically mentions public suffix as a reason why a client can discard = a > cookie. Yes. The draft suggests that people discard cookies in ways that are productive. I'd rather not encourage folks to discard cookies in ways that don't interoperate, but, from a protocol point of view, we need to allow them to do that. Hence the current text in the spec. You're welcome to build a user agent that discards cookies with unbalanced double-quotes. However, you'll find your user agent in the minority. Instead, I'd recommend you build a user agent that doesn't treat double-quote as a special character and we'll all live happier lives. >>> Perhaps one way to do that is to >>> specifically say that the result of using quotes in this fashion is >>> undefined? >> >> Leaving things like this undefined hurts interoperability. > > The situation for this particular value syntax is already undefined, and > while it is a corner case, it can have unanticipated effects, particularl= y > in combination with different cookie ordering algorithms. Putting the ser= ver > administrators on notice about the issue should hopefully increase > interoperability because they can then avoid the problematic cases. The behavior for this particular value syntax is indeed defined. You can find the definition in Section 5. We're already advising server administrators not to use double-quotes. That's the most helpful piece of advise I know as it avoids the complexities here. For servers, there's no real reason to use double-quotes anyway. It's just a trail of tears. > If we are going to document cookies as used on the Internet, then I think > that includes pointing out the areas that should be avoided, particularly > the ones where the results will be undefined. That should not just be don= e > by how the syntax is defined, but also directly mentioning them. > > This information can be mentioned either as notes (or Notes) in the > definitions themselves, or collected in a separate "Implementation > pitfalls"-section. I agree that we should discuss this issue in more depth in the deviation description document. However, I think we should fill up this document with a bunch of informative text about legacy user agents except in cases where understanding that information is of critical importance (e.g., for security). Adam From ietf@adambarth.com Sun May 30 14:22:40 2010 Return-Path: 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 5A2953A6896 for ; Sun, 30 May 2010 14:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.859 X-Spam-Level: X-Spam-Status: No, score=-0.859 tagged_above=-999 required=5 tests=[AWL=0.518, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2] 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 oAJxbqiLiZF8 for ; Sun, 30 May 2010 14:22:38 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 136303A6833 for ; Sun, 30 May 2010 14:22:38 -0700 (PDT) Received: by gwj19 with SMTP id 19so2343809gwj.31 for ; Sun, 30 May 2010 14:22:23 -0700 (PDT) Received: by 10.101.4.15 with SMTP id g15mr3680021ani.149.1275254543210; Sun, 30 May 2010 14:22:23 -0700 (PDT) Received: from mail-yw0-f182.google.com (mail-yw0-f182.google.com [209.85.211.182]) by mx.google.com with ESMTPS id n18sm26251600anl.2.2010.05.30.14.22.20 (version=SSLv3 cipher=RC4-MD5); Sun, 30 May 2010 14:22:21 -0700 (PDT) Received: by ywh12 with SMTP id 12so2514637ywh.19 for ; Sun, 30 May 2010 14:22:20 -0700 (PDT) Received: by 10.231.120.37 with SMTP id b37mr4543330ibr.81.1275254540093; Sun, 30 May 2010 14:22:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.60.4 with HTTP; Sun, 30 May 2010 14:22:00 -0700 (PDT) In-Reply-To: <9c8006lme07degqokchpkk0jq5vkt1njdu@hive.bjoern.hoehrmann.de> References: <9c8006lme07degqokchpkk0jq5vkt1njdu@hive.bjoern.hoehrmann.de> From: Adam Barth Date: Sun, 30 May 2010 14:22:00 -0700 Message-ID: To: Bjoern Hoehrmann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: http-state@ietf.org Subject: Re: [http-state] Comments on draft-ietf-httpstate-cookie-08.txt (4.1.2.2 - 5.2.6) X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 May 2010 21:22:40 -0000 On Fri, May 28, 2010 at 4:05 PM, Bjoern Hoehrmann wrote= : > * Adam Barth wrote: >>> Later in the section: "WARNING: Not all user agents support the Max-Age >>> attribute. User agents that do not support the Max-Age attribute will >>> ignore the attribute." I see no reason why this needs to be a "WARNING" >>> rather than a note, >> >>Changed to a NOTE. >> >>> and the text needs to clarify that support for the >>> attribute is not optional but rather required. >> >>That requirement is contained in the section entitled User Agent Requirem= ents. > > The point is that the text does not say those user agents are non-con- > forming, so the casual reader may well assume support is optional. It > should say something like "Some older user agents do not support it", > or whatever, so long as it is clear that they are not compliant. I've changed this to the following: [[ Some legacy user agents do not support the Max-Age attribute. ]] Hopefully that should be sufficient to convey that this is not desired. >>> And "will" is also the wrong word. >> >>What word do you suggest instead? > > I don't have a ready proposal how to rephrase it, but the point is that > they may not do so and still conform to the specification. I've removed the word "will." >>> The subsequent "Warning" needs to explain how and why the described be- >>> haviour is erroneous. >> >>I don't understand this comment. =A0It's a warning that some existing >>user agents behave incorrect w.r.t. the description that section. >>That behavior is erroneous: it is in error. > > A remedy would be to state in the note what the correct behavior is, > rather than simply say it is wrong. Obviously the developers of the > misbehaving user agents did not think it wrong. On the contrary, even the developers of the misbehaving user agents agree that the behavior is wrong, at least according to their public statements on the matter. >>> In section 4.1.2.4, "If the server omits the Path attribute, the user >>> agent will use the directory of the request-uri's path component as the >>> default value." It is not clear what the "directory" of a path componen= t >>> is, RFC 3986 for example does not define it. >> >>I've put directory in quotes. =A0The definition is in Section 5. > > This probably works if you include the forward reference to the re- > levant sub-section of section 5. Done. >>> "If the server conforms to the requirements in Section 4.1, the >>> requirements in the Section 5 will cause the user agent to return a >>> Cookie header that conforms to the following grammar" This seems some- >>> what confused. If the user agent is free to send whatever it wants in >>> the header, perhaps because the `Set-Cookie` it processed was invalid, >>> then this should be clearly stated here, more so if it is required to. >> >>Section 4 does not contain any requirements on the user agent. =A0All >>the user agent requirements are contained in Section 5. =A0This sentence >>just states some consequences of those requirements. > > The text draws attention to a condition, either it matters that the > server conforms to the requirements in section 4.1 for the user agent > to meet the requirements in section 5, then it needs to be explained > what the implications are of the server not doing so, or the user agent > will behave according to the requirements in section 5 regardless of > whether the server conforms to its requirements, then no attention > should be drawn to the condition. The consequent follows only if both of the antecedents are satisfied. There's no entanglement between the antecedents. I've changed the structure of this sentence to be more parallel to reflect the parallelism in the situation. I've also demoted the mention of Section 5 to a parenthetical. [[ The user agent sends stored cookies to the origin server in th= e Cookie header. If the server conforms to the requirements in (and the user agent conforms to the requirements in the ), the use= r agent will send a Cookie header that conforms to the following grammar: ]] >>> In section 5.1.1, "If the found-day-of-month flag is not set ..." Up to >>> this point it has not been explained what this flag is. The same goes >>> probably for all "flags". Definitions need to be added. >> >>They don't mean anything other than what the text says. =A0There's >>nothing to define. > > There are two occurrences in the draft of `found-day-of-month`, the > first is "If the found-day-of-month flag is not set and ..."; the other > is in "Abort these steps and fail to parse if ... at least one of the > found-day-of-month, found-month, found-year, or found-time flags is not > set"; Ah, I understand your confusion. You missed the third occurrence of the term in which the flag is actually set. :) > The variable is read twice but never written to. You might try to read > the draft after replacing all occurences of "found-day-of-month" with > "squirrel0815"; that is, in effect, what I do. I could guess that maybe > `found-day-of-month` is supposed to be set when the `day-of-month` sym- > bol is used when parsing the input, but the draft does not say that, so > my guess may very well be wrong. I think the text still makes sense if read with squirrel0815: [[ If the squirrel0815 flag is not set and the date-token matches the day-of-month production, set the squirrel0815 flag and ... [...] at least one of the squirrel0815, found-month, found-year, or found-time flags is not set, ... ]] >>> The surprising requirements in this section need to be accompanied by >>> some rationale, for example, accepting 1601 as year but not 1600 is >>> surprising and so is the 68/69 boundary. >> >>The reason is just that's how the protocol works. =A0It's odd, but >>that's how it works. > > I think it is unlikely that surprising requirements will be widely im- > plemented unless the reasoning behind them is explained. That requirement is already widely implemented, so we have nothing to fear = here. > I also note that the draft fails to address handling impossible dates > like the 31st of february, but that is obviously an error. Fixed. We not fail explicitly when no such date exists. >>> In section 5.1.2 it needs to be explained what is supposed to happen if >>> the normalization process fails, e.g. when ToASCII fails. >> >>Can you provide a test case that illustrates behavior that you think >>is not defined? > > For instance, ToASCII(ToASCII(x)) fails for any `x`, and the draft does > not discuss this failure. > >>> There should >>> be a reminder that using non-ASCII characters directly is prohibited. >> >>Who is prohibited from using non-ASCII characters for what? =A0I don't >>understand your request. > > A `domain-value` cannot contain non-ASCII characters directly. Do you mean there's a certain sequence of octets that the server is prohibited from sending? Please read the draft more carefully. The server is permitted to send any sequence of octets it pleases. We recommend against sending some crazy ones, but none are prohibited by this document. >>> There needs to be a discussion, I am not sure this is the right place, >>> on the handling of permissable HTTP "hosts" (non-DNS names, IP-Literals >>> and IPv4 addresses, for instance); some questions are, is it intentiona= l >>> that the Domain attribute disallows setting the attribute to a IPv4 >>> address, would a leading '.' in the attribute still be stripped, if suc= h >>> host specifications are disallowed, must all cookies coming from them b= e >>> rejected? With a Set-Cookie from 127.0.0.1 with no Domain attribute, is >>> it incorrect to imply Domain=3D127.0.0.1? (I don't care, the specificat= ion >>> however needs to discuss those questions). >> >>Can you provide a test case that illustrates behavior that you think >>is not defined? > > I believe I did. I should be more clear. In this case, I'm asking for a sequence of octets exchanged by the server and the user agent that causes the protocol to arrive in a situation that you believe is not defined. You have not provided any such sequence of octets and so I cannot use them to test the protocol definition. >>> The draft needs to explain how to handle a Set-Cookie header in a reply >>> to an `OPTIONS *` request. Right now it seems `uri-path` would be unde- >>> fined in that case, but the draft does not say what the consequence is. >>> There should be an explicit mention of the case, not just adjusted algo= - >>> rithms. >> >>The draft says: >> >>[[ >> =A0 =A0 =A0 =A0 =A0 =A0If the uri-path is empty or if first character= of the uri-path >> =A0 =A0 =A0 =A0 =A0 =A0is not a U+002F ("/") character, output U+002F ("= /") and skip the >> =A0 =A0 =A0 =A0 =A0 =A0remaining steps. >>]] >> >>Doesn't this fall under the case of the uri-path being empty? > > Since `uri-path` is "the path portion", and "*" is not a path, we do not > know what `uri-path` is. I've changed the text to say explicitly that uri-path is empty if the path portion of the request-uri does not exist. In that case, the default-path will be computed as "/", which is correct. >>> In section 5.2, if the draft takes the position that HTTP header values >>> are sequences of octets and not Unicode code points, then it needs to b= e >>> explained at the beginning of this section how those octets are turned >>> into characters (at least so long as it refers directly to the header >>> and not some pre-processed value based on it, and so long it refers to >>> characters instead of octets). >> >>The octets are never turned into characters. > > You eventually pass some of the octets to the ToASCII function which > only accepts characters, not octets. So, either you do convert, or you > cannot use ToASCII. What algorithm should I use instead? It's quite difficult to work with underlying specifications that can't provide such elementray concepts as the URL of an HTTP request or the host name of a URL. >>> In section 5.2.1 and subsequent sections the term "case-insensitively >>> matches" is not defined; this should probably be defined in the termi- >>> nology section. >> >>I'll be happy to add this if you can provide the definition you'd like >>to see in the terminology section. > > There should be plenty of specifications to steal the text from, you > could say "In this specification two strings are said to case-insen- > sitively match each other if and only if they are equivalent under the > i;ascii-casemap collation defined in RFC 4790". I am sure you can find > more appropriate text. [[ The "i;ascii-casemap" collation is a simple collation that operates on octet strings and treats US-ASCII letters case-insensitively. ]] That does appear to be what we'd like. Thanks. >>> I doubt the draft should require implementations to use the "last" Date >>> header, there are plenty of HTTP implementations where that is not >>> possible as the headers are only accessible in folded form. >> >>As far as I can tell, that's how the protocol works. =A0Can you provide >>a test case that shows otherwise? > > A quick reading of the libwww-perl code suggests it does not use the > "Date" header at all when determining the expiration time. Qt would > seem to be another example. See below. >>> Section >>> 4.1.2.1 also should be updated to clearly express that even though the >>> expiry time is set in an absolute form, it'll be handled as relative >>> value, as that is rather surprising. >> >>There are lots of details explained in Section 5 that are not >>presented in Section 4. =A0It's unclear why this particular detail >>merits inclusion. > > It is common for cookie processing library to operate only on the values > of the Set-Cookie and Cookie headers, not on whole request and response > objects or the value of the headers plus the value of a Date header; for > example, QNetworkCookie::parseCookies only takes a byte array as input. > Obviously the requirement has not been anticipated or has been ignored. > That should be sufficient reason to draw special attention to it. See below. On Sat, May 29, 2010 at 11:15 AM, Daniel Stenberg wrote: > On Fri, 28 May 2010, Bjoern Hoehrmann wrote: >> I doubt the draft should require implementations to use the "last" Date >> header, there are plenty of HTTP implementations where that is not possi= ble >> as the headers are only accessible in folded form. Section 4.1.2.1 also >> should be updated to clearly express that even though the expiry time is= set >> in an absolute form, it'll be handled as relative value, as that is rath= er >> surprising. > > I agree. I don't think we've discussed this properly on the list. (Or if = we > did I might've missed it.) We discussed it briefly in the context of time zones. The current text is based on the Firefox behavior. > Why would the 'expires' attribute be treated relative like 5.2.1 describe= s? Dunno. > Expires is an absolute time, and I don't see why clients shouldn't try to > use exactly that time in time comparisons. If the server/client clocks ar= e > off in any significant way, every response-with-cookies without Date: hea= der > would then be subject to flaws and I expect that a majority of > cookie-sending server responses are done without Date: > > I also would expect that lots of implmentations treat that time as an > absolute and not a relative unconditionally. > > Are the big-5 doing it this way? I will test in more detail. Hopefully this is a Firefox-only behavior, in which case I'd be in favor of removing it because its very subtle. On Sat, May 29, 2010 at 11:37 AM, Yngve N. Pettersen (Developer Opera Software ASA) wrote: > On Sat, 29 May 2010 20:15:42 +0200, Daniel Stenberg wrot= e: > >> On Fri, 28 May 2010, Bjoern Hoehrmann wrote: >> >>> I doubt the draft should require implementations to use the "last" Date >>> header, there are plenty of HTTP implementations where that is not poss= ible >>> as the headers are only accessible in folded form. Section 4.1.2.1 also >>> should be updated to clearly express that even though the expiry time i= s set >>> in an absolute form, it'll be handled as relative value, as that is rat= her >>> surprising. >> >> I agree. I don't think we've discussed this properly on the list. (Or if >> we did I might've missed it.) >> >> Why would the 'expires' attribute be treated relative like 5.2.1 >> describes? Expires is an absolute time, and I don't see why clients >> shouldn't try to use exactly that time in time comparisons. If the >> server/client clocks are off in any significant way, every >> response-with-cookies without Date: header would then be subject to flaw= s >> and I expect that a majority of cookie-sending server responses are done >> without Date: >> >> I also would expect that lots of implmentations treat that time as an >> absolute and not a relative unconditionally. >> >> Are the big-5 doing it this way? > > Opera is using the Expires attribute as an absolute UTC date and time. > Frankly, I think it should stay that way. Thanks, this is useful data. > Servers should keep their clock well in sync, so should clients, > particularly since quite a few security features in SSL depends on a > reasonably accurate clock. There are plenty of non-SSL sites that we need to worry about as well. > The situation where a slightly off clock can cause problems is for > shortlived cookies, and those are better handled through maxage. Indeed, but that doesn't stop existing sites from using Expires. > My guess is that this has been adopted from the cache lifetime definition= s > in 2616 and 2616-bis. The text in the spec was adopted from studying how Firefox behaves at the suggestion of dwitte. I don't know the origin of the behavior in Firefox. > I have no idea whether other clients use relative time at present, but if > they don't, then all the clients that could be adapted to it would alread= y > support maxage. Considerations about Max-Age are irrelevant. We're worried about already deployed servers who are using Expires instead of Max-Age. On Sat, May 29, 2010 at 1:43 PM, Daniel Stenberg wrote: > On Sat, 29 May 2010, Yngve N. Pettersen (Developer Opera Software ASA) > wrote: >> The situation where a slightly off clock can cause problems is for >> shortlived cookies, and those are better handled through maxage. > > Well, one could imagine a similar concept for maxage, like for the case > where the server wants the cookie to be alive 10 seconds, but the mere > transfer of the cookie to the client takes 5... I would expect most clien= t > implementations to consider the maxage time to start ticking the moment t= he > cookie is actually parsed and not from the Date: of the http response. I'll add this to my testing matrix. Adam From yngve@opera.com Sun May 30 14:48:16 2010 Return-Path: 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 819313A6782 for ; Sun, 30 May 2010 14:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] 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 ojQcFd0gwRIN for ; Sun, 30 May 2010 14:48:14 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id 5BFD63A692D for ; Sun, 30 May 2010 14:48:14 -0700 (PDT) Received: from acorna (30.169.202.84.customer.cdi.no [84.202.169.30]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4ULlx7T010410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 30 May 2010 21:48:00 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Adam Barth" References: Date: Sun, 30 May 2010 23:47:57 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Yngve N. Pettersen (Developer Opera Software ASA)" Organization: Opera Software AS Message-ID: In-Reply-To: User-Agent: Opera Mail/10.53 (Win32) Cc: "http-state@ietf.org" Subject: Re: [http-state] Comments on draft-ietf-httpstate-cookie-08 X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 May 2010 21:48:16 -0000 On Sun, 30 May 2010 22:48:16 +0200, Adam Barth wrote: > On Fri, May 28, 2010 at 6:05 PM, Yngve Nysaeter Pettersen > wrote: >> Here are some more comments about the httpstate draft. > >> - %XX escaping and path compares. Maybe add a reference to the URI >> compare >> definition in 2616? > > Can you provide a test case that demonstrates that %-escaping is > relevant in this context? My testing shows that user agents ignore > %-escaping in the Path attribute. Now, some user agents canonicalize > %-escaping in URLs, but that's a matter best left to another working > group, IMHO. target URI is /foo/%41/bar, path is /foo/a/ >> As for the server-side, when sending this header >> >> Cookie: name1="foo1; name2=bar"; name3=foo2"2; name4=bar"4; name5=foo >> >> to Django 1.1 or the Python 2.6 Cookie module, the result is the >> following >> set of cookies: >> >> name1="foo1; name2=bar" >> name3=foo2 >> name4=bar >> name5=foo > > That's only an issue if Django sends a Set-Cookie header that > generates that Cookie header. If somewhere there's a Django server > that does send such a Set-Cookie header, the author of that server is > likely expecting the Cookie header to parse that way because that's > how it works for the majority of user agents. If they aren't > expecting that parsing, they'll discover it as soon as they test their > site with any version of IE. You are assuming that Django is the only framework involved in the system. And AFAICT this behavior comes from *Python's* module for cookie handling, and is *not* Django-only, meaning that potentially all Python based systems could encounter this problem. And keep in mind that this was just the frameworks I had immediately at hand, it may well be (probably very likely) that other frameworks are behaving in the same fashion. I think it is quite possible that a parser such as Django/Python's can be integrated into an existing system that under some circumstances use unbalance quotes by another system. If so, testing might not reveal the issue until much later. One possibility is that the cookie's value is directly or indirectly derived from user input (which could be very dangerous in any case). > By contrast, if we adopt Opera's parsing of the Set-Cookie header, > then we're much more likely to cause interoperability problems for > sites that rely on the more common parsing. Not too frequently I suspect; I can recall only one, maybe two, cases (and the one I remember showed up in my mailbox last week) >> The situation for this particular value syntax is already undefined, and >> while it is a corner case, it can have unanticipated effects, >> particularly >> in combination with different cookie ordering algorithms. Putting the >> server >> administrators on notice about the issue should hopefully increase >> interoperability because they can then avoid the problematic cases. > > The behavior for this particular value syntax is indeed defined. You By "undefined" I mean that there are already deployed systems that behave in different fashions from what might be expected if unbalanced quotes are used. Perhaps "the result is unpredicatable" would be a better description. > can find the definition in Section 5. We're already advising server > administrators not to use double-quotes. That's the most helpful Not in that many words, but it is admittedly implied by the token specification of cookie-value. I think that in this case it is better to have a little redundancy by pointing out that this is one character where the "opaque" part is ignored by a number of clients (and may be ignored by serverside frameworks), and we are not just talking about Opera, we are also talking about a major client like FireFox 3.6 and earlier versions (whether or not nightlies have changed behavior in this area) -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ******************************************************************** From ietf@adambarth.com Sun May 30 16:53:16 2010 Return-Path: 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 AEB4A3A6877 for ; Sun, 30 May 2010 16:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.499 X-Spam-Level: X-Spam-Status: No, score=0.499 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] 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 y3BkrRhNgD8X for ; Sun, 30 May 2010 16:53:15 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by core3.amsl.com (Postfix) with ESMTP id EAF0E3A6970 for ; Sun, 30 May 2010 16:53:14 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so886003fga.13 for ; Sun, 30 May 2010 16:53:00 -0700 (PDT) Received: by 10.87.15.40 with SMTP id s40mr7786882fgi.44.1275263579970; Sun, 30 May 2010 16:52:59 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by mx.google.com with ESMTPS id d8sm12733123fga.1.2010.05.30.16.52.58 (version=SSLv3 cipher=RC4-MD5); Sun, 30 May 2010 16:52:59 -0700 (PDT) Received: by gwj19 with SMTP id 19so2396928gwj.31 for ; Sun, 30 May 2010 16:52:56 -0700 (PDT) Received: by 10.231.120.37 with SMTP id b37mr4705781ibr.81.1275263576697; Sun, 30 May 2010 16:52:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.60.4 with HTTP; Sun, 30 May 2010 16:52:36 -0700 (PDT) In-Reply-To: References: From: Adam Barth Date: Sun, 30 May 2010 16:52:36 -0700 Message-ID: To: "Yngve N. Pettersen (Developer Opera Software ASA)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "http-state@ietf.org" Subject: Re: [http-state] Comments on draft-ietf-httpstate-cookie-08 X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 May 2010 23:53:16 -0000 On Sun, May 30, 2010 at 2:47 PM, Yngve N. Pettersen (Developer Opera Software ASA) wrote: > On Sun, 30 May 2010 22:48:16 +0200, Adam Barth wrote= : >> On Fri, May 28, 2010 at 6:05 PM, Yngve Nysaeter Pettersen >> wrote: >>> Here are some more comments about the httpstate draft. > >>> - %XX escaping and path compares. Maybe add a reference to the URI >>> compare >>> definition in 2616? >> >> Can you provide a test case that demonstrates that %-escaping is >> relevant in this context? =A0My testing shows that user agents ignore >> %-escaping in the Path attribute. =A0Now, some user agents canonicalize >> %-escaping in URLs, but that's a matter best left to another working >> group, IMHO. > > target URI is /foo/%41/bar, path is /foo/a/ Right, so that depends on whether the user agent canonicalizes %41 to "a" in its URL processing code. I don't think we should be concerned with that in this working group. I'm also working on URL parsing and canonicalization, so hopefully we'll get that stuff ironed out as well. >>> As for the server-side, when sending this header >>> >>> =A0Cookie: =A0name1=3D"foo1; name2=3Dbar"; name3=3Dfoo2"2; name4=3Dbar"= 4; name5=3Dfoo >>> >>> to Django 1.1 or the Python 2.6 Cookie module, the result is the >>> following >>> set of cookies: >>> >>> =A0name1=3D"foo1; name2=3Dbar" >>> =A0name3=3Dfoo2 >>> =A0name4=3Dbar >>> =A0name5=3Dfoo >> >> That's only an issue if Django sends a Set-Cookie header that >> generates that Cookie header. =A0If somewhere there's a Django server >> that does send such a Set-Cookie header, the author of that server is >> likely expecting the Cookie header to parse that way because that's >> how it works for the majority of user agents. =A0If they aren't >> expecting that parsing, they'll discover it as soon as they test their >> site with any version of IE. > > You are assuming that Django is the only framework involved in the system= . > And AFAICT this behavior comes from *Python's* module for cookie handling= , > and is *not* Django-only, meaning that potentially all Python based syste= ms > could encounter this problem. And keep in mind that this was just the > frameworks I had immediately at hand, it may well be (probably very likel= y) > that other frameworks are behaving in the same fashion. > > I think it is quite possible that a parser such as Django/Python's can be > integrated into an existing system that under some circumstances use > unbalance quotes by another system. If so, testing might not reveal the > issue until much later. One possibility is that the cookie's value is > directly or indirectly derived from user input (which could be very > dangerous in any case). Regardless, either those systems work today or they don't. If they work today, then they'll work with the cookie protocol as specified. If they don't work today, well, then they should be fixed. We're not introducing any new behavior that hasn't been deployed for many, many years. >> By contrast, if we adopt Opera's parsing of the Set-Cookie header, >> then we're much more likely to cause interoperability problems for >> sites that rely on the more common parsing. > > Not too frequently I suspect; I can recall only one, maybe two, cases (an= d > the one I remember showed up in my mailbox last week) By contrast, I don't think IE has gotten such an email in the past decade despite shipping this behavior for as long as I can tell. >>> The situation for this particular value syntax is already undefined, an= d >>> while it is a corner case, it can have unanticipated effects, >>> particularly >>> in combination with different cookie ordering algorithms. Putting the >>> server >>> administrators on notice about the issue should hopefully increase >>> interoperability because they can then avoid the problematic cases. >> >> The behavior for this particular value syntax is indeed defined. =A0You > > By "undefined" I mean that there are already deployed systems that behave= in > different fashions from what might be expected if unbalanced quotes are > used. =A0Perhaps "the result is unpredicatable" would be a better descrip= tion. Depends what sets peoples expectations. In my experience, the first thing to set people's expectations is the behavior of Internet Explorer (especially in a standards vacuum, like we've had historically with cookies). That might not be a pleasant fact, and we might wish to pretend it's not true, but that is the world in which we find ourselves. >> can find the definition in Section 5. =A0We're already advising server >> administrators not to use double-quotes. =A0That's the most helpful > > Not in that many words, but it is admittedly implied by the token > specification of cookie-value. I think that in this case it is better to > have a little redundancy by pointing out that this is one character where > the "opaque" part is ignored by a number of clients (and may be ignored b= y > serverside frameworks), and we are not just talking about Opera, we are a= lso > talking about a major client like FireFox 3.6 and earlier versions (wheth= er > or not nightlies have changed behavior in this area) There are lots of exciting characters that cause wacky behavior. Just because your user agent happens to get tripped up on this one doesn't mean it's worth calling out in the spec. We could add reams of rationale for everything in the document. In this case, I think we'd be better of explaining the life and times of the double-quote character in the deviation description document. Actually, the story is pretty engaging when told from the beginning as a narrative (if you're into this sort of thing). I'd rather set out the full context and explanation in the other document. Adam From ietf@adambarth.com Sun May 30 18:59:04 2010 Return-Path: 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 AC2293A693F for ; Sun, 30 May 2010 18:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.354 X-Spam-Level: X-Spam-Status: No, score=0.354 tagged_above=-999 required=5 tests=[AWL=-0.869, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_43=0.6] 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 XkldqwEsnpS9 for ; Sun, 30 May 2010 18:59:02 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id E7B113A6832 for ; Sun, 30 May 2010 18:59:01 -0700 (PDT) Received: by gyh4 with SMTP id 4so2453263gyh.31 for ; Sun, 30 May 2010 18:58:47 -0700 (PDT) Received: by 10.151.24.20 with SMTP id b20mr4399676ybj.198.1275271126421; Sun, 30 May 2010 18:58:46 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by mx.google.com with ESMTPS id q8sm7555807ybk.7.2010.05.30.18.58.43 (version=SSLv3 cipher=RC4-MD5); Sun, 30 May 2010 18:58:44 -0700 (PDT) Received: by gyh4 with SMTP id 4so2453213gyh.31 for ; Sun, 30 May 2010 18:58:43 -0700 (PDT) Received: by 10.231.155.3 with SMTP id q3mr4903835ibw.20.1275271123376; Sun, 30 May 2010 18:58:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.60.4 with HTTP; Sun, 30 May 2010 18:58:23 -0700 (PDT) In-Reply-To: References: From: Adam Barth Date: Sun, 30 May 2010 18:58:23 -0700 Message-ID: To: Bjoern Hoehrmann Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: http-state@ietf.org Subject: Re: [http-state] Comments on draft-ietf-httpstate-cookie-08.txt (1 - 4.1.2.) X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 01:59:05 -0000 On Wed, May 26, 2010 at 2:52 PM, Bjoern Hoehrmann wrote= : > * Adam Barth wrote: >>> Later in the section, there should be a bibliographic reference for the >>> "Netscape cookie specification". >> >>I'd be happy to add this if you let me know what citation you think we >>should use here. =A0The problem is that I don't know of a canonical URL >>to cite now that the original Netscape site is defunct. > > It does not have to include an address, something like 'Netscape > Communications Corp., "Persistent Client State - HTTP Cookies"' would > do. http://wp.netscape.com/newsref/std/cookie_spec.html should be the > address, the Internet Archive has archived copies of it, and it should > be fine to cite the Internet Archive address (at least I did do that > in RFC 4329 for the JavaScript reference manual). Done. >>> In section 2.2 the imported rules should be phrased as grammar to make >>> them easer to scan and read, i.e., e.g. >>> >>> =A0ALPHA =3D ; A-Z / a-z >>> =A0... >> >>I looked a bunch of RFCs and this didn't appear to be that common. >>I'd be happy to do this if you can show me three relatively recent >>RFCs that use this pattern. > > RFC 5536, RFC 5537, RFC 5538. The draft itself does this for other > rules, like for `token`. See below. On Thu, May 27, 2010 at 12:49 AM, Julian Reschke wr= ote: > On 26.05.2010 22:45, Adam Barth wrote: >> On Wed, May 26, 2010 at 10:22 AM, Bjoern Hoehrmann >> =A0wrote: >>> Later in the section, there should be a bibliographic reference for the >>> "Netscape cookie specification". >> >> I'd be happy to add this if you let me know what citation you think we >> should use here. =A0The problem is that I don't know of a canonical URL >> to cite now that the original Netscape site is defunct. > > I agree that this needs a citation, even if we can't provide the original > URI. Proposal: create something on purl.org (I know the RFC Editor is lik= ely > to accept that), and let it redirect to the best copy we can find. If tha= t > breaks, we still can update the purl. I've added the citation without a URL. There are lots of broken URLs in the old cookie specs. I don't really want to add to the sadness of broken URLs. Hopefully search engines in the future will be powerful enough to find the document if it still exists. >>> In the same paragraph "However, none of >>> these documents describe how the Cookie and Set-Cookie headers are >>> actually used on the Internet" is rather unclear and does not appear to >>> do the relevant documents justice. As reader I am left wondering if the >>> intend is to say they did not attempt to do so, or were incomplete, or >>> what else is wrong with them. >> >> That's just a statement of fact. =A0I'm not sure what the intentions >> were of their creators, but (however we got here) we find ourselves in >> that situation. > > That statement is kind of confusing to people who do not already know the > history. > > Maybe it would make sense to cite > > [Kri2001] =A0 =A0 =A0 Kristol, D., =93HTTP Cookies: Standards, Privacy, a= nd > Politics=94, ACM Transactions on Internet Technology Vol. 1, #2, November > 2001, . > > to give some more context. Done. >>> In section 2.2 the imported rules should be phrased as grammar to make >>> them easer to scan and read, i.e., e.g. >>> >>> =A0ALPHA =3D =A0; A-Z / a-z >>> =A0... >> >> I looked a bunch of RFCs and this didn't appear to be that common. >> I'd be happy to do this if you can show me three relatively recent >> RFCs that use this pattern. > > Adam is right; not expanding the RFC 5234 base rules is quite common. Ok. I've left these as is. >>> In section 2.3 we have "The terms request-host and request-uri refer to >>> the values the user agent would send to the server as, respectively, th= e >>> host (but not port) and the absoluteURI (http_URL) of the HTTP >>> Request-Line." I am not entirely sure how to read that; for example, th= e >>> "host" would be part of "absoluteURI" if it is sent in the Request-Line= , >>> and sending an absoluteURI there is unusual (unless talking to a proxy)= . >>> Also, the reference to http_URL is probably incorrect if "https" URLs >>> are also permissable. >> >> I find it completely ridiculous that the specs make it so hard to say >> what URL and host we're sending a request to, which would seem to be >> the two most important things about an HTTP request. =A0Hopefully >> someone will chime in with the magic incantation we're supposed to use >> here. > > If you're willing to wait for httpbis, "Effective Request URI" might be t= he > right thing > (). I'm glad this is getting fixed. I don't particularly want to take a dependency on HTTPbis, as discussed before. >>> Later in the section, "The origin server MAY send the user agent a >>> Set-Cookie response header with the same or different information, or i= t >>> MAY send no Set-Cookie header at all." It is unclear what "same" refers >>> to here. It sounds like this might refer to servers setting the same >>> cookie over and over again even if the client is already sending it bac= k >>> but that does not become clear from the paragraph. >> >> It just means the server can send whatever it likes, including things >> that are the same or different from what it sent before or not sending >> things at all. > > I also have to point out that this use of MAY is irritating; just state t= hat > this is optional behavior. Ok. I've just removed this sentence. It was meant to be helpful, but it seems to be causing more problems then it's worth. It's not need for the normative content of the document anyway. >>> At the end of section 3 it should be pointed out that the do-not-fold >>> rule is inconsistent with RFC 2616. >> >> This is pointed out in HTTPbis. =A0At worst, this inconsistency will >> exist for only a short time. > > HTTPbis currently says: > > "Note: The "Set-Cookie" header as implemented in practice (as opposed to = how > it is specified in [RFC2109]) can occur multiple times, but does not use = the > list syntax, and thus cannot be combined into a single line. (See Appendi= x > A.2.3 of [Kri2001] for details.) Also note that the Set-Cookie2 header > specified in [RFC2965] =A0does not share this problem." > -- > > > So the Cookie spec has an additional requirement compared both to RFC 261= 6 > and HTTPbis, and that should be pointed out (and explained!). I've changed this text to be purely descriptive: [[ Note that folding multiple Set-Cookie header fields into a single header field might change the semantics of the header because = the U+002C (",") character is used by the Set-Cookie header in a way that conflicts with such folding. ]] >>> The grammar makes reference to "abs_path", but does not define what it >>> is. >> >> I've just made this. > > Is this supposed to be the same as abs_path in RFC 2396? If it is, RFC 39= 86 > has replaced this with path-absolute. More consistency with these specs > would be good. This production is just advice for servers. It doesn't really matter that much how closely they stick to abs_path and it's easier to have something concrete in the grammar instead of making the reader chase a mountain of definitions. >> ... >> I've removed the concept of a cookie store from this section because >> it's not needed to explain what's going on. >> ... > > It's good that you already improved the spec; can you please post this > somewhere (not as new ID!), so people doing the LC review can check wheth= er > something has already been addressed? Sure. As always, you can find the up-to-the-minute version of the draft he= re: http://github.com/abarth/http-state/blob/master/drafts/cookie.xml On Thu, May 27, 2010 at 7:33 AM, Bjoern Hoehrmann wrote= : > * Adam Barth wrote: >>I don't agree. =A0The purpose of the text in the spec is to explain why >>the text in this document isn't consistent with those documents. >>Those documents do not reflect reality. =A0This document is intended to >>reflect reality. > > The purpose of an introductory section is to take the reader from where > he is standing and explain to him where things will be going from there. > > Pointing out that the ten years old specification for the Set-Cookie2 > and Cookie2 headers does not describe how the Set-Cookie and Cookie > headers are used today does not do that, it rather misleads the reader. > > Telling the reader that even older specifications do not describe how > the headers are used currently is not helpful either unless it is also > explained how and to what degree things are different; what it says is > "You know stuff about cookies. It's wrong or not, continue with the next > three dozens of pages to find out." That leaves the reader constantly > wondering. > > Drawing attention to the obvious should be avoided as readers would have > to expend additional effort to confirm that what is being pointed out is > indeed obvious -- and not some subtlety they've missed -- for no gain. > If a specification replaces two older ones based on implementation ex- > perience, then it is obvious that the older specifications do not re- > flect current practise equally well. Hopefully the added citation to Kristol's missive should suffice. The old spec are actively harmful. This text is meant to reassure the reader that we're contrite for our previous sins and are trying to do no harm in this document. >>> Right now the first occurrence of "host-name" is in "A canonicalized >>> host-name is the host-name converted to ..." which proceeds without >>> saying what a "host-name" is in the first place. >> >>Precisely. =A0For example "f(x) =3D x + 1" doesn't proceed to say what "x= " >>is in the first place. > > In mathematics, function definitions require a specification of their > domain and codomain; you would know what `x` is, namely a member of > the domain of the function; but without specifying the domain you do > not have a function. That's a matter for philosophers of mathematics, but certainly not all of them would agree with you. :) > In the context of "hosts" the term "canonicalized" is overloaded with > definitions, RFC 1123 for example defines it quite differently than > draft-ietf-httpstate-cookie-08.txt. I've changed the text to define a "canonicalized string", which should emphasize that the name of the formal parameter is irrelevant. > Further, the permissable range of values for `request-host` is larger > than the apparent domain of the draft's `canonicalized` "function". > For instance, the "host" can be an IP-Literal, but you cannot apply > the ToASCII function to those -- they are outside its domain. Ok. Well, I'm happy to write whatever you like in that part of the spec. The point is we need the puny code version of the host name. When I wrote that before, someone complained that I couldn't use the words "puny code" in that way, so I adopted the text they recommend. Now I'm told that I can't use the text they gave me. This text is really trying to accomplish a very simply task, which is to obtain the lower case, puny code version of a host name from a URL. In code, this is as simple as writing "url->host()". Let me know what the magic phase is, and I'm happy to appease. > So I've found no reason to assume that I am supposed to lookup > "canonicalized request-host" under "A canonicalized host-name is". Hopefully replacing the string "host-name" with "string" has make this easier for you to understand. >>> The implied lws rule in RFC 2616 has been a source of considerable >>> confusion as it implied optional white space where people do not ex- >>> pect it and because some rules use it and some rules do not and that >>> is not made clear through the grammar but rather through prose and >>> thus easy to miss. The draft builds on RFC 2616 but unlike most other >>> extension header specifications does not re-use the grammar notation >>> defined in RFC 2616 but a very slightly different notation, and then >>> the draft imports rules from RFC 2616 where one has to pay very close >>> attention to those notational differences and the surrounding prose >>> to read the grammar correctly. I do not care much how, but I do think >>> the draft needs to draw attention to this to avoid confusion. >> >>Feel free to send me a diff with a proposed clarification. > > If you require help to turn my sketch into proper text, you would need > to tell what difficulty you are having. The very first sentence of the "Syntax Notation" section says: [[ This specification uses the Augmented Backus-Naur Form (ABNF) notation of . ]] Would you prefer that line said something else to clarify that we really mean the ABNF notation of RFC5234 as opposed to something else? Would you like that text copy/pasted to every location where we use an ABNF grammar? I'm happy to review a diff to the spec. In general, the more specific your feedback, the more actionable it is by me. Currently, your feedback is "I do not care much how, but I do think the draft needs to draw attention to this to avoid confusion." I don't know how to draw more attention to the issue other than stating unequivocally which grammar form we're using as the first normative requirement after stating our conformance criteria. Adam From derhoermi@gmx.net Mon May 31 06:54:23 2010 Return-Path: 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 9E6DC3A68A4 for ; Mon, 31 May 2010 06:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.264 X-Spam-Level: X-Spam-Status: No, score=-1.264 tagged_above=-999 required=5 tests=[AWL=0.735, BAYES_50=0.001, GB_I_LETTER=-2] 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 OP1uUM3TwsfV for ; Mon, 31 May 2010 06:54:22 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id C444C3A684D for ; Mon, 31 May 2010 06:54:21 -0700 (PDT) Received: (qmail invoked by alias); 31 May 2010 13:54:08 -0000 Received: from dslb-094-222-135-191.pools.arcor-ip.net (EHLO hive) [94.222.135.191] by mail.gmx.net (mp011) with SMTP; 31 May 2010 15:54:08 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1/MYxZvX43MpwDZ9IB2OnZ+FLWIpyt3gp1sH2vE0n 3TsYYPyDyDycVA From: Bjoern Hoehrmann To: Adam Barth Date: Mon, 31 May 2010 15:54:02 +0200 Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: http-state@ietf.org Subject: Re: [http-state] Comments on draft-ietf-httpstate-cookie-08.txt (1 - 4.1.2.) X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 13:54:23 -0000 * Adam Barth wrote: >>>> In section 2.2 the imported rules should be phrased as grammar to make >>>> them easer to scan and read, i.e., e.g. >>>> >>>> ALPHA = ; A-Z / a-z >>>> ... >>> >>> I looked a bunch of RFCs and this didn't appear to be that common. >>> I'd be happy to do this if you can show me three relatively recent >>> RFCs that use this pattern. >> >> Adam is right; not expanding the RFC 5234 base rules is quite common. > >Ok. I've left these as is. Assuming Julian's point is about the "A-Z" comment above, that is not my concern at all. The current text already has expansions, but they are misleading (for example, it calls `ALPHA` just "letters", but there are many letters that `ALPHA` does not include). I am fine with omitting the current expansions alltogether, but would prefer using ABNF syntax as above, regardless of the "; A-Z / a-z" comment, as that is more readable and a convention the document uses elsewhere. >On Thu, May 27, 2010 at 7:33 AM, Bjoern Hoehrmann wrote: Please do not lump replies to multiple messages into one message. This is a discussion list and discussions become very difficult to follow if you cannot track replies properly. >> Drawing attention to the obvious should be avoided as readers would have >> to expend additional effort to confirm that what is being pointed out is >> indeed obvious -- and not some subtlety they've missed -- for no gain. >> If a specification replaces two older ones based on implementation ex- >> perience, then it is obvious that the older specifications do not re- >> flect current practise equally well. > >Hopefully the added citation to Kristol's missive should suffice. The >old spec are actively harmful. This text is meant to reassure the >reader that we're contrite for our previous sins and are trying to do >no harm in this document. I do not believe that is sufficient. I believe I've explained why I think the current formulation is inadequate and I've made suggestions how to rephrase it. If you have no suggestions how to rephrase it in a manner we can agree on, I am happy to raise this issue again during IETF review, perhaps others have some suggestions. >> In the context of "hosts" the term "canonicalized" is overloaded with >> definitions, RFC 1123 for example defines it quite differently than >> draft-ietf-httpstate-cookie-08.txt. > >I've changed the text to define a "canonicalized string", which should >emphasize that the name of the formal parameter is irrelevant. I will revisit this later. >> Further, the permissable range of values for `request-host` is larger >> than the apparent domain of the draft's `canonicalized` "function". >> For instance, the "host" can be an IP-Literal, but you cannot apply >> the ToASCII function to those -- they are outside its domain. > >Ok. Well, I'm happy to write whatever you like in that part of the >spec. The point is we need the puny code version of the host name. >When I wrote that before, someone complained that I couldn't use the >words "puny code" in that way, so I adopted the text they recommend. >Now I'm told that I can't use the text they gave me. > >This text is really trying to accomplish a very simply task, which is >to obtain the lower case, puny code version of a host name from a URL. > In code, this is as simple as writing "url->host()". Let me know >what the magic phase is, and I'm happy to appease. I am happy to make a suggestion once there is a proper definition for `request-host`. If you start from a resource identifier, this will most likely need a condition (if it is non-ascii and represents an IDN, then transform into the IDNA encoding) and an exception handler (if trans- formation fails, then...; I do not know what is to happen in that case though). >>[ABNF vs RFC 2616 grammar differences] >Would you prefer that line said something else to clarify that we >really mean the ABNF notation of RFC5234 as opposed to something else? > Would you like that text copy/pasted to every location where we use >an ABNF grammar? I'm happy to review a diff to the spec. Copying the rfc1123-date grammar from draft-ietf-httpbis-p1-messaging-09 into an appendix would probably be the best solution as differences with case-sensitivity and white space would then no longer be a source of confusion. Otherwise there simply should be a reminder that the grammar notation is different from RFC 2616 and care must be taken to apply the right rules for imported symbols. -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de Am Badedeich 7 Telefon: +49(0)160/4415681 http://www.bjoernsworld.de 25899 Dagebll PGP Pub. KeyID: 0xA4357E78 http://www.websitedev.de/ From ietf@adambarth.com Mon May 31 09:26:27 2010 Return-Path: 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 0D7393A689B for ; Mon, 31 May 2010 09:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.822 X-Spam-Level: X-Spam-Status: No, score=-0.822 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2] 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 BgzJyNjWE2Ns for ; Mon, 31 May 2010 09:26:25 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 7BFCD3A687B for ; Mon, 31 May 2010 09:26:25 -0700 (PDT) Received: by vws15 with SMTP id 15so823973vws.31 for ; Mon, 31 May 2010 09:26:10 -0700 (PDT) Received: by 10.224.78.104 with SMTP id j40mr1778336qak.251.1275323169224; Mon, 31 May 2010 09:26:09 -0700 (PDT) Received: from mail-yw0-f182.google.com (mail-yw0-f182.google.com [209.85.211.182]) by mx.google.com with ESMTPS id f5sm1617693qcg.8.2010.05.31.09.26.05 (version=SSLv3 cipher=RC4-MD5); Mon, 31 May 2010 09:26:05 -0700 (PDT) Received: by ywh12 with SMTP id 12so3518332ywh.19 for ; Mon, 31 May 2010 09:26:04 -0700 (PDT) Received: by 10.151.28.14 with SMTP id f14mr5442311ybj.398.1275323164383; Mon, 31 May 2010 09:26:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.147.66 with HTTP; Mon, 31 May 2010 09:25:44 -0700 (PDT) In-Reply-To: References: From: Adam Barth Date: Mon, 31 May 2010 09:25:44 -0700 Message-ID: To: Bjoern Hoehrmann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: http-state@ietf.org Subject: Re: [http-state] Comments on draft-ietf-httpstate-cookie-08.txt (1 - 4.1.2.) X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 16:26:27 -0000 On Mon, May 31, 2010 at 6:54 AM, Bjoern Hoehrmann wrote= : > * Adam Barth wrote: >>>>> In section 2.2 the imported rules should be phrased as grammar to mak= e >>>>> them easer to scan and read, i.e., e.g. >>>>> >>>>> =A0ALPHA =3D =A0; A-Z / a-z >>>>> =A0... >>>> >>>> I looked a bunch of RFCs and this didn't appear to be that common. >>>> I'd be happy to do this if you can show me three relatively recent >>>> RFCs that use this pattern. >>> >>> Adam is right; not expanding the RFC 5234 base rules is quite common. >> >>Ok. =A0I've left these as is. > > Assuming Julian's point is about the "A-Z" comment above, that is not my > concern at all. The current text already has expansions, but they are > misleading (for example, it calls `ALPHA` just "letters", but there are > many letters that `ALPHA` does not include). I am fine with omitting the > current expansions alltogether, but would prefer using ABNF syntax as > above, regardless of the "; A-Z / a-z" comment, as that is more readable > and a convention the document uses elsewhere. This text comes verbatim from HTTPbis: http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-09#section-1.2 Is there a better role model that I should follow? >>> Drawing attention to the obvious should be avoided as readers would hav= e >>> to expend additional effort to confirm that what is being pointed out i= s >>> indeed obvious -- and not some subtlety they've missed -- for no gain. >>> If a specification replaces two older ones based on implementation ex- >>> perience, then it is obvious that the older specifications do not re- >>> flect current practise equally well. >> >>Hopefully the added citation to Kristol's missive should suffice. =A0The >>old spec are actively harmful. =A0This text is meant to reassure the >>reader that we're contrite for our previous sins and are trying to do >>no harm in this document. > > I do not believe that is sufficient. I believe I've explained why I > think the current formulation is inadequate and I've made suggestions > how to rephrase it. If you have no suggestions how to rephrase it in a > manner we can agree on, I am happy to raise this issue again during IETF > review, perhaps others have some suggestions. Ok. I stand by the current text as factually accurate. >>> In the context of "hosts" the term "canonicalized" is overloaded with >>> definitions, RFC 1123 for example defines it quite differently than >>> draft-ietf-httpstate-cookie-08.txt. >> >>I've changed the text to define a "canonicalized string", which should >>emphasize that the name of the formal parameter is irrelevant. > > I will revisit this later. > >>> Further, the permissable range of values for `request-host` is larger >>> than the apparent domain of the draft's `canonicalized` "function". >>> For instance, the "host" can be an IP-Literal, but you cannot apply >>> the ToASCII function to those -- they are outside its domain. >> >>Ok. =A0Well, I'm happy to write whatever you like in that part of the >>spec. =A0The point is we need the puny code version of the host name. >>When I wrote that before, someone complained that I couldn't use the >>words "puny code" in that way, so I adopted the text they recommend. >>Now I'm told that I can't use the text they gave me. >> >>This text is really trying to accomplish a very simply task, which is >>to obtain the lower case, puny code version of a host name from a URL. >> In code, this is as simple as writing "url->host()". =A0Let me know >>what the magic phase is, and I'm happy to appease. > > I am happy to make a suggestion once there is a proper definition for > `request-host`. Here's the definition of request-host: [[ The terms request-host and request-uri refer to the values the u= ser agent would send to the server as, respectively, the host (but not port) and the absoluteURI (http_URL) of the HTTP Request-Line. ]] Is that definition improper? What would a superior definition be? > If you start from a resource identifier, this will most > likely need a condition (if it is non-ascii and represents an IDN, then > transform into the IDNA encoding) and an exception handler (if trans- > formation fails, then...; I do not know what is to happen in that case > though). We need to start with an HTTP request. >>>[ABNF vs RFC 2616 grammar differences] > >>Would you prefer that line said something else to clarify that we >>really mean the ABNF notation of RFC5234 as opposed to something else? >> Would you like that text copy/pasted to every location where we use >>an ABNF grammar? =A0I'm happy to review a diff to the spec. > > Copying the rfc1123-date grammar from draft-ietf-httpbis-p1-messaging-09 > into an appendix would probably be the best solution as differences with > case-sensitivity and white space would then no longer be a source of > confusion. Otherwise there simply should be a reminder that the grammar > notation is different from RFC 2616 and care must be taken to apply the > right rules for imported symbols. I've add the following text near the use of 1123-date: [[ sane-cookie-date =3D ; Note that RFC 2616 uses a different grammatical notat= ion ; than this document (which uses ABNF from RFC5234). ]] Hopefully that addresses your concerns. Adam From derhoermi@gmx.net Mon May 31 10:35:47 2010 Return-Path: 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 783D328C100 for ; Mon, 31 May 2010 10:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.716 X-Spam-Level: X-Spam-Status: No, score=-0.716 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_20=-0.74] 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 TKVVvP96NcUq for ; Mon, 31 May 2010 10:35:41 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id E52C13A6A81 for ; Mon, 31 May 2010 10:35:27 -0700 (PDT) Received: (qmail invoked by alias); 31 May 2010 17:35:08 -0000 Received: from dslb-094-222-135-191.pools.arcor-ip.net (EHLO hive) [94.222.135.191] by mail.gmx.net (mp071) with SMTP; 31 May 2010 19:35:08 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+WuH8pm/yWGGhHV+Rlo3GHgpbBjK69Nf7X1YC4DT xtTm7ayEkogxcb From: Bjoern Hoehrmann To: Adam Barth Date: Mon, 31 May 2010 19:34:59 +0200 Message-ID: References: <9c8006lme07degqokchpkk0jq5vkt1njdu@hive.bjoern.hoehrmann.de> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: http-state@ietf.org Subject: Re: [http-state] Comments on draft-ietf-httpstate-cookie-08.txt (4.1.2.2 - 5.2.6) X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 17:35:47 -0000 * Adam Barth wrote: >>>I don't understand this comment. It's a warning that some existing >>>user agents behave incorrect w.r.t. the description that section. >>>That behavior is erroneous: it is in error. >> >> A remedy would be to state in the note what the correct behavior is, >> rather than simply say it is wrong. Obviously the developers of the >> misbehaving user agents did not think it wrong. > >On the contrary, even the developers of the misbehaving user agents >agree that the behavior is wrong, at least according to their public >statements on the matter. By your own account there have been several developers who have made the same mistake; could you explain how the specification would become worse if it briefly mentioned why the mistake actually is a mistake, and what would have been correct instead? >I've changed the structure of this sentence to be more parallel to >reflect the parallelism in the situation. I've also demoted the >mention of Section 5 to a parenthetical. > >[[ > The user agent sends stored cookies to the origin server in the > Cookie header. If the server conforms to the requirements in target="sane-set-cookie" /> (and the user agent conforms to the > requirements in the ), the user > agent will send a Cookie header that conforms to the following > grammar: >]] What you really seem to be trying to say is that user agents may send bad Cookie headers if and only if the Set-Cookie header they got also did not conform to the specification. That would be important to say, but that a user agent that conforms to the specification will behave in a conforming manner when dealing with conforming input is not important. >> There are two occurrences in the draft of `found-day-of-month`, the >> first is "If the found-day-of-month flag is not set and ..."; the other >> is in "Abort these steps and fail to parse if ... at least one of the >> found-day-of-month, found-month, found-year, or found-time flags is not >> set"; > >Ah, I understand your confusion. You missed the third occurrence of >the term in which the flag is actually set. :) I see. Please use &nbhy; (U+2011) instead of the hyphen, xml2rfc will then not wrap identifiers around, that way you can actually locate them. Alternatively you could quote them or use the underscore instead. >>>> The surprising requirements in this section need to be accompanied by >>>> some rationale, for example, accepting 1601 as year but not 1600 is >>>> surprising and so is the 68/69 boundary. >>> >>>The reason is just that's how the protocol works. It's odd, but >>>that's how it works. >> >> I think it is unlikely that surprising requirements will be widely im- >> plemented unless the reasoning behind them is explained. > >That requirement is already widely implemented, so we have nothing to fear here. Well, the draft requires the 19XXs to start with 1969, Gecko/20100529 and Opera 10.51 use 1970, Internet Explorer 6 uses 1980. The draft re- quires to ignore the Expires attribute if the year is below 1601, and Opera 10.51 rather treats all years before 1900 as 2036 (on my system anway). That is not my understanding of "widely implemented". >>>> There needs to be a discussion, I am not sure this is the right place, >>>> on the handling of permissable HTTP "hosts" (non-DNS names, IP-Literals >>>> and IPv4 addresses, for instance); some questions are, is it intentional >>>> that the Domain attribute disallows setting the attribute to a IPv4 >>>> address, would a leading '.' in the attribute still be stripped, if such >>>> host specifications are disallowed, must all cookies coming from them be >>>> rejected? With a Set-Cookie from 127.0.0.1 with no Domain attribute, is >>>> it incorrect to imply Domain=127.0.0.1? (I don't care, the specification >>>> however needs to discuss those questions). >>> >>>Can you provide a test case that illustrates behavior that you think >>>is not defined? >> >> I believe I did. > >I should be more clear. In this case, I'm asking for a sequence of >octets exchanged by the server and the user agent that causes the >protocol to arrive in a situation that you believe is not defined. >You have not provided any such sequence of octets and so I cannot use >them to test the protocol definition. Well, to pick an example, "Set-Cookie from 127.0.0.1 with no Domain attribute" should be entirely sufficient to make a test case if there is something to test. Similarily, you should be able to answer, "is it intentional that the Domain attribute disallows setting the attribute to a IPv4 address" (in the so-called well-behaved profile, if I need to add that) without observing implementation behavior. I do not see how a hex dump of IP packets would really help here. >>>> The draft needs to explain how to handle a Set-Cookie header in a reply >>>> to an `OPTIONS *` request. Right now it seems `uri-path` would be unde- >>>> fined in that case, but the draft does not say what the consequence is. >>>> There should be an explicit mention of the case, not just adjusted algo- >>>> rithms. >I've changed the text to say explicitly that uri-path is empty if the >path portion of the request-uri does not exist. In that case, the >default-path will be computed as "/", which is correct. I would need to know your reasoning behind not mentioning `OPTIONS *` explicitly to tell whether that is sufficient. -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de Am Badedeich 7 Telefon: +49(0)160/4415681 http://www.bjoernsworld.de 25899 Dagebll PGP Pub. KeyID: 0xA4357E78 http://www.websitedev.de/ From ietf@adambarth.com Mon May 31 10:48:41 2010 Return-Path: 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 34F1F28C0EB for ; Mon, 31 May 2010 10:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.016 X-Spam-Level: X-Spam-Status: No, score=0.016 tagged_above=-999 required=5 tests=[AWL=-0.421, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622] 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 r5vm5wlpnzGO for ; Mon, 31 May 2010 10:48:40 -0700 (PDT) Received: from mail-yw0-f182.google.com (mail-yw0-f182.google.com [209.85.211.182]) by core3.amsl.com (Postfix) with ESMTP id BAE403A6A73 for ; Mon, 31 May 2010 10:48:39 -0700 (PDT) Received: by ywh12 with SMTP id 12so3618546ywh.19 for ; Mon, 31 May 2010 10:48:23 -0700 (PDT) Received: by 10.231.193.93 with SMTP id dt29mr6222582ibb.71.1275328103529; Mon, 31 May 2010 10:48:23 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id f1sm27254934ibg.3.2010.05.31.10.48.22 (version=SSLv3 cipher=RC4-MD5); Mon, 31 May 2010 10:48:22 -0700 (PDT) Received: by iwn42 with SMTP id 42so594367iwn.31 for ; Mon, 31 May 2010 10:48:22 -0700 (PDT) Received: by 10.231.195.143 with SMTP id ec15mr6180770ibb.90.1275328100446; Mon, 31 May 2010 10:48:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.147.66 with HTTP; Mon, 31 May 2010 10:48:00 -0700 (PDT) In-Reply-To: References: <9c8006lme07degqokchpkk0jq5vkt1njdu@hive.bjoern.hoehrmann.de> From: Adam Barth Date: Mon, 31 May 2010 10:48:00 -0700 Message-ID: To: Bjoern Hoehrmann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: http-state@ietf.org Subject: Re: [http-state] Comments on draft-ietf-httpstate-cookie-08.txt (4.1.2.2 - 5.2.6) X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 17:48:41 -0000 On Mon, May 31, 2010 at 10:34 AM, Bjoern Hoehrmann wrot= e: > * Adam Barth wrote: >>>>I don't understand this comment. =A0It's a warning that some existing >>>>user agents behave incorrect w.r.t. the description that section. >>>>That behavior is erroneous: it is in error. >>> >>> A remedy would be to state in the note what the correct behavior is, >>> rather than simply say it is wrong. Obviously the developers of the >>> misbehaving user agents did not think it wrong. >> >>On the contrary, even the developers of the misbehaving user agents >>agree that the behavior is wrong, at least according to their public >>statements on the matter. > > By your own account there have been several developers who have made the > same mistake; could you explain how the specification would become worse > if it briefly mentioned why the mistake actually is a mistake, and what > would have been correct instead? I'm not sure it was a mistake when they made it. They just made a different choice than other folks in the absence of a specification. In any case, you're just asking for a footnote to a footnote. It doesn't seem important. >>I've changed the structure of this sentence to be more parallel to >>reflect the parallelism in the situation. =A0I've also demoted the >>mention of Section 5 to a parenthetical. >> >>[[ >> =A0 =A0 =A0 =A0 =A0The user agent sends stored cookies to the origin = server in the >> =A0 =A0 =A0 =A0 =A0Cookie header. If the server conforms to the requirem= ents in > =A0 =A0 =A0 =A0 =A0target=3D"sane-set-cookie" /> (and the user agent con= forms to the >> =A0 =A0 =A0 =A0 =A0requirements in the ), the user >> =A0 =A0 =A0 =A0 =A0agent will send a Cookie header that conforms to the = following >> =A0 =A0 =A0 =A0 =A0grammar: >>]] > > What you really seem to be trying to say is that user agents may send > bad Cookie headers if and only if the Set-Cookie header they got also > did not conform to the specification. That would be important to say, > but that a user agent that conforms to the specification will behave in > a conforming manner when dealing with conforming input is not important. What is a "bad" Cookie header? The document defines no such thing. The text means exactly what it says. If the two antecedents are true, then the consequent follows. Nothing more. Nothing less. That statement neither imposes nor relaxes any normative requirements on user agents, which you can detect by the lack of 2119 keywords. >>> There are two occurrences in the draft of `found-day-of-month`, the >>> first is "If the found-day-of-month flag is not set and ..."; the other >>> is in "Abort these steps and fail to parse if ... at least one of the >>> found-day-of-month, found-month, found-year, or found-time flags is not >>> set"; >> >>Ah, I understand your confusion. =A0You missed the third occurrence of >>the term in which the flag is actually set. =A0:) > > I see. Please use &nbhy; (U+2011) instead of the hyphen, xml2rfc will > then not wrap identifiers around, that way you can actually locate them. > Alternatively you could quote them or use the underscore instead. Ok, now you're nit picking which characters I'm using in the names of opaque identifiers. This is ridiculous. >>>>> The surprising requirements in this section need to be accompanied by >>>>> some rationale, for example, accepting 1601 as year but not 1600 is >>>>> surprising and so is the 68/69 boundary. >>>> >>>>The reason is just that's how the protocol works. =A0It's odd, but >>>>that's how it works. >>> >>> I think it is unlikely that surprising requirements will be widely im- >>> plemented unless the reasoning behind them is explained. >> >>That requirement is already widely implemented, so we have nothing to fea= r here. > > Well, the draft requires the 19XXs to start with 1969, Gecko/20100529 > and Opera 10.51 use 1970, Internet Explorer 6 uses 1980. The draft re- > quires to ignore the Expires attribute if the year is below 1601, and > Opera 10.51 rather treats all years before 1900 as 2036 (on my system > anway). That is not my understanding of "widely implemented". Do you have test cases that demonstrate these claims? If so, I'd be happy to add them to the test suite. >>>>> There needs to be a discussion, I am not sure this is the right place= , >>>>> on the handling of permissable HTTP "hosts" (non-DNS names, IP-Litera= ls >>>>> and IPv4 addresses, for instance); some questions are, is it intentio= nal >>>>> that the Domain attribute disallows setting the attribute to a IPv4 >>>>> address, would a leading '.' in the attribute still be stripped, if s= uch >>>>> host specifications are disallowed, must all cookies coming from them= be >>>>> rejected? With a Set-Cookie from 127.0.0.1 with no Domain attribute, = is >>>>> it incorrect to imply Domain=3D127.0.0.1? (I don't care, the specific= ation >>>>> however needs to discuss those questions). >>>> >>>>Can you provide a test case that illustrates behavior that you think >>>>is not defined? >>> >>> I believe I did. >> >>I should be more clear. =A0In this case, I'm asking for a sequence of >>octets exchanged by the server and the user agent that causes the >>protocol to arrive in a situation that you believe is not defined. >>You have not provided any such sequence of octets and so I cannot use >>them to test the protocol definition. > > Well, to pick an example, "Set-Cookie from 127.0.0.1 with no Domain > attribute" should be entirely sufficient to make a test case if there > is something to test. Thanks. I'll test this case. > Similarily, you should be able to answer, "is it > intentional that the Domain attribute disallows setting the attribute to > a IPv4 address" (in the so-called well-behaved profile, if I need to add > that) without observing implementation behavior. Yes. Doing so is meaningless at best and harmful at worse. Setting the Domain attribute to an IPv4 address would make the cookie available to all "subdomains" of that IP address, which is a concept that doesn't make sense. Supplying no Domain attribute, however, is perfectly sensible as it means the user agent should return the cookie to that IP address alone. > I do not see how a hex dump of IP packets would really help here. I'm just asking that you be precise. The more precise we are in our discussions, the less likely we are to misunderstand each other. For example, now that I know you're worried about Set-Cookie headers received by the user agent from IPv4 addresses without a Domain attribute, I can do something concrete with your feedback. >>>>> The draft needs to explain how to handle a Set-Cookie header in a rep= ly >>>>> to an `OPTIONS *` request. Right now it seems `uri-path` would be und= e- >>>>> fined in that case, but the draft does not say what the consequence i= s. >>>>> There should be an explicit mention of the case, not just adjusted al= go- >>>>> rithms. > >>I've changed the text to say explicitly that uri-path is empty if the >>path portion of the request-uri does not exist. =A0In that case, the >>default-path will be computed as "/", which is correct. > > I would need to know your reasoning behind not mentioning `OPTIONS *` > explicitly to tell whether that is sufficient. OPTIONS is but one of many cases in which this situation can occur. Rather than trying to enumerate every possible case, I've just written the requirements to handle the general case. Adam