Subject: [weirds] Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 2 Dec 2013 19:27:45 -0800

On Mon, Dec 2, 2013 at 6:40 AM, Hollenbeck, Scott
<[email-masked]>wrote:

> > Having read this section and section 6, I really think that 3.2.3
> > should either say that it only supports ASCII, or else that we should
> > say something more about the on-the-wire behaviour particularly for
> > entity name searches.  I think just hoping that both ends will do the
> > right thing is an excellent way to reduce interoperability.  Here is
> > what I think should happen.
> >
> >      An RDAP client wishing to perform an entity search by name MUST
> >      convert the search term into Unicode in UTF-8 encoding using
> >      whatever local rules are in effect.  It SHOULD map fullwidth and
> >      halfwidth characters to their decomposition equivalents.  It MAY
> >      perform any local case mapping deemed necessary.  It SHOULD
> >      normalize the string using NFC.  I think this is all I'd want to
> >      put in a precis profile for clients; it'd be based on
> >      FreeFormClass.  It'd be cleaner to put this all in a profile.
> >      Failure to map fullwidth and halfwidth characters are more likely
> >      to lead to false negatives in searches.  Failure to perform NFC
> >      on the string increases the probability that the server will
> >      perform NFC and match on something different than what was sent.
> >
> >      An RDAP server receiving a search term string MUST treat the
> >      input as Unicode in UTF-8 encoding.  If the search term is not
> >      valid UTF-8, the server MAY immediately stop processing and
> >      return an error.  The server SHOULD perform NFC on the string;
> >      failure to do this is likely to lead to variability in seaches
> >      depending on the oringinating system.  The server can then
> >      process the query.
>
> I'm still not sure of how we want to approach this. There are a small
> number of people suggesting simple binary comparison, and a smaller number
> suggesting something akin to the above. I may ask our chairs to consider a
> consensus call for one approach or the other so we can put this to bed.
>

I'd like to avoid a formal consensus call without more feedback on the
record first, or at least a (i.e., this) request for some.  Could people
please weigh in on preferred paths here and some reason(s) for your choices?

I'll Cc PSA and John Klensin directly, again at the risk of being
constructive.  :-)

-MSK

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 3 Dec 2013 11:58:10 +0000

From: Murray S. Kucherawy [mailto:[email-masked]]
Sent: Monday, December 02, 2013 10:28 PM
To: Hollenbeck, Scott
Cc: Andrew Sullivan; [email-masked]; John C Klensin; Peter Saint-Andre
Subject: Opinions please (was Re: [weirds] comments on draft-ietf-weirds-rdap-query-08)

>      depending on the oringinating system.  The server can then
I'm still not sure of how we want to approach this. There are a small number of people suggesting simple binary comparison, and a smaller number suggesting something akin to the above. I may ask our chairs to consider a consensus call for one approach or the other so we can put this to bed.

I'd like to avoid a formal consensus call without more feedback on the record first, or at least a (i.e., this) request for some.  Could people please weigh in on preferred paths here and some reason(s) for your choices?
I'll Cc PSA and John Klensin directly, again at the risk of being constructive.  :-)

[SAH] While I value John's and Peter's opinions, what we really need are more _implementer_ opinions. Thanks for asking, Murray.

Scott

---

From: Ernie Dainow <[email-masked]>
Date: Wed, 04 Dec 2013 15:26:06 -0500

On 12/3/2013 6:58 AM, Hollenbeck, Scott wrote:
>
> *From:*Murray S. Kucherawy [mailto:[email-masked]]
> *Sent:* Monday, December 02, 2013 10:28 PM
> *To:* Hollenbeck, Scott
> *Cc:* Andrew Sullivan; [email-masked]; John C Klensin; Peter Saint-Andre
> *Subject:* Opinions please (was Re: [weirds] comments on 
> draft-ietf-weirds-rdap-query-08)
>
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     I'm still not sure of how we want to approach this. There are a
>     small number of people suggesting simple binary comparison, and a
>     smaller number suggesting something akin to the above. I may ask
>     our chairs to consider a consensus call for one approach or the
>     other so we can put this to bed.
>
> record first, or at least a (i.e., this) request for some.  Could 
> people please weigh in on preferred paths here and some reason(s) for 
> your choices?
>
> [SAH] While I value John's and Peter's opinions, what we really need 
> are more _/implementer/_ opinions. Thanks for asking, Murray.
>
> Scott
>
>
I implemented Unicode search on the server side. I agree with Andrew's 
proposal, except for a few comments posted previously. Without a 
specification with sufficient precision such as this, there is no 
reliability in any search or lookup results. As per an earlier example, 
if you lookup a domain and get no result, you don't really know if the 
domain is not registered or if the lookup failed because of 
normalization differences between the lookup/search name and the data 
being searched.

I have a few questions/comments about one other issue.
       The client SHOULD map fullwidth and halfwidth characters to their 
decomposition equivalents.

Isn't what is needed here is to map fullwidth characters to their 
Compatibility equivalents, not Decomposition?

For example, fullwidth A, which is Unicode u'\uff21', Hex UTF-8 
'\xef\xbc\xa1' is normalized as:
    NFC  A u'\uff21'  '\xef\xbc\xa1'
    NFKC A u'A'  'A'
    NFD  A u'\uff21'  '\xef\xbc\xa1'
    NFKD A u'A'  'A'

The Compatibility forms NFKC, NFKD map the fullwidth to halfwidth. So 
can we say the client should apply NFKC or NFKD to normalize fullwidth 
characters to Compatibility form.

I'm not sure all clients know enough about their locale to determine 
that they should perform fullwidth mapping. This can be generalized and 
simplified for the client by shifting it to the server. The server rule 
would be to first normalize the search/lookup using NFKC or NFKD and 
then normalize the result to NFC before doing the lookup against data 
that is in NFC.

-Ernie

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 04 Dec 2013 13:58:48 -0700

On 12/4/13 1:26 PM, Ernie Dainow wrote:
>> [SAH] While I value John’s and Peter’s opinions, what we really need

RFC 5985 uses the term "decomposition mapping", for instance:

       Fullwidth and halfwidth characters (those defined with
       Decomposition Types <wide> and <narrow>) are mapped to their
       decomposition mappings as shown in the Unicode character
       database.

