idnits 2.17.1 draft-iab-dns-assumptions-00.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 620. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 597. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 604. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 610. ** 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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages 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 (November 29, 2004) is 7085 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 (~~), 5 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: May 30, 2005 November 29, 2004 5 What's in a Name: False Assumptions about DNS Names 6 draft-iab-dns-assumptions-00 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 May 30, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). 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. IAB Members . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 9. Informative References . . . . . . . . . . . . . . . . . . . . 12 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13 72 Intellectual Property and Copyright Statements . . . . . . . . 14 74 1. Introduction 76 The Domain Name System (DNS) [1] provides an essential service on the 77 Internet, mapping structured names to a variety of different types of 78 data. Most often it is used to obtain the IP address of a host 79 associated with that name [2][1][3]. However, it can be used to 80 obtain other information, and proposals have been made for nearly 81 everything, including geographic information [4]. 83 Domain names are most often used in identifiers used by application 84 protocols. The most well known include email addresses and URIs, 85 such as the HTTP URL [5], RTSP URL [6] and SIP URI [7]. These 86 identifiers are ubiquitous, appearing on business cards, web pages, 87 street signs, and so on. Because of this, there has been a strong 88 demand to acquire domain names that have significance to people 89 through equivalence to registered trademarks, company names, types of 90 services, and so on. Such identifiers serve many business purposes, 91 including extension of brand, advertising, and so on. 93 People often make assumptions about the type of service that is or 94 should be provided by a host associated with that name. This problem 95 first manifested itself in the "DNS land grab" that occurred through 96 the registration of trademarked names by people who were not owners 97 of those trademarks. The reason people did that is that they knew 98 that users who saw the name in an HTTP URL would assume that the URL 99 referenced a site associated with the trademarked name. Another 100 example are the various proposals for a TLD that could be associated 101 with adult content [8]. Yet another example are requests for TLDs 102 associated with mobile devices and services. 104 The essence of the problem is that humans will frequently make 105 assumptions about a name based on their expectations and 106 understanding of what the name implies. When these assumptions are 107 wrong, the user might be surprised, but the system works, and the 108 human can do something different having realized that its assumption 109 was false. When an automata makes similar assumptions, the system 110 might fail, and it might fail systematically. For this reason, this 111 document focuses primarily on assumptions that might be made by 112 client and server automata about the service that is or should be 113 provided by a host associated with a DNS name. In this context, an 114 "assumption" is defined as any behavior that is expected when 115 accessing a service at a domain name, even though the behavior is not 116 explicitly indicated in the DNS or otherwise codified in protocol 117 specifications. Although DNS names can contain data besides host 118 identifiers (i.e., IP addresses), we consider only this case. 120 2. Modeling Usage of the DNS 122 +--------+ 123 | | 124 | | 125 | DNS | 126 |Service | 127 | | 128 +--------+ 129 ^ | 130 | | 131 | | 132 | | 133 /--\ | | 134 | | | V 135 | | +--------+ +--------+ 136 \--/ | | | | 137 | | | | | 138 ---+--- | Client |-------------------->| Server | 139 | | | | | 140 | | | | | 141 /\ +--------+ +--------+ 142 / \ 143 / \ 145 User 147 Figure 1 149 Figure 1 shows a simple conceptual model of how the DNS is used by 150 applications. A user of the application obtains an identifier for 151 particular content or service it wishes to obtain. This identifier 152 is often a URL or URI that contains a domain name. The user enters 153 this identifier into their client application (for example, by typing 154 in the URL in a web browser window). The client is the automata (a 155 software and/or hardware system) that contacts a server for that 156 application in order to provide service to the user. To do that, it 157 contacts a DNS server to resolve the domain name in the identifier to 158 an IP address. It then contacts the server at that IP address. This 159 simple model applies to application protocols such as HTTP [5], SIP 160 [7], RTSP [6], and SMTP [9]. 162 From this model, it is clear that three entities in the system can 163 potentially make false assumptions about the service provided by the 164 server. The human user may form expectations relating to the content 165 of the service based on a parsing of the host name from which the 166 content originated. The server might assume that the client 167 connecting to it supports protocols that it does not, can process 168 content that it cannot, or has capabilities that it does not. 169 Similarly, the client might assume that the server supports 170 protocols, content, or capabilities that it does not. 172 3. Possible Assumptions 174 For each of the three elements, there are many types of false 175 assumptions that can be made. 177 3.1 By the User 179 The set of possible assumptions here is nearly boundless. A user 180 might assume that an HTTP URL that looks like a company name maps to 181 a server run by that company. They might assume that an email from a 182 email address in the .gov TLD is actually from a government employee. 183 They might assume that the web content within a TLD labeled as adult 184 content (for example, .sex) is actually web content [8]. These 185 assumptions are unavoidable, and not the focus of this document. 187 3.2 By the Client 189 Since the client is an automata, it concerns itself with the 190 protocols needed to communicate with the server. As a result, the 191 assumptions it might make are assumptions in the operation of the 192 protocols for communicating with the server. These assumptions 193 manifest themselves in an implementation through the replacement of a 194 standardized protocol negotiation technique for an ill-defined rule 195 for determining some kind of protocol parameter. The result is often 196 a loss of interoperability, degradation in reliability and worsening 197 of user experience. 199 Authentication Algorithm: Though a protocol might support a 200 multiplicity of authentication techniques, a client might assume 201 that a server always supports one that is only optional according 202 to the protocol. For example, a SIP client contacting a SIP 203 server in a domain that appeared to be used to identify mobile 204 devices (for example, www.example.cellular) might assume it 205 supports the optional AKA digest technique [10]. As another 206 example, a web client might assume that a server with the name 207 https.example.com supports HTTP over TLS [16]. 209 Data Formats: Though a protocol might allow a multiplicity of data 210 formats to be sent from the server to the client, the client might 211 assume a specific one, rather than using the content labeling and 212 negotiation capabilities of the underlying protocol. For example, 213 an RTSP client might assume that all audio content delivered to it 214 from media.example.cellular uses a low bandwidth codec. As 215 another example, a mail client might assume that the contents of 216 messages it retrieves from a mail server at mail.pop.cellular are 217 always text, instead of checking the MIME headers [11] in the 218 message to determine the actual content type. 220 Protocol Extensions: The client attempts an operation on the server 221 which requires the server to support an optional protocol 222 extension. However, the client merely assumes that this extension 223 is supported, rather than implementing the fallback logic 224 necessary if it is not. As an example, a SIP client requires 225 reliable provisional responses to its request (RFC 3262 [17]), and 226 it assumes that this extension is supported on servers in the 227 domain sip.example.telecom. Furthermore, the client has not 228 implemented the fallback behavior defined in RFC 3262, since it 229 assumes that all servers it will communicate with are in this 230 domain, and that all support this extension. However, this 231 assumption proves wrong. The result is that the client is unable 232 to make any phone calls. 234 Languages: The client supports facilities for processing text content 235 differently depending on the language of the text. Rather than 236 determining the language from markers in the message from the 237 server, the client assumes a language based on the domain name. 238 This assumption can easily be wrong. For example, a client might 239 assume that any text in a web page retrieved from www.example.de 240 is in German, and attempt a translation to Finnish. This would 241 fail dramatically if the text was actually in French. 243 3.3 By the Server 245 The server, like the client, is an automata. It is servicing a 246 particular domain - www.company.cellular, for example. It might 247 assume that all clients connecting to this domain support particular 248 capabilities, rather than using the underlying protocol to make this 249 determination. Some examples include: 251 Authentication Algorithm: The server can assume that a client 252 supports a particular, optional, authentication technique, and it 253 therefore does not support the mandatory one. 255 Data Formats: The server can assume that the client supports a 256 particular set of MIME types, and is only capable of sending ones 257 within that set. When it generates content in a protocol 258 response, it ignores any content negotiation headers that were 259 present in the request. For example, a web server might ignore 260 the Accept HTTP header field and send a specific image format. 262 Protocol Extensions: The server might assume that the client supports 263 a particular optional protocol extension, and so it does not 264 support the fallback behavior necessary in the case where it does 265 not. 267 Client Characteristics: The server might assume certain things about 268 the physical characteristics of its clients, such as memory 269 footprint, processing power, screen sizes, screen colors, pointing 270 devices, and so on. Based on these assumptions, it might choose 271 specific behaviors when processing a request. For example, a web 272 server might always assume that clients connect through cell 273 phones, and therefore return content that lacks images and is 274 tuned for such devices. 276 4. Consequences of False Assumptions 278 There are numerous negative outcomes that can arise from the various 279 false assumptions that users, servers and clients can make. These 280 include: 282 Interoperability Failure: In these cases, the client or server 283 assumed some kind of protocol operation which was wrong. The 284 result is that the two are unable to communicate, and the user 285 receives some kind of an error. This represents a total 286 interoperability failure, manifesting itself as a lack of service 287 to users of the system. Unfortunately, this kind of failure 288 persists. Repeated attempts over time by the client to access the 289 service will fail. Only a change in the server or client software 290 can fix this problem. 292 System Failure: In these cases, the client or server mis-interpreted 293 a protocol operation, and this mis-interpretation was serious 294 enough to uncover a bug in the implementation. The bug causes a 295 system crash or some kind of outage, either transient or permanent 296 (until user reset). If this failure occurs in a server, not only 297 will the connecting client lose service, but other clients 298 attempting to connect will not get service. As an example, if a 299 web server assumes that content passed to it from a client 300 (created, for example, by a digital camera) is of a particular 301 content type, and it always passes image content to a codec for 302 de-compression prior to storage, the codec might crash when it 303 unexpectedly receives an image compressed in a different format. 305 Poor User Experience: In these cases, the client and server 306 communicate, but the user receives a diminished user experience. 307 For example, if a client on a PC connects to a web site that 308 provides content for mobile devices, the content may be 309 underwhelming when viewed on the PC. Or, a client accessing a 310 streaming media service may receive content of very low bitrate, 311 even though the client supported better codecs. Indeed, if a user 312 wishes to access content from both a cellular device and a PC 313 using a shared address book (that is, an address book shared 314 across multiple devices), they would need two entries in that 315 address book, and would need to use the right one from the right 316 device. This is a poor user experience. 318 5. Reasons why the Assumptions can be False 320 Assumptions made by clients and servers about the operation of 321 protocols when contacting a particular domain are brittle, and can be 322 wrong for many reasons. On the server side, many of the assumptions 323 are based on the notion that a domain name will only be given to, or 324 used by, a restricted set of clients. If the owner of the domain 325 assumes something about those clients, and can assume that only those 326 clients use the domain name, that it can configure or program the 327 server to operate specifically for those clients. Both parts of this 328 assumption can be wrong, as discussed in more detail below. 330 On the client side, the notion is similar, being based on the 331 assumption that a server within a particular domain will provide a 332 specific type of service. Sub-delegation and evolution, both 333 discussed below, can make these assumptions wrong. 335 5.1 Evolution 337 The Internet, and the devices which access it, are constantly 338 evolving, often at a rapid pace. Unfortunately, there is a tendency 339 to build for the here and now, and then worry about the future at a 340 later time. Many of the assumptions above are predicated on 341 characteristics of today's clients and servers. Support for specific 342 protocols, authentication techniques or content are based on today's 343 standards and today's devices. Even though they may, for the most 344 part, be true, they won't always be. An excellent example is mobile 345 devices. A server servicing a domain accessed by mobile devices 346 might make assumptions about the protocols, protocol extensions, 347 security mechanisms, screen sizes or processor power of such devices. 348 However, all of these characteristics can and will change over time. 350 When they do change, the change is usually evolutionary. The result 351 is that the assumptions remain valid in some cases, but not in 352 others. It is difficult to fix such systems, since it requires the 353 server to detect what type of client is connecting, and what its 354 capabilities are. Unless the system is built and deployed with these 355 capability negotiation techniques built in to begin with, such 356 detection can be extremely difficult. In fact, fixing it will often 357 require the addition of such capability negotiation features which, 358 if they had been in place and used to begin with, would have avoided 359 the problem altogether. 361 5.2 Leakage 363 Servers also make assumptions because of the belief that they will 364 only be accessed by specific clients, and in particular, those which 365 are configured or provisioned to use the domain name. In essence, 366 there is an assumption of community - that a specific community knows 367 and uses the domain name, while others outside of the community do 368 not. 370 The problem is that this notion of community is a false one. The 371 Internet is global. The DNS is global. There is no technical 372 barrier that separates those inside of the community from those 373 outside. The ease with which information propagates across the 374 Internet makes it extremely likely that such domain names will 375 eventually find their way into clients outside of the presumed 376 community. The ubiquitous presence of domain names in various URI 377 formats, coupled with the ease of conveyance of URIs, makes such 378 leakage merely a matter of time. Furthermore, since the DNS is 379 global, and since it can only have one root [12], it becomes possible 380 for clients outside of the community to search and find and use such 381 "special" domain names. 383 5.3 Sub Delegation 385 Clients and users make assumptions about domains because of the 386 notion that there is some kind of centralized control that can 387 enforce those assumptions. However, the DNS is not centralized, it 388 is distributed. If a domain doesn't delegate its sub-domains and has 389 its records within a single zone, it is possible to maintain a 390 centralized policy about operation of its domain. However, once a 391 domain gets sufficiently large that it begins to delegate sub-domains 392 to other authorities, it becomes increasingly difficult to maintain 393 any kind of central control on the nature of the service provided in 394 each sub-domain. Adherance to policies could be checked by having a 395 robot periodically sweep the records in all sub-domains; this will 396 only validate policies which are explicit within the record 397 themselves (such as TTLs), and even then, it will be slow. Worse 398 yet, most policies (such as support for specific protocol extensions) 399 cannot be learned from the DNS itself, and cannot be verified in an 400 automated way. The other choice is to hope that any centralized 401 policies are being followed, and then wait for complaints. That 402 approach has many problems. 404 The invalidation of assumptions due to sub-delegation is discussed in 405 further detail by Eastlake in Section 4.1.3 of [8] and by Faltstrom 406 in Section 3.3 of [19]. 408 As a result of the fragility of policy continuity across 409 sub-delegations, if a client or user assumes some kind of property 410 associated with a TLD (such as ".wifi"), it becomes exponentially 411 more likely with the number of sub-domains that this property will 412 not exist in a server identified by a particular name. For example, 413 in "store.chain.company.provider.wifi", there may be four levels of 414 delegation from ".wifi", making it quite likely that the properties 415 which the owner of ".wifi" wishes to enforce are not present. 417 6. Recommendations 419 Based on these problems, the clear conclusion is that clients, 420 servers and users should not make assumptions on the nature of the 421 service provided to, or by, a domain. More specifically, however, 422 the following can be said: 424 Follow the Specifications: When specifications define mandatory 425 baseline procedures and formats, those should be implemented and 426 supported, even if the expectation is that optional procedures 427 will most often be used. For example, if a specification mandates 428 a particular baseline authentication technique, but allows others 429 to be negotiated and used, implementations need to implement the 430 baseline authentication algorithm even if the other ones are used 431 most of the time. 433 Use Capability Negotiation: Many protocols are engineered with 434 capability negotiation mechanisms. For example, a content 435 negotiation framework has been defined for protocols using MIME 436 content [13][14][15]. SIP allows for clients to negotiate the 437 media types used in the multimedia session, as well as protocol 438 parameters. HTTP allows for clients to negotiate the media types 439 returned in requests for content. When such features are 440 available in a protocol, client and servers should make use of 441 them rather than making assumptions about supported capabilities. 442 A corollary is that protocol designers should include such 443 mechanisms when evolution is expected in the usage of the 444 protocol. 446 The DNS Record Type Says it All: The only assumptions one can make 447 about the service defined by the name are encapsulated in the DNS 448 resource record type that is retrieved. For example, if an A 449 record exists for the domain web.example.com, one cannot assume 450 that web service is available at the domain, since all the A 451 record says is that the host with that name has a particular IP 452 address. The only way to definitively know if a service is 453 available at a domain is through SRV records [2]. As an example, 454 a client can do a query for _sip._udp.example.com to learn if SIP 455 UDP services are available at example.com [18]. 457 To summarize - there is never a need to make assumptions. Rather 458 than doing so, utilize the specifications and the negotiation 459 capabilities they provide, and the overall system will be robust and 460 interoperable. 462 7. Security Considerations 464 One of the assumptions that can be made by clients or servers is the 465 availability and usage (or lack thereof) of certain security 466 protocols and algorithms. For example, a client accessing a service 467 in a particular domain might assume a specific authentication 468 algorithm or hash function in the application protocol. It is 469 possible that, over time, weaknesses are found in such a technique, 470 requiring usage of a different mechanism. Similarly, a system might 471 start with an insecure mechanism, and then decide later on to use a 472 secure one. In either case, assumptions made on security properties 473 can result in interoperability failures, or worse yet, providing 474 service in an insecure way, even though the client asked for, and 475 thought it would get, secure service. This kinds of assumptions are 476 fundamentally unsound even if the records themselves are secured with 477 DNSSEC. 479 8. IAB Members 481 Internet Architecture Board members at the time of writing of this 482 document are: 484 Bernard Aboba 486 Harald Alvestrand 488 Rob Austein 490 Leslie Daigle 492 Patrik Faltstrom 494 Sally Floyd 496 Mark Handley 497 Bob Hinden 499 Geoff Huston 501 Jun-ichiro Itojun Hagino 503 Eric Rescorla 505 Pete Resnick 507 Jonathan Rosenberg 509 9 Informative References 511 [1] Mockapetris, P., "Domain names - concepts and facilities", STD 512 13, RFC 1034, November 1987. 514 [2] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 515 specifying the location of services (DNS SRV)", RFC 2782, 516 February 2000. 518 [3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 519 Three: The Domain Name System (DNS) Database", RFC 3403, 520 October 2002. 522 [4] Davis, C., Vixie, P., Goodwin, T. and I. Dickinson, "A Means 523 for Expressing Location Information in the Domain Name System", 524 RFC 1876, January 1996. 526 [5] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 527 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 528 HTTP/1.1", RFC 2616, June 1999. 530 [6] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming 531 Protocol (RTSP)", RFC 2326, April 1998. 533 [7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 534 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 535 Session Initiation Protocol", RFC 3261, June 2002. 537 [8] Eastlake, D., ".sex Considered Dangerous", RFC 3675, February 538 2004. 540 [9] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 541 2001. 543 [10] Niemi, A., Arkko, J. and V. Torvinen, "Hypertext Transfer 544 Protocol (HTTP) Digest Authentication Using Authentication and 545 Key Agreement (AKA)", RFC 3310, September 2002. 547 [11] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 548 Extensions (MIME) Part One: Format of Internet Message Bodies", 549 RFC 2045, November 1996. 551 [12] Internet Architecture Board, "IAB Technical Comment on the 552 Unique DNS Root", RFC 2826, May 2000. 554 [13] Klyne, G., "Indicating Media Features for MIME Content", RFC 555 2912, September 2000. 557 [14] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 558 2533, March 1999. 560 [15] Klyne, G., "Protocol-independent Content Negotiation 561 Framework", RFC 2703, September 1999. 563 [16] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 565 [17] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional 566 Responses in Session Initiation Protocol (SIP)", RFC 3262, June 567 2002. 569 [18] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 570 (SIP): Locating SIP Servers", RFC 3263, June 2002. 572 [19] Faltstrom, P. and R. Austein, "Design Choices When Expanding 573 DNS", draft-iab-dns-choices-00 (work in progress), October 574 2004. 576 Author's Address 578 Jonathan Rosenberg, Editor 579 IAB 580 600 Lanidex Plaza 581 Parsippany, NJ 07054 582 US 584 Phone: +1 973 952-5000 585 EMail: jdrosen@cisco.com 586 URI: http://www.jdrosen.net 588 Intellectual Property Statement 590 The IETF takes no position regarding the validity or scope of any 591 Intellectual Property Rights or other rights that might be claimed to 592 pertain to the implementation or use of the technology described in 593 this document or the extent to which any license under such rights 594 might or might not be available; nor does it represent that it has 595 made any independent effort to identify any such rights. Information 596 on the procedures with respect to rights in RFC documents can be 597 found in BCP 78 and BCP 79. 599 Copies of IPR disclosures made to the IETF Secretariat and any 600 assurances of licenses to be made available, or the result of an 601 attempt made to obtain a general license or permission for the use of 602 such proprietary rights by implementers or users of this 603 specification can be obtained from the IETF on-line IPR repository at 604 http://www.ietf.org/ipr. 606 The IETF invites any interested party to bring to its attention any 607 copyrights, patents or patent applications, or other proprietary 608 rights that may cover technology that may be required to implement 609 this standard. Please address the information to the IETF at 610 ietf-ipr@ietf.org. 612 Disclaimer of Validity 614 This document and the information contained herein are provided on an 615 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 616 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 617 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 618 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 619 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 620 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 622 Copyright Statement 624 Copyright (C) The Internet Society (2004). This document is subject 625 to the rights, licenses and restrictions contained in BCP 78, and 626 except as set forth therein, the authors retain all their rights. 628 Acknowledgment 630 Funding for the RFC Editor function is currently provided by the 631 Internet Society.