Subject: [weirds] Entity name search

From: Ernie Dainow <[email-masked]>
Date: Mon, 26 Aug 2013 17:47:15 -0400

In 4.0 draft-ietf-weirds-rdap-query-06
   ... When comparing entity names, servers SHOULD use the normalization
rules
   and code points specified by [I-D.ietf-precis-nickname] to determine
   partial matches.
I don't think the normalization rules referred to are appropriate for RDAP
entity searches. The process in [I-D.ietf-precis-nickname] is designed to
produce unique names in order to avoid conflict of identifiers in chat
rooms or other applications. As such, it species a restricted set of
Unicode characters, the FreeformClass. But an Entity name, such as the name
of a Registrar, may be any Unicode string. Restricting names to a subset of
Unicode means that it may not be possible to enter a valid name of a
contact or organization.

-Ernie

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 27 Aug 2013 08:51:39 -0400

Le 2013-08-26 à 17:47, Ernie Dainow <[email-masked]> a écrit :

>    ... When comparing entity names, servers SHOULD use the normalization rules
> I don't think the normalization rules referred to are appropriate for RDAP entity searches. The process in [I-D.ietf-precis-nickname] is designed to produce unique names in order to avoid conflict of identifiers in chat rooms or other applications. As such, it species a restricted set of Unicode characters, the FreeformClass. But an Entity name, such as the name of a Registrar, may be any Unicode string.

do you really mean it?  Unicode contains a lot of stuff that makes no sense for an entity.  Actually, the precis framework and the nickname part should allow any entity name to be written. It would be useful to see a contrary case.

Marc.

> Restricting names to a subset of Unicode means that it may not be possible to enter a valid name of a contact or organization.
> 
> -Ernie
> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds

---

From: Ernie Dainow <[email-masked]>
Date: Tue, 27 Aug 2013 10:50:50 -0400

> do you really mean it?  Unicode contains a lot of stuff that makes no sense for an entity.  Actually, the precis framework and the nickname part should allow any entity name to be written. It would…
I don't have a contrary case at hand. But since the approach we have 
been taking with RDAP is to support legacy Whois, there may be any kind 
of name already registered in service providers databases. RFC 5733, 
Extensible Provisioning Protocol (EPP) Contact Mapping, states in 2.3
     Individual and organizational names MAY be provided in either
     UTF-8 [RFC3629 <http://tools.ietf.org/html/rfc3629>] or a subset of 
UTF-8 that can be represented in 7-bit ASCII
Unless we want to redefine what is allowed in the registration process, 
we should not restrict search.

-Ernie

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 27 Aug 2013 11:41:33 -0400

Le 2013-08-27 à 10:50, Ernie Dainow <[email-masked]> a écrit :

> I don't have a contrary case at hand. But since the approach we have been taking with RDAP is to support legacy Whois, there may be any kind of name already registered in service providers databases. RFC 5733, Extensible Provisioning Protocol (EPP) Contact Mapping, states in 2.3
>     UTF-8 [RFC3629] or a subset of UTF-8 that can be represented in 7-bit ASCII
> Unless we want to redefine what is allowed in the registration process, we should not restrict search.

The more the repertoire is large, including all kind of funny glyphs, the more complicated is to do good search and good results. So it is the advantage of everybody to leave out the ones that makes no sense.  For example, there are all sorts of punctuation, spaces, etc... that without any restriction or any profile (such as the precis work), will make the search on both client and server side more complicated and less useful from the user point of view. 

Marc.

---

From: Ernie Dainow <[email-masked]>
Date: Tue, 27 Aug 2013 13:47:39 -0400

On 8/27/2013 11:41 AM, Marc Blanchet wrote:
> Le 2013-08-27 à 10:50, Ernie Dainow <[email-masked] 
> <mailto:[email-masked]>> a écrit :
>
>>> Le 2013-08-26 à 17:47, Ernie Dainow<[email-masked]>  a écrit :
>>>
>> been taking with RDAP is to support legacy Whois, there may be any 
>> kind of name already registered in service providers databases. RFC 
>> 5733, Extensible Provisioning Protocol (EPP) Contact Mapping, states 
>> in 2.3
>>     UTF-8 [RFC3629 <http://tools.ietf.org/html/rfc3629>] or a subset 
>> of UTF-8 that can be represented in 7-bit ASCII
> The more the repertoire is large, including all kind of funny glyphs, 
> the more complicated is to do good search and good results. So it is 
> the advantage of everybody to leave out the ones that makes no sense. 
>  For example, there are all sorts of punctuation, spaces, etc... that 
> without any restriction or any profile (such as the precis work), will 
> make the search on both client and server side more complicated and 
> less useful from the user point of view.
>
Suppose a company registered as "A&P Big Names" where & is some obscure 
Unicode point not included in FreeformClass. If an RDAP user does a 
search for "A&*" they get an error, search string invalid. They now may 
try a search for "A*". They will probably get a truncated list, since 
all registries that support search limit the size to 50 or so entries. 
So with[I-D.ietf-precis-nickname] normalization, the user may not have 
any way to find an entity name.

I don't see how removing this normalization makes search more 
complicated. On the contrary it makes it easier; for the user, as this 
example shows; and for the server because it does not have to do a 
normalization check on the search string.

-Ernie

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 27 Aug 2013 14:01:09 -0400

Le 2013-08-27 à 13:47, Ernie Dainow <[email-masked]> a écrit :

> Suppose a company registered as "A&P Big Names" where & is some obscure Unicode point not included in FreeformClass. If an RDAP user does a search for "A&*" they get an error, search string invalid. They now may try a search for "A*". They will probably get a truncated list, since all registries that support search limit the size to 50 or so entries. So with[I-D.ietf-precis-nickname] normalization, the user may not have any way to find an entity name.

nickname is one of the profile of precis. One can define a new profile based on the framework to fill its needs. That is the whole purpose of the precis framework.  So don't stick on precis-nickname. My point is that we ought to have some profile that defines what is possible, we can't accept everything.

> 
> I don't see how removing this normalization makes search more complicated. On the contrary it makes it easier; for the user, as this example shows; and for the server because it does not have to do a normalization check on the search string.

normalization seems to me absolutely necessary. Moreover it is not enough. Therefore, I don't see other solution than defining a precis profile, if the current ones are not useful. (I'm happy to start a draft on this if people agree with the idea).  The next question is then who implements it: the server has to, the remaining question is how much the client shall do.

Marc.