>    NFC  Ａ u'\uff21'  '\xef\xbc\xa1'
>    NFKC A u'A'  'A'
>    NFD  Ａ u'\uff21'  '\xef\xbc\xa1'
>    NFKD A u'A'  'A'
> 
> The Compatibility forms NFKC, NFKD map the fullwidth to halfwidth.

I think they map fullwidth (i.e., <wide>) and halfwidth (i.e., <narrow>)
to their decomposition mappings. For instance, in the Unicode Character
Database we find:

3000;IDEOGRAPHIC SPACE;Zs;0;WS;<wide> 0020;;;;N;;;;;

and

FF61;HALFWIDTH IDEOGRAPHIC FULL STOP;Po;0;ON;<narrow>
3002;;;;N;HALFWIDTH IDEOGRAPHIC PERIOD;;;;

> So

Maybe.

> that they should perform fullwidth mapping. 

I'm not sure if fullwidth and halfwidth mapping is locale-specific.

> This can be generalized and
> simplified for the client by shifting it to the server. 

I think that's a good plan, especially if we think that some clients
won't be very advanced about these matters anyway.

> The server rule

To repeat Pete Resnick's question from Vancouver, are we more concerned
about false positives or false negatives? That will help us determine
what we think clients and servers need to do.

Peter

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

---

From: "John Levine" <[email-masked]>
Date: 4 Dec 2013 21:58:38 -0000

>what we think clients and servers need to do.

I would think false negatives.  Given the extreme vagueness about
exactly what a search does, it's most likely just to be displayed to
people who will pick some of the answers and do something with them.
It's certainly easier to skip an uninteresting answer you do see than
to select an interesting answer you don't.

-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 5 Dec 2013 14:50:23 +0000

> -----Original Message-----
> From: weirds [mailto:[email-masked]] On Behalf Of John Levine
> Sent: Wednesday, December 04, 2013 4:59 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [weirds] Opinions please (was Re: comments on draft-ietf-
> weirds-rdap-query-08)
> 

I agree. I can skip over returned results that don't look interesting to me. I can't do anything if I don't see them at all.

Scott

---

From: Ernie Dainow <[email-masked]>
Date: Thu, 5 Dec 2013 10:29:59 -0500

If the server is required to do normalization as proposed, then there
should be no false positives and no false negatives. That's kind of the
point of normalization. This is certainly true for a name lookup (or else
IDNA has a major fault), I am pretty sure it is also true for a search of
the form XXX*. Does anyone have a counter case of a false positive or a
false negative for either lookup or search?

-Ernie

On Thu, Dec 5, 2013 at 9:50 AM, Hollenbeck, Scott
<[email-masked]>wrote:

> I agree. I can skip over returned results that don't look interesting to
> me. I can't do anything if I don't see them at all.
>
> Scott
> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds
>

---

From: Andy Newton <[email-masked]>
Date: Mon, 9 Dec 2013 12:57:04 +0000

From:  Ernie Dainow <[email-masked]>
Date:  Thursday, December 5, 2013 10:29 AM
To:  Scott Hollenbeck <[email-masked]>
Cc:  John Levine <[email-masked]>, "[email-masked]" <[email-masked]>,
"[email-masked]" <[email-masked]>
Subject:  Re: [weirds] Opinions please (was Re: comments
on	draft-ietf-weirds-rdap-query-08)

>IDNA has a major fault), I am pretty
> sure it is also true for a search of the form XXX*. Does anyone have a
>counter case of a false positive or a false negative for either lookup or
>search?
>
>-Ernie
>
>
>

At least for me I find this thread confusing because it seems we are
conflating four use cases:

1. Domain lookups
2. Domain searches
3. Entity lookups
4. Entity searches

It is my hope we can throw out #3. That would be a lookup on an identifier
such as a handle or email address and not a Jcard FN. Is there any
disagreement?

The text above regarding IDNA seems to apply to #1 and #2 but not #4. #4
would require profiles from Precis. Is that correct?

As for #1, are there cases where IDNA normalization rules do not strictly
apply with regards to domain name variants. For instance, if a registry
had rules that specified Goethe.example and Göthe.example are variants
wouldn't the mandatory normative language to do normalization and then do
a binary comparison forbid a server from returning one or the other as a
variant of the domain being queried?

-andy

---

From: Andy Newton <[email-masked]>
Date: Mon, 9 Dec 2013 13:07:16 +0000

From:  Ernie Dainow <[email-masked]>
Date:  Wednesday, December 4, 2013 3:26 PM
To:  Scott Hollenbeck <[email-masked]>, "Murray S. Kucherawy"
<[email-masked]>
Cc:  John C Klensin <[email-masked]>, "[email-masked]"
<[email-masked]>, Peter Saint-Andre <[email-masked]>
Subject:  Re: [weirds] Opinions please (was Re: comments
on	draft-ietf-weirds-rdap-query-08)

>I'm not sure all clients know enough about their locale to determine that
>they should perform fullwidth mapping. This can be generalized and
>would be to first normalize the search/lookup using NFKC or NFKD and then
>normalize the result to NFC before doing the lookup against data that is
>in NFC.

I'm supportive of shifting the burden to the server for clients that do
not or cannot know to do normalization.

