One document matched: draft-sullivan-dnssd-mdns-dns-interop-00.xml
<?xml version='1.0' encoding='ascii'?>
<!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-sullivan-dnssd-mdns-dns-interop-00" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
<front>
<title abbrev="mDNS and DNS Interop">Requirements for Labels to Interoperate Between mDNS and DNS</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>IETF</workgroup>
<abstract>
<t>Despite its name, DNS-Based Service Discovery can use naming systems other than the Domain Name System when looking for services. Different name systems use different conventions for the characters allowed in any name. In order for DNS-SD to be used effectively in environments where multiple different name systems are in use, it is important to follow a common set of conventions for naming. This memo presents an outline of the reqiurements for selection of labels for mDNS and DNS when they are expected to interoperate in this manner. </t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="default">
<t>DNS-Based Service Discovery (DNS-SD, <xref target="RFC6763" pageno="false" format="default"/>) specifies a mechanism for discovering services using queries both to the Domain Name System (DNS, <xref target="RFC1034" pageno="false" format="default"/>, <xref target="RFC1035" pageno="false" format="default"/>) and to Multicast DNS (mDNS, <xref target="RFC6762" pageno="false" format="default"/>). Conventional use of the DNS generally follows the host name rules <xref target="RFC0952" pageno="false" format="default"/> 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" pageno="false" format="default"/>, <xref target="RFC5891" pageno="false" format="default"/>, <xref target="RFC5892" pageno="false" format="default"/>, <xref target="RFC5893" pageno="false" format="default"/>, <xref target="RFC5894" pageno="false" format="default"/>, <xref target="RFC5895" pageno="false" format="default"/>). It is worth noting that the LDH rule is a convention, and not a strict rule of the DNS. It is assumed to be true widely enough, however, that in many circumstances names cannot be used 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" pageno="false" format="default"/>, 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" pageno="false" format="default"/> format.</t>
<t>Users 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 names in different contexts. As a result, the same string might be tried as a name using different name resolution technologies. If DNS-SD is to be used in an environment where both mDNS and DNS are to be queried for services, then the names to be queried will need to be compatible with the rules and conventions for both DNS and mDNS.</t>
<t>One approach to interoperability under these circumstances is to use a single operational convention for names under the different naming systems. This memo posits such a use profile, and outlines what is necessary to make it work.</t>
<section title="Conventions and terms used in this document" toc="default">
<t>Wherever appropriate, this memo uses the terminology defined in Section 2 of <xref target="RFC5890" pageno="false" format="default"/>. 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" pageno="false" format="default"/> and other documents dealing with Unicode code points. In the interests of brevity and consistency, the definitions are not repeated here.</t>
<t>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 often intercept labels that do not conform to the LDH rule and apply IDNA and other transformations.</t>
<t>The term "owner name" (common to the DNS vernacular) is used here to apply not just to the names to be looked up in the DNS, but to any name that might be looked up either in the DNS or using mDNS.</t>
</section>
</section>
<section title="Requirements for a profile for label interoperation" anchor="sec-label-interop" toc="default">
<t>Any interoperability between mDNS and DNS will require interoperability across some of the portions of a DNS-SD Service Instance Name (see <xref target="sec-dnssd-portions" pageno="false" format="default"/>) that are implicated in regular mDNS and DNS lookups. The open question is which of the 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>Because the profile will need to apply to names that might need to interoperate with names in the DNS, and because mDNS permits labels that IDNA does not, the profile will reduce the labels that may be used with mDNS. Consequently, some recommendations from <xref target="RFC6763" pageno="false" format="default"/> will not really be possible to implement using names subject to the profile. In particular, <xref target="RFC6763" pageno="false" format="default"/>, section 4.1.3 recommends that rich text, human-readable labels be used, and includes punctuation and space characters in the examples. It is not clear whether such uses will be possible, because spaces and most punctuation are permitted neither in U-labels nor in LDH labels. In addition, the same section recommends that labels always be stored and communicated as UTF-8, even in the DNS. Because IDNA2008 libraries will treat any Unicode-encoded labels as candidate U-labels and attempt to perform resolution in A-label form, the advice to store and transmit labels as UTF-8 in the DNS is likely to encounter problems. By contrast, mDNS normally uses UTF-8.</t>
<t>U-labels cannot contain upper case letters. 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 may contain upper case characters, so the profile will need either to restrict the use of upper case or come up with a reliable and predictable convention for case folding.</t>
</section>
<section title="DNS-SD portions" anchor="sec-dnssd-portions" toc="default">
<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>. 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" pageno="false" format="default"/>, section 4.1.</t>
<section title="The <Instance> Portion of the Service Instance Name" anchor="sec-prof-instance" toc="default">
<t><xref target="RFC6763" pageno="false" format="default"/> 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; a specification of the profile will need to select one of these strategies.</t>
<t>The first option is to treat this portion as likely to be intercepted by system-wide IDNA-aware resolvers. In this case, the portion needs 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 that is exclusively mDNS-based.</t>
<t>The second option is to specify that the portion never be handled by "normal" DNS resolution, and that it instead be handled by a special DNS-SD resolution path. In this case, DNS-SD works as it always does, but at the cost of a possibly more complicated system-wide resolver or special resolution code built into the DNS-SD system.</t>
</section>
<section title="The <Service> Portion of the Service Instance Name" anchor="sec-prof-service" toc="default">
<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" pageno="false" format="default"/>) 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.</t>
</section>
<section title="The <Domain> Portion of the Service Instance Name" anchor="sec-prof-domain" toc="default">
<t>The <Domain> portion of the service instance name forms an integral part of the QNAME submitted for DNS resolution, and a system-wide resolver that is IDNA2008-aware is likely to interpret labels with UTF-8 in the QNAME as candidates for IDNA2008 processing. Therefore, these labels will need to be subject to the profile. </t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements" toc="default">
<t>The author gratefully acknowledges the insights of Kerry Lynn.</t>
</section>
<section anchor="IANA" title="IANA Considerations" toc="default">
<t>This memo makes no requests of IANA.</t>
</section>
<section anchor="Security" title="Security Considerations" toc="default">
<t>This memo presents some requirements for future development, but does not specify anything. Therefore, it has no imlpications for security.</t>
</section>
</middle>
<back>
<!--references split to informative and normative-->
<!--<references title="Normative References"> &bibxml2rfc-normative; </references> -->
<references title="Informative References"><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="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="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> </references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:42:18 |