Subject: [http-state] editorial nits: -httpstate-cookie-12

From: =JeffH <[email-masked]>
Date: Fri, 17 Sep 2010 17:48:32 -0700

1. extraneous ">" char..

 >  domain-value      = <subdomain>
 >                        ; defined in [RFC1034], Section 3.5, as
 >                        ; enhanced by [RFC1123], Section 2.1>

s/2.1>/2.1/

2. string == sequence of octets

 >> 5.1.2. Canonicalized domain string
 >>
 >>   A canonicalized domain string is a domain string converted to a series
 >>   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), label separators are normalized
 >>   to the U+002E (".") code point, and the labels are converted to lower
 >> case.
 >
 > This looks pretty good, but this algorithm outputs a sequence of
 > labels.  It's more convenient editorially if the algorithm outputs a
 > sequence of octets.  I've used your approach, but changed the output
 > format.

..and thus say in -12..

5.1.2. Canonicalized host names

    A canonicalized domain name is the string generated by the following
    algorithm:

..though, we don't explicitly say anywhere in the spec that "string" is always 
explicitly another name for a "sequence of octets" (altho we do say that 
specifically about the cookie-string).

I suggest that we put something like this in the Terminology section (perhaps 
before the present final para in that sect)..

    The term string means a sequence of octets.

3. host name vs. domain name

we're using "host name" and "domain name" interchangeably -- perhaps we should 
use just "host name" ?

4. s/agents MUST implement/agent MUST implement/

(sec 6.3)

HTH,

=JeffH

---

From: Adam Barth <[email-masked]>
Date: Fri, 24 Sep 2010 18:17:14 -0700

>>                        ; enhanced by [RFC1123], Section 2.1>

Done.

> ..though, we don't explicitly say anywhere in the spec that "string" is
> always explicitly another name for a "sequence of octets" (altho we do say
> that specifically about the cookie-string).
>
> I suggest that we put something like this in the Terminology section
> (perhaps before the present final para in that sect)..
>
>

Done.

> we're using "host name" and "domain name" interchangeably -- perhaps we
> should use just "host name" ?

I went through and looked at each occurrence of the string "domain" in
the document.  I changed a handful of these to "host" as seemed
appropriate.  Unfortunately, we can't change them all because cookies
have an attribute named "Domain".  I've left the ones that are
derivatives of that protocol element (e.g., domain-attribute).

> 4. s/agents MUST implement/agent MUST implement/

Done.

Adam

---

From: Julian Reschke <[email-masked]>
Date: Sat, 25 Sep 2010 09:30:54 +0200

>  > sequence of octets. I've used your approach, but changed the output

The spec now (-13) says:

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

and has a normative reference to RFC 3490.

I believe this is intentional (right?), but it is a normative reference 
to an obsoleted spec, and thus will draw attention. I recommend stating 
in the references why this WG believes it's ok to have that reference.

(Sorry, this is just a statement on how references are treated, I really 
have no clue what's the *right* thing to do with respect to this).

(Also a nit: the two Section references could use a consistent format, 
and the sentence should end with a ".").

Best regards, Julian

---

From: Adam Barth <[email-masked]>
Date: Sat, 25 Sep 2010 00:51:25 -0700

On Sat, Sep 25, 2010 at 12:30 AM, Julian Reschke <[email-masked]> wrote:
>>  >> 5.1.2. Canonicalized domain string
>>  >>
>>  >> A canonicalized domain string is a domain string converted to a series
>>  >> 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), label separators are
>> normalized
>>  >> to the U+002E (".") code point, and the labels are converted to lower
>>  >> case.
>>  >
>>  > This looks pretty good, but this algorithm outputs a sequence of
>>  > labels. It's more convenient editorially if the algorithm outputs a
>>  > sequence of octets. I've used your approach, but changed the output
>>  > format.
>>
>> ..and thus say in -12..
>
> The spec now (-13) says:
>
> "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
> I believe this is intentional (right?),

Yes.

> but it is a normative reference to
> an obsoleted spec, and thus will draw attention. I recommend stating in the
> references why this WG believes it's ok to have that reference.

This is explained in Section 6.3.

> have no clue what's the *right* thing to do with respect to this).

The right thing to do is for the IDNA folks not to publish
unimplementable specs, but that ship has sailed apparently.

Adam

---

From: Julian Reschke <[email-masked]>
Date: Sat, 25 Sep 2010 10:01:34 +0200

On 25.09.2010 09:51, Adam Barth wrote:
> ...
> ...

I recommend adding a link from the reference back to Section 6.3, 
pointing out that this explains the presence of the reference.

Best regards, Julian