If there are to be cases where the client is more informed, we could add
an optional HTTP query parameter indicating the type of preprocessing
performed by the client. Such as ?qspp=NFKC (where qspp means 'query
string preprocessing').

-andy

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 9 Dec 2013 10:09:49 -0500

On Mon, Dec 09, 2013 at 12:57:04PM +0000, Andy Newton wrote:
> apply with regards to domain name variants. 

Either they do, or the term "normalization" is not being used in the
strict sense that Unicode uses it.  I think it's the latter, because of this:

> For instance, if a registry

Well, "Göthe.example" is not legal under IDNA, so the registry can
have all the policy it wants.  That name is never an IDNA name: in
IDNA2003 it's mapped away and in IDNA2008 it's DISALLOWED.  This is
because of normalization.  Specifically, in IDNA2008 it's because
Göthe is not stable under NFKC and case folding (göthe is).  But I
don't think the variant issue has anything to do with it.  More
generally, the variant stuff is unrelated to normalization, as near as
I can tell.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ernie Dainow <[email-masked]>
Date: Mon, 09 Dec 2013 13:33:05 -0500

> would require profiles from Precis. Is that correct?
#3,4 I don't think there is any restriction on a handle, it could be 
Unicode.
#1,2 There is nothing that is specific to IDNA. The special rules for 
IDNA (such as allowing only certain code points) don't come into play. 
These are important if you need to establish validity of a domain name 
before allowing it to be registered. If you are just doing lookup or 
search against a data base of registered names, then it is just Unicode 
strings being compared.

For Unicode lookup and search to return consistent results, 
normalization is required. I don't see any differences between 1,2,3,4 
in this regard. Unless there is a very specific reason or case, we 
should try to specify one general rule for all Unicode lookup and search.
> variant of the domain being queried?
Yes, the rule would prevent returning such variant names as a search 
result. But the language incorported from John K suggests that the way 
to handle variants, or any other links between database records, would 
be to indicate it in the search results. If a search for abl* returns 
"able" and "ab1e" is a variant, it could be returned in the search 
result as a variant element, which is already defined in json-response-06.

  "domainSearchResults" :
  [
    {
      "handle" : "1-XXXX",
      "ldhName" : "able.example.com",
      "variants": [
           {
              "relation": [
                 "restricted registration"
              ],
              "variantNames": [
                 {
                    "unicodeName": "ab1e.example.com"
                    "ldhName": "ab1e.example.com",
                 },
                 ...

Perhaps we should define the variant relationship, or generalize it to 
any database linked records in search results, for those providers who 
are able to return such information.

-Ernie

---

From: Simon Perreault <[email-masked]>
Date: Mon, 09 Dec 2013 15:54:40 -0500

> performed by the client. Such as ?qspp=NFKC (where qspp means 'query

A robust server would never trust the client and would normalize the 
query, or at least check that it is normalized, no matter what the 
client says.

So assuming servers always normalize, I don't see the point in mandating 
client-side normalization.

Simon

---

From: Carlos Martinez-Cagnazzo <[email-masked]>
Date: Mon, 9 Dec 2013 19:20:12 -0200

I'm not fully familiar with what normalization involves. However, as a
design principle I would never, ever trust the client with anything.

On Mon, Dec 9, 2013 at 6:54 PM, Simon Perreault <[email-masked]
> wrote:

> query, or at least check that it is normalized, no matter what the client
> says.
>

-- 
--
=========================
Carlos M. Martinez-Cagnazzo
h <http://cagnazzo.name>ttp://cagnazzo.me
=========================

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 9 Dec 2013 19:12:13 -0500

Le 2013-12-09 à 16:20, Carlos Martinez-Cagnazzo <[email-masked]> a écrit :

> I'm not fully familiar with what normalization involves.

- converting a string of codepoint(s) into another string of codepoints, based on some rules. 
- simple example: converting e ' into é.

> However, as a design principle I would never, ever trust the client with anything.

that is what I was trying to say at the mike during vancouver meeting. Given that we could expect clients (especially the javascript ones done by typical web programmer) to not do any normalization nor any string preparation before sending to the server, then we shall at least say something about that fact to server implementors in the spec. We could also point them to ways to mitigate that problem. The best would be to specify the server side behavior, but there was resistance on doing so. I'm more than happy if we specify a default server side behavior, because it will provide better results and better interoperability.

Marc.

> 
> 
> On Mon, Dec 9, 2013 at 6:54 PM, Simon Perreault <[email-masked]> wrote:
> A robust server would never trust the client and would normalize the query, or at least check that it is normalized, no matter what the client says.
> 
> So assuming servers always normalize, I don't see the point in mandating client-side normalization.
> 
> Simon
> 
> http://cagnazzo.me

---

From: Andy Newton <[email-masked]>
Date: Tue, 10 Dec 2013 14:34:24 +0000

>#3,4 I don't think there is any restriction on a handle, it could be

Ok. Agreed. If a registry issues Unicode handles, they get what they ask
for I suppose. :)

>                    "ldhName": "ab1e.example.com",

For searches, I'm in agreement. But for lookups I am questioning the
normative language of requiring the server to normalize and then do a
strict binary comparison.

Given the example above and the rules of binary comparison, a lookup of
"ab1e" would disallow the server from returning "able" even if just to
note it as a domain variant of "ab1e". Are we ok with that?

>are able to return such information.

I don't understand this. By declaring the variant under "variantNames",
the relationship is established. We could also suggest servers return a
canonical rel in the "links" array. Is anything more than that needed?

-andy

---

From: Andy Newton <[email-masked]>
Date: Tue, 10 Dec 2013 14:38:40 +0000

I agree with what has been stated here. However, deep down in one of these threads it was mentioned that a client MIGHT normalize based on specific locale rules of which the server would have no knowledge. In such cases, does the server need to know about it?

-andy

From: Marc Blanchet <[email-masked]<mailto:[email-masked]>>
Date: Monday, December 9, 2013 7:12 PM
To: Carlos Martinez <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08))

Le 2013-12-09 à 16:20, Carlos Martinez-Cagnazzo <[email-masked]<mailto:[email-masked]>> a écrit :

Marc.

On Mon, Dec 9, 2013 at 6:54 PM, Simon Perreault <[email-masked]<mailto:[email-masked]>> wrote:
Le 09/12/2013 08:07, Andy Newton a écrit :

Simon

_______________________________________________
weirds mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/weirds

--
--
=========================
Carlos M. Martinez-Cagnazzo
h<http://cagnazzo.name/>ttp://cagnazzo.me<http://cagnazzo.me/>
=========================
_______________________________________________
weirds mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/weirds

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 10 Dec 2013 10:05:23 -0500

On Mon, Dec 09, 2013 at 07:12:13PM -0500, Marc Blanchet wrote:
> 
> meeting. Given that we could expect clients (especially the
> javascript ones done by typical web programmer) to not do any
> normalization nor any string preparation before sending to the
> server, then we shall at least say something about that fact to
> server implementors in the spec.

There are a couple of issues here.

First, IDNA2008 does say that the client side MUST reject labels not
in NFC.  Now, this is partly because it's the client side doing the
U-label/A-label conversion (because the DNS server talks only
A-labels).  But really, to maximize the liklihood of something
working, the client ought to normalize, and ought to send only UTF-8
in NFC.

So my suggestion is that the client SHOULD send UTF-8 in NFC, with an
explicit acknowledgement that the client may not be able to do this
reliably; that the server in any case MUST convert to a single
coded character set and normalization for the purposes of matching;
and that server matching using UTF-8 in NFC is RECOMMENDED for maximal
predictability and interoperation.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 10 Dec 2013 10:06:13 -0500

> Ok. Agreed. If a registry issues Unicode handles, they get what they ask

Surely we could put text to that effect in the document?

A

-- 
Andrew Sullivan
[email-masked]

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 10 Dec 2013 10:11:42 -0500

> predictability and interoperation.

I agree.

marc.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 10 Dec 2013 15:25:49 +0000

> From: weirds [mailto:[email-masked]] On Behalf Of Marc
> Blanchet
> Sent: Tuesday, December 10, 2013 10:12 AM
> To: Andrew Sullivan
> Cc: <[email-masked]>
> Subject: Re: [weirds] using a preprocessing query parameter (was Re:
> Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08))
> 
> 

Andrew, could you put this in the form of text that could be incorporated into the document?

Scott

---

From: Ernie Dainow <[email-masked]>
Date: Tue, 10 Dec 2013 12:16:15 -0500

...
> strict binary comparison.
There is no fundamental difference between lookup and search. They are 
both a binary comparison between a query string and target data, where 
query and target are Unicode, represented as UTF-8. The only difference 
between the two is length. In lookup you compare the whole strings, in 
search (of the form XXX*) you just compare the first N characters.

To ensure reliable results for both lookup and search, you need to 
normalize the query string and the target data to the same normalization 
form.

This generalization applies to any Unicode search/lookup -- names, 
nameservers, entities or thingamabobs.

> canonical rel in the "links" array. Is anything more than that needed?

Search results as currently defined return only handle and name. If we 
are to have a standard way to return variants or any other database 
linked records, those elements need to be specified. A more general way 
to do this than using the "variants" element above would be to say 
something like,

Each name returned in a search result can optionally contain information 
about associated data (database linked records), for example

"domainSearchResults": [
     {
         "ldhName" : "ablest.example.com",
         "handle" : "45986w45"
     },
     {
         "ldhName" : "able.example.com",
         "handle" : "34598w28",
         "associatedData": [
             {
                 "type": "variant",
                 "names": [
                     "ab1e.example.com",
                     ...
                 ]
             }
         ]
     },
     ...
]

-Ernie

---

From: "John Levine" <[email-masked]>
Date: 10 Dec 2013 19:30:04 -0000

>strict binary comparison.

I'm with you here, this is overspecified.  Servers will in fact do
whatever they do, and if their internal design turns oe into ö they
will do that no matter what we say.

I'd stick with clients SHOULD send UTF-8 NFC, and servers SHOULD
normalize non-NFC if they can, and leave it at that.

---

From: "John Levine" <[email-masked]>
Date: 10 Dec 2013 19:35:07 -0000

>I agree with what has been stated here. However, deep down in one of these threads it was mentioned that a client MIGHT
>normalize based on specific locale rules of which the server would have no knowledge. In such cases, does the server need to
>know about it?

Clients MIGHT do a lot of things.  Absent specific examples which we
understand well enough to describe, and volunteers who say they will
write server and client code that implements it in an interoperable
way, I'd prefer not to guess about extensions and edge cases.

>From what I've seen, if clients send UTF-8, in NFC form where
possible, that will maximize their chances of interoperating with most
servers.

R's,
John

---

From: Andy Newton <[email-masked]>
Date: Tue, 10 Dec 2013 21:07:17 +0000

>nameservers, entities or thingamabobs.

Fair enough. This applies to searches and lookups. However, I'm focusing
not on the need for normalization but the second step specified in one of
the earlier threads -- strict comparison of the normalized strings. This,
I think, will disallow servers from returning domain variants as a direct
result.

>to do this than using the "variants" element above would be to say

The current draft does not limit searches to only returning handles and
names. That's just an elided example.

>         "ldhName" : "able.example.com",

I think the current draft supports what JCK was talking about. I don't
think there is any need to modify the current data model.

-andy

---

From: Andy Newton <[email-masked]>
Date: Tue, 10 Dec 2013 21:08:33 +0000

On 12/10/13 2:35 PM, "John Levine" <[email-masked]> wrote:

>>I agree with what has been stated here. However, deep down in one of
>>these threads it was mentioned that a client MIGHT
>>normalize based on specific locale rules of which the server would have
>>no knowledge. In such cases, does the server need to
>>know about it?
>

This works for me. Just wanted to make sure we are all in agreement.

-andy

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 10 Dec 2013 21:21:33 +0000

> From: weirds [mailto:[email-masked]] On Behalf Of Andy Newton
> Sent: Tuesday, December 10, 2013 4:09 PM
> To: John Levine; [email-masked]

Me, too, and it's consistent with sentiment expressed in an earlier note from Andrew in which I asked for some suggested text.

Scott

---

From: Ernie Dainow <[email-masked]>
Date: Tue, 10 Dec 2013 16:43:00 -0500

If servers are just going to do what they do, what is the point in trying
to develop a standard. Imagine the havoc if the DNS standards were this
loose and DNS lookups worked sometimes but not at other times.

The Internet is much better off with a standard that strives for
interoperability. If a provider does not do normalization as per spec, then
they should document that (along with any other limitations) on their Help
page. That way, a user can be forewarned that some queries against certain
servers may not succeed. A spec that only specifies SHOULD will lead to
inconsistent results with no indication of when or why.

-Ernie

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 10 Dec 2013 16:47:34 -0500

Le 2013-12-10 à 16:43, Ernie Dainow <[email-masked]> a écrit :

> If servers are just going to do what they do, what is the point in trying to develop a standard. Imagine the havoc if the DNS standards were this loose and DNS lookups worked sometimes but not at other times.
> 
> The Internet is much better off with a standard that strives for interoperability. If a provider does not do normalization as per spec, then they should document that (along with any other limitations) on their Help page. That way, a user can be forewarned that some queries against certain servers may not succeed. A spec that only specifies SHOULD will lead to inconsistent results with no indication of when or why.

- agree.
- we shall be strive for maximum interoperability and best likely results of lookup/search for users, 
- while knowing that a) implementations in the field may not fully conform  b) i18n searching is difficult and the solution won't be perfect.

Marc.

---

From: "John R Levine" <[email-masked]>
Date: 10 Dec 2013 16:57:11 -0500

> loose and DNS lookups worked sometimes but not at other times.

We have a large installed base of registry software.  Search is a marginal 
feature, and it is utterly implausible that anyone will do anything for 
search that involves much more than a lookup that does whatever their 
database does now.

I'm all in favor of making things as interoperable as we can, but I'm also 
in favor of not making promises we can't keep.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 11 Dec 2013 12:51:40 +0000

> From: weirds [mailto:[email-masked]] On Behalf Of Andrew
> Sullivan
> Sent: Tuesday, December 10, 2013 10:05 AM
> To: [email-masked]

[snip]

> predictability and interoperation.

I'm going to try to speed this along by suggesting text. Here's what rdap-query-08 currently says:

"Servers SHOULD thus accept any search pattern that is otherwise properly encoded.  If the pattern consists entirely of ASCII characters, servers SHOULD use case-insensitive prefix matching against ASCII labels to determine partial matches.  If the text in the pattern is or can be converted to a U-label, servers SHOULD use prefix matching against U-labels to determine partial matches."

Suggested new text:

"Clients SHOULD send UTF-8 queries encoded using Normalization Form C (NFC, [Unicode-UAX15]); note that clients might not be able to do this reliably. Servers MUST convert to a single coded character set and normalization for the purposes of matching. Server matching using UTF-8 in NFC is RECOMMENDED to maximize predictability and interoperability. If the query pattern consists entirely of ASCII characters, servers SHOULD use case-insensitive prefix matching against ASCII labels to determine partial matches."

Does this work? Please suggest specific changes if not.

Scott

---

From: Andy Newton <[email-masked]>
Date: Wed, 11 Dec 2013 15:47:23 +0000

On 12/11/13 7:51 AM, "Hollenbeck, Scott" <[email-masked]> wrote:

>>
>Suggested new text:
>
>"Clients SHOULD send UTF-8 queries encoded using Normalization Form C
>(NFC, [Unicode-UAX15]); note that clients might not be able to do this
>reliably. Servers MUST convert to a single coded character set and
>normalization for the purposes of matching. Server matching using UTF-8
>in NFC is RECOMMENDED to maximize predictability and interoperability. If
>the query pattern consists entirely of ASCII characters, servers SHOULD
>use case-insensitive prefix matching against ASCII labels to determine
>partial matches."
>

In the very last sentence I would replace "ASCII labels" with "ASCII
characters", but this works for me.

-andy

---

From: "John Levine" <[email-masked]>
Date: 11 Dec 2013 16:27:17 -0000

>characters", but this works for me.

I prefer ASCII labels, contrasted to A-labels or U-labels, but I don't
feel very strongly.  Otherwise fine.

---

From: Andy Newton <[email-masked]>
Date: Wed, 11 Dec 2013 17:21:57 +0000

>feel very strongly.  Otherwise fine.

I don't feel strongly either. My reasoning for ASCII characters is to be
consistent (the term is used in the first part of the sentence) and
because "labels" seems specific to DNS whereas characters covers the
ground for other uses.

-andy

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 11 Dec 2013 17:27:26 +0000

> Sent: Wednesday, December 11, 2013 12:22 PM
> >>>in NFC is RECOMMENDED to maximize predictability and
> interoperability.
> >>>If

I agree, "characters" is better.

Scott

---

From: Ernie Dainow <[email-masked]>
Date: Wed, 11 Dec 2013 16:58:32 -0500

> Does this work? Please suggest specific changes if not.
Andrew S. also submitted an earlier comment that was more explicit and 
covered a few more things. I have generalized it to cover all queries 
(it was submitted in the context of entity searches) and merged it with 
the above.

An RDAP client submitting a query containing one or more strings of 
characters that are not US-ASCII MUST convert such strings into Unicode 
in UTF-8 encoding. It MAY perform any local case mapping deemed 
necessary. It SHOULD normalize the strings using Normalization Form C 
(NFC, [Unicode-UAX15]); note that clients might not be able to do this 
reliably.

An RDAP server receiving a query containing one or more strings of 
characters MUST treat each string as Unicode in UTF-8 encoding. If any 
string is not valid UTF-8, the server MAY immediately stop processing 
the query and return an error.  Servers SHOULD map fullwidth and 
halfwidth characters to their decomposition equivalents. Servers MUST 
convert strings to the same coded character set of the target data that 
is to be looked up or searched and each string MUST be normalized using 
the same normalization that was used on the target data. Normalization 
Form C (NFC, [Unicode-UAX15]) is RECOMMENDED to be consistent with IDNA 
[RFC5891] and to maximize predictability and interoperability.

For domain names or nameserver lookups or searches, servers SHOULD use 
case-insensitive matching on US-ASCII characters.

-Ernie

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 12 Dec 2013 14:45:05 +0000

> From: Ernie Dainow [mailto:[email-masked]]
> Sent: Wednesday, December 11, 2013 4:59 PM
> To: Hollenbeck, Scott; Andrew Sullivan; [email-masked]
> > "Servers SHOULD thus accept any search pattern that is otherwise
> properly encoded.  If the pattern consists entirely of ASCII
> characters, servers SHOULD use case-insensitive prefix matching against
> ASCII labels to determine partial matches.  If the text in the pattern
> is or can be converted to a U-label, servers SHOULD use prefix matching
> against U-labels to determine partial matches."
> >
> > Suggested new text:
> >
> in NFC is RECOMMENDED to maximize predictability and interoperability.
> If the query pattern consists entirely of ASCII characters, servers
> SHOULD use case-insensitive prefix matching against ASCII labels to
> determine partial matches."
> >

I can live with this version, too, though it's much more prescriptive. One question, though: what exactly does "a query containing one or more strings of characters" look like?

Scott

---

From: Ernie Dainow <[email-masked]>
Date: Thu, 12 Dec 2013 10:16:03 -0500

> I can live with this version, too, though it's much more prescriptive. One question, though: what exactly does "a query containing one or more strings of characters" look like?
In the case of search the query is
     domains?name=<domain search pattern>
I was trying to separate out the query "string" in angle brackets from 
the whole query as defined. In the case of a future boolean search, 
there would be more than one string. If this is confusing and too 
general for our purposes now, then this can be simplified by simply 
dropping the phrase "one or more strings of characters" and just use 
"query".

-Ernie

---

From: Andy Newton <[email-masked]>
Date: Thu, 12 Dec 2013 15:47:51 +0000

On 12/11/13 4:58 PM, "Ernie Dainow" <[email-masked]> wrote:

>in UTF-8 encoding.

The MUST here is inconsistent with the direction of these threads
regarding what a client may and may not do. I believe the MUST should be a
SHOULD.

> It MAY perform any local case mapping deemed

Given that this last sentence is a SHOULD and not a MUST, I fail to see
why any of the normalizations are MUST instead of SHOULD. These behaviors
are recommended (I.e SHOULD) because there is a potential for
non-interoperability if the recommendation is not followed but
non-interoperability is not a guarantee. On this, I don't care strongly
though.

-andy

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 12 Dec 2013 13:56:27 -0500

> Does this work? Please suggest specific changes if not.

Sorry I didn't get to this first (it's all-hands week at Dyn).  I
think that looks reasonable, yes.  Thanks.

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 12 Dec 2013 13:58:31 -0500

