Re: [dnssd] Partial review of draft-ietf-dnssd-mdns-dns-interop-04

Tim Chown <> Tue, 14 March 2017 17:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E80CC1329C6 for <>; Tue, 14 Mar 2017 10:17:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZJBoyUxkeVSO for <>; Tue, 14 Mar 2017 10:17:40 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2B0E11329C3 for <>; Tue, 14 Mar 2017 10:17:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mimecast20170213; t=1489511858; bh=rUQ/45XPuchdykRgAQizvcwyzml9OxVjQrNwtnP0p6c=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=U3p7hY6fupY2BTlRyboeHUE4JcpbshSZ2f2OnJckL9t76brViKgwCrlg1X+boQD6MxMH1rD2PCHT+uRNLm3tcwJXbQi4s12zJPxLwNdtHGMl1AjjgqzDFXuhwL752bxGo4N5imQstRf2bIT/bpW/uvKT8OOXonntG3fzkUKEEr8=
Received: from ( []) (Using TLS) by with ESMTP id uk-mta-63-POq7Ns0HN1yKQuKztN0_8A-1; Tue, 14 Mar 2017 17:17:34 +0000
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Tue, 14 Mar 2017 17:17:33 +0000
Received: from ([fe80::59f7:b9fe:6ca:9476]) by ([fe80::59f7:b9fe:6ca:9476%14]) with mapi id 15.01.0977.010; Tue, 14 Mar 2017 17:17:32 +0000
From: Tim Chown <>
To: Juergen Schoenwaelder <>
CC: Andrew Sullivan <>, ops-dir <>, "" <>, "" <>
Thread-Topic: Partial review of draft-ietf-dnssd-mdns-dns-interop-04
Thread-Index: AQHSmAbyl0qojN3MA0i/ibIoNwSKcqGLFdSAgAYA1YCAA4cEAA==
Date: Tue, 14 Mar 2017 17:17:32 +0000
Message-ID: <>
References: <> <> <20170312112531.GC50035@elstar.local>
In-Reply-To: <20170312112531.GC50035@elstar.local>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-mailer: Apple Mail (2.3259)
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1137; 7:T1KazxERbqUu3rzGmIaAqATPGhpZ7ktfezNiPUxx+UGz5C1TFU/aBfvVI/f4kFHXgGQSCV3RmLem+Exuf6zG30NM4USCJWp6kquyXVIQUnTU9OXSyubv3whFKRA+lc+K+No+ahQbfpFApi/vfwe9zTLz1cRHiOQCsBj4FTG11CKLq89mvEKbbNCE0FnY5g4060ao+UtfFw8ydwnZld2GIrfXeK5bBuTJHWUBfKLTftQ9Mn664pmhVqAD9yuU2DG5oMVKWt/55vSQhezitJcUfZJYv4ZcQrC3V6Yv6jyWxKkUTbVlEhWrFrawDhqimo4JRZdgpZwcOrXuz/5L13ueZw==; 20:1N5wwGPawcAJN86wE3ILW0dHgc1/zWCRPIqaJxEZ1SVk1Qiu4p0pEUkCAj58sT2uVERdPWrXIIQ+xnV17eJ0dTYNbO3AxXv5waCaaDH10boASmkWH0OeCAnCQgwwuFlls+D5QgBeLdIIqYHsICiWusosVWGlJgatMBBAWo7rnxA=
x-ms-office365-filtering-correlation-id: 67d920bd-1410-4af8-a74e-08d46afe008d
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM3PR07MB1137;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123558025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:AM3PR07MB1137; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1137;
x-forefront-prvs: 02462830BE
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(51444003)(24454002)(51914003)(8936002)(54906002)(3846002)(189998001)(3660700001)(3280700002)(106116001)(99286003)(81166006)(5660300001)(2906002)(4326008)(6512007)(8676002)(86362001)(229853002)(102836003)(2900100001)(50226002)(57306001)(230783001)(33656002)(7736002)(82746002)(6246003)(38730400002)(6116002)(6916009)(6436002)(83716003)(42882006)(74482002)(2950100002)(6486002)(36756003)(76176999)(50986999)(53936002)(53546007)(305945005)(6506006)(66066001)(110136004)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1137;; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: <>
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2017 17:17:32.7061 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1137
X-MC-Unique: POq7Ns0HN1yKQuKztN0_8A-1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
Archived-At: <>
Subject: Re: [dnssd] Partial review of draft-ietf-dnssd-mdns-dns-interop-04
X-Mailman-Version: 2.1.21
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 14 Mar 2017 17:17:42 -0000


> On 12 Mar 2017, at 11:25, Juergen Schoenwaelder <> wrote:
> Andrew,
> your response is helpful for me to understand things better. The
> situation indeed seems complicated.

The discussion below is useful, and I suspect many people will have similar comments to Juergen's. One question is therefore whether additional or different wording would help better set the context of the document. I think the meat of the text is good, and Andrew has done a great job in pulling together the input that’s been made, but we’ve been staring at it for some time now in dnssd, and are perhaps overly familiar with it. 

Any suggestions are very welcome!

