Subject: [weirds] rdap-query Proposed Changes Discussed Last Week

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 11 Nov 2013 13:04:18 +0000

During last week's working group meeting we talked through some very specific questions concerning search and i18n. I think the feeling in the room was that we could simplify things greatly by changing text in the rdap-query draft to make it clear that search processing requires no more than basic binary character comparison. This has a potential impact on section 4 of rdap-query-07, which currently includes this text:

"Because Unicode characters may be combined with another Unicode character or characters, partial matching requires that a server maintain a list of valid character combinations to be considered a match. When comparing DNS U-labels, servers SHOULD use the code points specified in [RFC5892] to determine partial matches.  When comparing entity names, servers SHOULD use the normalization rules and code points specified by [I-D.ietf-precis-nickname] to determine partial matches."

Marc Blanchet touched on the topic here:

http://www.ietf.org/mail-archive/web/weirds/current/msg03288.html

I'm going to suggest that the paragraph above be replaced with this:

"Servers can expect to receive search patterns from clients that contain character strings encoded in different forms supported by HTTP. It is entirely possible to apply filters and normalization rules to search patterns prior to making character comparisons, but this type of processing is more typically needed to determine the validity of registered strings than to match patterns. Servers SHOULD thus accept any search pattern that is otherwise properly encoded and servers SHOULD use case-insensitive binary comparisons to determine partial matches."

In addition, we have to make changes to our URIs based on the topic described here:

http://www.ietf.org/mail-archive/web/weirds/current/msg03285.html

We'll see how that discussion goes before changing anything.

Finally, we spent some time talking about how searches might uncover implicit relationships between registered objects, such as the relationship between a registered IDN and its variants. I think we agreed that explicit search results should be limited to matches, but RDAP includes the ability to describe relationships and we talked about adding text to address that possibility. John Klensin drafted some text that can be added to the end of section 4:

"Conceptually, a name-record in the database may include a link to an associated name-record which may include a link to another such record and so on. If an implementation is to return more than one name-record in response to a query, information from the records thereby identified is returned.  

Note that this model includes any arrangements for associated names, including those that are linked by policy mechanisms and names bound together for some other purposes.

Note also that returning information that was not explicitly selected by an exact-match lookup, including additional names that match a relatively fuzzy search as well as lists of names that are linked together, may cause privacy issues."

The privacy topic will also need to be addressed in the Security Considerations section.

Scott

---

From: "John Levine" <[email-masked]>
Date: 11 Nov 2013 21:58:46 -0000

There's one bit here that's confusing to me:

> Servers SHOULD thus accept any search pattern that is otherwise
> properly encoded and servers SHOULD use case-insensitive binary
> comparisons to determine partial matches.

I don't understand what this means unless it means that you can only
search for A-labels.

For U-labels, there's no case folding, so I guess it would mean that
you do a case-insensitive prefix match against A-labels, or a plain
prefix match of the Unicode characters against U-labels.

It's also not clear whether foo* is supposed to match against
A-labels, U-labels, or both, and how if at all the client says
which one it means.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 12 Nov 2013 12:13:48 +0000

> -----Original Message-----
> From: John Levine [mailto:[email-masked]]
> Sent: Monday, November 11, 2013 4:59 PM
> To: [email-masked]
> Cc: Hollenbeck, Scott
> Subject: Re: [weirds] rdap-query Proposed Changes Discussed Last Week
> 

I struggled with that text. If you refer back to the note from Marc, I was trying to capture the "be liberal in what you accept" sentiment. I don't see a need for a client to say anything about U-labels or A-labels. They should be able to send a search pattern and the server should attempt to find anything that matches. Can you suggest a rewording that is easier to understand?

Scott

---

From: Simon Perreault <[email-masked]>
Date: Tue, 12 Nov 2013 10:32:42 -0500

> prefix match of the Unicode characters against U-labels.

Would "co*" match "cœur"?

As a user, I would expect it to match.
As an implementer, aaaaaaaaaaaaaaargh...

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: "John Levine" <[email-masked]>
Date: 12 Nov 2013 16:07:34 -0000

>I struggled with that text.

Hmmn.  How about this:

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.