> feel very strongly.  Otherwise fine.

If the goal is to draw the distinction with A-labels and U-labels,
IDNA2008 has the (awkward) term "NR-LDH label".  The precision might
be helpful, because of course an A-label is always an all-ASCII label,
but string matching in it is not what we want I presume.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 12 Dec 2013 14:02:09 -0500

On Wed, Dec 11, 2013 at 04:58:32PM -0500, Ernie Dainow wrote:
> characters MUST treat each string as Unicode in UTF-8 encoding.

I originally thought that, but of course the client can use the
Content-Type to set the character set explicitly, I guess, no?  

> processing the query and return an error.  Servers SHOULD map
> fullwidth and halfwidth characters to their decomposition
> equivalents. Servers MUST convert strings to the same coded
> character set of the target data that is to be looked up or searched
> and each string MUST be normalized using the same normalization that
> was used on the target data. Normalization Form C (NFC,
> [Unicode-UAX15]) is RECOMMENDED to be consistent with IDNA [RFC5891]
> and to maximize predictability and interoperability.

This stuff was intended basically to make a precis profile in mini.  I
do think that's a better idea, but I got the impression that the WG
didn't agree.  These additions are my preference, however.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 12 Dec 2013 19:20:50 +0000

> From: Andy Newton [mailto:[email-masked]]
> Sent: Thursday, December 12, 2013 10:48 AM
> To: Ernie Dainow; Hollenbeck, Scott; Andrew Sullivan; [email-masked]

