idnits 2.17.1 draft-iab-dns-assumptions-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 637. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 614. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 621. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 627. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 6 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 5, 2005) is 7051 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. '5') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2326 (ref. '6') (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 2821 (ref. '9') (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 2818 (ref. '16') (Obsoleted by RFC 9110) == Outdated reference: A later version (-08) exists of draft-iab-dns-choices-00 Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Rosenberg 2 Internet-Draft IAB 3 Expires: July 6, 2005 January 5, 2005 5 What's in a Name: False Assumptions about DNS Names 6 draft-iab-dns-assumptions-01 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of section 3 of RFC 3667. By submitting this Internet-Draft, each 12 author represents that any applicable patent or other IPR claims of 13 which he or she is aware have been or will be disclosed, and any of 14 which he or she become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on July 6, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 The Domain Name System (DNS) provides an essential service on the 42 Internet, mapping structured names to a variety of data, usually IP 43 addresses. These names appear in email addresses, URIs, and other 44 application layer identifiers that are often rendered to human users. 45 Because of this, there has been a strong demand to acquire names that 46 have significance to people, through equivalence to registered 47 trademarks, company names, types of services, and so on. A danger of 48 this trend is that the humans and automata which consume and use 49 these identifiers will make assumptions about the services that are 50 or should be provided by the hosts associated with these identifiers. 51 This document discusses this problem in more detail and makes 52 recommendations on how it can be avoided. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Modeling Usage of the DNS . . . . . . . . . . . . . . . . . . 4 58 3. Possible Assumptions . . . . . . . . . . . . . . . . . . . . . 5 59 3.1 By the User . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.2 By the Client . . . . . . . . . . . . . . . . . . . . . . 5 61 3.3 By the Server . . . . . . . . . . . . . . . . . . . . . . 6 62 4. Consequences of False Assumptions . . . . . . . . . . . . . . 7 63 5. Reasons why the Assumptions can be False . . . . . . . . . . . 8 64 5.1 Evolution . . . . . . . . . . . . . . . . . . . . . . . . 8 65 5.2 Leakage . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 5.3 Sub Delegation . . . . . . . . . . . . . . . . . . . . . . 9 67 6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 10 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 70 9. IAB Members . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 10. Informative References . . . . . . . . . . . . . . . . . . . 12 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 73 Intellectual Property and Copyright Statements . . . . . . . . 15 75 1. Introduction 77 The Domain Name System (DNS) [1] provides an essential service on the 78 Internet, mapping structured names to a variety of different types of 79 data. Most often it is used to obtain the IP address of a host 80 associated with that name [2][1][3]. However, it can be used to 81 obtain other information, and proposals have been made for nearly 82 everything, including geographic information [4]. 84 Domain names are most often used in identifiers used by application 85 protocols. The most well known include email addresses and URIs, 86 such as the HTTP URL [5], RTSP URL [6] and SIP URI [7]. These 87 identifiers are ubiquitous, appearing on business cards, web pages, 88 street signs, and so on. Because of this, there has been a strong 89 demand to acquire domain names that have significance to people 90 through equivalence to registered trademarks, company names, types of 91 services, and so on. Such identifiers serve many business purposes, 92 including extension of brand, advertising, and so on. 94 People often make assumptions about the type of service that is or 95 should be provided by a host associated with that name. This problem 96 first manifested itself in the "DNS land grab" that occurred through 97 the registration of trademarked names by people who were not owners 98 of those trademarks. The reason people did that is that they knew 99 that users who saw the name in an HTTP URL would assume that the URL 100 referenced a site associated with the trademarked name. Another 101 example are the various proposals for a TLD that could be associated 102 with adult content [8]. Yet another example are requests for TLDs 103 associated with mobile devices and services. 105 The essence of the problem is that humans will frequently make 106 assumptions about a name based on their expectations and 107 understanding of what the name implies. When these assumptions are 108 wrong, the user might be surprised, but the system works, and the 109 human can do something different having realized that its assumption 110 was false. When an automaton makes similar assumptions, the system 111 might fail, and it might fail systematically. For this reason, this 112 document focuses primarily on assumptions that might be made by 113 client and server automata about the service that is or should be 114 provided by a host associated with a DNS name. In this context, an 115 "assumption" is defined as any behavior that is expected when 116 accessing a service at a domain name, even though the behavior is not 117 explicitly indicated in the DNS or otherwise codified in protocol 118 specifications. Although the DNS can contain data besides host 119 identifiers (i.e., IP addresses), we only consider the usage of the 120 DNS for the purposes of translating a name to a host address. 122 2. Modeling Usage of the DNS 124 +--------+ 125 | | 126 | | 127 | DNS | 128 |Service | 129 | | 130 +--------+ 131 ^ | 132 | | 133 | | 134 | | 135 /--\ | | 136 | | | V 137 | | +--------+ +--------+ 138 \--/ | | | | 139 | | | | | 140 ---+--- | Client |-------------------->| Server | 141 | | | | | 142 | | | | | 143 /\ +--------+ +--------+ 144 / \ 145 / \ 147 User 149 Figure 1 151 Figure 1 shows a simple conceptual model of how the DNS is used by 152 applications. A user of the application obtains an identifier for 153 particular content or service it wishes to obtain. This identifier 154 is often a URL or URI that contains a domain name. The user enters 155 this identifier into their client application (for example, by typing 156 in the URL in a web browser window). The client is the automaton (a 157 software and/or hardware system) that contacts a server for that 158 application in order to provide service to the user. To do that, it 159 contacts a DNS server to resolve the domain name in the identifier to 160 an IP address. It then contacts the server at that IP address. This 161 simple model applies to application protocols such as HTTP [5], SIP 162 [7], RTSP [6], and SMTP [9]. 164 From this model, it is clear that three entities in the system can 165 potentially make false assumptions about the service provided by the 166 server. The human user may form expectations relating to the content 167 of the service based on a parsing of the host name from which the 168 content originated. The server might assume that the client 169 connecting to it supports protocols that it does not, can process 170 content that it cannot, or has capabilities that it does not. 171 Similarly, the client might assume that the server supports 172 protocols, content, or capabilities that it does not. 174 3. Possible Assumptions 176 For each of the three elements, there are many types of false 177 assumptions that can be made. 179 3.1 By the User 181 The set of possible assumptions here is nearly boundless. A user 182 might assume that an HTTP URL that looks like a company name maps to 183 a server run by that company. They might assume that an email from a 184 email address in the .gov TLD is actually from a government employee. 185 They might assume that the content obtained from a web server within 186 a TLD labeled as containing adult materials (for example, .sex) 187 actually contains adult content [8]. These assumptions are 188 unavoidable, may all be false, and not the focus of this document. 190 3.2 By the Client 192 Even though the client is an automaton, it can make some of the same 193 assumptions that a human user might make. For example, many clients 194 assume that any host with a hostname that begins with "www" is a web 195 server, even though this assumption may be false. 197 In addition, the client concerns itself with the protocols needed to 198 communicate with the server. As a result, it might make assumptions 199 about the operation of the protocols for communicating with the 200 server. These assumptions manifest themselves in an implementation 201 through the replacement of a standardized protocol negotiation 202 technique for an ill-defined rule for determining some kind of 203 protocol parameter. The result is often a loss of interoperability, 204 degradation in reliability and worsening of user experience. 206 Authentication Algorithm: Though a protocol might support a 207 multiplicity of authentication techniques, a client might assume 208 that a server always supports one that is only optional according 209 to the protocol. For example, a SIP client contacting a SIP 210 server in a domain that appeared to be used to identify mobile 211 devices (for example, www.example.cellular) might assume it 212 supports the optional AKA digest technique [10]. As another 213 example, a web client might assume that a server with the name 214 https.example.com supports HTTP over TLS [16]. 216 Data Formats: Though a protocol might allow a multiplicity of data 217 formats to be sent from the server to the client, the client might 218 assume a specific one, rather than using the content labeling and 219 negotiation capabilities of the underlying protocol. For example, 220 an RTSP client might assume that all audio content delivered to it 221 from media.example.cellular uses a low bandwidth codec. As 222 another example, a mail client might assume that the contents of 223 messages it retrieves from a mail server at mail.example.cellular 224 are always text, instead of checking the MIME headers [11] in the 225 message to determine the actual content type. 227 Protocol Extensions: The client attempts an operation on the server 228 which requires the server to support an optional protocol 229 extension. However, the client merely assumes that this extension 230 is supported, rather than implementing the fallback logic 231 necessary if it is not. As an example, a SIP client requires 232 reliable provisional responses to its request (RFC 3262 [17]), and 233 it assumes that this extension is supported on servers in the 234 domain sip.example.telecom. Furthermore, the client has not 235 implemented the fallback behavior defined in RFC 3262, since it 236 assumes that all servers it will communicate with are in this 237 domain, and that all support this extension. However, this 238 assumption proves wrong. The result is that the client is unable 239 to make any phone calls. 241 Languages: The client supports facilities for processing text content 242 differently depending on the language of the text. Rather than 243 determining the language from markers in the message from the 244 server, the client assumes a language based on the domain name. 245 This assumption can easily be wrong. For example, a client might 246 assume that any text in a web page retrieved from www.example.de 247 is in German, and attempt a translation to Finnish. This would 248 fail dramatically if the text was actually in French. 250 3.3 By the Server 252 The server, like the client, is an automaton. It is servicing a 253 particular domain - www.company.cellular, for example. It might 254 assume that all clients connecting to this domain support particular 255 capabilities, rather than using the underlying protocol to make this 256 determination. Some examples include: 258 Authentication Algorithm: The server can assume that a client 259 supports a particular, optional, authentication technique, and it 260 therefore does not support the mandatory one. 262 Data Formats: The server can assume that the client supports a 263 particular set of MIME types, and is only capable of sending ones 264 within that set. When it generates content in a protocol 265 response, it ignores any content negotiation headers that were 266 present in the request. For example, a web server might ignore 267 the Accept HTTP header field and send a specific image format. 269 Protocol Extensions: The server might assume that the client supports 270 a particular optional protocol extension, and so it does not 271 support the fallback behavior necessary in the case where it does 272 not. 274 Client Characteristics: The server might assume certain things about 275 the physical characteristics of its clients, such as memory 276 footprint, processing power, screen sizes, screen colors, pointing 277 devices, and so on. Based on these assumptions, it might choose 278 specific behaviors when processing a request. For example, a web 279 server might always assume that clients connect through cell 280 phones, and therefore return content that lacks images and is 281 tuned for such devices. 283 4. Consequences of False Assumptions 285 There are numerous negative outcomes that can arise from the various 286 false assumptions that users, servers and clients can make. These 287 include: 289 Interoperability Failure: In these cases, the client or server 290 assumed some kind of protocol operation which was wrong. The 291 result is that the two are unable to communicate, and the user 292 receives some kind of an error. This represents a total 293 interoperability failure, manifesting itself as a lack of service 294 to users of the system. Unfortunately, this kind of failure 295 persists. Repeated attempts over time by the client to access the 296 service will fail. Only a change in the server or client software 297 can fix this problem. 299 System Failure: In these cases, the client or server mis-interpreted 300 a protocol operation, and this mis-interpretation was serious 301 enough to uncover a bug in the implementation. The bug causes a 302 system crash or some kind of outage, either transient or permanent 303 (until user reset). If this failure occurs in a server, not only 304 will the connecting client lose service, but other clients 305 attempting to connect will not get service. As an example, if a 306 web server assumes that content passed to it from a client 307 (created, for example, by a digital camera) is of a particular 308 content type, and it always passes image content to a codec for 309 de-compression prior to storage, the codec might crash when it 310 unexpectedly receives an image compressed in a different format. 312 Poor User Experience: In these cases, the client and server 313 communicate, but the user receives a diminished user experience. 314 For example, if a client on a PC connects to a web site that 315 provides content for mobile devices, the content may be 316 underwhelming when viewed on the PC. Or, a client accessing a 317 streaming media service may receive content of very low bitrate, 318 even though the client supported better codecs. Indeed, if a user 319 wishes to access content from both a cellular device and a PC 320 using a shared address book (that is, an address book shared 321 across multiple devices), they would need two entries in that 322 address book, and would need to use the right one from the right 323 device. This is a poor user experience. 325 5. Reasons why the Assumptions can be False 327 Assumptions made by clients and servers about the operation of 328 protocols when contacting a particular domain are brittle, and can be 329 wrong for many reasons. On the server side, many of the assumptions 330 are based on the notion that a domain name will only be given to, or 331 used by, a restricted set of clients. If the owner of the domain 332 assumes something about those clients, and can assume that only those 333 clients use the domain name, that it can configure or program the 334 server to operate specifically for those clients. Both parts of this 335 assumption can be wrong, as discussed in more detail below. 337 On the client side, the notion is similar, being based on the 338 assumption that a server within a particular domain will provide a 339 specific type of service. Sub-delegation and evolution, both 340 discussed below, can make these assumptions wrong. 342 5.1 Evolution 344 The Internet, and the devices which access it, are constantly 345 evolving, often at a rapid pace. Unfortunately, there is a tendency 346 to build for the here and now, and then worry about the future at a 347 later time. Many of the assumptions above are predicated on 348 characteristics of today's clients and servers. Support for specific 349 protocols, authentication techniques or content are based on today's 350 standards and today's devices. Even though they may, for the most 351 part, be true, they won't always be. An excellent example is mobile 352 devices. A server servicing a domain accessed by mobile devices 353 might try to make assumptions about the protocols, protocol 354 extensions, security mechanisms, screen sizes or processor power of 355 such devices. However, all of these characteristics can and will 356 change over time. 358 When they do change, the change is usually evolutionary. The result 359 is that the assumptions remain valid in some cases, but not in 360 others. It is difficult to fix such systems, since it requires the 361 server to detect what type of client is connecting, and what its 362 capabilities are. Unless the system is built and deployed with these 363 capability negotiation techniques built in to begin with, such 364 detection can be extremely difficult. In fact, fixing it will often 365 require the addition of such capability negotiation features which, 366 if they had been in place and used to begin with, would have avoided 367 the problem altogether. 369 5.2 Leakage 371 Servers also make assumptions because of the belief that they will 372 only be accessed by specific clients, and in particular, those which 373 are configured or provisioned to use the domain name. In essence, 374 there is an assumption of community - that a specific community knows 375 and uses the domain name, while others outside of the community do 376 not. 378 The problem is that this notion of community is a false one. The 379 Internet is global. The DNS is global. There is no technical 380 barrier that separates those inside of the community from those 381 outside. The ease with which information propagates across the 382 Internet makes it extremely likely that such domain names will 383 eventually find their way into clients outside of the presumed 384 community. The ubiquitous presence of domain names in various URI 385 formats, coupled with the ease of conveyance of URIs, makes such 386 leakage merely a matter of time. Furthermore, since the DNS is 387 global, and since it can only have one root [12], it becomes possible 388 for clients outside of the community to search and find and use such 389 "special" domain names. 391 5.3 Sub Delegation 393 Clients and users make assumptions about domains because of the 394 notion that there is some kind of centralized control that can 395 enforce those assumptions. However, the DNS is not centralized, it 396 is distributed. If a domain doesn't delegate its sub-domains and has 397 its records within a single zone, it is possible to maintain a 398 centralized policy about operation of its domain. However, once a 399 domain gets sufficiently large that it begins to delegate sub-domains 400 to other authorities, it becomes increasingly difficult to maintain 401 any kind of central control on the nature of the service provided in 402 each sub-domain. Adherance to policies could be checked by having a 403 robot periodically sweep the records in all sub-domains; this will 404 only validate policies which are explicit within the record 405 themselves (such as TTLs), and even then, it will be slow. Worse 406 yet, most policies (such as support for specific protocol extensions) 407 cannot be learned from the DNS itself, and cannot be verified in an 408 automated way. The other choice is to hope that any centralized 409 policies are being followed, and then wait for complaints. That 410 approach has many problems. 412 The invalidation of assumptions due to sub-delegation is discussed in 413 further detail by Eastlake in Section 4.1.3 of [8] and by Faltstrom 414 in Section 3.3 of [19]. 416 As a result of the fragility of policy continuity across 417 sub-delegations, if a client or user assumes some kind of property 418 associated with a TLD (such as ".wifi"), it becomes exponentially 419 more likely with the number of sub-domains that this property will 420 not exist in a server identified by a particular name. For example, 421 in "store.chain.company.provider.wifi", there may be four levels of 422 delegation from ".wifi", making it quite likely that the properties 423 which the owner of ".wifi" wishes to enforce are not present. These 424 properties may not be present due to human error or due to a willful 425 decision not to adhere to them. 427 6. Recommendations 429 Based on these problems, the clear conclusion is that clients, 430 servers and users should not make assumptions on the nature of the 431 service provided to, or by, a domain. More specifically, however, 432 the following can be said: 434 Follow the Specifications: When specifications define mandatory 435 baseline procedures and formats, those should be implemented and 436 supported, even if the expectation is that optional procedures 437 will most often be used. For example, if a specification mandates 438 a particular baseline authentication technique, but allows others 439 to be negotiated and used, implementations need to implement the 440 baseline authentication algorithm even if the other ones are used 441 most of the time. 443 Use Capability Negotiation: Many protocols are engineered with 444 capability negotiation mechanisms. For example, a content 445 negotiation framework has been defined for protocols using MIME 446 content [13][14][15]. SIP allows for clients to negotiate the 447 media types used in the multimedia session, as well as protocol 448 parameters. HTTP allows for clients to negotiate the media types 449 returned in requests for content. When such features are 450 available in a protocol, client and servers should make use of 451 them rather than making assumptions about supported capabilities. 453 A corollary is that protocol designers should include such 454 mechanisms when evolution is expected in the usage of the 455 protocol. 457 The DNS Record Type Says it All: The only assumptions one can make 458 about the service defined by the name are encapsulated in the DNS 459 resource record type that is retrieved. For example, if an A or 460 AAAA record exists for the domain web.example.com, one cannot 461 assume that web service is available at the domain, since all the 462 A or AAAA record says is that the host with that name has a 463 particular IP address. The only way to definitively know if a 464 service is available at a domain is through SRV records [2]. As 465 an example, a client can do a query for _sip._udp.example.com to 466 learn if a server is listening for SIP requests over UDP within 467 the example.com domain [18]. 469 To summarize - there is never a need to make assumptions. Rather 470 than doing so, utilize the specifications and the negotiation 471 capabilities they provide, and the overall system will be robust and 472 interoperable. 474 7. Security Considerations 476 One of the assumptions that can be made by clients or servers is the 477 availability and usage (or lack thereof) of certain security 478 protocols and algorithms. For example, a client accessing a service 479 in a particular domain might assume a specific authentication 480 algorithm or hash function in the application protocol. It is 481 possible that, over time, weaknesses are found in such a technique, 482 requiring usage of a different mechanism. Similarly, a system might 483 start with an insecure mechanism, and then decide later on to use a 484 secure one. In either case, assumptions made on security properties 485 can result in interoperability failures, or worse yet, providing 486 service in an insecure way, even though the client asked for, and 487 thought it would get, secure service. This kinds of assumptions are 488 fundamentally unsound even if the records themselves are secured with 489 DNSSEC. 491 8. Acknowledgements 493 The IAB would like to thank Brian Carpenter for his comments. 495 9. IAB Members 497 Internet Architecture Board members at the time of writing of this 498 document are: 500 Bernard Aboba 502 Harald Alvestrand 504 Rob Austein 506 Leslie Daigle 508 Patrik Faltstrom 510 Sally Floyd 512 Mark Handley 514 Bob Hinden 516 Geoff Huston 518 Jun-ichiro Itojun Hagino 520 Eric Rescorla 522 Pete Resnick 524 Jonathan Rosenberg 526 10 Informative References 528 [1] Mockapetris, P., "Domain names - concepts and facilities", STD 529 13, RFC 1034, November 1987. 531 [2] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 532 specifying the location of services (DNS SRV)", RFC 2782, 533 February 2000. 535 [3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 536 Three: The Domain Name System (DNS) Database", RFC 3403, 537 October 2002. 539 [4] Davis, C., Vixie, P., Goodwin, T. and I. Dickinson, "A Means 540 for Expressing Location Information in the Domain Name System", 541 RFC 1876, January 1996. 543 [5] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 544 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 545 HTTP/1.1", RFC 2616, June 1999. 547 [6] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming 548 Protocol (RTSP)", RFC 2326, April 1998. 550 [7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 551 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 552 Session Initiation Protocol", RFC 3261, June 2002. 554 [8] Eastlake, D., ".sex Considered Dangerous", RFC 3675, February 555 2004. 557 [9] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 558 2001. 560 [10] Niemi, A., Arkko, J. and V. Torvinen, "Hypertext Transfer 561 Protocol (HTTP) Digest Authentication Using Authentication and 562 Key Agreement (AKA)", RFC 3310, September 2002. 564 [11] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 565 Extensions (MIME) Part One: Format of Internet Message Bodies", 566 RFC 2045, November 1996. 568 [12] Internet Architecture Board, "IAB Technical Comment on the 569 Unique DNS Root", RFC 2826, May 2000. 571 [13] Klyne, G., "Indicating Media Features for MIME Content", RFC 572 2912, September 2000. 574 [14] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 575 2533, March 1999. 577 [15] Klyne, G., "Protocol-independent Content Negotiation 578 Framework", RFC 2703, September 1999. 580 [16] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 582 [17] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional 583 Responses in Session Initiation Protocol (SIP)", RFC 3262, June 584 2002. 586 [18] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 587 (SIP): Locating SIP Servers", RFC 3263, June 2002. 589 [19] Faltstrom, P. and R. Austein, "Design Choices When Expanding 590 DNS", draft-iab-dns-choices-00 (work in progress), October 591 2004. 593 Author's Address 595 Jonathan Rosenberg, Editor 596 IAB 597 600 Lanidex Plaza 598 Parsippany, NJ 07054 599 US 601 Phone: +1 973 952-5000 602 EMail: jdrosen@cisco.com 603 URI: http://www.jdrosen.net 605 Intellectual Property Statement 607 The IETF takes no position regarding the validity or scope of any 608 Intellectual Property Rights or other rights that might be claimed to 609 pertain to the implementation or use of the technology described in 610 this document or the extent to which any license under such rights 611 might or might not be available; nor does it represent that it has 612 made any independent effort to identify any such rights. Information 613 on the procedures with respect to rights in RFC documents can be 614 found in BCP 78 and BCP 79. 616 Copies of IPR disclosures made to the IETF Secretariat and any 617 assurances of licenses to be made available, or the result of an 618 attempt made to obtain a general license or permission for the use of 619 such proprietary rights by implementers or users of this 620 specification can be obtained from the IETF on-line IPR repository at 621 http://www.ietf.org/ipr. 623 The IETF invites any interested party to bring to its attention any 624 copyrights, patents or patent applications, or other proprietary 625 rights that may cover technology that may be required to implement 626 this standard. Please address the information to the IETF at 627 ietf-ipr@ietf.org. 629 Disclaimer of Validity 631 This document and the information contained herein are provided on an 632 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 633 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 634 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 635 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 636 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 637 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 639 Copyright Statement 641 Copyright (C) The Internet Society (2005). This document is subject 642 to the rights, licenses and restrictions contained in BCP 78, and 643 except as set forth therein, the authors retain all their rights. 645 Acknowledgment 647 Funding for the RFC Editor function is currently provided by the 648 Internet Society.