Subject: [weirds] Comments on draft-ietf-weirds-rdap-query

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 15 Sep 2014 00:46:55 -0700

Hi there,

I've reviewed this draft.  It looks pretty much ready to go.  I have these
editorial suggestions:

1) Are the bullet lists in Section 1.1 and 2 done with the usual xml2rfc
mechanisms?  The spacing seems to be unusual.

2) Section 2 includes a reference to NICNAME.  Do we need to include a
definition or reference for it?

3) The end of section 2 starts to tread into security stuff.  Should there
be a reference to draft-ietf-weirds-rdap-sec?

4) Section 3.1.3 has SHOULDs and SHOULD NOTs, but I'm wondering why they
aren't MUSTs and MUST NOTs.  Otherwise, under what conditions would one
deviate from the advice, and in what way (i.e., what alternatives are
there)?

5) Section 3.1.4, same thing.

6) In Section 3.1.5, indicate that the syntax of <handle> is specific to
the registration provider.

7) Same question about the SHOULDs in Section 4.

-MSK

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 15 Sep 2014 13:19:38 +0000

From: weirds [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Monday, September 15, 2014 3:47 AM
To: [email-masked]
Subject: [weirds] Comments on draft-ietf-weirds-rdap-query

Hi there,
I've reviewed this draft.  It looks pretty much ready to go.  I have these editorial suggestions:
1) Are the bullet lists in Section 1.1 and 2 done with the usual xml2rfc mechanisms?  The spacing seems to be unusual.
[SAH] Yes, list style="hanging".
2) Section 2 includes a reference to NICNAME.  Do we need to include a definition or reference for it?
[SAH] NICNAME and WHOIS are really the same thing per RFC 954. We should either add NICNAME to the first use of WHOIS or drop it from Section 2 since we cite RFC 3912 as a reference, and 3912 doesn’t use NICNAME. I’d prefer to drop use of NICNAME.
3) The end of section 2 starts to tread into security stuff.  Should there be a reference to draft-ietf-weirds-rdap-sec?
[SAH] Yes, that would be appropriate.
4) Section 3.1.3 has SHOULDs and SHOULD NOTs, but I'm wondering why they aren't MUSTs and MUST NOTs.  Otherwise, under what conditions would one deviate from the advice, and in what way (i.e., what alternatives are there)?
5) Section 3.1.4, same thing.
[SAH] They’re SHOULDs and SHOULD NOTs because the people that suggested that text wrote it that way ☺. Perhaps Andrew Sullivan can explain the deviation conditions if they exist.
6) In Section 3.1.5, indicate that the syntax of <handle> is specific to the registration provider.
[SAH] OK.
7) Same question about the SHOULDs in Section 4.

-MSK

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 16 Sep 2014 21:22:56 -0400

Hi,

It would appear that I've fallen down on the job (again) because the
internationalization advice in the document as it now stands is
inconsistent among sections.  Section 3.1.3 says to convert everything
to A-labels for the purposes of matching.  Section 4 recommends
storing things as U-labels.  I recognize my hand in some of this text,
and yet it's clearly mad advice.  (This may be telling me something
about my state of mind.)  I want to describe three things that I think
we're trying to do, and then suggest an answer to Murray at the end.