I care strongly about coming to agreement on text ;), so how do we all feel about Andy's suggestion to use SHOULD instead of MUST? That is:

An RDAP client submitting a query string containing non-ASCII characters SHOULD convert such strings into Unicode in UTF-8 encoding. It MAY perform any local case mapping deemed necessary. It SHOULD normalize the strings using Normalization Form C (NFC, [Unicode-UAX15]); note that clients might not be able to do this reliably.

An RDAP server SHOULD treat each query string as Unicode in UTF-8 encoding. If a string is not valid UTF-8, the server MAY immediately stop processing the query and return an error.  Servers SHOULD map fullwidth and halfwidth characters to their decomposition equivalents. Servers SHOULD convert strings to the same coded character set of the target data that is to be looked up or searched and each string SHOULD be normalized using the same normalization that was used on the target data. Normalization Form C (NFC, [Unicode-UAX15]) is RECOMMENDED to be consistent with IDNA [RFC5891] and to maximize predictability and interoperability. If the query pattern consists entirely of ASCII characters, servers SHOULD use case-insensitive matching against ASCII characters to determine matches.

I'm going to have to see which error is appropriate to return in this context, but is this getting closer?

Scott

---

From: Ernie Dainow <[email-masked]>
Date: Fri, 13 Dec 2013 11:07:32 -0500