> On Wed, Mar 08, 2017 at 10:44:59AM -0500, Andrew Sullivan wrote:
>> Hi,
>> Thanks for the review.  I think there is an issue here that is
>> apparently not clear enough to you as a reader, so it's really helpful
>> to learn that.  I'd like to figure out how to make it clearer.
>> On Wed, Mar 08, 2017 at 04:24:25AM -0800, Jürgen Schönwälder wrote:
>>> Disclaimer: I regret that DNS does not use UTF-8 in its labels, to me
>>> , as an outside observer, it seems IDNA was a big mistake. But given
>>> the IETF standards we have, it seems one has to properly IDNA encode
>>> UTF-8 in DNS labels. 
>> This isn't exactly correct, and I think that it may be the source of
>> the problem you had with the document.
>> DNS as such makes literally no restrictions on what "characters" can
>> appear in a label, except for length.  A label can have 63 octets.
>> Any octet is permitted.  Perhaps unfortunately, however, in the
>> original specification ASCII was treated specially in two ways.
>> First, labels are matched "case insensitively" in ASCII.  Second, STD
>> 13 recommended the letter,digit,hyphen rule for labels to maximise
>> compatibility with deployed hostnames.  Because STD 13 was written
>> before RFC 2119 keywords were in use, the distinctions among good
>> operational practice and protocol restrictions was not always clear to
>> every reader, so many people understood LDH to be a DNS restriction,
>> but it wasn't.
> This was clear to me since I am well aware that the DNS protocol ships
> octets.
>> Apart from the special treatment of ASCII, DNS also makes no rules
>> about character sets.  So, there's no way to tell, for a given label,
>> what its encoding scheme is -- UTF-8, JIS, ISO-8859-n, or what all.
> Yes, but historically (if I understand things right), the character
> set was effectively restricted to LDH (ASCII) - the restriction was
> not part of the protocol but imposed by other 'recommendations'.
>> It is because of the above that we ended up with IDNA.  Nothing about
>> IDNA prevents other schemes for labels (including using characters
>> outside the ASCII range).  The possibilities are discussed at some
>> length in RFC 6055.
> With a time machine available, we should probably have moved from LDH
> (ASCII) to UTF-8 (or a subset of UTF-8). Multiple different character
> _encodings_ in the label space can't really be a feature. Note that I
> consider further restrictions (i.e., use of white space) something
> separate from the encoding scheme used.
> I think I recall that people said back in a day that moving from LDH
> to UTF-8 may be risky since we do not know whether all DNS
> implementations got the "DNS ships octets" thing right. And there may
> be situations where entering a UTF-8 name correctly may not be
> feasible on certain devices. Looking back in time, these may have been
> valid concerns back then but they are likely less so today and instead
> of having a transition plan to have UTF-8 encoded labels we went for a
> solution that gives us complexity forever. [And yes, I do not know all
> the details of the discussions and so I am likely summarizing things
> up very wrongly.] But from an outsider perspective, it seems that
> having (i) a transition plan to UTF-8 encoding of labels and (ii) a
> clear separation of further label restrictions from the encoding
> aspects would have been desirable.
>> At the same time, we know that the root zone and a very large number
>> of TLDs (maybe all, but I bet not) restrict delegations to LDH, and
>> that they use some variation of IDNA (including non-IETF IDNA variants
>> based on UTS#46 -- this is how some TLDs allow registering emoji,
>> since they weren't "emoji" when IDNA2003 came out and many of the code
>> points were undefined under Unicode 3.2.  Emoji are DISALLOWED under
>> IDNA2008 because they're not "letters or digits" in any writing
>> system).  So, given the distributed administration of the DNS, there
>> is no way to be sure how a given octet sequence ought to be
>> interpreted, but we can be fairly sure that some administrators of
>> some zones will definitely not permit UTF-8 labels in their zones.
> Well, obviously, this is the clunky result we have now.
>> This is the problem the I-D is intending to highlight, and it sounds
>> like it wasn't clear to you.  Is any of the above clearer?  Would any
>> more introductory material help to make this plain?
> For me personally, it would have been good to know more about what is
> out there. I understand traditional LDH labels and I understand
> IDNA2003 and IDNA2008 labels. I understand that mDNS says UTF-8 and
> pretty much no restrictions on instance portion of a service name.
> Are there significant deployments out there that use other encodings
> or restrictions?
>>> would that be? I looked up RFC 6055 and I am surprised to read text
>>> about 'intelligent (stub) resolver' there as this seems to be asking
>>> for trouble. 
>> Yes :) That's the trouble I think we're in, and it's why I worked on
>> this I-D in the first place.
>>> To me, it sounds like you are saying 'some portions of
>>> the name hierarchy may use raw UTF-8 labels while other portions may
>>> not and we do not tell you how to set them appart in a reliable
>>> way'. If this is the approach, then the approach is in my personal
>>> view broken. (And please recall the disclaimer above.)
>> It may be broken, but it is the reality in a distributed system with
>> distributed administration.  One cannot make rules about what other
>> people put in their zones, and the DNS is already clear that any octet
>> at all is permitted in the DNS.
> The protocol ships octets. The question is how to interpret them. If
> there would be agreement that the octets by default represent UTF-8
> encoded characters life would start to be somewhat simpler. This would
> solve the encoding part, it does not solve the 'which restrictions
> apply to this label part'. OK, I am ignorant of the complexity of
> deploying this but a decent transition plan to something simpler may
> be better long term than more layeres of things that do not play well
> together.
>>> In section 3, what does the term 'implicated' mean?
>> Would "involved" make it clearer to you?  The point is that different
>> portions of a DNS-SD name have different properties, and only some of
>> those are going to have potentially ambiguous i18n encodings in the
>> DNS.  

Perhaps “included” works better than “implicated", but that’s pure personal preference.

>>> What I do not understand: Why is it desirable to treat DNS labels
>>> that
>>> carry DNS-SD Service Instance Names different than any other labels
>>> that may contain UTF-8 characters? 
>> Because DNS-SD says that the labels should be raw UTF-8 in the DNS,
>> and because of IDNA some zones have a policy where raw UTF-8 is not
>> permitted (and some resolvers may automatically convert U-labels to
>> A-labels).
> Yes, sounds like a decent conflict asking for surprises.

Best wishes,
Tim (dnssd co-chair)