Subject: [weirds] comments on draft-ietf-weirds-rdap-query-08

From: Andrew Sullivan <[email-masked]>
Date: Wed, 27 Nov 2013 14:41:17 -0500

Hi,

Now that I'm all sorted out on which document I ought to be paying
attention to, I'm reviewing draft-ietf-weirds-rdap-query-08.  Here are
some comments.

Section 3.1.3: "where XXXX is a fully-qualified domain name [RFC4343]"
The string "fully-qualified domain name" does not, as near as I can
tell, appear in RFC 4343.  What isn't clear to me is whether this is
_really_ fully-qualified in the DNS sense -- e.g. "example.com."; or
fully-qualified in the way an enormous number of people usually use
it, which is really "qualified relative to the root" --
e.g. "example.com".

Later, "IDN labels SHOULD NOT be represented as a mixture of A-labels
and U-labels."  I think this probably means "If XXXX contains any IDN
label, then every IDN label in XXXX SHOULD be either A-labels or
U-labels, and not a mixture."  Perhaps shorter and still as clear is,
"IDNs SHOULD NOT be represented as a mixture of A-labels and U-labels;
that is, any IDN SHOULD use only A-labels or only U-labels."  The
reason I'm having trouble with this is that "xn--jxalpdlp.com"
contains an A-label and an NR-LDH label, so we can't just say "no
mixing".  If nobody else finds the existing text possibly misleading,
I don't feel too strongly about it.

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.
    
In Section 4, we have 'A character string representing a top-level
domain MAY be concatenated to the end of the search pattern to limit
the scope of the search.[…] The search pattern "exam*.com" will match
"example.com".'  Why only top-level domain?  What's wrong with
"exam*.co.uk", for instance?  Or "exam*.crankycanuck.ca", for that
matter?

I suspect that the paragraph beginning with "Partial matching is not
feasible across combinations of Unicode…" is going to lead to
confusion.  I _think_ what it means is that "e*" does not match é
(i.e. U+0301 COMBINING ACUTE ACCENT plus U+0065, but also U+00E9).
But in my reading, the paragraph appears to say that "é*" can't match
"école".  Is that what's intended?  (I presume not since two
paragraphs later describes how to do that.)

The paragraph starting "Servers can expect to receive search patterns
from clients that…" appears to say that you can send your query term
in Win-1252 and expect a match.  If that's the intention, I suggest
that this protocol is going to be completely useless for any non-ASCII
search.

The two paragraphs on name-records with associations will probably not
be comprehensible to anyone who doesn't know what a variant is, but I
can live with them.  It's not clear to me, from this text, whether
these are just another part of the domain array, or whether what's
returned is a reference (a link?).  This could be because I haven't
read carefully enough yet, so this might come clear as I re-read.

I hope these comments are useful.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]