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
- [dnssd] A concrete example of the Punycode fallba… Ilya Kulakov
- Re: [dnssd] A concrete example of the Punycode fa… Andrew Sullivan
- Re: [dnssd] A concrete example of the Punycode fa… manning bill
- Re: [dnssd] A concrete example of the Punycode fa… Andrew Sullivan
- Re: [dnssd] A concrete example of the Punycode fa… Douglas Otis
- Re: [dnssd] A concrete example of the Punycode fa… Andrew Sullivan
- Re: [dnssd] A concrete example of the Punycode fa… Douglas Otis
- Re: [dnssd] A concrete example of the Punycode fa… Andrew Sullivan
- Re: [dnssd] A concrete example of the Punycode fa… Stuart Cheshire