Subject: [http-state] Comments on draft-ietf-httpstate-cookie-08.txt (1 - 4.1.2.)

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 26 May 2010 19:22:58 +0200

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 = <as defined in ...> ; 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,
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Adam Barth <[email-masked]>
Date: Wed, 26 May 2010 13:45:22 -0700

Thanks for your comments.  I've accepted the majority of your
recommendations.  Details inline.

Adam

>   name/value pairs in the Cookie header.

Done.

> "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

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.

>  ALPHA = <as defined in ...> ; 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.

> 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.

> Also, the reference to http_URL is probably incorrect if "https" URLs

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.

> different to translate, another that it is unclear who "we" really is.

Fixed.

> 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.

> rule is inconsistent with RFC 2616.

This is pointed out in HTTPbis.  At worst, this inconsistency will
exist for only a short time.

> there because the text is discussing the following example).

I fixed this by adding some introductory text instead of white space.

> 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.

> 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.  :)

> be a note of the grammar differences, if any, here, or maybe earler in

We already say that:

        <t>This specification uses the Augmented Backus-Naur Form (ABNF)
        notation of <xref target="RFC5234"/>.</t>

> The grammar makes reference to "abs_path", but does not define what it

I've just made this <any CHAR except CTLs or ";">.

> include two attributes with the same name."

I've added a definition.

> and there should be a rationale for this somewhat surprising rule.

Done.

> "two or more" or possibly better "Servers SHOULD include at most one".

Done.

> 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:

          <t>The semantics of the cookie-value are not defined by this
          document.</t>

> race condition could also use an answer to "so what".

This seems like an editorial issue.

> 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: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 26 May 2010 23:52:30 +0200

>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).

>were of their creators, but (however we got here) we find ourselves in

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.

>RFCs that use this pattern.

RFC 5536, RFC 5537, RFC 5538. The draft itself does this for other
rules, like for `token`.

>someone will chime in with the magic incantation we're supposed to use

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).

>that are the same or different from what it sent before or not sending

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".

>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.

>        notation of <xref target="RFC5234"/>.</t>

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.

>          <t>The semantics of the cookie-value are not defined by this

That is better.

>This seems like an editorial issue.

Yes, I agree it is an editorial issue.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Daniel Stenberg <[email-masked]>
Date: Thu, 27 May 2010 00:05:55 +0200 (CEST)

On Wed, 26 May 2010, Bjoern Hoehrmann wrote:

> 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: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 27 May 2010 00:13:42 +0200

>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
              <http://www.netscape.com/newsref/std/cookie_spec.html>,
              undated.

Should not really matter either way though, so long as it's not just
'the so-called "Netscape cookie specification"'.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Adam Barth <[email-masked]>
Date: Wed, 26 May 2010 16:03:03 -0700

> not attempt to do that, which I do not think is a fact.

I've removed the "by contrast."

> RFC 5536, RFC 5537, RFC 5538. The draft itself does this for other

Ok.  I'll add this to my queue.

> supposed to be the "request-host" but I would have to debug the code to

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).

> 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.

Fixed.

> 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: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 27 May 2010 02:08:35 +0200

>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".

>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.

>languages.  The semantics of those terms are defined in their

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.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Adam Barth <[email-masked]>
Date: Wed, 26 May 2010 17:30:17 -0700

On Wed, May 26, 2010 at 5:08 PM, Bjoern Hoehrmann <[email-masked]> wrote:
> 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

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.

> Cookie2 and Set-Cookie2 headers, those are unaffected by this draft".

Those statements would significantly less accurate than what's in the
current draft.

> 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.

> The first occurrence

That's like say f(5) doesn't explain how that's different than 5.

> 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 user
      agent another Set-Cookie response header or it MAY send no Set-Cookie
      header at all.
]]

> 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 <[email-masked]>
Date: Thu, 27 May 2010 09:49:30 +0200

On 26.05.2010 22:45, Adam Barth wrote:
> ...
> On Wed, May 26, 2010 at 10:22 AM, Bjoern Hoehrmann<[email-masked]>  wrote:

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.

> were of their creators, but (however we got here) we find ourselves in

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, 
<http://arxiv.org/abs/cs.SE/0105018>.

to give some more context.

>>   ALPHA =<as defined in ...>  ; A-Z / a-z
>>   ...
>

Adam is right; not expanding the RFC 5234 base rules is quite common.

> someone will chime in with the magic incantation we're supposed to use

If you're willing to wait for httpbis, "Effective Request URI" might be 
the right thing 
(<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.html#effective.request.uri>).

> that are the same or different from what it sent before or not sending

I also have to point out that this use of MAY is irritating; just state 
that this is optional behavior.

> 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." 
-- 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.html#rfc.section.3.2.p.7>

So the Cookie spec has an additional requirement compared both to RFC 
2616 and HTTPbis, and that should be pointed out (and explained!).

> I've just made this<any CHAR except CTLs or ";">.

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.

> 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: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 27 May 2010 16:33:52 +0200

>Those documents do not reflect reality.  This document is intended to

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.

>Precisely.  For example "f(x) = x + 1" doesn't proceed to say what "x"

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".

>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.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Adam Barth <[email-masked]>
Date: Sun, 30 May 2010 18:58:23 -0700

Done.

> RFC 5536, RFC 5537, RFC 5538. The draft itself does this for other

See below.

On Thu, May 27, 2010 at 12:49 AM, Julian Reschke <[email-masked]> wrote:
> 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.

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.

> That statement is kind of confusing to people who do not already know the
> history.
>
> [Kri2001]       Kristol, D., “HTTP Cookies: Standards, Privacy, and
> Politics”, ACM Transactions on Internet Technology Vol. 1, #2, November
> 2001, <http://arxiv.org/abs/cs.SE/0105018>.
>

Done.

> Adam is right; not expanding the RFC 5234 base rules is quite common.

Ok.  I've left these as is.

> If you're willing to wait for httpbis, "Effective Request URI" might be the
> right thing

I'm glad this is getting fixed.  I don't particularly want to take a
dependency on HTTPbis, as discussed before.

> I also have to point out that this use of MAY is irritating; just state that
> 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.

> "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!).

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.
]]

> 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.

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.

> somewhere (not as new ID!), so people doing the LC review can check whether
> something has already been addressed?

Sure.  As always, you can find the up-to-the-minute version of the draft here:

http://github.com/abarth/http-state/blob/master/drafts/cookie.xml

> 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.

> the domain of the function; but without specifying the domain you do

That's a matter for philosophers of mathematics, but certainly not all
of them would agree with you.  :)

> 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.

> 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.

> "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.

> to tell what difficulty you are having.

The very first sentence of the "Syntax Notation" section says:

[[

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: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 31 May 2010 15:54:02 +0200

>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 <[email-masked]> 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.

>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.

>emphasize that the name of the formal parameter is irrelevant.

I will revisit this later.

>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]

>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.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Adam Barth <[email-masked]>
Date: Mon, 31 May 2010 09:25:44 -0700

> 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?

> review, perhaps others have some suggestions.

Ok.  I stand by the current text as factually accurate.

> `request-host`.

Here's the definition of request-host:

[[
        <t>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.</t>
]]

Is that definition improper?  What would a superior definition be?

> If you start from a resource identifier, this will most

We need to start with an HTTP request.

> right rules for imported symbols.

I've add the following text near the use of 1123-date:

[[
sane-cookie-date  = <rfc1123-date, as defined in RFC 2616>
                    ; Note that RFC 2616 uses a different grammatical notation
                    ; than this document (which uses ABNF from RFC5234).
]]

Hopefully that addresses your concerns.

Adam