> Content-Type to set the character set explicitly, I guess, no?
Content-Type is only for the body. All RDAP queries defined so far 
contain the query string in the URI and no body. Does a client have any 
options of how to encode the URI?

-Ernie

---

From: Ernie Dainow <[email-masked]>
Date: Fri, 13 Dec 2013 11:25:17 -0500

On Thu, Dec 12, 2013 at 2:20 PM, Hollenbeck, Scott <[email-masked]

>
> I care strongly about coming to agreement on text ;), so how do we all
> feel about Andy's suggestion to use SHOULD instead of MUST? That is:
>
> An RDAP client submitting a query string containing non-ASCII characters
> SHOULD convert such strings into Unicode in UTF-8 encoding. It MAY perform
> any local case mapping deemed necessary. It SHOULD normalize the strings
> using Normalization Form C (NFC, [Unicode-UAX15]); note that clients might
> not be able to do this reliably.
>
> An RDAP server SHOULD treat each query string as Unicode in UTF-8
> encoding. If a string is not valid UTF-8, the server MAY immediately stop
> processing the query and return an error.  Servers SHOULD map fullwidth and
> halfwidth characters to their decomposition equivalents. Servers SHOULD
> convert strings to the same coded character set of the target data that is
> to be looked up or searched and each string SHOULD be normalized using the
> same normalization that was used on the target data. Normalization Form C
> (NFC, [Unicode-UAX15]) is RECOMMENDED to be consistent with IDNA [RFC5891]
> and to maximize predictability and interoperability. If the query pattern
> consists entirely of ASCII characters, servers SHOULD use case-insensitive
> matching against ASCII characters to determine matches.
>

