One document matched: draft-ietf-dnssd-mdns-dns-interop-03.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- NOTE: you need ekr's bibxml2rfc to use this XML file. -->
<!-- processing instructions (for a complete list and description,
see file http://xml.resource.org/authoring/README.html -->
<!-- try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>
<!-- items used when reviewing the document -->
<?rfc comments="yes" ?> <!-- controls display of <cref> elements -->
<?rfc inline="yes" ?> <!-- when no, put comments at end in comments section,
otherwise, put inline -->
<?rfc editing="no" ?> <!-- when yes, insert editing marks -->
<!-- create table of contents (set it options).
Note the table of contents may be omitted
for very short documents -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<!-- choose the options for the references. Some like
symbolic tags in the references (and citations)
and others prefer numbers. -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<!-- these two save paper: start new paragraphs from the same page etc. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of processing instructions -->
<!-- Information about the document.
categories values: std, bcp, info, exp, and historic
For Internet-Drafts, specify attribute "ipr".
(ipr values are: full3667, noModification3667, noDerivatives3667),
Also for Internet-Drafts, can specify values for
attributes "iprExtract", and "docName". Note
that the value for iprExtract is the anchor attribute
value of a section that can be extracted, and is only
useful when the value of "ipr" is not "full3667". -->
<!-- TODO: verify which attributes are specified only
by the RFC editor. It appears that attributes
"number", "obsoletes", "updates", and "seriesNo"
are specified by the RFC editor (and not by
the document author). -->
<rfc
category="info"
ipr="trust200902"
docName="draft-ietf-dnssd-mdns-dns-interop-03"
>
<front>
<title abbrev="Multi-resolution Interop">On Interoperation of
Labels Among Conventional DNS and Other Resolution Systems</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author
fullname="Andrew Sullivan"
initials="A. J."
surname="Sullivan">
<!-- abbrev not needed but can be used for the header
if the full organization name is too long -->
<organization abbrev="Dyn">Dyn</organization>
<address>
<postal>
<street>150 Dow St.</street>
<city>Manchester</city>
<region>NH</region>
<code>03101</code>
<country>U.S.A.</country>
</postal>
<email>asullivan@dyn.com</email>
</address>
</author>
<date /> <!-- month="May" is no longer necessary
note also, day="30" is optional -->
<!-- <area>Internet</area> -->
<!-- WG name at the upperleft corner of the doc,
IETF fine for individual submissions -->
<workgroup>DNSSD</workgroup>
<abstract>
<t>Despite its name, DNS-Based Service Discovery can use naming
systems other than the Domain Name System when looking for
services. Moreover, when it uses the DNS, DNS-Based Service
Discovery uses the full capability of DNS, rather than using a
subset of available octets. In order for DNS-SD to be used
effectively in environments where multiple different name systems
and conventions for their operation are in use, it is important to
attend to differences in the underlying technology and operational
environment. This memo presents an outline of the requirements
for selection of labels for conventional DNS and other resolution
systems when they are expected to interoperate in this manner.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>DNS-Based Service Discovery (DNS-SD, <xref target="RFC6763" />)
specifies a mechanism for discovering services using queries to
the Domain Name System (DNS, <xref target="RFC1034" />, <xref
target="RFC1035" />); and to any other system that uses domain
names, such as Multicast DNS (mDNS, <xref target="RFC6762" />).
Many applications that use the DNS follow "Internet hostname"
syntax <xref target="RFC0952" /> for labels -- the so-called LDH
rule. That convention is the reason behind the development of
Internationalized Domain Names for Applications (IDNA2008, <xref
target="RFC5890" />, <xref target="RFC5891" />, <xref
target="RFC5892" />, <xref target="RFC5893" />, <xref
target="RFC5894" />, <xref target="RFC5895" />). It is worth
noting that the LDH rule is a convention, and not a rule of the
DNS; this is made entirely plain by <xref target="RFC2181" />,
section 11, and discussed further in <xref target="RFC6055" />, section 3.
Nevertheless, there is a widespread belief that in many
circumstances domain names cannot be used in the DNS unless they
cleave to the LDH rule.</t>
<t>At the same time, mDNS requires that labels be encoded in UTF-8,
and permits a range of characters in labels that are not permitted
by IDNA2008 or the LDH rule. For example, mDNS encourages the use of
spaces and punctuation in mDNS names (see <xref target="RFC6763" />,
section 4.1.3). It does not restrict which Unicode code points may
be used in those labels, so long as the code points are UTF-8 in
Net-Unicode <xref target="RFC5198" /> format.</t>
<t>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, and are inclined simply
to use the same domain names in different contexts. As a result,
the same domain name might be tried using different name
resolution technologies. If a given name will not work across the
various environments, then user expectations are likely to be best
satisfied when at least some parts of the domain names to be
queried are compatible with the rules and conventions for all the
relevant technologies. Given the uses of DNS-SD, a choice for
such compatibility likely lies with the application designer or
service operator.</t>
<t>One approach to interoperability under these circumstances is
to use a single operational convention (a "profile") for domain
names under the different naming systems. This memo assumes such
a use profile, and attempts to outline what is necessary to make
it work without specifying any particular technology. It does
assume, however, that the global DNS is eventually likely to be
implicated. Given the general tendency of all resolution
eventually to fall through to the DNS, that assumption does not
seem controversial.</t>
<t>It is worth noting that users of DNS-SD do not use the service
discovery names in the same way that users of other domain names
might. In many cases, domain names can be entered as direct user
input. But the service discovery context generally assumes users
are picking a service from a list. As a result, the sorts of
application considerations that are appropriate to the
general-purpose DNS name, and that resulted in the A-label/U-label
split (see below) in IDNA2008, are not entirely the right approach
for DNS-SD.</t>
<section title="Conventions and terms used in this document">
<t>Wherever appropriate, this memo uses the terminology defined
in Section 2 of <xref target="RFC5890" />. In particular, the
reader is assumed to be familiar with the terms "U-label", "LDH
label", and "A-label" from that document. Similarly, the reader
is assumed to be familiar with the U+NNNN notation for Unicode
code points used in <xref target="RFC5890" /> and other documents
dealing with Unicode code points. In the interests of brevity
and consistency, the definitions are not repeated here.</t>
<t>Sometimes this memo refers to names in the DNS as though the
LDH rule and IDNA2008 are strict requirements. They are not.
DNS labels are, in principle, just collections of octets, and
therefore in principle the LDH rule is not a constraint. In
practice, applications sometimes intercept labels that do not
conform to the LDH rule and apply IDNA and other
transformations.</t>
<t>The DNS, perhaps unfortunately, has produced its own jargon.
Unfamiliar DNS-related terms in this memo should be found in
<xref target="RFC7719" />.</t>
<t>The term "owner name" (common to the DNS vernacular; see
above) is used here to apply not just to the domain names to be
looked up in the DNS, but to any name that might be looked up
either in the DNS or using another technology. It therefore
includes names that might not actually exist anywhere. In
addition, what follows depends on the idea that not every domain
name will be looked up in the DNS. For instance, names ending
in "local." (in the presentation format) are not ordinarily
looked up using DNS, but instead looked up using mDNS.</t>
<t>DNS-SD specifies three portions of the owner name for a
DNS-SD resource record. These are the <Instance> portion,
the <Service> portion, and the <Domain> portion.
The owner name made of these three parts is called the Service
Instance Name. It is worth observing that a portion may be more
than one label long. See <xref target="RFC6763" />, section
4.1. Further discussion of the parts is found in <xref
target="sec-dnssd-portions" />.</t>
<t>Throughout this memo, mDNS is used liberally as the
alternative resolution mechanism to DNS. This is for
convenience rather than rigour: any alternative name resolution
to DNS could present the same friction with the prevailing
operational conventions of the global DNS. It so happens that
mDNS is the overwhelmingly successful alternative as of this
writing, so it is used in order to make the issues plainer to
the reader. Other alternative resolution mechanisms may in
general be read wherever mDNS appears in the text, except where
details of the mDNS specification appear.</t>
</section>
</section>
<section title="Why there could be a problem at all"
anchor="sec-problem-at-all">
<t>One might reasonably wonder why there is a problem to be solved
at all. After all, DNS labels permit any octet whatsoever, and
anything that can be useful with DNS-SD cannot use any names that
are outside the protocol strictures of the DNS.</t>
<t>The reason for the trouble is twofold. First, and least
troublesome, is the possibility of resolvers that are attempting
to offer IDNA service system-wide. Given the design of IDNA2008,
it is reasonable to suppose that on some systems high-level name
resolution libraries will perform the U-label/A-label
transformation automatically, saving applications from these
details. But system-level services do not always have available
to them the resolution context, and may apply the transformation
in a way that foils rather than helps the application. Of course,
if this were the main problem, it would presumably be
self-correcting; for the right answer would be, "Don't use those
libraries for DNS-SD," and DNS-SD would not work reliably in cases
where such libraries were in use. This would be unfortunate; but
given that DNS-SD in Internet contexts is as of this writing not
in ubiquitous use, it should not represent a fatal issue.</t>
<t>The greater problem is that the "infrastructure" types of DNS
service -- the root zone, the top-level domains, and so on -- have
embraced IDNA and refuse registration of raw UTF-8 into their
zones. As of this writing there is (perhaps unfortunately) no
reliable way to discover where these sorts of DNS services end.
Nevertheless, some client programs (notably web browsers) have
adopted a number of different policies about how domain names will
be looked up and presented to users given the policies of the
relevant DNS zone operators. None of these policies permit raw
UTF-8. Since it is anticipated that DNS-SD when used with the DNS
will be inside domain names beneath those kinds of
"infrastructure" domains, the implications of IDNA2008 must be a
consideration.</t>
<t>For further exploration of issues relating to encoding of
domain names generally, the reader should consult <xref
target="RFC6055" />.</t>
</section>
<section title="Requirements for a profile for label interoperation"
anchor="sec-label-interop">
<t>Any interoperability between DNS (including prevailing
operational conventions) and other resolution technologies will
require interoperability across the portions of a DNS-SD Service
Instance Name that are implicated in regular DNS lookups. Only
some portions are implicated. In any case, if a given portion is
implicated, the profile will need to apply to all labels in that
portion.</t>
<t>In addition, because DNS-SD Service Instance Names can be used
in a domain name slot, care must be taken by DNS-SD-aware
resolvers to handle the different portions as outlined here, so
that DNS-SD portions that do not use IDNA2008 will not be treated
as U-labels and will not accidentally undergo IDNA processing.</t>
<t>Because the profile will apply to names that might appear in
the public DNS, and because other resolution mechanisms (such as
mDNS) could permit labels that IDNA does not, the profile might
reduce the labels that could be used with those other resolution
mechanisms. One consequence of this is that some recommendations
from <xref target="RFC6763" /> will not really be possible to
implement using names subject to the profile. In particular,
<xref target="RFC6763" />, section 4.1.3 recommends that labels
always be stored and communicated as UTF-8, even in the DNS.
Because of the way the public DNS is currently operated (see <xref
target="sec-problem-at-all" />), the advice to store and transmit
labels as UTF-8 in the DNS is likely either to encounter problems,
or to result in unnecessary traffic to the public DNS, or both.
In particular, 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 for zones that are using IDNA2008. By contrast,
for example, mDNS normally uses UTF-8.</t>
<t>U-labels cannot contain upper case letters (see <xref
target="RFC5894" />, sections 3.1.3 and 4.2). That restriction
extends to ASCII-range upper case letters that work fine in
LDH-labels. It may be confusing that the character "A" works in
the DNS when none of the characters in the label has a diacritic,
but does not work when there is such a diacritic in the label.
Labels in mDNS names (or other resolution technologies) may
contain upper case characters, so the profile will need either to
restrict the use of upper case or come up with a convention for
case folding (even in the presence of diacritics) that is reliable
and predictable to users.</t>
</section>
<section title="DNS-SD portions" anchor="sec-dnssd-portions">
<t>Service Instance Names are made up of three portions.</t>
<section title="The <Instance> Portion of the Service
Instance Name" anchor="sec-prof-instance">
<t><xref target="RFC6763" /> is clear that the <Instance>
portion of the Service Instance Name is intended for
presentation to users, and therefore virtually any character is
permitted in it. There are two ways that a profile might address
this portion.</t>
<t>The first way would be to treat this portion as likely to be
intercepted by system-wide IDNA-aware (but otherwise
context-unaware) resolvers, or likely subject to strict IDNA
conformance requirements for publication in the relevant zone.
In this case, the portion would need to be made subject to the
profile, thereby curtailing what characters may appear in this
portion. This approach permits DNS-SD to use any standard
system resolver but presents inconsistencies with the DNS-SD
specification and with DNS-SD use that is exclusively
mDNS-based. Therefore, this strategy is rejected.</t>
<t>Instead, DNS-SD implementations can intercept the
<Instance> portion of a Service Instance Name and ensure
that those labels are never handed to IDNA-aware resolvers that
might attempt to convert these labels into A-labels. Under this
approach, the DNS-SD <Instance> portion works as it always
does, but at the cost of using special resolution code built
into the DNS-SD system. A practical consequence of this is that
zone operators need to be prepared not to apply the LDH rule to
all labels, and may need to make special concessions to ensure
that the <Instance> portion can contain spaces, upper and
lower case, and any UTF-8 code point; or else to prepare a user
interface to handle the exceptions that would otherwise be
generated. Automatic conversion to A-labels is not
acceptable.</t>
<t>It is worth noting that this advice is not actually
compatible with advice in <xref target="RFC6055" />, section 4.
That section appears to assume that names are not really
composed of subsections, but because <xref target="RFC6763" />
specifies portions of names, the advice in this memo is to
follow the advice of <xref target="RFC6055" /> according to the
portion of the domain name, rather than for the whole domain
name. As a practical matter, this likely means special-purpose
name resolution software for DNS-SD.</t>
</section>
<section title="The <Service> Portion of the Service
Instance Name" anchor="sec-prof-service">
<t>DNS-SD includes a <Service> component in the Service
Instance Name. This component is not really user-facing data,
but is instead control data embedded in the Service Instance
Name. This component includes so-called "underscore labels",
which are labels prepended with U+005F (_). The underscore
label convention was established by DNS SRV (<xref
target="RFC2782" />) for identifying metadata inside DNS names.
A system-wide resolver (or DNS middlebox) that cannot handle
underscore labels will not work with DNS-SD at all, so it is
safe to suppose that such resolvers will not attempt to do
special processing on these labels. Therefore, the
<Service> portion of the Service Instance Name will not be
subject to the profile. By the same token, underscore labels
are never subject to IDNA processing (they are formally
incompatible), and therefore concerns about IDNA are irrelevant
for these labels.</t>
</section>
<section title="The <Domain> Portion of the
Service Instance Name" anchor="sec-prof-domain">
<t>The <Domain> portion of the Service Instance Name forms
an integral part of the owner name submitted for DNS resolution.
A system-wide resolver that is IDNA2008-aware is likely to
interpret labels with UTF-8 in the owner name as candidates for
IDNA2008 processing. More important, operators of
internationalized domain names will frequently publish such names
in the public DNS as A-labels; certainly, the top-most labels will
always be A-labels. Therefore, these labels will need to be
subject to the profile. 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 <xref
target="RFC6763" />, because it privileges IDNA2008-compatible
labels over UTF-8 labels. There is more than one way to achieve
such a result, but in terms of predictability it is probably best
if the lowest-level resolution component is able to learn the
correct resolution context, so that it can perform the correct
transformations on the various domain portions.</t>
<t>One might argue against the above restriction on either of two
grounds:
<list style="numbers">
<t>It is possible the names may be in the DNS in UTF-8, and RFC
6763 already specifies a fallback strategy of progressively
attempting first the UTF-8 label lookup (it might not be a
U-label) and then if possible the A-label lookup.</t>
<t>Zone administrators that wish to support DNS-SD can publish a
UTF-8 version of the zone along side the A-label version of the
zone.</t>
</list>
The first of these is rejected because it represents a potentially
significant increase in DNS lookup traffic for no value. It is
possible for a DNS-SD application to identify the <Domain>
portion of the Service Instance Name. The standard way to publish
IDNs on the Internet uses IDNA. Therefore, additional lookups
should not be encouraged. When <xref target="RFC6763" /> was
published, the bulk of IDNs were lower in the tree. Now that
there are internationalized labels in the root zone, it is
desirable to minimize queries to the Internet infrastructure if
they are sure to be answered in the negative.</t>
<t>The second reason depends on the idea that it is possible to
maintain two names in sync with one another. This is not strictly
speaking true, although in this case the domain operator could
simply create a DNAME record <xref target="RFC6672" /> from the
UTF-8 name to the IDNA2008 zone. This still, however, relies on
being able to reach the (UTF-8) name in question, and it is
unlikely that the UTF-8 version of the zone will be delegated from
anywhere. Moreover, in many organizations the support for DNS-SD
and the support for domain name delegations are not performed by
the same department, and depending on a co-ordination between the
two will make the system more fragile, or slower, or both.</t>
<t>Some resolvers -- particularly those that are used in mixed DNS
and non-DNS environments -- may be aware of different operational
conventions in different parts of the DNS tree. For example, it
may be possible for implementations to use hints about the
boundary of an organization's domain name infrastructure, in order
to tell (for instance) that example.com. is part of the Example
Organization while com. is a large delegation-centric zone on the
public Internet. In such cases, the resolution system might
reverse its preferences to prefer plain UTF-8 labels when
resolving names below the boundary point in the DNS tree. The
result would be that any lookup past the boundary point and closer
to the root would use LDH-labels first, falling back to UTF-8 only
after a failure; but a lookup below the boundary point would use
UTF-8 labels first, and try other strategies only in case of
negative answers. The mechanism to learn such a boundary is beyond
the scope of this document.</t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The author gratefully acknowledges the insights of Joe Abley,
Stuart Cheshire, Paul Hoffman, Kerry Lynn, and Dave Thaler. Kerry
Lynn deserves special gratitude for his energy and persistence in
pressing unanswered questions. Doug Otis sent many comments about
visual confusability.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo makes no requests of IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This memo presents some requirements for future development, but
does not specify anything. It makes no additional security-specific
requirements. Issues arising due to visual confusability of names
apply to this case as well as to any other case of internationalized
names, but interoperation between different resolution systems and
conventions does not alter the severity of those issues.
</t>
</section>
</middle>
<back>
<!--references split to informative and normative-->
<!--
<references title="Normative References"> -->
<!-- BEGIN INCLUDED references file draft-sullivan-dnssd-mdns-dns-interop-01.xml-normative -->
<!-- END INCLUDED references file draft-sullivan-dnssd-mdns-dns-interop-01.xml-normative -->
<!--</references>
-->
<references title="Informative References">
<!-- BEGIN INCLUDED references file draft-sullivan-dnssd-mdns-dns-interop-01.xml-informative -->
<reference anchor='RFC0952'>
<front>
<title>DoD Internet host table specification</title>
<author initials='K.' surname='Harrenstien' fullname='K. Harrenstien'>
<organization>SRI International</organization></author>
<author initials='M.' surname='Stahl' fullname='M. Stahl'>
<organization>SRI International</organization></author>
<author initials='E.' surname='Feinler' fullname='E. Feinler'>
<organization>SRI International</organization></author>
<date year='1985' day='1' month='October' /></front>
<seriesInfo name='RFC' value='952' />
<format type='TXT' octets='12388' target='http://www.rfc-editor.org/rfc/rfc952.txt' />
</reference>
<reference anchor='RFC1034'>
<front>
<title abbrev='Domain Concepts and Facilities'>Domain names - concepts and facilities</title>
<author initials='P.' surname='Mockapetris' fullname='P. Mockapetris'>
<organization>Information Sciences Institute (ISI)</organization></author>
<date year='1987' day='1' month='November' /></front>
<seriesInfo name='STD' value='13' />
<seriesInfo name='RFC' value='1034' />
<format type='TXT' octets='129180' target='http://www.rfc-editor.org/rfc/rfc1034.txt' />
</reference>
<reference anchor='RFC1035'>
<front>
<title abbrev='Domain Implementation and Specification'>Domain names - implementation and specification</title>
<author initials='P.' surname='Mockapetris' fullname='P. Mockapetris'>
<organization>USC/ISI</organization>
<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country></postal>
<phone>+1 213 822 1511</phone></address></author>
<date year='1987' day='1' month='November' /></front>
<seriesInfo name='STD' value='13' />
<seriesInfo name='RFC' value='1035' />
<format type='TXT' octets='125626' target='http://www.rfc-editor.org/rfc/rfc1035.txt' />
</reference>
<reference anchor='RFC2181'>
<front>
<title abbrev='DNS Clarifications'>Clarifications to the DNS Specification</title>
<author initials='R.' surname='Elz' fullname='Robert Elz'>
<organization>Computer Science</organization>
<address>
<postal>
<street>Parkville</street>
<street>Victoria</street>
<street>3052</street>
<street>Australia.</street></postal>
<email>kre@munnari.OZ.AU</email>
<uri>e</uri></address></author>
<author initials='R.' surname='Bush' fullname='Randy Bush'>
<organization>RGnet, Inc.</organization>
<address>
<postal>
<street>5147 Crystal Springs Drive</street>
<street>Bainbridge Island</street>
<street>Washington</street>
<street>98110</street>
<street>United States.</street>
<country>NE</country></postal>
<email>randy@psg.com</email></address></author>
<date year='1997' month='July' />
<area>Applications</area>
<keyword>DNS</keyword>
<keyword>domain name system</keyword></front>
<seriesInfo name='RFC' value='2181' />
<format type='TXT' octets='36989' target='http://www.rfc-editor.org/rfc/rfc2181.txt' />
<format type='XML' octets='38931' target='http://xml.resource.org/public/rfc/xml/rfc2181.xml' />
</reference>
<reference anchor='RFC2782'>
<front>
<title abbrev='DNS SRV RR'>A DNS RR for specifying the location of services (DNS SRV)</title>
<author initials='A.' surname='Gulbrandsen' fullname='Arnt Gulbrandsen'>
<organization>Troll Tech</organization>
<address>
<postal>
<street>Waldemar Thranes gate 98B</street>
<city>Oslo</city>
<region />
<code>N-0175</code>
<country>NO</country></postal>
<phone>+47 22 806390</phone>
<facsimile>+47 22 806380</facsimile>
<email>arnt@troll.no</email></address></author>
<author initials='P.' surname='Vixie' fullname='Paul Vixie'>
<organization>Internet Software Consortium</organization>
<address>
<postal>
<street>950 Charter Street</street>
<city>Redwood City</city>
<region>CA</region>
<code>94063</code>
<country>US</country></postal>
<phone>+1 650 779 7001</phone></address></author>
<author initials='L.' surname='Esibov' fullname='Levon Esibov'>
<organization>Microsoft Corporation</organization>
<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country></postal>
<email>levone@microsoft.com</email></address></author>
<date year='2000' month='February' />
<abstract>
<t>This document describes a DNS RR which specifies the location of the
server(s) for a specific protocol and domain.</t></abstract></front>
<seriesInfo name='RFC' value='2782' />
<format type='TXT' octets='24013' target='http://www.rfc-editor.org/rfc/rfc2782.txt' />
</reference>
<reference anchor='RFC5198'>
<front>
<title>Unicode Format for Network Interchange</title>
<author initials='J.' surname='Klensin' fullname='J. Klensin'>
<organization /></author>
<author initials='M.' surname='Padlipsky' fullname='M. Padlipsky'>
<organization /></author>
<date year='2008' month='March' />
<abstract>
<t>The Internet today is in need of a standardized form for the transmission of internationalized "text" information, paralleling the specifications for the use of ASCII that date from the early days of the ARPANET. This document specifies that format, using UTF-8 with normalization and specific line-ending sequences. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5198' />
<format type='TXT' octets='45708' target='http://www.rfc-editor.org/rfc/rfc5198.txt' />
</reference>
<reference anchor='RFC5890'>
<front>
<title>Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework</title>
<author initials='J.' surname='Klensin' fullname='J. Klensin'>
<organization /></author>
<date year='2010' month='August' />
<abstract>
<t>This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5890' />
<format type='TXT' octets='54245' target='http://www.rfc-editor.org/rfc/rfc5890.txt' />
</reference>
<reference anchor='RFC5891'>
<front>
<title>Internationalized Domain Names in Applications (IDNA): Protocol</title>
<author initials='J.' surname='Klensin' fullname='J. Klensin'>
<organization /></author>
<date year='2010' month='August' />
<abstract>
<t>This document is the revised protocol definition for Internationalized Domain Names (IDNs). The rationale for changes, the relationship to the older specification, and important terminology are provided in other documents. This document specifies the protocol mechanism, called Internationalized Domain Names in Applications (IDNA), for registering and looking up IDNs in a way that does not require changes to the DNS itself. IDNA is only meant for processing domain names, not free text. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5891' />
<format type='TXT' octets='38105' target='http://www.rfc-editor.org/rfc/rfc5891.txt' />
</reference>
<reference anchor='RFC5892'>
<front>
<title>The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)</title>
<author initials='P.' surname='Faltstrom' fullname='P. Faltstrom'>
<organization /></author>
<date year='2010' month='August' />
<abstract>
<t>This document specifies rules for deciding whether a code point, considered in isolation or in context, is a candidate for inclusion in an Internationalized Domain Name (IDN).</t><t> It is part of the specification of Internationalizing Domain Names in Applications 2008 (IDNA2008). [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5892' />
<format type='TXT' octets='187370' target='http://www.rfc-editor.org/rfc/rfc5892.txt' />
</reference>
<reference anchor='RFC5893'>
<front>
<title>Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)</title>
<author initials='H.' surname='Alvestrand' fullname='H. Alvestrand'>
<organization /></author>
<author initials='C.' surname='Karp' fullname='C. Karp'>
<organization /></author>
<date year='2010' month='August' />
<abstract>
<t>The use of right-to-left scripts in Internationalized Domain Names (IDNs) has presented several challenges. This memo provides a new Bidi rule for Internationalized Domain Names for Applications (IDNA) labels, based on the encountered problems with some scripts and some shortcomings in the 2003 IDNA Bidi criterion. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5893' />
<format type='TXT' octets='38870' target='http://www.rfc-editor.org/rfc/rfc5893.txt' />
</reference>
<reference anchor='RFC5894'>
<front>
<title>Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale</title>
<author initials='J.' surname='Klensin' fullname='J. Klensin'>
<organization /></author>
<date year='2010' month='August' />
<abstract>
<t>Several years have passed since the original protocol for Internationalized Domain Names (IDNs) was completed and deployed. During that time, a number of issues have arisen, including the need to update the system to deal with newer versions of Unicode. Some of these issues require tuning of the existing protocols and the tables on which they depend. This document provides an overview of a revised system and provides explanatory material for its components. This document is not an Internet Standards Track specification; it is published for informational purposes.</t></abstract></front>
<seriesInfo name='RFC' value='5894' />
<format type='TXT' octets='115174' target='http://www.rfc-editor.org/rfc/rfc5894.txt' />
</reference>
<reference anchor='RFC5895'>
<front>
<title>Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008</title>
<author initials='P.' surname='Resnick' fullname='P. Resnick'>
<organization /></author>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'>
<organization /></author>
<date year='2010' month='September' />
<abstract>
<t>In the original version of the Internationalized Domain Names in Applications (IDNA) protocol, any Unicode code points taken from user input were mapped into a set of Unicode code points that "made sense", and then encoded and passed to the domain name system (DNS). The IDNA2008 protocol (described in RFCs 5890, 5891, 5892, and 5893) presumes that the input to the protocol comes from a set of "permitted" code points, which it then encodes and passes to the DNS, but does not specify what to do with the result of user input. This document describes the actions that can be taken by an implementation between receiving user input and passing permitted code points to the new IDNA protocol. This document is not an Internet Standards Track specification; it is published for informational purposes.</t></abstract></front>
<seriesInfo name='RFC' value='5895' />
<format type='TXT' octets='16556' target='http://www.rfc-editor.org/rfc/rfc5895.txt' />
</reference>
<reference anchor='RFC6055'>
<front>
<title>IAB Thoughts on Encodings for Internationalized Domain Names</title>
<author initials='D.' surname='Thaler' fullname='D. Thaler'>
<organization /></author>
<author initials='J.' surname='Klensin' fullname='J. Klensin'>
<organization /></author>
<author initials='S.' surname='Cheshire' fullname='S. Cheshire'>
<organization /></author>
<date year='2011' month='February' />
<abstract>
<t>This document explores issues with Internationalized Domain Names (IDNs) that result from the use of various encoding schemes such as UTF-8 and the ASCII-Compatible Encoding produced by the Punycode algorithm. It focuses on the importance of agreeing on a single encoding and how complicated the state of affairs ends up being as a result of using different encodings today.</t></abstract></front>
<seriesInfo name='RFC' value='6055' />
<format type='TXT' octets='58799' target='http://www.rfc-editor.org/rfc/rfc6055.txt' />
</reference>
<reference anchor='RFC6672'>
<front>
<title>DNAME Redirection in the DNS</title>
<author initials='S.' surname='Rose' fullname='S. Rose'>
<organization /></author>
<author initials='W.' surname='Wijngaards' fullname='W. Wijngaards'>
<organization /></author>
<date year='2012' month='June' />
<abstract>
<t>The DNAME record provides redirection for a subtree of the domain name tree in the DNS. That is, all names that end with a particular suffix are redirected to another part of the DNS. This document obsoletes the original specification in RFC 2672 as well as updates the document on representing IPv6 addresses in DNS (RFC 3363). [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='6672' />
<format type='TXT' octets='45704' target='http://www.rfc-editor.org/rfc/rfc6672.txt' />
</reference>
<reference anchor='RFC6762'>
<front>
<title>Multicast DNS</title>
<author initials='S.' surname='Cheshire' fullname='S. Cheshire'>
<organization /></author>
<author initials='M.' surname='Krochmal' fullname='M. Krochmal'>
<organization /></author>
<date year='2013' month='February' />
<abstract>
<t>As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful.</t><t> Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names.</t><t> The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures.</t></abstract></front>
<seriesInfo name='RFC' value='6762' />
<format type='TXT' octets='184992' target='http://www.rfc-editor.org/rfc/rfc6762.txt' />
</reference>
<reference anchor='RFC6763'>
<front>
<title>DNS-Based Service Discovery</title>
<author initials='S.' surname='Cheshire' fullname='S. Cheshire'>
<organization /></author>
<author initials='M.' surname='Krochmal' fullname='M. Krochmal'>
<organization /></author>
<date year='2013' month='February' />
<abstract>
<t>This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD.</t></abstract></front>
<seriesInfo name='RFC' value='6763' />
<format type='TXT' octets='125192' target='http://www.rfc-editor.org/rfc/rfc6763.txt' />
</reference>
<!-- END INCLUDED references file
draft-sullivan-dnssd-mdns-dns-interop-01.xml-informative -->
<?rfc include="reference.RFC.7719.xml"?>
</references>
<section title="Change History" anchor="sec_change_hist">
<t>Note to RFC Editor: this section should be removed prior to
publication.</t>
<section title="draft-ietf-dnssd-mdns-dns-interop-03">
<t>
<list style="symbols">
<t>Additional alteration of title</t>
<t>Attempt to address WGLC comments from Dave Thaler
(2016-04-02)</t>
</list>
</t>
</section>
<section title="draft-ietf-dnssd-mdns-dns-interop-02">
<t>
<list style="symbols">
<t>Altered the title to make it more generic than mDNS.</t>
<t>Addressed issues raised by Dave Thaler in review on
2015-07-18.</t>
<t>Added a note to <xref target="Security" /> about visual
confusion. I don't know whether this will satisfy Doug Otis
but it is the only thing I can see that could possibly be
relevant. </t>
<t>Added discussion of finding "boundary" in <xref
target="sec-prof-domain" />.</t>
</list>
</t>
</section>
<section title="draft-ietf-dnssd-mdns-dns-interop-01">
<t>Alter text to make clear that the main issue is the way the
public DNS is currently administered, not system resolvers. I
suppose this should have been clear before, but I didn't do that.
Many thanks to Kerry Lynn for penetrating questions that
illuminated what I'd left out.</t>
</section>
<section title="draft-ietf-dnssd-mdns-dns-interop-00">
<t>1st WG version</t>
<t>Add text to make clear that fallback from A-label lookup to
UTF-8 label lookup ok, per WG comments at IETF 91</t>
</section>
<section title="draft-sullivan-dnssd-mdns-dns-interop-01">
<t>
<list style="symbols">
<t>Decided which portions would be affected</t>
<t>Explained the difference in user interfaces between DNS-SD
and usual DNS operation</t>
<t>Provided background on why the Domain portion should be
treated differently</t>
</list>
</t>
</section>
<section title="draft-sullivan-dnssd-mdns-dns-interop-00">
<t>Initial version.</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:20:42 |