Subject: [http-state] AD review of draft-ietf-httpstate-cookie

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 18 Oct 2010 15:56:56 -0600

Given the advanced state of draft-ietf-httpstate-cookie, I expect to
soon receive a publication request from the WG chair so that we can move
it forward. Because there is an I-D cutoff next Monday, I am sending my
"AD review" now in case Adam has time to address these comments before then.

I'll raise the more significant issues on this list, and send editorial
nits directly to the author.

1. The Introduction mentions RFC 2109 and RFC 2965, but does not
recommend what to do with them once we publish what we hope is a
complete and correct definition of cookies. After consultation with
other members of the IESG, I suggest that we ask the RFC Editor to (a)
change the status of RFC 2109 to Historic, (b) change the status of RFC
2965 to Historic, and (c) obsolete RFC 2965.

Thus I suggest that we add the following text to the end of the
Introduction:

###

   Therefore, with relation to previous IETF specifications of the HTTP
   state management mechanism, this document requests the following
   actions:

   1. Change the status of RFC 2109 to Historic (it has already been
      obsoleted by RFC 2965).

   2. Change the status of RFC 2965 to Historic.

   3. Indicate that RFC 2965 is obsoleted by this document.

###

2. In Section 4.1.1, we state:

   To maximize compatibility with user agents, servers that wish to
   store non-ASCII data in a cookie-value SHOULD encode that data using
   a printable ASCII encoding.

Merely talking about "a printable ASCII encoding" without referencing
any specifications or recommending a particular encoding might not help
to maximize interoperability. Can we make a more specific recommendation
here?

3. The document talks about "legacy user agents" but the force of the
adjective "legacy" is unclear. At times, the behaviors ascribed to
legacy user agents appear to be easily found in current and widely
deployed user agents. Can we safely drop the term "legacy" (or replace
it with "existing")?

4. In Section 4.1.2.3 we mention "public suffixes" but don't define the
term. I think a forward reference to Section 5.3 might be appropriate here.

5. In step 5 of Section 5.1.1, the cutoff for year-value is 1601. This
seems somewhat counterintuitive. Perhaps a few words of explanation
might be helpful?

6. In Section 5.1.2, we state:

   1.  Convert the host name to a sequence of NR-LDH labels (see Section
       2.3.2.2 of [RFC5890]) and/or A-labels according to the
       appropriate IDNA specification [RFC5891] or [RFC3490] (see
       Section 6.3 of this specification)

Do we really mean "and/or"? That is, is it acceptable to mix NR-LDH
labels and A-labels -- specifically, NR-LDH labels per RFC 5890 and
A-labels per RFC 3490? I think we might need to word this more carefully.

7. In Section 5.2, we state:

   When a user agent receives a Set-Cookie header field in an HTTP
   response, the user agent MUST parse the field-value of the Set-Cookie
   header field as a set-cookie-string (defined below).

