On 30 Mar 2017, at 14:10, The IESG <iesg-secretary(_at_)ietf(_dot_)org> wrote:
The IESG has received a request from the Extensions for Scalable DNS
Service Discovery WG (dnssd) to consider the following document:
- 'On Interoperation of Labels Among Conventional DNS and Other
<draft-ietf-dnssd-mdns-dns-interop-04.txt> as Informational RFC
Overall I think this document is very good.
Re-reading draft-04 today, I have a few minor comments.
Users and developers of applications are, of course, frequently
unconcerned with (not to say oblivious to) the name-resolution
system(s) in service at any given moment
Does “not to say” mean “not oblivious” or “oblivious”?
It would be clearer to say:
Users ... are, of course, frequently unconcerned with (but not oblivious to)
Users ... are, of course, frequently unconcerned with (or even oblivious to)
As a result, the same domain name might be tried using different name
Any given name may only be looked up using the single name resolution
technology appropriate for that name.
It might be clearer to say:
As a result, names entered into the same domain name slot might be resolved
using different name resolution technologies.
the global DNS is eventually likely to be implicated
The global DNS is already used for service discovery. Every time someone prints
at an IETF meeting using AirPrint to the Terminal Room printer, the global DNS
is being used. This is now, not the future.
How about just removing the word “eventually”?
In any case, if a given portion is implicated, the
profile will need to apply to all labels in that portion.
This is overly strict. It’s not necessarily all-or-nothing. The <Domain>
portion of the Service Instance Name may require mixed handling. Consider the
Service Instance Name:
Public Printer._ipp._tcp.3rd Floor.café.com.
The <Instance> portion, “Public Printer”, is UTF-8.
The <Service> portion, “_ipp._tcp”, is plain ASCII, and uncomplicated.
The <Domain> portion is mixed.
“3rd Floor” has a space, and has to be UTF-8.
But “café.com” is actually registered as “xn--caf-dma.com” and has to be
converted as such.
Fortunately the iterative algorithm described in RFC 6763, and implemented and
shipping in Apple products and the Open Source mDNSResponder code, handles
this. So, while this may appear to be a problem, it is in fact a solved problem.
some recommendations from [RFC6763] will not really be possible to implement
Can you elaborate on what recommendations are not possible to implement?
many labels in the <Domain> part of a Service Instance Name are
unlikely to be found in the UTF-8 form in the public DNS tree
Saying “unlikely” is too strong. An administrator who wants spaces or similar
exotic Unicode characters in a service discovery domain name will have to use
UTF-8 for that name, even if host names in the same zone use Punycode. And this
is not hard to do. You simply edit the zone file using a UTF-8-capable text
editor, and type in the desired UTF-8 text. Name servers such as ‘named’ will
happily serve that zone. The name server itself doesn’t need to be
UTF-8-capable in any way. It just acts on the bytes in the zone file, without
attempting to interpret how humans will perceive those bytes.
mDNS normally uses UTF-8.
mDNS exclusively uses UTF-8.
As a practical matter, this
likely means special-purpose name resolution software for DNS-SD.
This reads as if it’s talking about some hypothetical future. This
special-purpose name resolution software is already used for service discovery,
and has been since Mac OS X 10.2 in 2002. This special-purpose name resolution
software, and its APIs, is on Apple products, Microsoft Windows, Linux, and
Android. So, again, this text is describing a non-problem. It’s like text
warning against using JPEG as an image format in 2017, because JPEG images
require “special-purpose JPEG image decoding software”, at a time when all
major platforms have had JPEG image decoding software for many years.
DNS-SD implementations ought somehow to identify the <Domain> portion of
the Service Instance Name and treat it subject to IDNA2008 in case the
domain is to be queried from the global DNS. In the event that the
<Domain> portion of the Service Instance Name fails to resolve, it is
acceptable to substitute labels with plain UTF-8, starting at the
lowest label in the DNS tree and working toward the root. This
approach differs from the rule for resolution published in [RFC6763],
because it privileges IDNA2008-compatible labels over UTF-8 labels.
If we want to recommend this change in behavior, I think this document is the
wrong place to do it.
RFC 6763 is a published Standards-Track specification. For good or bad, it went
though thorough lengthy review, and is a result of the IETF consensus process.
I think it’s confusing to have an Informational RFC that appears to update a
Standards-Track RFC. Should an implementer follow RFC 6763 because it’s a
Standards-Track specification and this document is merely Informational, and
doesn’t say, “Updates: RFC 6763”? Or should an implementer follow this document
because it’s newer and therefore is assumed to supersede any text found in
older Standards-Track RFCs?
RFC 6763 specifies an iterative algorithm that is implemented, and in use, and
appears to work. Overturning that specification should require careful scrutiny
and Standards-Track action. In 2017, does the IETF want to be encouraging
movement towards UTF-8 as the universal encoding for everything, or encouraging
continued diversification into “every protocol invents its own different
incompatible encoding for international text”?
The first of these is rejected because it represents a potentially
significant increase in DNS lookup traffic for no value.
I request removing the value judgement “for no value”.
The value of using UTF-8 is that it is both more compact and more expressive
An issue with the first of these is that it represents a potentially
significant increase in DNS lookup traffic.
it is unlikely that the UTF-8 version of the zone will be delegated from
This is circular logic. An administrator using a UTF-8 zone *will* make sure
that UTF-8 zone is accessible, or there’s no point having it. This could be
done by delegation, but need not be. Subdomains don’t have to be delegated --
subdomains can exist in a single zone. Not all subdomain boundaries need to be
zone cuts, and many are not.