Subject: [Idna-update] FWD: Last Calls on two IDNA documents

From: John C Klensin <[email-masked]>
Date: Fri, 02 Aug 2019 17:15:38 -0400

For those who don't follow the IETF-announce list and are
interested, Last Calls were announced today  on
draft-klensin-idna-unicode-review and
draft-klensin-idna-rfc5891bis.  The former is the clarification
to the "new Unicode version" review process discussed
extensively while we were working on the Unicode 11.0 and 12.0
updates and IANA tables early in the year (and on
draft-faltstrom-unicode11 and draft-faltstrom-unicode12).  The
latter is a significantly updated version of clarification to
the "registry restrictions" material that has been kicking
around for a few years.

If you have comments, please follow the Last Call instructions
included below.

best,
   john

---------- Forwarded Message ----------
Date: Friday, August 2, 2019 09:08 -0700
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: [email-masked],
[email-masked], [email-masked]
Subject: Last Call: <draft-klensin-idna-unicode-review-02.txt>
(IDNA Review for New Unicode Versions) to Proposed Standard

The IESG has received a request from an individual submitter to
consider the following document: - 'IDNA Review for New Unicode
Versions'   <draft-klensin-idna-unicode-review-02.txt> as
Proposed Standard

The IESG plans to make a decision in the next few weeks, and
solicits final comments on this action. Please send substantive
comments to the [email-masked] mailing lists by 2019-08-30.
Exceptionally, comments may be sent to [email-masked] instead. In
either case, please retain the beginning of the Subject line to
allow automated sorting.

Abstract

   The standards for Internationalized Domain Names in
Applications    (IDNA) require a review of each new version of
Unicode to determine    whether incompatibilities with prior
version or other issues exist    and, where appropriate, to
allow the IETF to decide on the trade-offs    between
compatibility with prior IDNA versions and compatibility with
Unicode going forward.  That requirement, and its relationship to
   tables maintained by IANA, has caused significant confusion
in the    past.  This document makes adjustments to the review
procedure based    on experience and updates IDNA, specifically
RFC 5892, to reflect    those changes and clarify the various
relationships involved.  It    also makes other minor
adjustments to align that document with    experience.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-klensin-idna-unicode-revi
ew/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-klensin-idna-unicode-revi
ew/ballot/

No IPR declarations have been submitted directly on this I-D.

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce

---------- End Forwarded Message ----------

---------- Forwarded Message ----------
Date: Friday, August 2, 2019 13:30 -0700
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: [email-masked],
[email-masked], [email-masked]
Subject: Last Call: <draft-klensin-idna-rfc5891bis-04.txt>
(Internationalized Domain Names in Applications (IDNA): Registry
Restrictions and Recommendations) to Proposed Standard

The IESG has received a request from an individual submitter to
consider the following document: - 'Internationalized Domain
Names in Applications (IDNA): Registry
   Restrictions and Recommendations'
  <draft-klensin-idna-rfc5891bis-04.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and
solicits final comments on this action. Please send substantive
comments to the [email-masked] mailing lists by 2019-08-30.
Exceptionally, comments may be sent to [email-masked] instead. In
either case, please retain the beginning of the Subject line to
allow automated sorting.

Abstract
   The IDNA specifications for internationalized domain names
combine    rules that determine the labels that are allowed in
the DNS without    violating the protocol itself and an
assignment of responsibility,    consistent with earlier
specifications, for determining the labels    that are allowed
in particular zones.  Conformance to IDNA by    registries and
other implementations requires both parts.  Experience
strongly suggests that the language describing those
responsibilities    was insufficiently clear to promote safe and
interoperable use of the    specifications and that more details
and discussion of circumstances    would have been helpful.
Without making any substantive changes to    IDNA, this
specification updates two of the core IDNA documents (RFC
5980 and 5891) and the IDNA explanatory document (RFC 5894) to
provide that guidance and to correct some technical errors in the
   descriptions.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-klensin-idna-rfc5891bis/

When IESG discussion has begun, it can be tracked via
https://datatracker.ietf.org/doc/draft-klensin-idna-rfc5891bis/b
allot/

No IPR declarations have been submitted directly on this I-D.

The document contains these normative downward references.
See RFC 3967 for additional information: 
    rfc5894: Internationalized Domain Names for Applications