There are three basic problems we're facing.  The first is that we
want handling to be reliable, and handling of IDNs seems to be more
reliable if we use only specialized name-handling code to deal with
IDNA.  I expect RDAP servers to cope with the whole domain name query.
They're unlikely to have specialized DNS stuff in them that knows how
to break the presentation-format version of a name into constituent
labels in every case.  (In practice, people often try to do this using
the presentation-format label separator, ".".  The problem is that "."
is itself a legal character in some labels, and so if an RDAP client
is assembling stuff from poorly-controlled data sources, it's entirely
possible to get something that has an embedded dot.  This is a corner
case, of course, but I think it's a corner we need to cope with.)  I
think, not having to break the name into labels in order to convert
the different labels into one form or the other and then reassemble
the resulting labels into a name and then to look the name up
increases the chances of success, and I think servers should be free
to refuse to do that work on behalf of clients if they want.

The second problem we have is that people want partial-string matching
for U-labels to work pretty much the way it works for LDH-labels.  So,
in section 3.2.1 we say to use U-labels even though just above we just
finished telling people "always match on the A-label".  We _have_ to
do this, because there's no way to do a partial-string match on the
A-label.  But worse, there isn't really a good way to do
partial-string matching on a U-label either that is always reliable.
For instance, suppose we have the name passé.com.  Now, the string
passé when NFC-normalized uses U+00E9.  But the decomposition form
would use e (U+0065) and the combining acute accent (U+0301).  The
document now says that you're not allowed to do partial-matching
"where a Unicode character may be legally combined with another
Unicode character or characters," but the simple fact is that, due to
combining characters, _any_ characters can in fact be combined.  And
in the case of "passe*", it looks like an LDH query, but it might not
be.  (Fine: our answer to that is "passé" doesn't match and "passed"
does; but now respecting "Clients should avoid submitting a partial
match search of Unicode characters where a Unicode character may be
legally combined with another Unicode character or characters," looks
like a taller order.)

The third problem we have is that we didn't want to wait on precis
profiles to cope with most of this, deciding instead to try to do it
in the document.  I _think_ we got the rules right in section 4 (I
think I contributed some text, but I can't remember for sure), but I
don't know quite how carefully it's been reviewed.

> deviate from the advice, and in what way (i.e., what alternatives are

Some of us thought that MUST [NOT] was the right specification, but
people pointed out that you might be sending things from a system that
wasn't IDNA-clever and so didn't know how to do the conversion.  Hence
the SHOULDs.  We had a discussion about how to handle the case where
the server can't cope with the mixed form, and I don't think we came
to a conclusion about what error to return.  Here's another possible
addition of text, in case it helps:

   […] IDNs SHOULD NOT be represented as a mixture of A-labels and
   U-labels; that is, all internationalized labels in an IDN SHOULD be
   either A-labels or U-labels.  It is possible for an RDAP client to
   assemble a query string from multiple independent data sources.
   Such a client might not be able to perform conversions between
   A-labels and U-labels.  An RDAP server that receives a query string
   with a mixture of A-labels and U-labels MAY convert all the
   U-labels to A-labels, perform IDNA processing, and proceed with
   exact-match lookup.  In such cases, the response to be returned to
   the query source may not match the input from the query source.
   Alternatively, the server MAY refuse to process the query.  [I
   _think_ the right response in that case is 400, but I defer to
   others on it.]

On another note, I still think that 

   If the client sends the server an IDN in U-label format, servers that
   support IDNs MUST convert the IDN into A-label format and perform
   IDNA processing as specified in RFC 5891 [RFC5891].  The server
   should perform an exact match lookup using the A-label.

is overspecifying in the last sentence.  It could say instead "The
server MAY perform the match using either the A-label or U-label form;
using one consistent form for matching every label is likely to be
more reliable."  The point of the "peform IDNA processing" is to ensure
that the putative U-label in hand really is a valid IDN that could (in
A-label form) be in the DNS.  I don't think we care how actual matches
in people's databases are performed.  I think we arrived at "should
match A-label form" because, if you've already done all this work, the
match is more likely to be correct.

> 5) Section 3.1.4, same thing.

This should work the same.  Maybe a reference back to the previous
section.

> 7) Same question about the SHOULDs in Section 4.

I'm much more nervous about the discussion in section 4, and I think
it wouldn't be a bad idea to try to get some review from people in
precis or on the idnabis list or something.  (Did we already do that
and I've just been running to hard to see it?  If so, apologies.)

The SHOULD NOT in

    Servers SHOULD NOT partially match
   combinations of Unicode characters where a Unicode character may be
   legally combined with another Unicode character or characters.

is basically a way of weaseling out of the combining-character problem
I was talking about above, without getting into a deep discussion of
all the ways that this precept can be violated.  Would it help to say,
"It should be noted that, because of the way combining characters can
be combined with many other charactes, it may not always be possible
to detect possible cases where a character could have been combined
with another character, but was not"?

I read the document through, and the rest of the sections look sane to
me.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]