R's,
John

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 12 Nov 2013 22:45:55 +0000

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Simon Perreault
> Sent: Tuesday, November 12, 2013 10:33 AM
> To: [email-masked]

"o" (006F) and "œ" (0153) are distinct, different characters. No match.

Scott

---

From: "John Levine" <[email-masked]>
Date: 13 Nov 2013 00:16:55 -0000

>"o" (006F) and "œ" (0153) are distinct, different characters. No match.

If anyone would like to dive into the Dismal Black Swamp of No Return
that is IDN variant policy, get yourself a full rubber suit and
breathing apparatus, and I'm sure several of us can offer helpful
advice about where to start and give you a fond farewell.

---

From: Simon Perreault <[email-masked]>
Date: Wed, 13 Nov 2013 10:20:58 -0500

> "o" (006F) and "œ" (0153) are distinct, different characters. No match.

Couldn't a registrar decide to add normalized domain names to the 
haystack? That is, in the database that is queried on search, both 
"cœur" and "coeur" would be present and pointing to the same domain. 
Then any search query would match. Exactly like what Google has been 
doing for many years, and that seems to work fine so far.

I'm not trying to find gotchas. I know there are tons of them. I'm 
trying to argue that we need to be liberal when specifying the set of 
matches that servers are allowed to return.

Simon

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 13 Nov 2013 18:09:46 +0000

> On Nov 13, 2013, at 10:21 AM, "Simon Perreault" <[email-masked]> wrote:
> 
> Couldn't a registrar decide to add normalized domain names to the haystack? That is, in the database that is queried on search, both "cœur" and "coeur" would be present and pointing to the same domain. Then any search query would match. Exactly like what Google has been doing for many years, and that seems to work fine so far.
> 
> I'm not trying to find gotchas. I know there are tons of them. I'm trying to argue that we need to be liberal when specifying the set of matches that servers are allowed to return.

If the registry contains both names the situation is a little different. You'll get a match on one pattern or another, and then the link relationship stuff in the text provided by John Klensin comes into play. The server may choose to return info describing the relationship, but it shouldn't be required to do so.

Scott

---

From: "John Levine" <[email-masked]>
Date: 13 Nov 2013 18:24:49 -0000

>"cœur" and "coeur" would be present

We really, really, REALLY don't want to go there.  That is the Dismal
Black Swamp of No Return that is IDN variant policy.

R's,
John

---

From: Simon Perreault <[email-masked]>
Date: Wed, 13 Nov 2013 13:31:57 -0500

Le 2013-11-13 13:24, John Levine a écrit :
>>> "o" (006F) and "�" (0153) are distinct, different characters. No match.
>>
>> "c�ur" and "coeur" would be present
>

I agree! That was only an example to illustrate my point. Concrete text 
proposal would go along the lines of:

"Servers are free to interpret U-label search queries according to local 
policy."

Simon

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 14 Nov 2013 01:45:23 -0800

> matching against U-labels to determine partial matches.
I don't have any particular objection to using MUSTard here, but we do need
to be careful about it.  The IESG these days, when it sees a SHOULD, likes
it to be accompanied by a description or example of the circumstances in
which it would be appropriate (or at least acceptable) to deviate from the
SHOULD.  Can you think of such prose to add here?  If not, then maybe MUST
is better.

-MSK

---

From: John R Levine <[email-masked]>
Date: Thu, 14 Nov 2013 10:15:43 -0500 (EST)

> SHOULD.  Can you think of such prose to add here?  If not, then maybe MUST

What I had in mind is that some TLDs such as .US and .EDU have no IDN 
names, and some of the new ones have no ASCII names, so there's no point 
to looking for names that aren't there.

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

---

From: Ernie Dainow <[email-masked]>
Date: Mon, 18 Nov 2013 14:35:11 -0500

> "Servers can expect to receive search patterns from clients that contain character strings encoded in different forms supported by HTTP. It is entirely possible to apply filters and normalization r…
I agree that there should be no requirements on the client.
But if there are no rules for search on the server, search may produce 
different results.

