Re: [dnssd] A concrete example of the Punycode fallback variants for the <Domain> portion

Andrew Sullivan <ajs@anvilwalrusden.com> Mon, 16 December 2013 17:45 UTC

Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3521AE0B9 for <dnssd@ietfa.amsl.com>; Mon, 16 Dec 2013 09:45:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.141
X-Spam-Level:
X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vL4Uwj7NXhK5 for <dnssd@ietfa.amsl.com>; Mon, 16 Dec 2013 09:45:40 -0800 (PST)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id F19171AE0B5 for <dnssd@ietf.org>; Mon, 16 Dec 2013 09:45:39 -0800 (PST)
Received: from mx1.yitter.info (nat-08-mht.dyndns.com [216.146.45.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 084D88A031 for <dnssd@ietf.org>; Mon, 16 Dec 2013 17:45:38 +0000 (UTC)
Date: Mon, 16 Dec 2013 12:45:33 -0500
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dnssd@ietf.org
Message-ID: <20131216174533.GD1828@mx1.yitter.info>
References: <2966D8D9-16B5-4A95-97DC-606BB4338043@gmail.com> <20131215155347.GA65994@mx1.yitter.info> <81AD729F-6FA1-4290-8EEF-6F6333AA6638@isi.edu> <2831E050-956E-4A8F-832B-EA75A5165BCF@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <2831E050-956E-4A8F-832B-EA75A5165BCF@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dnssd] A concrete example of the Punycode fallback variants for the <Domain> portion
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Dec 2013 17:45:41 -0000

Hi,

I'm not sure I entirely understand your message.  But. . .

On Mon, Dec 16, 2013 at 09:07:31AM -0800, Douglas Otis wrote:
> 
> 1) Hostnames should be subjected to the same canonicalization to
> establish valid UTF-8 strings prior to conversion.  Bonjour already
> supports a means to override naming conflicts often seen as a
> prefixed number value (n).  Once proper canonicalization is applied,
> users may be required to adjust the hostname if unhappy with the
> results. 

When you say "the same canonicalization", what do you mean?  The DNS
owner names that result from RFC 6763 are in Net-Unicode (RFC 5198);
this entails NFC, but not much more.  The U-label portions of any
owner name arising from IDNA2008 have more restrictions -- most
punctuation is disallowed, upper case characters are not permitted
because they're not stable under case folding and NFKC, spaces are
disallowed, and so on.  This difference is why I suggested a common
interoperable profile (see draft-sullivan-dnssd-label-miprofile-00.
Stuart had some quibbles about the recommendations in there, but in
any case the recommendations are outside our charter.  I'm supposed to
pull out the problem statement part, which I guess I could be doing
rather than writing this mail).

> 2) There are two processes normally involved.  One is discovering
> services after selecting from a list of domains, and resolving
> services after selecting from a list of hostnames.  In each case,
> both of these presentations can be done using UTF-8 (provided proper
> canonicalization is applied.  Whether the label gets converted to an
> A-Label will depend on the selection of the domain.  

If I understand the above, you're suggesting that the user will know
how to cope with the issue.  Frankly, I think that is just naïve.
Users do not have a theory of operation of IDNA vs. plain UTF-8 labels
in the DNS, and subtle inconsistencies between them are going to be at
least mystifying and at worst opportunities for bad behaviour.

Best,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com