What if cookie processing is disabled? In that case, the MUST would not
apply. I think we need a hypothetical imperative here ("If a user agent
that does not have cookies disabled receives...", not a categorical
imperative.

8. In Section 5.3, steps 5 and 6 can override step 4, and step 6 can
override step 5; yet the earlier steps say things like "let the
domain-attribute be..." even though that assignment might be discarded.
Do we need to word this more carefully?

9. In Section 5.3, step 6 says:

           If the canonicalized request-host does not domain-match the
           domain-attribute, ignore the cookie entirely and abort these
           steps.

           Set the cookie's host-only-flag to false.

           Set the cookie's domain to the domain-attribute.

Given that cookie processing is aborted per the first paragraph, why do
we go on to instruct the user agent about further steps to be completed?

10. In Section 5.3, we state:

   The user agent MUST evict all expired cookies from the cookie store
   if, at any time, an expired cookie exists in the cookie store.

That seems to border on an implementation detail (does the user agent
need to continually check to see if there are any expired cookies?).
More surprising is that in Section 5.4 we don't say something like this:

   The user agent MUST NOT include in the cookie-list any cookie that
   is expired.

11. In Section 6.3, we reference Unicode TR 46; it might also be
appropriate to reference RFC 5895. (I need to think a bit more about the
internationalization issues here, and perhaps ping a few folks with
greater i18n knowledge to provide feedback.)

As mentioned, I'll contact Adam separately about some smaller issues.

Thanks!

Peter

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

---

From: Adam Barth <[email-masked]>
Date: Wed, 20 Oct 2010 22:41:34 -0700

>   3. Indicate that RFC 2965 is obsoleted by this document.

Done (with wording tweaked).

> to maximize interoperability. Can we make a more specific recommendation

Done.  I suggested Base64.

> deployed user agents. Can we safely drop the term "legacy" (or replace

Done.

> term. I think a forward reference to Section 5.3 might be appropriate here.

Done.

> seems somewhat counterintuitive. Perhaps a few words of explanation

I'm not sure there is much of a good explanation here.  I suspect the
original motivation was that such old dates are extremely unlikely to
be correct and so we fail to parse the date, which is less destructive
than, for example, deleting the cookie.

> A-labels per RFC 3490? I think we might need to word this more carefully.

Done.  I made it clear that the UA can't mix the two.

> that does not have cookies disabled receives...", not a categorical

The user agent is given the option of ignoring the contents of the
Set-Cookie header later in the process (which is observationally
equivalent to ignoring it at the beginning).  I've added some text to
the beginning of the process to make it clear that the user agent can
bail out at the beginning.

> Do we need to word this more carefully?

We can change to an SSA presentation, but it seems easier to just
mutate the domain-attribute variable.  The interaction between these
different components is slightly subtle to capture.  I'm inclined to
leave the presentation as-is.

> we go on to instruct the user agent about further steps to be completed?

Those are for the case when the if-clause evaluates to false.  I've
made that clearer by explicitly adding an "Otherwise" label.

>   The user agent MUST NOT include in the cookie-list any cookie that

It's just a model of the storage.  I expect most implementations to
implement that requirement lazily (only evicting expired cookies when
they touch them).  The model is simpler this way because I don't have
to preface every read from the cookie store with a conditional about
expired cookies.

> greater i18n knowledge to provide feedback.)

Ok.  Let me know when you've sorted out what you'd like me to reference here.

> As mentioned, I'll contact Adam separately about some smaller issues.

These are also done now.

Thanks,
Adam

---

From: Dan Winship <[email-masked]>
Date: Thu, 21 Oct 2010 08:41:02 -0400

> Done.  I suggested Base64.

It said that originally, but that contradicts the earlier rule that
"Servers SHOULD NOT send Set-Cookie headers that fail to conform to the
following grammar: ... cookie-value = token". ("token" is much much more
conservative than any existing client actually needs anyway...)

-- Dan

---

From: Julian Reschke <[email-masked]>
Date: Thu, 21 Oct 2010 14:59:42 +0200

> conservative than any existing client actually needs anyway...)

Requiring a specific encoding here doesn't make sense; it's data only 
the server setting the cookie cares about, so there's no interop issue.

That being said: are we getting a new draft to read before the cut-off?

Best regards, Julian

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 21 Oct 2010 11:09:34 -0600

> the server setting the cookie cares about, so there's no interop issue.

Julian, you are right. But then the text shouldn't say "To maximize
compatibility with user agents..." (ISTM).

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 21 Oct 2010 11:13:11 -0600

Thanks! Looking forward to the revised I-D so that we can issue the IETF
Last Call once Jeff has finished the proto writeup.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 21 Oct 2010 19:59:30 +0200

> compatibility with user agents..." (ISTM).

Yes, that's misleading.

Maybe: "For compatibility with user agents which indeed restrict cookie 
values to ...."?

Best regards, Julian

---

From: Adam Barth <[email-masked]>
Date: Thu, 21 Oct 2010 11:18:17 -0700

> conservative than any existing client actually needs anyway...)

That's a good point.  Unfortunately, Base 32 is out b/c it uses = as a
pad.  I've changed it to base 16, which should fit inside token.

On Thu, Oct 21, 2010 at 5:59 AM, Julian Reschke <[email-masked]> wrote:
> Requiring a specific encoding here doesn't make sense; it's data only the
> server setting the cookie cares about, so there's no interop issue.

Indeed.  It's not a requirement.  It's just an example of an encoding
you could use.

> That being said: are we getting a new draft to read before the cut-off?

Yep.  I'm just holding off in case folks had feedback, which turned
out to be a good idea.  ;)

> Maybe: "For compatibility with user agents which indeed restrict cookie

Well, following this advice is helpful for maximizing compatibility
with all user agents, regardless of whether they indeed restrict
cookies values to token (at least now that the advice is fixed).

          <t>To maximize compatibility with user agents, servers that wish to
          store arbitrary data in a cookie-value SHOULD encode that data, for
          example, using Base 16 <xref target="RFC3548" />.</t>

Adam