For example, search for sé* will not match sémaphore in a number of cases.
In NFC or NFKC, é is a single "Combined" character:
Unicode U+00C9
Hex (UTF_8) 0xC3 0xA9
In NFD or NFKD, é is "Decomposed" as e followed by acute accent:
Unicode U+0045 U+00C9
Hex (UTF_8) 0x65 0xCC 0x81
If the Client submits the search string in a "Composed" normalization 
form (NFC or NFKC) and the server data is in "Decomposed" form (NFD or 
NFKD) there is no match on a binary (hex) search, or vice versa.

If the server keeps its data in one normalized form and normalizes the 
search string received from the client to that form, it will return 
consistent results.

However, it is still possible to get different results from different 
servers:
If one server uses a Composed form, NFC or NFKC, a search for se* will 
not match sémaphore.
If another server uses a Decomposed form, NFD or NFKD, a search for se* 
will match sémaphore.

While an argument can be made that the broadest search results produced 
by the latter case are most useful to a client, for consistency with 
IDNA RFC 5890, NFC should be used.
See earlier thread, 
http://www.ietf.org/mail-archive/web/weirds/current/msg03182.html.

So the the spec should say something like
To ensure that consistent search results are returned from any server, 
the server MUST
normalize the search string received from the client to NFC and MUST 
perform the
search against data that is normalized to NFC.

Note the example é is representative of many combined Unicode characters 
such as ü, å. It does not apply to characters such as œ that cannot be 
decomposed.

-Ernie

---

From: Andy Newton <[email-masked]>
Date: Tue, 19 Nov 2013 22:58:48 +0000

>search against data that is normalized to NFC.

Is this a case where we should use MUST/SHOULD language or simply offer
guidance in non-normative text? It almost seems like we are intruding on
registry policy regarding how they collect and store data.

-andy

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 20 Nov 2013 12:07:02 +0000

> From: Andy Newton [mailto:[email-masked]]
> Sent: Tuesday, November 19, 2013 5:59 PM
> To: Ernie Dainow; Hollenbeck, Scott; [email-masked]
> Subject: Re: [weirds] rdap-query Proposed Changes Discussed Last Week -
> Unicode search
> 

I'd be OK with adding something like this:

"In order to provide more consistent pattern matching behavior servers SHOULD normalize Unicode client inputs using the same normalization form the server uses to store Unicode data."

Would this work?

Scott

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 20 Nov 2013 09:23:48 -0300

> "In order to provide more consistent pattern matching behavior servers SHOULD normalize Unicode client inputs using the same normalization form the server uses to store Unicode data."

(while being in the ICANN whois ng meeting...;-):
- the most important thing is to describe clearly the potential issue so implementors of the server side know what the kind of problem they will see.
-  if we decide that the client does not do any preparation, then on the wire, it is what it is: unknown state of the string being sent.  
- unless we want to morph the current paragraph to the level of i18n details that are in idna and precis, and even more, since they don't do search as here, then we can't be fully normative.  
- suggesting some changes to the text you sent:

NEW:
"In order to provide more consistent pattern matching behavior, server implementations may choose to pre-process client inputs, such as normalization, before performing the match with the stored data.  Additional information on pre-processing steps is discussed in [idna2008, precis-framework]".

Regards, Marc.

> 
> Would this work?
> 
> Scott
> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds

---

From: "John Levine" <[email-masked]>
Date: 20 Nov 2013 15:22:08 -0000

>NEW:
>"In order to provide more consistent pattern matching behavior, server implementations may choose to pre-process client
>inputs, such as normalization, before performing the match with the stored data.  Additional information on
>pre-processing steps is discussed in [idna2008, precis-framework]".

This is better.  I don't expect that clients will have any idea what
normalization servers do, so the best they can hope for is that the
servers follow applicable IETF advice which would be idna2008 for
domain names and precis (still in progress) for handles.

Is there any recommended normalization for things like names and
addresses?

R's,
John

---

From: Ernie Dainow <[email-masked]>
Date: Wed, 20 Nov 2013 10:45:27 -0500

The key question to answer is, are the different results acceptable from a
standards point of view? If so, then we don't need normalization
requirements, otherwise we MUST.

Also note that this issue does not only apply to search. It applies to
lookup as well, wherever there is Unicode in the lookup name, whether the
name is a domain, entity or whatever.

So, if you lookup domain музей.tld and get no result, is it because
a) there was no registered domain
 or
