[UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt

Mon Mar 13 13:22:52 UTC 2017

To avoid the conflict, I could imagine a transaction like:

"Your requested domain name Q has been identified as one likely to cause user confusions due to its mix of characters and character sets. (See our Confusables Policy, here).   As a result, ownership of this domain name must be bundled with the following additional domain names:
X
Y
Z
This bundle of domain names is available for the low price of $$.
Unfortunately, we are not able to offer the domain name Q separately from this bundle. If you are not interested in this bundle, might we suggest the following alternatives:
H
J
K
Thanks."

-----Original Message-----
From: nalini.elkins at insidethestack.com [mailto:nalini.elkins at insidethestack.com] 
Sent: Monday, March 13, 2017 1:35 PM
To: Shawn Steele <Shawn.Steele at microsoft.com>; Richard Merdinger <rmerdinger at godaddy.com>; Edmon Chung <edmon at registry.asia>; UA-discuss at icann.org; Mark Svancarek <marksv at microsoft.com>
Subject: Re: [UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt

>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