Subject: [http-state] I-D Action:draft-ietf-httpstate-cookie-11.txt

From: [email-masked]
Date: Sun, 5 Sep 2010 18:45:02 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the HTTP State Management Mechanism Working Group of the IETF.

	Title           : HTTP State Management Mechanism
	Author(s)       : A. Barth
	Filename        : draft-ietf-httpstate-cookie-11.txt
	Pages           : 40
	Date            : 2010-09-05

This document defines the HTTP Cookie and Set-Cookie header fields.
These header fields can be used by HTTP servers to store state
(called cookies) at HTTP user agents, letting the servers maintain a
stateful session over the mostly stateless HTTP protocol.  Although
cookies have many historical infelicities that degrade their security
and privacy, the Cookie and Set-Cookie header fields are widely used
on the Internet.Editorial Note (To be removed by RFC Editor)

If you have suggestions for improving this document, please send
email to <mailto:[email-masked]>.  Suggestions with test cases
are especially appreciated.  Further Working Group information is
available from <https://tools.ietf.org/wg/httpstate/>.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-httpstate-cookie-11.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 Sep 2010 09:28:21 +0200

Hi,

two editorial nits with respect to references:

-- snip --
$ saxon -l draft-ietf-httpstate-cookie-11.xml rfc2629.xslt > 
draftietf-httpstate-cookie-11.html
WARNING: unused reference 'RFC1034' (at line 1447)
-- snip --

(This apparently has been around since -09, sorry for not reporting earlier)

-- snip --
$ saxon draft-ietf-httpstate-cookie-11.xml check-references.xslt 
intended-status=proposed

Normative References:
RFC1034: [STANDARD] (-> STD0013) ok
RFC2119: [BEST CURRENT PRACTICE] (-> BCP0014) ok
RFC2616: [DRAFT STANDARD] ok
RFC3490: [PROPOSED STANDARD] obsoleted by RFC5890 RFC5891
RFC3629: [STANDARD] (-> STD0063) ok
RFC4790: [PROPOSED STANDARD] ok
RFC5234: [STANDARD] (-> STD0068) ok
RFC5246: [PROPOSED STANDARD] ok

Informative References:
Kri2001: not checked
Netscape: not checked
RFC2109: [PROPOSED STANDARD] obsoleted by RFC2965
RFC2818: [INFORMATIONAL] ok
RFC2965: [PROPOSED STANDARD] ok
RFC3864: [BEST CURRENT PRACTICE] (-> BCP0090) ok
-- snip --

The RFC 3490 reference probably needs to be updated.

Best regards, Julian

---

From: Adam Barth <[email-masked]>
Date: Mon, 6 Sep 2010 00:41:02 -0700

> RFC3490: [PROPOSED STANDARD] obsoleted by RFC5890 RFC5891

It looks like these were just published in August 2010.  It's unclear
to me which is the correct document to reference.  Do you know what
changed between these documents?  We'd need to check which of these
documents better reflects reality.

> RFC2109: [PROPOSED STANDARD] obsoleted by RFC2965

This reference is quite intentional.  :)

Adam

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 Sep 2010 10:17:41 +0200

On 06.09.2010 09:41, Adam Barth wrote:
> On Mon, Sep 6, 2010 at 12:28 AM, Julian Reschke<[email-masked]>  wrote:

I feared you would ask.

This is why I'm always recommending to be specific in references; it 
helps a lot when they need to be updated.

<http://tools.ietf.org/html/rfc5890#section-2.3.2.1> seems to be 
relevant, but I'm not sure.

> This reference is quite intentional.  :)

I know, that's why I didn't mention it explicitly. The poor tool can't 
know, however.

Best regards, Julian

---

From: "Anne van Kesteren" <[email-masked]>
Date: Mon, 06 Sep 2010 10:20:17 +0200

> relevant, but I'm not sure.

See also: http://unicode.org/reports/tr46/ Last I checked it was quite the  
mess.

-- 
Anne van Kesteren
http://annevankesteren.nl/

---

From: Adam Barth <[email-masked]>
Date: Mon, 6 Sep 2010 01:44:08 -0700

On Mon, Sep 6, 2010 at 1:20 AM, Anne van Kesteren <[email-masked]> wrote:
>> This is why I'm always recommending to be specific in references; it helps
>> a lot when they need to be updated.
>>
>> <http://tools.ietf.org/html/rfc5890#section-2.3.2.1> seems to be relevant,
>> but I'm not sure.
>

Ugg...  I was afraid of something like that.

I suspect that user agents will decide what to do w.r.t. IDNA
relatively independently of which document we happen to reference.  If
it would make the IETF happy to reference the newer document, I think
we can do that without the world coming to an end.

Adam

---

From: "Anne van Kesteren" <[email-masked]>
Date: Mon, 06 Sep 2010 10:47:48 +0200

On Mon, 06 Sep 2010 10:44:08 +0200, Adam Barth <[email-masked]> wrote:
>> See also: http://unicode.org/reports/tr46/ Last I checked it was quite  
>> the mess.
>

True. It's not like IETF endorsing Cookie2 made a difference. *runs*

---

From: Adam Barth <[email-masked]>
Date: Mon, 6 Sep 2010 02:30:36 -0700

Hey now.  Be nice.

Adam