b) the server looked up the name in NFD against NFC data
     NFD  '\xd0\xbc\xd1\x83\xd0\xb7\xd0\xb5\xd0\xb8\xcc\x86'
     NFC  '\xd0\xbc\xd1\x83\xd0\xb7\xd0\xb5\xd0\xb9'

I don't see how we can declare this is a standard if lookups and searches
of the same data work sometimes and fail other times. Are there any IETF
general principles on what constitutes a standard?

-Ernie

On Wed, Nov 20, 2013 at 7:07 AM, Hollenbeck, Scott <[email-masked]
> wrote:

> "In order to provide more consistent pattern matching behavior servers
> SHOULD normalize Unicode client inputs using the same normalization form
> the server uses to store Unicode data."
>
> Would this work?
>
> Scott
>

---

From: James Mitchell <[email-masked]>
Date: Thu, 21 Nov 2013 01:03:08 +0000

The standard can provide a baseline, and anything above the baseline is up to the server. I say this because IMO complete interop is highly improbable when considering user expectations/perception, given a set of users from different backgrounds, interacting with servers located across the world, designed by users having possibly different expectations/perceptions, developed under different constraints.

The problem here seems to stem from two different classes of users, one who can enter the exact domain name (ACE or U-label) that they are looking for, e.g. automated systems, and another who enters a sequence of characters they believe represent the domain name (human using a specific/constrained input device, or doing what worked in a browser or other application).

In the first scenario, input is an A-label or U-label. Servers MUST perform an exact match.

In the second scenario, input may be an A-label or U-label, in which servers MUST perform exact matching as in the first scenario. When input is a unicode string (not U-label), a server could map the input to a U-label (for some definition of map), or to return a list of possible/suggested domain names, and have the client chose the one they are after. I’m guessing from the discussion that mapping is the intended course of action, and name-suggestion is out. I suggest servers SHOULD perform mapping consistent with UTS-46 non-transitional.

That said, servers MAY perform additional matches, to match variant domain names as defined in server’s IDN table. I’m not sure if “oe” (ligature) to “oe” matching is a good idea for exact (whole-label) matching, and should be left to partial matching; it introduces the possibility of returning more than one result, where the registry allows registration of both, thus requiring a mechanism to select the desired name. However, I don’t think there is any harm if the registry allows registration of only one of these names.

I suggest fairly generic text for partial matching: Servers MUST return a domain name in the response to a partial match (subject to server-defined response size limits), where the input string matches, using byte-by-byte prefix matching, a domain name that would be returned in an exact match. Maintaining the previous requirement, servers SHOULD perform pre-processing on the input string to map the input into a sequence that could match a U-label (UTS-46?), and MAY perform additional processing to widen the search and return domain names that may be expected by the user, where “expected" is defined by the server, e.g. mapping “oe” (ligature) to “oe”.

Is there anything more than that?  Does the behaviour of current WHOIS servers contradict this?

Regards,
James Mitchell
ARI Registry Services.

From: Ernie Dainow <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 21 November 2013 2:45 am
To: "Hollenbeck, Scott" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [weirds] rdap-query Proposed Changes Discussed Last Week - Unicode search

The key question to answer is, are the different results acceptable from a standards point of view? If so, then we don't need normalization requirements, otherwise we MUST.

Also note that this issue does not only apply to search. It applies to lookup as well, wherever there is Unicode in the lookup name, whether the name is a domain, entity or whatever.

I don't see how we can declare this is a standard if lookups and searches of the same data work sometimes and fail other times. Are there any IETF general principles on what constitutes a standard?

-Ernie

On Wed, Nov 20, 2013 at 7:07 AM, Hollenbeck, Scott <[email-masked]<mailto:[email-masked]>> wrote:
> From: Andy Newton [mailto:[email-masked]<mailto:[email-masked]>]
> To: Ernie Dainow; Hollenbeck, Scott; [email-masked]<mailto:[email-masked]>
> On 11/18/13 2:35 PM, "Ernie Dainow" <[email-masked]<mailto:[email-masked]>> wrote:
>

Would this work?

Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 25 Nov 2013 15:12:09 +0000

