[UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt
nalini.elkins at insidethestack.com
nalini.elkins at insidethestack.com
Mon Mar 13 12:35:08 UTC 2017
>Pretty much all of the concerns regarding the character repertoire can be resolved and the registrar level if the registrars would ensure that they did not allow registrations of multiple domain variations that >might confuse their users. Or if they bundled those registrations.
There is a potential conflict of interest here. Registries want to sell as many domains as they can as that is how they make money.
Thanks,
Nalini Elkins
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360
From:
Shawn
Steele
Sent:
3/12/2017 7:33
PM
To:
Richard
Merdinger;
Edmon
Chung;
Mark Svancarek; UA-discuss at icann.org
Subject:
RE: [UA-discuss] FW: I-D Action:
draft-klensin-idna-rfc5891bis-00.txt
My concern is John’s emphasis on
creating very restrictive character rule sets.
The most restrictive rules created
by IDNA2008 have been ignored because of user demand and
backwards compatibility. Eg: no-emoji in labels.
People want emoji, but IDNA2008
doesn’t permit it. Part of that is compatibility
with the permitted IDNA2003 emoji, however there has also
been demand for emoji characters newly added to
Unicode.
I think that it is appropriate to
remind registrars that they are responsible for creating
sane rules for their spaces, but it is clear that users do
not want to be tied to
the most restrictive demands of IDNA2008.
Implementations appear to be settling on the Unicode
provided idna data and I would much prefer to see the IETF
standards point to the IDNA character sets provided by
Unicode (while still encouraging registrars to
do sane things that make sense for their
domains).
A good example of something a
registrar might want to consider could be something like
ü. Some spaces may allow ü without much restriction,
however for .de, .ch, .at, etc.
it might make sense to recognize that ü has an alternate
ue spelling and to provide bundling or blocking of domains
like müller.ch and mueller.ch. That kind of rule is
very domain/language specific. Though it is not called
out as some of the bidi rules are,
the RFCs allow registrars to implement such a policy if it
fits their purposes. Of course many other behaviors
are called out by the IDNA2008 rules.
Pretty much all of the concerns
regarding the character repertoire can be resolved and the
registrar level if the registrars would ensure that they did
not allow registrations
of multiple domain variations that might confuse their
users. Or if they bundled those
registrations.
-Shawn
From: Richard Merdinger
[mailto:rmerdinger at godaddy.com]
Sent: Saturday, March 11, 2017 11:35 PM
To: Edmon Chung <edmon at registry.asia>; Mark
Svancarek <marksv at microsoft.com>;
UA-discuss at icann.org
Cc: Shawn Steele <Shawn.Steele at microsoft.com>
Subject: Re: [UA-discuss] FW: I-D Action:
draft-klensin-idna-rfc5891bis-00.txt
Agree, thanks for forwarding
Mark This was a very cogent statement of affairs
relative to the closing out of known IDN issues (or our
current inability to do so).
I agree with Edmon in that I think
the UA effort should strive to be a catalyst
here.
--Rich
From:
<ua-discuss-bounces at icann.org>
on behalf of Edmon Chung <edmon at registry.asia>
Date: Sunday, March 12, 2017 at 7:11 AM
To: 'Mark Svancarek' <marksv at microsoft.com>,
"UA-discuss at icann.org"
<UA-discuss at icann.org>
Cc: 'Shawn Steele' <Shawn.Steele at microsoft.com>
Subject: Re: [UA-discuss] FW: I-D Action:
draft-klensin-idna-rfc5891bis-00.txt
Thanks for forwarding this
Mark,
This seems to be something useful
for UA, perhaps we should work with the IDN team at ICANN
(along with the communities networked from the LGR work) to
see where we can best support.
Edmon
-----Original Message-----
From:
ua-discuss-bounces at icann.org [mailto:ua-discuss-bounces at icann.org]
On
Behalf Of Mark Svancarek via
UA-discuss
Sent: Sunday, 12 March 2017 12:58
PM
To:
UA-discuss at icann.org
Cc: Shawn Steele <Shawn.Steele at microsoft.com>
Subject: [UA-discuss] FW: I-D
Action: draft-klensin-idna-rfc5891bis-00.txt
FYI, too much stuff from John for
me to dig into this a.m.
-----Original Message-----
From: Idna-update [mailto:idna-update-bounces at alvestrand.no]
On Behalf Of John
C Klensin
Sent: Saturday, March 11, 2017
8:25 AM
To:
idna-update at alvestrand.no
Subject: FWD: I-D Action:
draft-klensin-idna-rfc5891bis-00.txt
Hi.
For the information of those who
may be watching this list but not the IETF
announcement one...
Asmus Freytag and I have started
to put together a draft that addresses a problem
with the IDNA2008 specs,
specifically that we failed to make the responsibility
of
registries to define code point
and label acceptability rules that were considerably
more narrow (and better understood
by them) than the full set of labels allowed by
RFC 5891-5893. It
doesn't actually change anything because that
requirement is in
the existing specs; it just makes
(or tries to make) the requirements painfully clear to
those who have been missing or
misreading them.
It also provides an explicit link
between IDNA2008 requirements and ICANN work on
repertoires and label generation
rules without endorsing that work as more than one
thoughtful approach that might be
examined for either reference or inspiration.
Comments (obviously) welcome.
For anyone who might wonder, this
document avoids the more controversial
IDNA2008 issues including:
* Multiple suggestions that we
should add emoji, a subset of code points with
General Category "So",
to the list of code
points allowed by
IDNA. There are many reasons to not do that
but it seems clear that, at some
point, the IETF will need to either document those
reasons or make the
change. Volunteers to put together or work on a
document
would be welcome.
* The non-decomposing code point
problem, formerly (and
incorrectly) known as the Hamza
problem. There has been no
discernable activity on this since
the IAB Statement and LUCID BOF almost exactly
two years ago. I've
further updated the working copy of
draft-klensin-idna-5892upd-
unicode70 to cover additional
cases and issues, but, in part because it is clearly
inappropriate for a quick-patch
individual submission, have been advised to not post
it until we have a plan to make
progress.
So far, there is no such plan.
* The (IMO, growing) problem of
multiple and inconsistent specifications for IDNs
and IDN handling, with different
ones being used in different higher-level protocols
and areas of the
Internet. The use of different specifications and
definitions creates
opportunities for user and
implementer confusion, interoperability difficulties,
domain
names that cannot be resolved
under some circumstances, and various sorts of
attacks.
The specifications involved
include IDNA2008, IDNA2003, assorted local
"updates"
to IDNA2003 that use versions of
Stringprep locally updated to assorted versions of
Unicode, and the various versions
of UTR#46. The latest version of the latter
explicitly
allows emoji along with other
symbols. A few months ago, I
suggested to the IAB I18N program
that a document be produced that at least
pointed out the problems
associated with multiple divergent specifications, but
the
idea got no traction.
It appears to me that, although
almost everyone agrees that IDNs, and well- and
clearly-functional IDNs, are
important, virtually no one is willing to do the hard
work,
at least unless they are being
supported by ICANN (disclosure: I am not) or
organizations whose interests lie
in selling names, preferably as many of them as
possible (I have no support from
any of them either). Until and unless that
changes,
I don't see much prospect for
getting those other issues addressed in a way that
might lead to consensus
documents.
john
---------- Forwarded Message
----------
Date: Saturday, March 11, 2017
07:22 -0800
From:
internet-drafts at ietf.org
To:
i-d-announce at ietf.org
Subject: I-D Action:
draft-klensin-idna-rfc5891bis-00.txt
A New Internet-Draft is available
from the on-line Internet-Drafts directories.
Title
: Internationalized Domain Names in
Applications (IDNA): Registry
Restrictions and Recommendations
Authors
: John C Klensin
Asmus Freytag
Filename :
draft-klensin-idna-rfc5891bis-00.txt
Pages
: 10
Date :
2017-03-11
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
responsibility was
insufficiently clear to promote safe and
interoperable use of
the specifications and that more
details
and some specific examples
would have been
helpful. This
specification updates the earlier
ones to provide that
guidance and to correct some
technical errors in the descriptions. It does not
alter
the protocols and rules
themselves in
any way.
The IETF datatracker status page
for this draft is:
https://datatracker.ietf.org/doc/draft-klensin-idna-rfc5891bis/
There's also a htmlized
version available at:
https://tools.ietf.org/html/draft-klensin-idna-rfc5891bis-00
Please note that it may take a
couple of minutes from the time of submission until
the htmlized version and diff are
available at tools.ietf.org.
Internet-Drafts are also available
by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
I-D-Announce mailing list
I-D-Announce at ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories:
http://www.ietf.org/shadow.html or
ftp://ftp.ietf.org/ietf/1shadow-sites.txt
---------- End Forwarded Message
----------
_______________________________________________
Idna-update mailing list
Idna-update at alvestrand.no
http://www.alvestrand.no/mailman/listinfo/idna-update
More information about the UA-discuss
mailing list