(IDNA): Background, Explanation, and Rationale (Informational -
IETF stream)     rfc1591: Domain Name System Structure and
Delegation (Informational - Legacy stream)

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce

---------- End Forwarded Message ----------

---

From: "J-F C. Morfin" <[email-masked]>
Date: Sun, 04 Aug 2019 01:53:13 +0200

John,
all of us trust Patrick's and your competence and wiseness IRT iDNs. 
And thank you for your constant updating. However, I observe that the 
retained solution regularly calls for updates.
I am considering a polynym (strict lingual synonyms) oriented DDDS 
service (bigdata multilingual database labels for cross-origin data). 
A first idea is to build it on a similar basis as iDNs. However 
concerns are about Unicode stability over decades.
The need is for a string in any language returning the its polynym in 
any other language indicated by its langtag. Would you have a better 
suggestion? The project is to try to locate the service at a 
meditarean group of universities.
Best
jfc

At 23:15 02/08/2019, John C Klensin wrote:
>IDNA-UPDATE mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/idna-update

---

From: John C Klensin <[email-masked]>
Date: Sun, 04 Aug 2019 00:09:57 -0400

--On Sunday, August 4, 2019 01:53 +0200 "J-F C. Morfin"
<[email-masked]> wrote:

> John,
> all of us trust Patrick's and your competence and wiseness IRT
> iDNs. And thank you for your constant updating. However, I
> observe that the retained solution regularly calls for updates.

Thanks although more eyes --and different perspectives-- on this
stuff are always helpful.  Put differently, while I'm glad you
trust us, I don't :-(.  And it does indeed call for updates.

> I am considering a polynym (strict lingual synonyms) oriented
> DDDS service (bigdata multilingual database labels for
> cross-origin data). A first idea is to build it on a similar
> basis as iDNs. However concerns are about Unicode stability
> over decades.

First of all, if you are building a new system, you don't need
the baggage that IDNs/ IDNA are carrying around as the result of
the DNS not being well-designed for non-ASCII labels at the
beginning and of many legacy applications that are even less
well designed and implemented for those situations. 

> The need is for a string in any language returning the its
> polynym in any other language indicated by its langtag. Would
> you have a better suggestion? The project is to try to locate
> the service at a meditarean group of universities.

You are facing several problems.  One is Unicode itself.  As
"universal" coding systems goes, it is probably as good or
better than anything else we can easily imagine, but its design
and implementation involved design choices that are not optimal
for all purposes (or all languages and writing systems).  A
different system might do better for some of those choices, but
would almost certainly be worse for others.  That is one of the
reasons for the update problem: as long as new code points (or
at least new code points that are not symbols or otherwise
excluded from "words") are being added, some decisions about the
properties associated with code points are going to involve
tradeoffs and those tradeoffs may not be optimal for IDNs, for
your system, or for any other one with its own set of
constraints and desirable characteristics.   So, if one is going
to have strict stability and forward compatibility for
identifiers or other strings, especially if more than just code
point assignments are involved, regular review of properties and
property assignments would seem to be a requirement. If you can
define things so that all you care about is stability of the
code point assignments and binding to abstract characters
themselves, and you have no need to define or enforce
equivalence of different encodings of "the same" string or
character within that string, then there is probably no issue.

The second problem is one with which I believe you are familiar
because you've raised equivalent issues before in other
contexts.  While some technical terms that were invented only
very recently do work, there are many terms, both mononyms and
polynyms, for which exact and unique translations do not exist
or are controversial.  If you want to check that out further,
looking at the EUROVOC and AGROVOC multilingual controlled
vocabularies might be a start.  Those two examples are, however,
specialized vocabularies; more traditional multilingual thesauri
pose even more complex problems.

best,
    john'

---

From: Jaap Akkerhuis <[email-masked]>
Date: Mon, 05 Aug 2019 13:34:24 +0200

I'm fine with draft-klensin-idna-rfc5891bis-04.txt.

Nit: I couldn't help notice a typo on Page 3 where RFC 1501 is
mentioned while c;early 1591 is meant.

	jaap

---

From: John C Klensin <[email-masked]>
Date: Mon, 05 Aug 2019 09:54:57 -0400

> mentioned while c;early 1591 is meant.

Jaap,

Glad you couldn't help noticing.  I obviously didn't.  Fixed in
working copy.

thanks for catching that and thanks for the careful reading.

   john