From: James Mitchell [mailto:[email-masked]]
Sent: Wednesday, November 20, 2013 8:03 PM
To: Ernie Dainow; Hollenbeck, Scott
Cc: [email-masked]
Subject: Re: [weirds] rdap-query Proposed Changes Discussed Last Week - Unicode search

In the second scenario, input may be an A-label or U-label, in which servers MUST perform exact matching as in the first scenario. When input is a unicode string (not U-label), a server could map the input to a U-label (for some definition of map), or to return a list of possible/suggested domain names, and have the client chose the one they are after. I'm guessing from the discussion that mapping is the intended course of action, and name-suggestion is out. I suggest servers SHOULD perform mapping consistent with UTS-46 non-transitional.

That said, servers MAY perform additional matches, to match variant domain names as defined in server's IDN table. I'm not sure if "oe" (ligature) to "oe" matching is a good idea for exact (whole-label) matching, and should be left to partial matching; it introduces the possibility of returning more than one result, where the registry allows registration of both, thus requiring a mechanism to select the desired name. However, I don't think there is any harm if the registry allows registration of only one of these names.

I suggest fairly generic text for partial matching: Servers MUST return a domain name in the response to a partial match (subject to server-defined response size limits), where the input string matches, using byte-by-byte prefix matching, a domain name that would be returned in an exact match. Maintaining the previous requirement, servers SHOULD perform pre-processing on the input string to map the input into a sequence that could match a U-label (UTS-46?), and MAY perform additional processing to widen the search and return domain names that may be expected by the user, where "expected" is defined by the server, e.g. mapping "oe" (ligature) to "oe".

Apologies to anyone that isn't reading this with an HTML-aware email client...

I don't understand this sentence: "Servers MUST return a domain name in the response to a partial match (subject to server-defined response size limits), where the input string matches, using byte-by-byte prefix matching, a domain name that would be returned in an exact match". I don't get the "partial match" and "exact match" bits. From the text above it sounds like you're describing the exact match lookup scenario in which case a byte-by-byte match is required. Can you provide an example if my proposed text change below doesn't address whatever use case you're trying to describe?

I have to craft text that works for non-domain searches, too. I also can't include non-ASCII characters. Let's try some minor rewording:

"Servers MUST perform a byte-by-byte binary comparison to determine exact matches. When processing Unicode text servers SHOULD perform pre-processing on the input string to normalize client inputs using the same normalization form the server uses to store Unicode data. Servers MAY perform additional processing to widen the search and return domain names that might be reasonably expected by the user, where "expected" is defined by the server, e.g. mapping U+0153 (LATIN SMALL LIGATURE OE) to "oe"."

I didn't include UTS-46 or any other mapping because servers may store data in different forms, and again, we're not always dealing with domain names.

Does this work?

Scott

---

From: Andy Newton <[email-masked]>
Date: Mon, 25 Nov 2013 15:29:17 +0000

From: <Hollenbeck>, Scott Hollenbeck <[email-masked]<mailto:[email-masked]>>
Date: Monday, November 25, 2013 10:12 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [weirds] rdap-query Proposed Changes Discussed Last Week - Unicode search

“Servers MUST perform a byte-by-byte binary comparison to determine exact matches. When processing Unicode text servers SHOULD perform pre-processing on the input string to normalize client inputs using the same normalization form the server uses to store Unicode data. Servers MAY perform additional processing to widen the search and return domain names that might be reasonably expected by the user, where “expected" is defined by the server, e.g. mapping U+0153 (LATIN SMALL LIGATURE OE) to “oe”.”

I'm unconvinced that a byte-for-byte comparison on an exact match lookup is always the right thing to do. It maybe that the domain being looked up is a variant according to a registries rules, and therefore the returned object is for another domain with a variant relation to the look up.

This text feels like it is overly prescriptive in that most registry operators know their rules for matching. We simply need the protocol to have clear delineations between lookups, searches in an authority area (e.g. TLD) and searches across multiple authority areas (e.g. multiple TLDs).

-andy

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 25 Nov 2013 15:35:43 +0000

From: Andy Newton [mailto:[email-masked]]
Sent: Monday, November 25, 2013 10:29 AM
To: Hollenbeck, Scott; [email-masked]
Cc: [email-masked]
Subject: Re: [weirds] rdap-query Proposed Changes Discussed Last Week - Unicode search

