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

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 2 Dec 2013 14:40:44 +0000

> -----Original Message-----
> From: weirds [mailto:[email-masked]] On Behalf Of Andrew
> Sullivan
> Sent: Wednesday, November 27, 2013 2:41 PM
> To: [email-masked]
> Subject: [weirds] comments on draft-ietf-weirds-rdap-query-08
> 
> 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".

Typical client use is "qualified relative to the root".

We could probably come up with a better reference than 4343. In EPP we use RFCs 952 and 1123 for domain and host name syntax. Which reference would you recommend?

> 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.

I'll use your text - thanks.

> 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.

> 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?

Nothing is wrong with those other examples. How does this text work for you?

"A character string representing multiple domain name labels MAY be concatenated to the end of the search pattern to limit the scope of the search."

> 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.)

No, that's not what's intended. Can you suggest replacement text?

> 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.

I don't know about "expect a match", but I do believe that servers will receive all kinds of crud from clients - and they need to do something reasonable with whatever they receive. This is one reason some of us are converging on the "simple binary comparison" approach to matching.

> 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.

This is part of the text provided by John Klensin. I'm open to suggestions for clarification.

> I hope these comments are useful.

They are - thank you!

Scott