Subject: [http-state] wrt 5.1.2. Domains and domain-match

From: =JeffH <[email-masked]>
Date: Thu, 09 Sep 2010 13:53:01 -0700

Hey Adam,

in this section..

5.1.2. Domains and domain-match

    A canonicalized string is the string converted to ASCII according to
    the IDNA specification [RFC3490] and converted to lower case.

    A string domain-matches a given domain string if at least one of the
    following conditions hold:

    o  The domain string and the string are identical.

    o  All of the following conditions hold:

       *  The domain string is a suffix of the string.

       *  The last character of the string that is not included in the
          domain string is a U+002E (".") character.

       *  The string is a host name (i.e., not an IP address).

..is the 1st para beginning "A canonicalized string" intended as a distinct 
algorithm separate from the algorithm beginning with the 2nd para?

i.e. when we say in step 5 of "5.3. Storage Model"..

            If the domain-attribute is identical to the canonicalized
            request-host:

.."canonicalized request-host" means "process request-host according to the 1st 
para of section 5.1.2" ?

It looks like the "canonicalized (string)" algorithm is invoked five times, 
while the "domain-match (string, givenDomainString)" alg is invoked only twice.

thanks,

=JeffH

---

From: Adam Barth <[email-masked]>
Date: Sat, 11 Sep 2010 14:54:45 -0700

> algorithm separate from the algorithm beginning with the 2nd para?

Yes.  Several folks have brought up questions about this sentence.  In
W3C specs, these things are much clearer because we can use fonts,
colors, and italics to make it clear what's a definition.  I'm happy
to make this clearer using whatever prevailing style the IETF uses to
define terms.  So far, no one has volunteered a clearer typography.

> .."canonicalized request-host" means "process request-host according to the
> 1st para of section 5.1.2" ?
>

That seems quite possible.

Adam

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 12 Sep 2010 00:22:39 +0200

>define terms.  So far, no one has volunteered a clearer typography.

In my experience, when hyphens are used in identifiers, and you wrap
lines at hyphens, then they become difficult to recognize for `grep`-
like tools and for people who are used to languages with different
hyphenation rules than those for the english language. Considering
your reaction to my suggestion for clearer typography there, perhaps
you could point out where you seek such suggestions, and where you'd
find them ridiculous?
-- 
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: Sat, 11 Sep 2010 16:03:21 -0700

> you could point out where you seek such suggestions, and where you'd

Oh, the problem that folks seem to be having is that the don't
recognize that text as a definition (perhaps because it's too simple a
definition).  In past drafts, we've used various typographical
conventions to indicate that we're defining an otherwise meaningless
term at this point.  For example, we've used "a /foobar/ is a cat with
a hat" or "a *foobar* is green eggs an ham."  However, various folks
in the working group thought the extra characters were distracting.
In non-plaintext, I'd just italicize the text (or hyperlink back from
all uses to the definition), but those options aren't really available
to us in this medium.

Adam