So you prefer the existing text in the document?

Scott

---

From: Andy Newton <[email-masked]>
Date: Mon, 25 Nov 2013 15:53:36 +0000

From: <Hollenbeck>, Scott Hollenbeck <[email-masked]<mailto:[email-masked]>>
Date: Monday, November 25, 2013 10:35 AM
To: Andrew Newton <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [weirds] rdap-query Proposed Changes Discussed Last Week - Unicode search

Good question. I think not. Rereading it, Section 4 might be better if we more clearly stated "Here is how a client asks for X" and "Here is how a server returns information meaning Y". How the processing is done is probably not something we should be doing, at least not with normative text.

I'll work on some wording.

-andy

---

From: Guillaume Leclanche <[email-masked]>
Date: Mon, 25 Nov 2013 10:54:01 -0500

2013/11/25 Hollenbeck, Scott <[email-masked]>

>  *From:* Andy Newton [mailto:[email-masked]]
> *Sent:* Monday, November 25, 2013 10:29 AM
> *To:* Hollenbeck, Scott; [email-masked]
> *Cc:* [email-masked]
>
> *Subject:* Re: [weirds] rdap-query Proposed Changes Discussed Last Week -
> Unicode search
>
>
>
> *From: *<Hollenbeck>, Scott Hollenbeck <[email-masked]>
> *Date: *Monday, November 25, 2013 10:12 AM
> *To: *"[email-masked]" <
> [email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [weirds] rdap-query Proposed Changes Discussed Last Week -
> Unicode search
>
>
>
> “Servers MUST perform a byte-by-byte binary comparison to determine exact
> matches. When processing Unicode text servers SHOULD perform pre-processing
> on the input string to normalize client inputs using the same normalization
> form the server uses to store Unicode data. Servers MAY perform additional
> processing to widen the search and return domain names that might be
> reasonably expected by the user, where “expected" is defined by the server,
> e.g. mapping U+0153 (LATIN SMALL LIGATURE OE) to “oe”.”
>
>
>
> I'm unconvinced that a byte-for-byte comparison on an exact match lookup
> is always the right thing to do. It maybe that the domain being looked up
> is a variant according to a registries rules, and therefore the returned
> object is for another domain with a variant relation to the look up.
>
>
>
> This text feels like it is overly prescriptive in that most registry
> operators know their rules for matching. We simply need the protocol to
> have clear delineations between lookups, searches in an authority area
> (e.g. TLD) and searches across multiple authority areas (e.g. multiple
> TLDs).
>

I think that the most important part in search is that the client should
know how the server is doing the search. The œ (U+153) doesn't have to be
extrapolated to "oe" everywhere, but the server should tell the client if
it is doing it or not. And we could even make it possible for the client to
ask the server to do it (or not).

So my proposal is :
1. we document the different search variants, and maybe write them in some
formal language
2. with each search, return the i18n rules that were used to do the search
in the response (using the formal language ?)
3. define a segment that can be used by the client to request the
default/available search rules on the server
4. allow the client to tune the way the server is doing its search

I don't think steps 2-3 are too difficult to implement. Step 4 looks
definitely more challenging as there would be sanity/security/performance
implication.

What do you think ?

Guillaume

---

From: "John Levine" <[email-masked]>
Date: 25 Nov 2013 16:39:19 -0000

>This text feels like it is overly prescriptive in that most registry operators know their rules for matching.

I have to agree.  This is the kind of prescription that registry
operators will read and ignore, and do whatever matching they were
planning to do.

R's,
John

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 25 Nov 2013 18:07:58 +0000

> So my proposal is :
> 1. we document the different search variants, and maybe write them in some formal language
> 2. with each search, return the i18n rules that were used to do the search in the response (using the formal language ?)
> 3. define a segment that can be used by the client to request the default/available search rules on the server
> I don't think steps 2-3 are too difficult to implement. Step 4 looks definitely more challenging as there would be sanity/security/performance implication.
>
> What do you think ?

This sounds more complicated than the text I proposed in response to Ernie and James, and if people have an issue with my proposal I can't see this being supported, either.

Scott