[gtld-tech] A-label and U-label mixing - RDAP query

[Gustavo Lozano]

Hello colleagues,
 
Apologies for crossposting.
 
During the public comments period of the "Registration Data Access Protocol
(RDAP) Operational Profile for gTLD Registries and Registrars",
https://www.icann.org/public-comments/rdap-profile-2015-12-03-en, the
following comment was received:
 
"Section 1.4.1 of the Operational Profile is inconsistent with the guidance
given in RFC 7482 regarding processing of RDAP queries containing a mixture
of IDN A-labels and U-labels. Per RFC 7482, ³IDNs SHOULD NOT be represented
as a mixture of A-labels and U-labels; that is, internationalized labels in
an IDN SHOULD be either all A-labels or all U-labels². This requirement is
not only inconsistent with RFC 7482, it is also counter to the consensus of
the IETF community regarding appropriate processing of IDN queries. "


Another comment on the same path says:


"Allowing A-labels and U-labels will be particularly unworkable for right to
left languages unless the RDAP server introduces arbitrary restrictions. It
is important to remember that RDAP is intended for machine-to-machine
communication. Since RFC 7482 is very clear on this guidance (do not mix the
two) any software client that generates this sort of query is broken. With
the relative youth of the RDAP standard there is unlikely to be a large
install base of software clients with said broken implementation. If ICANN
is aware of a software client that has incorrectly implemented the RDAP
standard and is now generating queries which combine A-labels and U-labels
then ICANN should take its concerns to the IETF where such challenges are
considered as part of any implementation discussion. Enshrining bad practice
within the Operational Profile will result in needless future changes to the
technology or additional service restrictions."


The comment is related to the following section of the gTLD RDAP profile:
 
"1.4.1 The RDAP server MUST support Internationalized Domain Name (IDN) RDAP
lookup queries using A-label or U-label format [RFC 5890] for domain name
and name server objects. The RDAP server MUST accept a mixture of the two
(i.e. A-label and U-label format) in the same RDAP lookup query².
 
The purpose of this message is to obtain feedback from this community
regarding this issue. We believe that the following text from RFC 7482 is a
requirement for the RDAP client: "IDNs SHOULD NOT be represented as a
mixture of A-labels and U-labels; that is, internationalized labels in an
IDN SHOULD be either all A-labels or all U-labels.".
 
RFC7482 provides an example of why a server may receive a mixture of
A-labels and U-labels in the query: "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."
 
RFC7482 gives two options to the server: "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".
 
We believe that the reasoning in RFC 7482 is sufficient to require gTLD RDAP
servers to accept and process a query that mixes A-labels and U-labels.


Question for this community: is the behavior specified in the gTLD RDAP
Profile (I.e. requiring processing of queries that mixes A-labels and
U-labels) consistent with RFC 7482?


Your feedback is appreciated.


Regards,
Gustavo


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gtld-tech/attachments/20160414/22358c2f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5056 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gtld-tech/attachments/20160414/22358c2f/smime-0001.p7s>