idnits 2.17.1 draft-ietf-dnssd-mdns-dns-interop-04.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 date (January 3, 2017) is 2663 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 7719 (Obsoleted by RFC 8499) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSSD A. Sullivan 3 Internet-Draft Dyn 4 Intended status: Informational January 3, 2017 5 Expires: July 7, 2017 7 On Interoperation of Labels Among Conventional DNS and Other Resolution 8 Systems 9 draft-ietf-dnssd-mdns-dns-interop-04 11 Abstract 13 Despite its name, DNS-Based Service Discovery can use naming systems 14 other than the Domain Name System when looking for services. 15 Moreover, when it uses the DNS, DNS-Based Service Discovery uses the 16 full capability of DNS, rather than using a subset of available 17 octets. In order for DNS-SD to be used effectively in environments 18 where multiple different name systems and conventions for their 19 operation are in use, it is important to attend to differences in the 20 underlying technology and operational environment. This memo 21 presents an outline of the requirements for selection of labels for 22 conventional DNS and other resolution systems when they are expected 23 to interoperate in this manner. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on July 7, 2017. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Conventions and terms used in this document . . . . . . . 3 61 2. Why there could be a problem at all . . . . . . . . . . . . . 4 62 3. Requirements for a profile for label interoperation . . . . . 5 63 4. DNS-SD portions . . . . . . . . . . . . . . . . . . . . . . . 6 64 4.1. The Portion of the Service 65 Instance Name . . . . . . . . . . . . . . . . . . . . . . 6 66 4.2. The Portion of the Service 67 Instance Name . . . . . . . . . . . . . . . . . . . . . . 7 68 4.3. The Portion of the Service Instance 69 Name . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 8. Informative References . . . . . . . . . . . . . . . . . . . 9 74 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 11 75 A.1. draft-ietf-dnssd-mdns-dns-interop-04 . . . . . . . . . . 11 76 A.2. draft-ietf-dnssd-mdns-dns-interop-03 . . . . . . . . . . 11 77 A.3. draft-ietf-dnssd-mdns-dns-interop-02 . . . . . . . . . . 11 78 A.4. draft-ietf-dnssd-mdns-dns-interop-01 . . . . . . . . . . 11 79 A.5. draft-ietf-dnssd-mdns-dns-interop-00 . . . . . . . . . . 11 80 A.6. draft-sullivan-dnssd-mdns-dns-interop-01 . . . . . . . . 12 81 A.7. draft-sullivan-dnssd-mdns-dns-interop-00 . . . . . . . . 12 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 84 1. Introduction 86 DNS-Based Service Discovery (DNS-SD, [RFC6763]) specifies a mechanism 87 for discovering services using queries to the Domain Name System 88 (DNS, [RFC1034], [RFC1035]); and to any other system that uses domain 89 names, such as Multicast DNS (mDNS, [RFC6762]). Many applications 90 that use the DNS follow "Internet hostname" syntax [RFC0952] for 91 labels -- the so-called LDH rule. That convention is the reason 92 behind the development of Internationalized Domain Names for 93 Applications (IDNA2008, [RFC5890], [RFC5891], [RFC5892], [RFC5893], 94 [RFC5894], [RFC5895]). It is worth noting that the LDH rule is a 95 convention, and not a rule of the DNS; this is made entirely plain by 96 [RFC2181], section 11, and discussed further in [RFC6055], section 3. 98 Nevertheless, there is a widespread belief that in many circumstances 99 domain names cannot be used in the DNS unless they cleave to the LDH 100 rule. 102 At the same time, mDNS requires that labels be encoded in UTF-8, and 103 permits a range of characters in labels that are not permitted by 104 IDNA2008 or the LDH rule. For example, mDNS encourages the use of 105 spaces and punctuation in mDNS names (see [RFC6763], section 4.1.3). 106 It does not restrict which Unicode code points may be used in those 107 labels, so long as the code points are UTF-8 in Net-Unicode [RFC5198] 108 format. 110 Users and developers of applications are, of course, frequently 111 unconcerned with (not to say oblivious to) the name-resolution 112 system(s) in service at any given moment, and are inclined simply to 113 use the same domain names in different contexts. As a result, the 114 same domain name might be tried using different name resolution 115 technologies. If a given name will not work across the various 116 environments, then user expectations are likely to be best satisfied 117 when at least some parts of the domain names to be queried are 118 compatible with the rules and conventions for all the relevant 119 technologies. Given the uses of DNS-SD, a choice for such 120 compatibility likely lies with the application designer or service 121 operator. 123 One approach to interoperability under these circumstances is to use 124 a single operational convention (a "profile") for domain names under 125 the different naming systems. This memo assumes such a use profile, 126 and attempts to outline what is necessary to make it work without 127 specifying any particular technology. It does assume, however, that 128 the global DNS is eventually likely to be implicated. Given the 129 general tendency of all resolution eventually to fall through to the 130 DNS, that assumption does not seem controversial. 132 It is worth noting that users of DNS-SD do not use the service 133 discovery names in the same way that users of other domain names 134 might. In many cases, domain names can be entered as direct user 135 input. But the service discovery context generally assumes users are 136 picking a service from a list. As a result, the sorts of application 137 considerations that are appropriate to the general-purpose DNS name, 138 and that resulted in the A-label/U-label split (see below) in 139 IDNA2008, are not entirely the right approach for DNS-SD. 141 1.1. Conventions and terms used in this document 143 Wherever appropriate, this memo uses the terminology defined in 144 Section 2 of [RFC5890]. In particular, the reader is assumed to be 145 familiar with the terms "U-label", "LDH label", and "A-label" from 146 that document. Similarly, the reader is assumed to be familiar with 147 the U+NNNN notation for Unicode code points used in [RFC5890] and 148 other documents dealing with Unicode code points. In the interests 149 of brevity and consistency, the definitions are not repeated here. 151 Sometimes this memo refers to names in the DNS as though the LDH rule 152 and IDNA2008 are strict requirements. They are not. DNS labels are, 153 in principle, just collections of octets, and therefore in principle 154 the LDH rule is not a constraint. In practice, applications 155 sometimes intercept labels that do not conform to the LDH rule and 156 apply IDNA and other transformations. 158 The DNS, perhaps unfortunately, has produced its own jargon. 159 Unfamiliar DNS-related terms in this memo should be found in 160 [RFC7719]. 162 The term "owner name" (common to the DNS vernacular; see above) is 163 used here to apply not just to the domain names to be looked up in 164 the DNS, but to any name that might be looked up either in the DNS or 165 using another technology. It therefore includes names that might not 166 actually exist anywhere. In addition, what follows depends on the 167 idea that not every domain name will be looked up in the DNS. For 168 instance, names ending in "local." (in the presentation format) are 169 not ordinarily looked up using DNS, but instead looked up using mDNS. 171 DNS-SD specifies three portions of the owner name for a DNS-SD 172 resource record. These are the portion, the 173 portion, and the portion. The owner name made of these 174 three parts is called the Service Instance Name. It is worth 175 observing that a portion may be more than one label long. See 176 [RFC6763], section 4.1. Further discussion of the parts is found in 177 Section 4. 179 Throughout this memo, mDNS is used liberally as the alternative 180 resolution mechanism to DNS. This is for convenience rather than 181 rigour: any alternative name resolution to DNS could present the same 182 friction with the prevailing operational conventions of the global 183 DNS. It so happens that mDNS is the overwhelmingly successful 184 alternative as of this writing, so it is used in order to make the 185 issues plainer to the reader. Other alternative resolution 186 mechanisms may in general be read wherever mDNS appears in the text, 187 except where details of the mDNS specification appear. 189 2. Why there could be a problem at all 191 One might reasonably wonder why there is a problem to be solved at 192 all. After all, DNS labels permit any octet whatsoever, and anything 193 that can be useful with DNS-SD cannot use any names that are outside 194 the protocol strictures of the DNS. 196 The reason for the trouble is twofold. First, and least troublesome, 197 is the possibility of resolvers that are attempting to offer IDNA 198 service system-wide. Given the design of IDNA2008, it is reasonable 199 to suppose that on some systems high-level name resolution libraries 200 will perform the U-label/A-label transformation automatically, saving 201 applications from these details. But system-level services do not 202 always have available to them the resolution context, and may apply 203 the transformation in a way that foils rather than helps the 204 application. Of course, if this were the main problem, it would 205 presumably be self-correcting; for the right answer would be, "Don't 206 use those libraries for DNS-SD," and DNS-SD would not work reliably 207 in cases where such libraries were in use. This would be 208 unfortunate; but given that DNS-SD in Internet contexts is as of this 209 writing not in ubiquitous use, it should not represent a fatal issue. 211 The greater problem is that the "infrastructure" types of DNS service 212 -- the root zone, the top-level domains, and so on -- have embraced 213 IDNA and refuse registration of raw UTF-8 into their zones. As of 214 this writing there is (perhaps unfortunately) no reliable way to 215 discover where these sorts of DNS services end. Nevertheless, some 216 client programs (notably web browsers) have adopted a number of 217 different policies about how domain names will be looked up and 218 presented to users given the policies of the relevant DNS zone 219 operators. None of these policies permit raw UTF-8. Since it is 220 anticipated that DNS-SD when used with the DNS will be inside domain 221 names beneath those kinds of "infrastructure" domains, the 222 implications of IDNA2008 must be a consideration. 224 For further exploration of issues relating to encoding of domain 225 names generally, the reader should consult [RFC6055]. 227 3. Requirements for a profile for label interoperation 229 Any interoperability between DNS (including prevailing operational 230 conventions) and other resolution technologies will require 231 interoperability across the portions of a DNS-SD Service Instance 232 Name that are implicated in regular DNS lookups. Only some portions 233 are implicated. In any case, if a given portion is implicated, the 234 profile will need to apply to all labels in that portion. 236 In addition, because DNS-SD Service Instance Names can be used in a 237 domain name slot, care must be taken by DNS-SD-aware resolvers to 238 handle the different portions as outlined here, so that DNS-SD 239 portions that do not use IDNA2008 will not be treated as U-labels and 240 will not accidentally undergo IDNA processing. 242 Because the profile will apply to names that might appear in the 243 public DNS, and because other resolution mechanisms (such as mDNS) 244 could permit labels that IDNA does not, the profile might reduce the 245 labels that could be used with those other resolution mechanisms. 246 One consequence of this is that some recommendations from [RFC6763] 247 will not really be possible to implement using names subject to the 248 profile. In particular, [RFC6763], section 4.1.3 recommends that 249 labels always be stored and communicated as UTF-8, even in the DNS. 250 Because of the way the public DNS is currently operated (see 251 Section 2), the advice to store and transmit labels as UTF-8 in the 252 DNS is likely either to encounter problems, or to result in 253 unnecessary traffic to the public DNS, or both. In particular, many 254 labels in the part of a Service Instance Name are unlikely 255 to be found in the UTF-8 form in the public DNS tree for zones that 256 are using IDNA2008. By contrast, for example, mDNS normally uses 257 UTF-8. 259 U-labels cannot contain upper case letters (see [RFC5894], sections 260 3.1.3 and 4.2). That restriction extends to ASCII-range upper case 261 letters that work fine in LDH-labels. It may be confusing that the 262 character "A" works in the DNS when none of the characters in the 263 label has a diacritic, but does not work when there is such a 264 diacritic in the label. Labels in mDNS names (or other resolution 265 technologies) may contain upper case characters, so the profile will 266 need either to restrict the use of upper case or come up with a 267 convention for case folding (even in the presence of diacritics) that 268 is reliable and predictable to users. 270 4. DNS-SD portions 272 Service Instance Names are made up of three portions. 274 4.1. The Portion of the Service Instance Name 276 [RFC6763] is clear that the portion of the Service 277 Instance Name is intended for presentation to users, and therefore 278 virtually any character is permitted in it. There are two ways that 279 a profile might address this portion. 281 The first way would be to treat this portion as likely to be 282 intercepted by system-wide IDNA-aware (but otherwise context-unaware) 283 resolvers, or likely subject to strict IDNA conformance requirements 284 for publication in the relevant zone. In this case, the portion 285 would need to be made subject to the profile, thereby curtailing what 286 characters may appear in this portion. This approach permits DNS-SD 287 to use any standard system resolver but presents inconsistencies with 288 the DNS-SD specification and with DNS-SD use that is exclusively 289 mDNS-based. Therefore, this strategy is rejected. 291 Instead, DNS-SD implementations can intercept the portion 292 of a Service Instance Name and ensure that those labels are never 293 handed to IDNA-aware resolvers that might attempt to convert these 294 labels into A-labels. Under this approach, the DNS-SD 295 portion works as it always does, but at the cost of using special 296 resolution code built into the DNS-SD system. A practical 297 consequence of this is that zone operators need to be prepared not to 298 apply the LDH rule to all labels, and may need to make special 299 concessions to ensure that the portion can contain spaces, 300 upper and lower case, and any UTF-8 code point; or else to prepare a 301 user interface to handle the exceptions that would otherwise be 302 generated. Automatic conversion to A-labels is not acceptable. 304 It is worth noting that this advice is not actually compatible with 305 advice in [RFC6055], section 4. That section appears to assume that 306 names are not really composed of subsections, but because [RFC6763] 307 specifies portions of names, the advice in this memo is to follow the 308 advice of [RFC6055] according to the portion of the domain name, 309 rather than for the whole domain name. As a practical matter, this 310 likely means special-purpose name resolution software for DNS-SD. 312 4.2. The Portion of the Service Instance Name 314 DNS-SD includes a component in the Service Instance Name. 315 This component is not really user-facing data, but is instead control 316 data embedded in the Service Instance Name. This component includes 317 so-called "underscore labels", which are labels prepended with U+005F 318 (_). The underscore label convention was established by DNS SRV 319 ([RFC2782]) for identifying metadata inside DNS names. A system-wide 320 resolver (or DNS middlebox) that cannot handle underscore labels will 321 not work with DNS-SD at all, so it is safe to suppose that such 322 resolvers will not attempt to do special processing on these labels. 323 Therefore, the portion of the Service Instance Name will 324 not be subject to the profile. By the same token, underscore labels 325 are never subject to IDNA processing (they are formally 326 incompatible), and therefore concerns about IDNA are irrelevant for 327 these labels. 329 4.3. The Portion of the Service Instance Name 331 The portion of the Service Instance Name forms an integral 332 part of the owner name submitted for DNS resolution. A system-wide 333 resolver that is IDNA2008-aware is likely to interpret labels with 334 UTF-8 in the owner name as candidates for IDNA2008 processing. More 335 important, operators of internationalized domain names will 336 frequently publish such names in the public DNS as A-labels; 337 certainly, the top-most labels will always be A-labels. Therefore, 338 these labels will need to be subject to the profile. DNS-SD 339 implementations ought somehow to identify the portion of the 340 Service Instance Name and treat it subject to IDNA2008 in case the 341 domain is to be queried from the global DNS. In the event that the 342 portion of the Service Instance Name fails to resolve, it is 343 acceptable to substitute labels with plain UTF-8, starting at the 344 lowest label in the DNS tree and working toward the root. This 345 approach differs from the rule for resolution published in [RFC6763], 346 because it privileges IDNA2008-compatible labels over UTF-8 labels. 347 There is more than one way to achieve such a result, but in terms of 348 predictability it is probably best if the lowest-level resolution 349 component is able to learn the correct resolution context, so that it 350 can perform the correct transformations on the various domain 351 portions. 353 One might argue against the above restriction on either of two 354 grounds: 356 1. It is possible the names may be in the DNS in UTF-8, and RFC 6763 357 already specifies a fallback strategy of progressively attempting 358 first the UTF-8 label lookup (it might not be a U-label) and then 359 if possible the A-label lookup. 361 2. Zone administrators that wish to support DNS-SD can publish a 362 UTF-8 version of the zone along side the A-label version of the 363 zone. 365 The first of these is rejected because it represents a potentially 366 significant increase in DNS lookup traffic for no value. It is 367 possible for a DNS-SD application to identify the portion of 368 the Service Instance Name. The standard way to publish IDNs on the 369 Internet uses IDNA. Therefore, additional lookups should not be 370 encouraged. When [RFC6763] was published, the bulk of IDNs were 371 lower in the tree. Now that there are internationalized labels in 372 the root zone, it is desirable to minimize queries to the Internet 373 infrastructure if they are sure to be answered in the negative. 375 The second reason depends on the idea that it is possible to maintain 376 two names in sync with one another. This is not strictly speaking 377 true, although in this case the domain operator could simply create a 378 DNAME record [RFC6672] from the UTF-8 name to the IDNA2008 zone. 379 This still, however, relies on being able to reach the (UTF-8) name 380 in question, and it is unlikely that the UTF-8 version of the zone 381 will be delegated from anywhere. Moreover, in many organizations the 382 support for DNS-SD and the support for domain name delegations are 383 not performed by the same department, and depending on a co- 384 ordination between the two will make the system more fragile, or 385 slower, or both. 387 Some resolvers -- particularly those that are used in mixed DNS and 388 non-DNS environments -- may be aware of different operational 389 conventions in different parts of the DNS tree. For example, it may 390 be possible for implementations to use hints about the boundary of an 391 organization's domain name infrastructure, in order to tell (for 392 instance) that example.com. is part of the Example Organization while 393 com. is a large delegation-centric zone on the public Internet. In 394 such cases, the resolution system might reverse its preferences to 395 prefer plain UTF-8 labels when resolving names below the boundary 396 point in the DNS tree. The result would be that any lookup past the 397 boundary point and closer to the root would use LDH-labels first, 398 falling back to UTF-8 only after a failure; but a lookup below the 399 boundary point would use UTF-8 labels first, and try other strategies 400 only in case of negative answers. The mechanism to learn such a 401 boundary is beyond the scope of this document. 403 5. Acknowledgements 405 The author gratefully acknowledges the insights of Joe Abley, Stuart 406 Cheshire, Paul Hoffman, Kerry Lynn, and Dave Thaler. Kerry Lynn 407 deserves special gratitude for his energy and persistence in pressing 408 unanswered questions. Doug Otis sent many comments about visual 409 confusability. 411 6. IANA Considerations 413 This memo makes no requests of IANA. 415 7. Security Considerations 417 This memo presents some requirements for future development, but does 418 not specify anything. It makes no additional security-specific 419 requirements. Issues arising due to visual confusability of names 420 apply to this case as well as to any other case of internationalized 421 names, but interoperation between different resolution systems and 422 conventions does not alter the severity of those issues. 424 8. Informative References 426 [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet 427 host table specification", RFC 952, October 1985. 429 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 430 STD 13, RFC 1034, November 1987. 432 [RFC1035] Mockapetris, P., "Domain names - implementation and 433 specification", STD 13, RFC 1035, November 1987. 435 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 436 Specification", RFC 2181, July 1997. 438 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 439 specifying the location of services (DNS SRV)", RFC 2782, 440 February 2000. 442 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 443 Interchange", RFC 5198, March 2008. 445 [RFC5890] Klensin, J., "Internationalized Domain Names for 446 Applications (IDNA): Definitions and Document Framework", 447 RFC 5890, August 2010. 449 [RFC5891] Klensin, J., "Internationalized Domain Names in 450 Applications (IDNA): Protocol", RFC 5891, August 2010. 452 [RFC5892] Faltstrom, P., "The Unicode Code Points and 453 Internationalized Domain Names for Applications (IDNA)", 454 RFC 5892, August 2010. 456 [RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left Scripts for 457 Internationalized Domain Names for Applications (IDNA)", 458 RFC 5893, August 2010. 460 [RFC5894] Klensin, J., "Internationalized Domain Names for 461 Applications (IDNA): Background, Explanation, and 462 Rationale", RFC 5894, August 2010. 464 [RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for 465 Internationalized Domain Names in Applications (IDNA) 466 2008", RFC 5895, September 2010. 468 [RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on 469 Encodings for Internationalized Domain Names", RFC 6055, 470 February 2011. 472 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 473 DNS", RFC 6672, June 2012. 475 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 476 February 2013. 478 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 479 Discovery", RFC 6763, February 2013. 481 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 482 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 483 2015, . 485 Appendix A. Change History 487 Note to RFC Editor: this section should be removed prior to 488 publication. 490 A.1. draft-ietf-dnssd-mdns-dns-interop-04 492 o Unchaged content to reset the I-D repo timer. 494 A.2. draft-ietf-dnssd-mdns-dns-interop-03 496 o Additional alteration of title 498 o Attempt to address WGLC comments from Dave Thaler (2016-04-02) 500 A.3. draft-ietf-dnssd-mdns-dns-interop-02 502 o Altered the title to make it more generic than mDNS. 504 o Addressed issues raised by Dave Thaler in review on 2015-07-18. 506 o Added a note to Section 7 about visual confusion. I don't know 507 whether this will satisfy Doug Otis but it is the only thing I can 508 see that could possibly be relevant. 510 o Added discussion of finding "boundary" in Section 4.3. 512 A.4. draft-ietf-dnssd-mdns-dns-interop-01 514 Alter text to make clear that the main issue is the way the public 515 DNS is currently administered, not system resolvers. I suppose this 516 should have been clear before, but I didn't do that. Many thanks to 517 Kerry Lynn for penetrating questions that illuminated what I'd left 518 out. 520 A.5. draft-ietf-dnssd-mdns-dns-interop-00 522 1st WG version 524 Add text to make clear that fallback from A-label lookup to UTF-8 525 label lookup ok, per WG comments at IETF 91 527 A.6. draft-sullivan-dnssd-mdns-dns-interop-01 529 o Decided which portions would be affected 531 o Explained the difference in user interfaces between DNS-SD and 532 usual DNS operation 534 o Provided background on why the Domain portion should be treated 535 differently 537 A.7. draft-sullivan-dnssd-mdns-dns-interop-00 539 Initial version. 541 Author's Address 543 Andrew Sullivan 544 Dyn 545 150 Dow St. 546 Manchester, NH 03101 547 U.S.A. 549 Email: asullivan@dyn.com