Subject: [Idna-update] Question about ℀

From: Shawn Steele <[email-masked]>
Date: Wed, 8 Aug 2018 00:21:27 +0000

For characters like ℀, would it be permissible to disallow them in the mapping step?  Currently the tables allow mapping ℀ to a/c, which is obviously not very great behavior since / is illegal in DNS.

USE_STD3_ASCII_RULES would clearly stomp out things like this, but it seems to me that it doesn’t really make sense to map these characters at all.

Am I missing some scenario?  Is there already a known list of this type of problematic characters somewhere?  (I can figure it out, but it doesn’t hurt to double check.)

-Shawn

 
http://blogs.msdn.com/shawnste

---

From: John C Klensin <[email-masked]>
Date: Tue, 07 Aug 2018 21:18:53 -0400

Shawn,

I can't figure out what you are talking about.

For starters, the text/plain (first) body part of your message
shows up here identified as 
  text/plain charset=UTF-8
(and is transmitted in Base64.  That should be fine because my
system handles plain text messages with that charset just fine.
However, what I see instead of whatever you intended (I'm
assuming U+2100) is the traditional little box (which you
probably see below).  

Then there is no USE_STD3_ASCII_RULES (or even
UseSTD3ASCIIRules, which is what appears in RFC 3490) flag in
IDNA2008, even in RFC 5895.   As far as IDNA2008 is concerned,
U+2100 has General Property So, which causes it to be DISALLOWED
for use in domain names, no "mapping step" (whatever that is)
needed or relevant.  Partially because of that, I don't know
what "the tables" you are referring to.

There is a "known list of this type of problematic characters",
but it is a subset, not identified separately, of the set of
characters that IDNA2008 classifies as DISALLOWED.  It includes
everything with General Property So including, notoriously, all
of the emoji.

So I either don't know what you are talking about, or you are
asking either about the preferred way to violate the standards
that the IETF has approved or how to conform to someone else's
standard.  For either of the latter, this may not be the right
place to ask.

best,
   john

--On Wednesday, August 8, 2018 00:21 +0000 Shawn Steele
<Shawn.Steele=[email-masked]> wrote:

> For characters like ℀, would it be permissible to disallow
> them in the mapping step?  Currently the tables allow mapping
> ℀ to a/c, which is obviously not very great behavior since /
> is illegal in DNS.
> 
> USE_STD3_ASCII_RULES would clearly stomp out things like this,
> but it seems to me that it doesn't really make sense to map
> these characters at all.
> 
> Am I missing some scenario?  Is there already a known list of
> this type of problematic characters somewhere?  (I can figure
> it out, but it doesn't hurt to double check.)

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 8 Aug 2018 07:31:06 +0200

> On 8 Aug 2018, at 02:21, Shawn Steele <Shawn.Steele=[email-masked]> wrote:
> 

There are no tables talking about mapping since IDNA2003. IDNA2008 do allow mapping before IDNA2008 rules actually are applied, and what mappings you apply is context and application dependent. So I am confused about what you mean by “tables”. Further, if the code point you refer to is U+2100 its derived property value according to IDNA2008 is DISALLOWED.

    Patrik

---

From: Shawn Steele <[email-masked]>
Date: Wed, 8 Aug 2018 16:32:32 +0000

Sorry, my misunderstanding and apparently a poor web punycode form I found online :)

-Shawn

-----Original Message-----
From: John C Klensin <[email-masked]> 
Sent: Tuesday, August 7, 2018 6:19 PM
To: Shawn Steele <[email-masked]>; [email-masked]
Subject: Re: [Idna-update] Question about ℀

Shawn,

For starters, the text/plain (first) body part of your message shows up here identified as
  text/plain charset=UTF-8
(and is transmitted in Base64.  That should be fine because my system handles plain text messages with that charset just fine.
However, what I see instead of whatever you intended (I'm assuming U+2100) is the traditional little box (which you probably see below).  

Then there is no USE_STD3_ASCII_RULES (or even UseSTD3ASCIIRules, which is what appears in RFC 3490) flag in
IDNA2008, even in RFC 5895.   As far as IDNA2008 is concerned,
U+2100 has General Property So, which causes it to be DISALLOWED
for use in domain names, no "mapping step" (whatever that is) needed or relevant.  Partially because of that, I don't know what "the tables" you are referring to.

There is a "known list of this type of problematic characters", but it is a subset, not identified separately, of the set of characters that IDNA2008 classifies as DISALLOWED.  It includes everything with General Property So including, notoriously, all of the emoji.

So I either don't know what you are talking about, or you are asking either about the preferred way to violate the standards that the IETF has approved or how to conform to someone else's standard.  For either of the latter, this may not be the right place to ask.

best,
   john

--On Wednesday, August 8, 2018 00:21 +0000 Shawn Steele <Shawn.Steele=[email-masked]> wrote:

> For characters like ℀, would it be permissible to disallow them in the 
> mapping step?  Currently the tables allow mapping ℀ to a/c, which is 
> obviously not very great behavior since / is illegal in DNS.
> 
> USE_STD3_ASCII_RULES would clearly stomp out things like this, but it 
> seems to me that it doesn't really make sense to map these characters 
> at all.
> 
> Am I missing some scenario?  Is there already a known list of this 
> type of problematic characters somewhere?  (I can figure it out, but 
> it doesn't hurt to double check.)