Subject: [I18ndir] Mixed Labels and RDAP

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 31 Jan 2019 17:10:58 +0000

Let me be among the first to ask this group of wise people for advice:

There is a small group of people who are working through development of an operational profile for the Registration Data Access Protocol (RDAP; see RFCs 7482 and 7483) for gTLD registries in an ICANN context. Section 3.1.3 of RFC 7482 (which describes domain name queries) notes that "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". The question in this ICANN working group is focused on what an RDAP server operator should do if it receives a query for a domain name that contains a mix of A-labels and U-labels. Should it reject the query as syntactically invalid, or should it try to be accommodating by doing something like converting U-labels to A-labels to produce an input domain name containing all A-labels? What would you folks suggest?

Scott

---

From: "Patrik Fältström" <[email-masked]>
Date: Thu, 31 Jan 2019 18:24:10 +0100

On 31 Jan 2019, at 18:10, Hollenbeck, Scott wrote:

> Should it reject the query as syntactically invalid, or should it try to be accommodating by doing something like converting U-labels to A-labels to produce an input domain name containing all A-labels? What would you folks suggest?

Without thinking for too many seconds (I might change my mind) one should be conservative with what one produce, but accept (if possible) what others do wrong.

As A-label / U-label relationship is 1:1, I do not see any problems doing the transformation if needed for individual labels.

It was different when using IDNA2003, but we are not there now.

   Patrik

---

From: "Marc Blanchet" <[email-masked]>
Date: Thu, 31 Jan 2019 12:29:50 -0500

On 31 Jan 2019, at 12:24, Patrik Fältström wrote:

>> Should it reject the query as syntactically invalid, or should it try 
>> to be accommodating by doing something like converting U-labels to 
>> A-labels to produce an input domain name containing all A-labels? 
>> What would you folks suggest?
>
> Without thinking for too many seconds (I might change my mind) one 
> should be conservative with what one produce, but accept (if possible) 
> what others do wrong.
>
> As A-label / U-label relationship is 1:1, I do not see any problems 
> doing the transformation if needed for individual labels.

right. I agree. My only concern is the difference in the query and the 
returned data. Query has one string of code points (mixed U and A), 
while the answer will have another string of code points (all A). Not a 
good design in general, and if the client is picky with verifying what 
it has sent and what it has received, then not good. (but honestly, 
those javascript web clients are pretty lazy and do not verify anything 
;-)

marc.

> -- 
> I18ndir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i18ndir

---

From: John C Klensin <[email-masked]>
Date: Thu, 31 Jan 2019 17:35:56 -0500

Scott,

While I agree with Patrik and Marc, your question raises two
other concerns for me, concerns that I should probably identify
now rather than later...

(1) If I correctly understand your question, it seems to me that
it is a business practices one, not a technical issue.   As
Patrik indirectly pointed out, it would be a technical issue if
the A-label <-> U-label relationship were not symmetric and
information-preserving, but that symmetry was one of the few key
changes in IDNA2008.  It would be an entirely rational business
decision to try to cut customer interaction and related costs as
much as possible, in which case the right answer to your
question might be a syntax error that gave as little information
about the relevant problem as possible.  It might be equally
reasonable to either try to figure out what the user meant and
get some verification of that or to conclude the the user was
confused and it is time for some human contact and real service
and education.  I know which policies I favor and what
approaches I'd like to see in companies I'd prefer to stay in
business, but I'm never going to buy enough domain names for my
opinion to count from that sort of business standpoint.   I also
note Marc's comment about the quality of Javascript libraries,
but one doesn't have to use the -- really high-quality customer
service tends to be expensive in software design as well as
personal.   However, I don't think your question is the sort of
question the IETF should be asked or that the IETF should
properly answer... ultimately and the above notwithstanding, if
you want my opinion on the subject, I can tell you where to send
a purchase order and I assume (or at least hope) that others
would give you similar answers.

(2) The creation of this list were evidence that there was very
little energy in the IETF among those with significant expertise
in i18n-related topics.  I hope we can keep the list
sufficiently focused on topics in the IETF's critical path --
especially documents that are long-overdue for consideration --
that we can effectively address those topics rather than getting
distracted by discussions that are not in that critical path.
If I'm in the rough about that, I hope someone will say so and
explain.

best,
    john

--On Thursday, January 31, 2019 12:29 -0500 Marc Blanchet
<[email-masked]> wrote:

>>> Should it reject the query as syntactically invalid, or
>>> should it try  to be accommodating by doing something like
>>> converting U-labels to  A-labels to produce an input domain
>>> name containing all A-labels?  What would you folks suggest?
>> 
>> Without thinking for too many seconds (I might change my
>> mind) one  should be conservative with what one produce, but
>> accept (if possible)  what others do wrong.
>> 
>> As A-label / U-label relationship is 1:1, I do not see any
>> problems  doing the transformation if needed for individual
>> labels.
> 
> right. I agree. My only concern is the difference in the query
> and the returned data. Query has one string of code points
> (mixed U and A), while the answer will have another string of
> code points (all A). Not a good design in general, and if the
> client is picky with verifying what it has sent and what it
> has received, then not good. (but honestly, those javascript
> web clients are pretty lazy and do not verify anything ;-)
> 
> marc.
> 
>>

---

From: Martin J. Dürst <[email-masked]>
Date: Fri, 1 Feb 2019 05:26:04 +0000

Hello everybody,

Given this is a new list, and I'm not sure who is on it, I might want to 
quickly introduce myself, even though up to now I think all the people 
who have contributed to this list already know me.

I have been Internationalization Activity Lead at the W3C from 1998 to 
2005, and continue to chair the Internationalization Interest Group of 
the W3C, although that's a low-effort job. I have worked on 
internationalization in the IETF since around 1994. I'm currently 
teaching and doing research at a Japanese University. I hope I'll be 
able to contribute to this group, although that will be modulated 
somewhat by the ebbs and flows of the Japanese academic year.

I'm looking forward to lots of productive discussions and work.

> If I'm in the rough about that, I hope someone will say so and

I don't know about the rough and so on, but I think a question such as 
Scott's fits very well with the description of this directorate and its 
responsibilities at https://datatracker.ietf.org/group/i18ndir/about/.

While this is not a formal review, it is often much more practical to 
answer direct questions like Scott's. It's also a good way to create a 
common understanding among the members of this new group. In this way, I 
don't think it's a distraction at all.

I have just quickly looked at 
https://datatracker.ietf.org/group/i18ndir/reviews/, it lists a number 
of documents open for review. An entry in each row says "auto-suggest", 
I'm not sure what that means, maybe somebody can explain. I case we are 
asked to review one of these documents each, I'd probably go with 
https://tools.ietf.org/html/draft-nottingham-rfc5785bis-08.

The list of reviewers at 
https://datatracker.ietf.org/group/i18ndir/reviewers/ is still empty. 
Maybe that means that some clerical work still has to be done, maybe 
that means that people only will show up in that list if they actually 
have done some work. Again, maybe somebody can explain.

John, I guess that if you have some specific documents that you think we 
should look at, you might as well just bring them up here.

Regards,   Martin.