idnits 2.17.1 draft-sullivan-dnssd-label-miprofile-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (October 18, 2013) is 3843 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF A. Sullivan 3 Internet-Draft Dyn 4 Intended status: Informational October 18, 2013 5 Expires: April 21, 2014 7 Using Labels With DNS-Based Service Discovery, mDNS, and DNS 8 draft-sullivan-dnssd-label-miprofile-00 10 Abstract 12 Despite its name, DNS-Based Service Discovery can use naming systems 13 other than the Domain Name System when looking for services. 14 Different name systems use different conventions for the characters 15 allowed in any name. In order for DNS-SD to be used effectively in 16 environments where multiple different name systems are in use, it is 17 important to follow a common set of conventions for naming. This 18 memo presents a convention for maximizing such interoperability. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 21, 2014. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Conventions and terms used in this document . . . . . . . . 3 56 2. The MI Profile . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.1. The MI Profile and DNS-SD . . . . . . . . . . . . . . . . . 4 58 2.1.1. The Portion of the Service Instance Name . . 5 59 2.1.2. The Portion of the Service Instance Name . . 6 60 2.1.3. The MI Profile and the Portion of the 61 Service Instance Name . . . . . . . . . . . . . . . . . 6 62 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 63 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 65 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 67 6.2. Informative References . . . . . . . . . . . . . . . . . . 7 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 DNS-Based Service Discovery (DNS-SD, [RFC6763]) specifies a mechanism 73 for discovering services using queries both to the Domain Name System 74 (DNS, [RFC1034], [RFC1035]) and to Multicast DNS (mDNS, [RFC6762]). 75 Conventional use of the DNS generally follows the host name rules 76 [RFC0952] for labels -- the so-called LDH rule. That convention is 77 the reason behind the development of Internationalized Domain Names 78 for Applications (IDNA2008, [RFC5890], [RFC5891], [RFC5892], 79 [RFC5893], [RFC5894], [RFC5895]). It is worth noting that the LDH 80 rule is a convention, and not a strict rule of the DNS. It is 81 assumed to be true widely enough, however, that in many circumstances 82 names cannot be used unless they cleave to the LDH rule. 84 At the same time, mDNS requires that labels be encoded in UTF-8, and 85 permits a range of characters in labels that are not permitted by 86 IDNA2008 or the LDH rule. For example, mDNS encourages the use of 87 spaces and punctuation in mDNS names (see [RFC6763], section 4.1.3). 88 It does not restrict which Unicode code points may be used in those 89 labels, so long as the code points are UTF-8 in Net-Unicode [RFC5198] 90 format. 92 Users of applications are, of course, frequently unconcerned with 93 (not to say oblivious to) the name-resolution system(s) in service at 94 any given moment, and are inclined simply to use the same names in 95 different contexts. As a result, the same string might be tried as a 96 name using different name resolution technologies. If DNS-SD is to 97 be used in an environment where both mDNS and DNS are to be queried 98 for services, then the names to be queried will need to be compatible 99 with the rules and conventions for both DNS and mDNS. This memo 100 provides advice on how to do that. For the sake of brevity, in what 101 follows the use of labels that work reliably with both mDNS and DNS 102 is called the "maximally inter-operative profile", or "MI profile". 104 It is important to emphasize that this profile is maximally 105 interoperable in the sense that it encourages the most 106 interoperability between DNS and mDNS environments; but it does not 107 guarantee it. IDNA2008 does not constrain DNS operators from putting 108 any labels they want (including those from outside the IDNA2008- 109 permissible repertoire) in zones. Rather, this profile is intended 110 to reduce the scope for variability between systems so that a minimal 111 (but predictable) subset of possible behaviour is available to 112 everyone. 114 1.1. Conventions and terms used in this document 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC 2119 [RFC2119]. 120 Wherever appropriate, this memo uses the terminology defined in 121 Section 2 of [RFC5890]. In particular, the reader is assumed to be 122 familiar with the terms "U-label", "LDH label", and "A-label" from 123 that document. Similarly, the reader is assumed to be familiar with 124 the U+NNNN notation for Unicode code points used in [RFC5890] and 125 other documents dealing with Unicode code points. In the interests 126 of brevity and consistency, the definitions are not repeated here. 128 The term "owner name" (common to the DNS vernacular) is used here to 129 apply not just to the names to be looked up in the DNS, but to any 130 name that might be looked up either in the DNS or using mDNS. 132 2. The MI Profile 134 In the following, we make recommendations for how to use DNS-SD where 135 that use needs to work seamlessly across DNS and mDNS. The 136 recommendations involve limitations on what labels should (and should 137 not) be used for names used with DNS-SD. The MI profile applies to 138 labels, not names. 140 The MI profile has three rules: 142 1. If the label is made entirely of LDH code points, then the label 143 MUST be an LDH label. 145 2. All LDH code points MUST be folded to lower case. 147 3. If the label contains any other code point, then the label MUST 148 be a well-formed U-label. 150 [[anchor3: Rule 1 is a tautology. I've wondered whether it's needed, 151 but it makes rule 2 clearer. --ajs@anvilwalrusden.com]] 153 2.1. The MI Profile and DNS-SD 155 DNS-SD specifies three portions of the owner name for a DNS-SD 156 resource record. These are the portion, the 157 portion, and the . The owner name made of these three parts 158 is called the Service Instance Name. It is worth observing that a 159 portion may be more than one label long. See [RFC6763], section 4.1. 161 To be effective, the MI profile is either applied to every label in a 162 Service Instance Name portion, or it is not applied to that portion 163 at all. The reason the profile might not be applied to a portion is 164 because different portions have different functions within the 165 Service Instance Name: some of them function as control data, and 166 therefore have special handling applied. Those portions are not 167 intended for user display. 169 Because the MI profile is to apply to names that might need to 170 interoperate with names in the DNS, the profile reduces the scope for 171 labels to be used with DNS or mDNS. Consequently, some 172 recommendations from [RFC6763] cannot really be implemented using 173 names subject to the MI profile. In particular, [RFC6763], section 174 4.1.3 recommends that rich text, human-readable labels be used, and 175 includes punctuation and space characters in the examples. Such uses 176 are incompatible with the MI profile, because spaces and most 177 punctuation are permitted neither in U-labels nor in LDH labels. In 178 addition, the same section recommends that labels always be stored 179 and communicated as UTF-8, even in the DNS. Because IDNA2008 180 libraries will treat any Unicode-encoded labels as candidate U-labels 181 and attempt to perform resolution in A-label form, the advice to 182 store and transmit labels as UTF-8 in the DNS is likely to encounter 183 problems and is NOT RECOMMENDED. Naturally, because mDNS always uses 184 UTF-8, mDNS labels SHOULD be transmitted as UTF-8 unless there is 185 strong reason to suppose that some mDNS responder is using A-labels. 186 The subset of allowable characters under the MI profile remains the 187 same, however, so some characters that would be available in mDNS 188 without the MI profile are not available when the MI profile is in 189 use. 191 The reason for rule 2 is merely to reduce potential user confusion. 192 U-labels cannot contain upper case letters. That restriction extends 193 to ASCII-range upper case letters that work fine in LDH-labels. It 194 is confusing that the character "A" works in the DNS when none of the 195 characters in the label has a diacritic, but does not work when there 196 is such a diacritic in the label. Therefore, MI profile requires 197 folding to lower case even traditional DNS labels, in the interests 198 of maximizing interoperability. 200 2.1.1. The Portion of the Service Instance Name 202 [RFC6763] is clear that the portion of the Service 203 Instance Name is intended for presentation to users, and therefore 204 virtually any character is permitted in it. Because the 205 portion may actually be part of the QNAME submitted for DNS 206 resolution, and because such names are subject to being intercepted 207 by a system-wide resolver that is IDNA2008-aware, use of the MI 208 profile on the portion of the Service Instance Name is 209 RECOMMENDED. This will probably reduce some of the utility of the 210 portion, but it provides the benefit that the entire name 211 can be looked up and used with DNS-SD when using the DNS. [[anchor4: 212 I am torn by this recommendation. This version is conditioned by a 213 mental model where a resolution system (more than a DNS resolver, but 214 including IDNA for instance) looks at a label. If the label has 215 Unicode characters in it, then the resolver attempts an IDNA2008 216 transformation on the label; otherwise, it attempts to use the label 217 in stock DNS operation. It's possible, however, that some systems 218 pick out things like underscore labels first, and thereby identify 219 "control" labels that purport to represent particular pieces of 220 functionality. In that case, the resolver could treat the whole name 221 differently, and pull off the Instance portion prior to the Service 222 portion. If it could do that, it could use straight UTF-8, spaces, 223 punctuation, and everything else. I'm sceptical of the reliability 224 of this, though, so it seems to me it'd be better to apply the 225 profile to anything that wasn't a control label. 226 --ajs@anvilwalrusden.com]] 228 2.1.2. The Portion of the Service Instance Name 230 DNS-SD includes a component in the Service Instance Name. 231 This component is not really user-facing data, but is instead control 232 data embedded in the Service Instance Name. This component includes 233 so-called "underscore labels", which are labels prepended with U+005F 234 (_). The underscore label convention was established by DNS SRV 235 ([RFC2782]) for identifying metadata inside DNS names. A system-wide 236 resolver (or DNS middlebox) that cannot handle underscore labels will 237 not work with DNS-SD at all, so it is safe to suppose that such 238 resolvers will not attempt to do special processing on these labels. 239 Note that underscore labels do not meet the requirements of the MI 240 profile, so the MI profile MUST NOT be applied to the 241 portion of the Service Instance Name. 243 2.1.3. The MI Profile and the Portion of the Service Instance 244 Name 246 The portion of the service instance name forms an integral 247 part of the QNAME submitted for DNS resolution, and a system-wide 248 resolver that is IDNA2008-aware is likely to interpret labels with 249 UTF-8 in the QNAME as candidates for IDNA2008 processing. Therefore, 250 use of the MI profile on such names is RECOMMENDED, unless there is 251 strong evidence that no resolvers in the resolution chain will 252 attempt to perform a U-label to A-label transformation during lookup, 253 and that the actual DNS server will have U-labels rather than 254 A-labels stored. In practice, these restrictions will permit plain 255 UTF-8 lookups in special conditions (e.g. on a local network with a 256 DNS server and careful administration) only. 258 3. Acknowledgements 260 The author gratefully acknowledges the insights of Kerry Lynn. 262 4. IANA Considerations 264 This memo makes no requests of IANA. 266 5. Security Considerations 268 This memo recommends a subset of available characters for use in DNS- 269 SD-related queries, consistent with the rules of mDNS and IDNA2008. 270 The security considerations of those protocols apply broadly to this 271 memo, but this memo introduces no additional security considerations 272 on its own. 274 6. References 276 6.1. Normative References 278 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 279 Requirement Levels", BCP 14, RFC 2119, March 1997. 281 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 282 Discovery", RFC 6763, February 2013. 284 6.2. Informative References 286 [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet 287 host table specification", RFC 952, October 1985. 289 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 290 STD 13, RFC 1034, November 1987. 292 [RFC1035] Mockapetris, P., "Domain names - implementation and 293 specification", STD 13, RFC 1035, November 1987. 295 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 296 specifying the location of services (DNS SRV)", RFC 2782, 297 February 2000. 299 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 300 Interchange", RFC 5198, March 2008. 302 [RFC5890] Klensin, J., "Internationalized Domain Names for 303 Applications (IDNA): Definitions and Document Framework", 304 RFC 5890, August 2010. 306 [RFC5891] Klensin, J., "Internationalized Domain Names in 307 Applications (IDNA): Protocol", RFC 5891, August 2010. 309 [RFC5892] Faltstrom, P., "The Unicode Code Points and 310 Internationalized Domain Names for Applications (IDNA)", 311 RFC 5892, August 2010. 313 [RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left Scripts for 314 Internationalized Domain Names for Applications (IDNA)", 315 RFC 5893, August 2010. 317 [RFC5894] Klensin, J., "Internationalized Domain Names for 318 Applications (IDNA): Background, Explanation, and 319 Rationale", RFC 5894, August 2010. 321 [RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for 322 Internationalized Domain Names in Applications (IDNA) 323 2008", RFC 5895, September 2010. 325 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 326 February 2013. 328 Author's Address 330 Andrew Sullivan 331 Dyn 332 150 Dow St. 333 Manchester, NH 03101 334 U.S.A. 336 Email: asullivan@dyn.com