In the last sentence, is there a particular reason that ASCII case
insensitive matching is done only when the whole string is ASCII rather
than character by character? This results in a number of inconsistencies:

uuuu.aaa       does not match  uuu.AAA
aaa-uuu.aaa  does not match  AAA-uuu.aaa

(where u is Unicode, a is ASCII character)

-Ernie

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 13 Dec 2013 16:53:23 +0000

From: Ernie Dainow [mailto:[email-masked]]
Sent: Friday, December 13, 2013 11:25 AM
To: Hollenbeck, Scott
Cc: Andy Newton; Andrew Sullivan; [email-masked]
Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08))

On Thu, Dec 12, 2013 at 2:20 PM, Hollenbeck, Scott <[email-masked]<mailto:[email-masked]>> wrote:

Scott

In the last sentence, is there a particular reason that ASCII case insensitive matching is done only when the whole string is ASCII rather than character by character? This results in a number of inconsistencies:

ASCII characters are also UTF-8-encoded Unicode characters. You could just as well re-write those patterns as uuuu.uuu and uuu-uuu.uuu, and then the Unicode processing text applies, right? The point I'm trying to get across is that a query pattern that contains only ASCII characters does not need to be subjected to the normalization processing used for patterns that contain non-ASCII characters. Is this better?

"A query pattern that contains only ASCII characters does not need to be normalized. Case-insensitive character comparison SHOULD be used to determine matches for these patterns."

Please suggest text if I'm still missing your point.

Scott

---

From: Ernie Dainow <[email-masked]>
Date: Fri, 13 Dec 2013 13:13:52 -0500

On 2013-12-13 11:53 AM, Hollenbeck, Scott wrote:
>
> *From:*Ernie Dainow [mailto:[email-masked]]
> *Sent:* Friday, December 13, 2013 11:25 AM
> *To:* Hollenbeck, Scott
> *Cc:* Andy Newton; Andrew Sullivan; [email-masked]
> *Subject:* Re: [weirds] using a preprocessing query parameter (was Re: 
> On Thu, Dec 12, 2013 at 2:20 PM, Hollenbeck, Scott 
> An RDAP client submitting a query string containing non-ASCII 
> characters SHOULD convert such strings into Unicode in UTF-8 encoding. 
> It MAY perform any local case mapping deemed necessary. It SHOULD 
> normalize the strings using Normalization Form C (NFC, 
> [Unicode-UAX15]); note that clients might not be able to do this reliably.
>
> encoding. If a string is not valid UTF-8, the server MAY immediately 
> stop processing the query and return an error.  Servers SHOULD map 
> fullwidth and halfwidth characters to their decomposition equivalents. 
> Servers SHOULD convert strings to the same coded character set of the 
> target data that is to be looked up or searched and each string SHOULD 
> be normalized using the same normalization that was used on the target 
> data. Normalization Form C (NFC, [Unicode-UAX15]) is RECOMMENDED to be 
> consistent with IDNA [RFC5891] and to maximize predictability and 
> interoperability. If the query pattern consists entirely of ASCII 
> characters, servers SHOULD use case-insensitive matching against ASCII 
> characters to determine matches.
>
> insensitive matching is done only when the whole string is ASCII 
> rather than character by character? This results in a number of 
> inconsistencies:
>
> ASCII characters are also UTF-8-encoded Unicode characters. You could 
> just as well re-write those patterns as uuuu.uuu and uuu-uuu.uuu, and 
> then the Unicode processing text applies, right? The point I'm trying 
> to get across is that a query pattern that contains only ASCII 
> characters does not need to be subjected to the normalization 
> processing used for patterns that contain non-ASCII characters. Is 
> this better?
>
> "A query pattern that contains only ASCII characters does not need to 
> be normalized. Case-insensitive character comparison SHOULD be used to 
> determine matches for these patterns."
>

Normalization does not do any case folding, so this results in the 
inconsistencies above. ASCII case insensitive matching should be done on 
all strings, not just those that are entirely ASCII. Excluding handles 
which are case sensitive.

Suggested text to replace last sentence:
For domain name or nameserver queries, servers SHOULD use 
case-insensitive matching on US-ASCII characters.

"US-ASCII" seems to be preferred in standards to "ASCII", 
http://www.iana.org/assignments/character-sets/character-sets.xhtml

-Ernie

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 13 Dec 2013 18:21:01 +0000

From: Ernie Dainow [mailto:[email-masked]]
Sent: Friday, December 13, 2013 1:14 PM
To: Hollenbeck, Scott
Cc: [email-masked]
Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08))

Cc: Andy Newton; Andrew Sullivan; [email-masked]<mailto:[email-masked]>

Scott

Scott

Normalization does not do any case folding, so this results in the inconsistencies above. ASCII case insensitive matching should be done on all strings, not just those that are entirely ASCII. Excluding handles which are case sensitive.

Who/what says handles are case sensitive?

Suggested text to replace last sentence:
For domain name or nameserver queries, servers SHOULD use case-insensitive matching on US-ASCII characters.

Why only domain name and name server queries?

Scott

---

From: Ernie Dainow <[email-masked]>
Date: Fri, 13 Dec 2013 14:47:23 -0500

On 2013-12-13 1:21 PM, Hollenbeck, Scott wrote:
> *Sent:* Friday, December 13, 2013 1:14 PM
> *To:* Hollenbeck, Scott
> *Cc:* [email-masked]
>     <mailto:[email-masked]>
>     *Subject:* Re: [weirds] using a preprocessing query parameter (was
>     Re: Opinions please (was Re: comments on
>     draft-ietf-weirds-rdap-query-08))
>
>     I care strongly about coming to agreement on text ;), so how do we
>     all feel about Andy's suggestion to use SHOULD instead of MUST?
>     That is:
>
>     characters SHOULD convert such strings into Unicode in UTF-8
>     encoding. It MAY perform any local case mapping deemed necessary.
>     It SHOULD normalize the strings using Normalization Form C (NFC,
>     encoding. If a string is not valid UTF-8, the server MAY
>     immediately stop processing the query and return an error.
>      Servers SHOULD map fullwidth and halfwidth characters to their
>     decomposition equivalents. Servers SHOULD convert strings to the
>     same coded character set of the target data that is to be looked
>     up or searched and each string SHOULD be normalized using the same
>     normalization that was used on the target data. Normalization Form
>     C (NFC, [Unicode-UAX15]) is RECOMMENDED to be consistent with IDNA
>     [RFC5891] and to maximize predictability and interoperability. If
>     the query pattern consists entirely of ASCII characters, servers
>     SHOULD use case-insensitive matching against ASCII characters to
>     determine matches.
>
>     I'm going to have to see which error is appropriate to return in
>     this context, but is this getting closer?
>
>     Scott
>
>     ASCII characters are also UTF-8-encoded Unicode characters. You
>     could just as well re-write those patterns as uuuu.uuu and
>     uuu-uuu.uuu, and then the Unicode processing text applies, right?
>     The point I'm trying to get across is that a query pattern that
>     contains only ASCII characters does not need to be subjected to
>     the normalization processing used for patterns that contain
>     non-ASCII characters. Is this better?
>
>     "A query pattern that contains only ASCII characters does not need
>     to be normalized. Case-insensitive character comparison SHOULD be
>     used to determine matches for these patterns."
>
> inconsistencies above. ASCII case insensitive matching should be done 
> on all strings, not just those that are entirely ASCII. Excluding 
> handles which are case sensitive.
>
Right, they may not be. Handle is defined only as "registry-unique 
identifiers" in json-response-06. It would be up to each server to 
determine whether to do case insensitive matching on handles or not.
> Why only domain name and name server queries?
Domain name and nameserver are ASCII case insensitive according to DNS 
standards.

Ernie

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 13 Dec 2013 20:03:56 +0000

From: Ernie Dainow [mailto:[email-masked]]
Sent: Friday, December 13, 2013 2:47 PM
To: Hollenbeck, Scott
Cc: [email-masked]
Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08))

Cc: [email-masked]<mailto:[email-masked]>

Scott

Scott

Who/what says handles are case sensitive?
Right, they may not be. Handle is defined only as "registry-unique identifiers" in json-response-06. It would be up to each server to determine whether to do case insensitive matching on handles or not.

Domain name and nameserver are ASCII case insensitive according to DNS standards.

Please note the word "only" in my question. What about entity handles and entity names? Assuming we go with "up to each server" as described above I can't use "For domain name or nameserver queries" as you suggested, and I really don't want to expand that to add entities because we run the risk of not covering queries that might be added in the future. So let's try again. How about "Case insensitive pattern matching SHOULD be used to compare US-ASCII characters in query patterns" instead of "If the query pattern consists entirely of ASCII characters, servers SHOULD use case-insensitive matching against ASCII characters to determine matches".

FWIW I think a server operator that treats handles as case sensitive and domain names as case insensitive is going to have some confusion issues with users.

Scott

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 13 Dec 2013 15:23:49 -0500

I can't entirely tell which bits of this message are from which
person, because quote markers seem to have been left out; apologies
for any confusion.  In any case,

> (where u is Unicode, a is ASCII character)

Yes.  The problem is that US-ASCII case folding rules are entirely
straightforward in English.  Once you get outside of English in
US-ASCII, everything goes pear-shaped very quickly.

For instance, according to the standard French orthography, the upper
case of é is E.  So if you have a string "ECOLE" and you want to do
case-insensitive searching, you need to look at "ecole" and "école" as
well.  We already decided, I believe, that we don't want to do this. 

(Worse, according to standard Québecois orthography, the upper case of
é is É, which means there aren't even universal rules.)

And that's an easy example.  Think about Turkish i-like characters,
for instance.

So, in my view (and in the view of anyone I've ever met who knows even
a little bit about the sharp, poiny bits of Unicode), handling a
string "case-insensitively" is complicated.  We said we weren't going
to do complicated, so let's just not.

As for doing this character by character, it will be completely
mystifying to anyone that a and A match but for some reason é and E
don't, in the same string.  No actual humans have a theory of the
ASCII range of Unicode vs. the rest of it, so we can't mix this
behaviour in the same string.

> For domain name or nameserver queries, servers SHOULD use case-insensitive matching on US-ASCII characters.

Not this, please.  That would appear to permit matching on écoLE, and
that's just not a U-label.

Best,

A
-- 
Andrew Sullivan
[email-masked]

---

From: Ernie Dainow <[email-masked]>
Date: Fri, 13 Dec 2013 15:40:44 -0500

> that's just not a U-label.

So is Scott's original wording on this safe, we do want to cover case 
insensitivity as in the DNS standard:

Since it is only a SHOULD, if the server treats handles or anything else 
as case sensitive, they are free to do so.

-Ernie

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 13 Dec 2013 16:23:04 -0500

On Fri, Dec 13, 2013 at 03:40:44PM -0500, Ernie Dainow wrote:
> 
> So is Scott's original wording on this safe, we do want to cover
> case insensitivity as in the DNS standard:

If we're trying to match the DNS matching rules, then we should say
that.  In that case, it's not _strings_ we're matching, but labels.
Each label is handled separately.  These cases are perfectly acceptable:

    école.EXAMPLE.com.
    école.EXample.com.

This case is not:

    écOLE.example.com.

So, if we're just trying to cope with DNS names, then we should say
something like this:

    DNS names are treated according to the DNS matching rules as
    described in [RFC1035], section 3.1 for NR-LDH labels; and the
    matching rules as described in [RFC5891], section 5.4 for
    U-labels.  Matching of DNS names proceeds one label at a time,
    because it is possible for a combination of U-labels and NR-LDH
    labels to be found in a single domain or host name.  The
    determination of whether a label is a U-label or an NR-LDH label
    is based on whether the label contains any characters outside of
    the ASCII letters, digits, or hyphen (the so-called LDH rule).

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 13 Dec 2013 23:13:03 +0000

Scott

> On Dec 13, 2013, at 4:23 PM, "Andrew Sullivan" <[email-masked]> wrote:
> 

[snip]

We also have to deal with entity names and handles.

Scott