INTERNET-DRAFT Eric A. Hall Document: draft-hall-email-srv-02.txt John C. Klensin Expires: January, 2005 July 2004 Category: Experimental Using SRV Resource Records to Automatically Configure Email Clients Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document specifies SRV resource records for Internet-based message-submission and message-retrieval services, and also defines behavioral rules for messaging clients to follow when these resource records are used to locate the messaging servers associated with a known mail domain. Internet Draft draft-hall-email-srv-02.txt July 2004 Table of Contents 1. Background and Overview...................................2 2. Prerequisites and Terminology.............................4 3. Messaging SRV Resource Records............................5 3.1. SRV Owner Names........................................5 3.2. SRV Resource Record Data...............................6 3.3. Address Resource Records...............................7 4. Client Processing Algorithms..............................7 4.1. Retrieval Server Lookups...............................9 4.2. Submission Server Lookups.............................11 5. Resource Record Caching..................................12 6. Security Considerations..................................13 7. IANA Considerations......................................14 8. Normative References.....................................14 9. Informative References...................................15 Acknowledgments...............................................15 Authors' Disclaimer and Addresses.............................15 Full Copyright Statement......................................16 1. Background and Overview Email networks built around Internet messaging technologies typically use a tiered message-transfer network model. In the common scenario, messaging clients send outgoing email messages to a default "submission" server, with these "first-hop" servers performing tasks such as message preparation, routing lookups, and next-hop transfers towards the final destination. Meanwhile, messaging clients which work in the typical model will also usually fetch incoming email messages from a default "retrieval" server, with these "last-hop" servers usually acting as the final delivery system for the user's mail domain. Messaging networks built on this model have historically used the Simple Message Transfer Protocol (SMTP) [RFC2821] and TCP port 25 for the first-hop submission service. However, RFC 2476 [RFC2476] formally defined a variant of SMTP as an explicit mail-submission service which more accurately reflects specific behavioral requirements of the common environment. RFC 2476 also reserved TCP port 587 specifically for use with the formal submission service, but also allows clients and servers to continue using full SMTP over TCP port 25. On the retrieval front, there are two standards-track services available for use, which are the Post Office Protocol v3 (POP3) Hall & Klensin I-D Expires: January 2005 [page 2] Internet Draft draft-hall-email-srv-02.txt July 2004 [STD53] and the Internet Message Access Protocol v4rev1 (IMAP4) [RFC3501]. Unlike the submission services, POP3 and IMAP4 are substantially different from each other, with different protocol models, command verbs, and port numbers (POP3 servers typically use TCP port 110, while IMAP4 servers typically use TCP port 143). Most messaging clients which work in these environments have historically used static configuration data to identify the protocol, hostname and port number to identify the submission and retrieval services, although a variety of products have also attempted to use automated configuration services in an effort to lessen the need for manual administration. For example, some products have used the Dynamic Host Configuration Protocol (DHCP) [RFC2131], the Interactive Mail Support Protocol (IMSP) and the Application Configuration Access Protocol (ACAP) [RFC2244], or even the Lightweight Directory Access Protocol (LDAP) [RFC3377] to store configuration data centrally, allowing clients to fetch centrally-managed configuration information when they are first loaded. Unfortunately, many of these services are unable to accommodate messaging networks that don't use the default port numbers for the specified service, are unable to provide recovery information when a pre-configured server becomes unavailable, are unable to support users on remote networks due to topology, security or bandwidth concerns, or have other issues which make them unsuitable for use outside of specific environments. Meanwhile, RFC 2782 [RFC2782] introduced a general-purpose mechanism for storing service-specific connection identifiers in the Domain Name System (DNS) [STD13] by way of a generalized Service Location ("SRV") resource record. In the SRV model, a network service can be identified by name within the scope of a particular domain, with multiple SRV resource records identifying the hostnames and port numbers of servers which provide the named service within that domain scope, but with the caveat that these resource records can only provide connection-level information, and cannot provide user-specific configuration data. This restriction is also present in other host-based configuration services (including DHCP and PPP, among others). However, SRV records have a significant advantage over these other services, in that DNS lookups are not tied to a particular network medium or management domain, and the configuration data can be retrieved from anywhere on the global Internet. In sum, this means that SRV resource records are useful when hosts need to use application services operated by a service provider, and are especially useful when the hosts are not connected to a static 'home' network. This Hall & Klensin I-D Expires: January 2005 [page 3] Internet Draft draft-hall-email-srv-02.txt July 2004 includes roaming clients that connect from different networks (such as an office or home network, or an airport or coffee house), dial-up clients which connect to different points-of- presence every time, and even those networks that are isolated behind a gateway device and therefore under different administrative control from the service provider. In support of these kinds of scenarios, this specification defines SRV resource records which can be used to identify the submission and retrieval servers for a particular messaging network, and also defines behavioral rules for messaging clients to use when locating these servers. Specifically, the model put forth in this document uses SRV resource records which are mapped to the mail domain of an email address, so that messaging clients can predictably discover the messaging servers that are associated with a particular mail domain, and also defines client-side algorithms for sorting equally-weighted responses. Note that this model assumes that the presence of an email address within a mail domain implies that the user has an account in the associated mail domain, that the user is authorized to use the servers associated with that domain, and that such usage is preferred or necessary (note that these caveats usually apply to retrieval services more than submission services, since retrieval services are usually associated with a specific host or cluster). In those environments where these assumptions do not reflect the actual messaging network or requirements, some other mechanism will be needed (potentially including manual configuration). Furthermore, the usage model described herein is specifically intended for non-critical configuration, such as bootstrapping a manual configuration process or for use as recovery information when a pre-configured server has become unavailable. Although these mechanisms MAY be used for ongoing configuration management, there are numerous scenarios which can cause the lookup or parsing processes to fail, and as such, these mechanisms SHOULD NOT be relied on for ongoing configuration management. 2. Prerequisites and Terminology Readers of this document are expected to be familiar with the specifications for message submission (RFC 2476), POP3 (STD 53), IMAP4 (RFC 3501), SRV resource records (RFC 2782), and the terminology of mail transport [RFC2821]. Hall & Klensin I-D Expires: January 2005 [page 4] Internet Draft draft-hall-email-srv-02.txt July 2004 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Messaging SRV Resource Records SRV resource records have an owner domain name which uniquely identifies a particular service within the scope of a particular domain, and also have data structures which provide information about the target hosts and their preferential rankings. 3.1. SRV Owner Names The owner domain name of SRV resource records are a concatenated sequence of labels which identify the service name, the transport protocol associated with that service, and the domain scope for that service, respectively. For SRV resource records which reference submission servers, the first two labels in this sequence MUST be "_submission" and "_tcp", while the domain scope sequence MUST be the same as the mail domain which is used by the messaging clients. Note that the "_submission" label refers to the submission service name, as registered with IANA. For SRV resource records which reference IMAP4 servers, the first two labels in this sequence MUST be "_imap" and "_tcp", while the domain scope sequence MUST be the same as the mail domain which is used by the messaging clients. Note that the IANA registration for the IMAP4 service is "imap" and not "imap4". For SRV resource records which reference POP3 servers, the first two labels in this sequence MUST be "_pop3" and "_tcp", while the domain scope sequence MUST be the same as the mail domain which is used by the messaging clients. Note that the domain scope for these resource records is explicitly defined as the mail domain of the user's email address, and is not tied to a hostname, a subnet, or any other type of name. The client processing algorithms defined in section 4 of this document use the mail domain of the user's email address as the domain scope of the SRV resource record lookups, so the resource records must be associated with the mail domain name in order for the algorithm to succeed (additional mapping techniques Hall & Klensin I-D Expires: January 2005 [page 5] Internet Draft draft-hall-email-srv-02.txt July 2004 are also provided for those scenarios where the mail domain is insufficient to be used for matching users to servers). For example, a messaging client which had been configured to use an email address of "user@example.net" and which needed to locate the submission server for that user would issues lookups for the SRV resource records bound to the "_submission._tcp.example.net" domain name, while an email address of "user@bna.tn.example.net" would issue lookups for "_submission._tcp.bna.tn.example.net". Alternative specifications are free to reuse the SRV identifier sequences described above, but SHOULD specify different naming contexts in order to avoid conflicts. For example, specifications that describe subnet-specific mapping algorithms can freely reuse the "_smtp._tcp" label sequence, but would best be served by mapping the sequence to an IN-ADDR.ADDR domain name instead of the forward domain. Similarly, per-user or per-host algorithms should make use of fully-qualified domain names which completely identify the target resource, rather than the domain name of that resourceÆ authoritative parent. 3.2. SRV Resource Record Data The SRV resource record data structure is described in detail in RFC 2782. In summary, the SRV resource record provides fields which identify a target server hostname, the port number of the associated service on that server, and priority and weighting data which reflect the overall preference of each particular server in the answer set. Note that the client-processing algorithms described in section 4 of this document allow a target server to be chosen from among an equally weighted set of answers by determining if any of the servers share the same subdomain or subnet as the messaging client. These mechanisms may be useful in those cases where a large and distributed messaging network shares a common mail domain for all of its users, but where that organization still needs to direct specific users towards servers that are dedicated to particular subdomains or subnets. In general terms, organizations which choose to make use of this specification are encouraged to provide multiple servers with different preference values, thereby allowing clients to automatically discover alternate servers in case the preferred server becomes unreachable or otherwise unavailable. Hall & Klensin I-D Expires: January 2005 [page 6] Internet Draft draft-hall-email-srv-02.txt July 2004 This specification does not define any custom handling rules for the weighting field of the SRV resource record. The default weightings defined in RFC 2782 are to be used. 3.3. Address Resource Records Once a preferred server has been selected from the SRV answer set, its hostname will need to be resolved into an IP address. Note that the client processing algorithms described in section 4 of this document allow an IP address to be chosen from among an equally weighted set of answers by allowing the client to determine which of the servers are "best" or "closest", based on the IP addresses of the client and the server(s). This mechanism may be useful in those cases where a large and distributed messaging network shares a common mail domain for all of its users, but where that organization still needs to direct specific users towards servers which are dedicated to particular subnets. For example, some clients or organizations may be able to leverage resolvers which attempt to locate the "closest" server through the use of subnet-mapping techniques, or which attempt to locate the "best" server from response-time monitors or load-balancing technologies which control the answer sets that are returned to the clients. Discussion of these technologies is beyond the scope of this document, although developers and administrators should be aware of their potential use. 4. Client Processing Algorithms In general terms, messaging clients are expected to locate the retrieval servers associated with a known mail domain whenever incoming email messages need to be retrieved, and are expected to locate the submission servers associated with a known mail domain whenever outgoing email messages need to be sent. However, this is an extremely simplistic overview of the process, with many potential exceptions. For example, a messaging client may be designed to use retrieval- service extensions to perform message submission (such as using a POP3 or IMAP4 submission extension), and in those cases, the client would need to use the SRV resource records associated with the retrieval service rather than the submission service. Furthermore, IMAP4 sessions tend to be fairly long-lived, and often involve multiple connections to different folders within a single folder hierarchy, but since changes to the resource record Hall & Klensin I-D Expires: January 2005 [page 7] Internet Draft draft-hall-email-srv-02.txt July 2004 data could theoretically result in different servers being chosen for each such connection, messaging clients need to reuse the current IP address for all of the active IMAP4 connections to a single server instead of issuing new lookups for each session. There are other common exceptions to the general rule, and in most cases, common sense should take precedence. In general terms, the process of locating a server requires two sub-processes. The first part of the process attempts to locate the hostnames and port numbers of the preferred servers that are associated with the mail domain of the primary email address of each user profile, while the second part of the process attempts to locate the IP addresses of those servers. Clients that wish to store this data permanently SHOULD only cache the preferred server information from the first part of the process. Meanwhile, clients SHOULD only perform the second part of the process whenever a connection is actually required (a detailed procedure is discussed in the algorithms below). In some cases, the entire process may need to be restarted, such as when routing errors, TCP errors, or session errors indicate that the client cannot currently use the preferred server. Once a connection to a selected server has been successfully established, messaging client MAY attempt to automate any login or configuration processes, as desired. For example, clients MAY attempt to use the local-part element of the email address as a login identifier for a given session, or MAY attempt to probe for the available encryption and authentication mechanisms, or MAY attempt to discover the IMAP4 namespace or subscription hierarchy, and so forth. However, attempts to automatically discover the configuration information can have a high likelihood of failure, either because some of the elements may not be predictable, or because different server products may have implemented features in slightly different ways. Since this process is somewhat prone to failure, it is not defined in this specification, although these processes are allowed and are generally encouraged. Note that some parameters will differ between servers (or even between nodes in a cluster), and as such, if any of the subsequent settings are cached by the client, most of these settings SHOULD be linked with a specific server rather than with the user's identity. Also note that some DNS resolvers are known to filter and restrict the resource record data which gets returned, and in those cases, the messaging client may need to issue its own "raw" DNS queries in order to ensure that all of the information is retrieved and processed correctly. Hall & Klensin I-D Expires: January 2005 [page 8] Internet Draft draft-hall-email-srv-02.txt July 2004 4.1. Retrieval Server Lookups Messaging clients which support both IMAP4 and POP3 SHOULD first attempt to locate the IMAP4 servers associated with the mail domain, and SHOULD NOT attempt to locate POP3 servers unless no IMAP4 servers can be located or reached. Messaging clients which only support one or the other service SHOULD only issue lookups for the retrieval service that the client supports, and SHOULD NOT issue lookups for services that are not supported by that messaging client. Clients which claim to be compliant with this specification SHOULD iterate at least once through the following steps for each eligible messaging identity: a. Determine if a retrieval server has been defined manually or through another configuration mechanism that has been given preference over this process. If so, only continue if those servers are unreachable or otherwise unavailable. b. If the client is looking for IMAP4 servers, extract the mail domain from the primary email address associated with the current profile, and append the "_imap" and "_tcp" labels to the left of that domain name. If the client is looking for POP3 servers, append the "_pop3" and "_tcp" labels to the left of the mail domain name. c. Issue a DNS query for the SRV resource records associated with the domain name formed in the preceding step. d. Determine the hostname of the preferred retrieval server. 1. If multiple candidate servers were returned, use the sorting rules specified in RFC 2782 to determine the preferred server(s). 2. If multiple candidate servers still exist, the client SHOULD give additional preference to any of the servers which have a hostname that appears to be in the same subdomain as the client hostname. Hall & Klensin I-D Expires: January 2005 [page 9] Internet Draft draft-hall-email-srv-02.txt July 2004 3. If multiple candidate servers still exist, the client MAY resolve each of the target server hostnames and use any services at its disposal to determine the "best" or "closest" IP address, and use the server associated with that address as the preferred target. Note that several addresses and targets can be returned during this process, and it may be imprudent to perform this process against very large sets. 4. If multiple candidate servers still exist, choose one at random from the preferred set. e. Use the port number associated with the server selected in step 4.1.d as the port number for the retrieval server. f. Resolve the IP address for the server chosen in step 4.1.d. Note that this data SHOULD NOT be stored permanently, and SHOULD only be used to resolve connection requests. 1. If multiple IP addresses are returned, the client MAY use any services at its disposal to determine the "best" or "closest" IP address from that set. 2. If multiple candidate addresses still exist, choose one at random from the preferred set. g. If a connection to the currently-preferred server cannot be established, locate the next-best target. 1. If multiple IP addresses are associated with the currently-preferred server, restart the process at step 4.1.f to determine the next-best IP address. 2. If all of the IP addresses for the currently-preferred host have been tried, use the next-preferred host from step 4.1.d. Clients SHOULD NOT try the next-preferred host until all of the IP addresses associated with the currently-preferred host have been tried. h. If the client is looking for IMAP servers and none were discovered or are otherwise available, extract the mail domain from the user's email address, append the "_pop3" and "_tcp" labels to the left of that domain name, and restart the process at step 4.1.c. If no POP3 servers were discovered or are otherwise available, report the failure to the user and exit. Hall & Klensin I-D Expires: January 2005 [page 10] Internet Draft draft-hall-email-srv-02.txt July 2004 4.2. Submission Server Lookups Unlike the algorithm defined for retrieval servers, submission services only require a single SRV resource record, and therefore only require a single lookup process. Clients which claim to be compliant with this specification SHOULD iterate through the following steps for each eligible identity: a. Determine if a submission server has been defined manually or through another configuration mechanism that has been given preference over this process. If so, only continue if those servers are unreachable or otherwise unavailable. b. Extract the mail domain from the primary email address associated with the current connection profile, and append the "_submission" and "_tcp" labels to the left of that domain name. c. Issue a DNS query for the SRV resource records associated with the domain name formed in the preceding step. d. Determine the hostname of the preferred submission server. 1. If multiple candidate servers were returned, use the sorting rules specified in RFC 2782 to determine the preferred server(s). 2. If multiple candidate servers still exist, the client SHOULD give additional preference to any of the servers which have a hostname that appears to be in the same subdomain as the client hostname. 3. If multiple candidate servers still exist, the client MAY resolve each of the target server hostnames and use any services at its disposal to determine the "best" or "closest" IP address, and use the server associated with that address as the preferred target. Note that several addresses and targets can be returned during this process, and it may be imprudent to perform this process against very large sets. Hall & Klensin I-D Expires: January 2005 [page 11] Internet Draft draft-hall-email-srv-02.txt July 2004 4. If multiple candidate servers still exist, the client SHOULD give a higher preference to targets which use port 587, and SHOULD give a lower preference to targets which use port 25. 5. If multiple candidate servers still exist, choose one at random from the preferred set. e. Use the port number associated with the server selected in step 4.2.d as the port number for the submission server. f. Resolve the IP address for the server chosen in step 4.2.d. Note that this data SHOULD NOT be stored permanently, and SHOULD only be used to resolve connection requests. 1. If multiple IP addresses are returned, the client MAY use any services at its disposal to determine the "best" or "closest" IP address from that set. 2. If multiple candidate addresses still exist, choose one at random from the preferred set. g. If a connection to the currently-preferred server cannot be established, locate the next-best target. 1. If multiple addresses are associated with the currently-preferred server, restart the process at step 4.2.f to determine the next-best IP address. 2. If all of the IP addresses for the currently-preferred host have been tried, use the next-preferred host from step 4.2.d. Clients SHOULD NOT try the next-preferred host until all of the IP addresses associated with the currently-preferred host have been tried. h. If no submission servers were discovered or are otherwise available, report the failure to the user and exit. 5. Resource Record Caching Messaging clients SHOULD NOT store the discovered configuration information for a length of time greater than the Time-to-Live values associated with the underlying resource records. Instead, clients SHOULD delete the discovered information whenever the underlying resource records have expired, and SHOULD NOT issue new queries until a new connection needs to be established. This Hall & Klensin I-D Expires: January 2005 [page 12] Internet Draft draft-hall-email-srv-02.txt July 2004 approach ensures that the messaging client will always get the latest information when accuracy is most critical. However, clients SHOULD remember which server and IP addresses are being used for current connections, so that that other servers can be tried if the current connection fails. Remembering the current server ensures that the client does not repeatedly select the same preferred server even though it has already been tried. Furthermore, multiple lookups for IMAP4 servers SHOULD NOT be issued if any connections for a given server are already active. All of the other connections for that server MUST reuse the existing server-specific socket tuple, and additional lookups for that profile MUST NOT be generated unless the current server becomes unavailable. Zone operators SHOULD NOT use excessively short or excessively long Time-to-Live values. As a general rule of thumb (subject to operator-specific requirements, of course), Time-to-Live values of a few hours tend to work the best. 6. Security Considerations Administrators should carefully consider if and how they want to make the resource records described in this document available to users on remote networks. Since these resource records provide information about the internal messaging network in a predictable form, hostile parties with access to the resource records can learn some operational details about the infrastructure simply by issuing predictable DNS queries. However, the potential risks from this should not be overstated, since the same information can often be learned by analyzing the Received headers in email messages which have passed through that same network. In this regard, providing this information in a resource record is no more of a risk than providing the information in a Received header of a message which has passed through that network. DNS domain names can be easily spoofed, and this is especially easy when the victim uses a DNS server under the control of a hostile party. By using a relatively simple technique, a hostile party can provide SRV resource records which redirect a user towards a hostile SMTP server, allowing the interloper to read and act upon the user's outbound email at will. Strong authentication services, transfer-layer encryption techniques, and message encryption are usually cited as sufficient defenses against such Hall & Klensin I-D Expires: January 2005 [page 13] Internet Draft draft-hall-email-srv-02.txt July 2004 attacks, in that they can prevent illegitimate sessions from being established and/or can make message contents unreadable. Clients that attempt to automate logins or which probe for available authentication mechanisms SHOULD use the strongest mechanism available, but MAY give preference to mechanisms that require less input. For example, mechanisms that only require a username and password MAY be given preference over mechanisms that require shared secrets or external tokens. In all cases, clients SHOULD attempt to use the STARTTLS mechanisms described in RFC 2595 [RFC2595], RFC 3207 [RFC3207] and RFC 3501 respectively. Note that these mechanisms require that clients compare the certificate name(s) against the hostname used in the initial connection request. In those cases where the algorithms from section 4 are used to seed a manual configuration, the selected target server's hostname MUST be used for the certificate comparison operation. In those cases where the client performs automatic discovery, the mail domain from the seed email address MUST be used for the comparison operation. Note that STARTTLS allows server certificates to publish multiple hostnames and wildcard domain names, and this allows a single server to match against multiple comparisons. In those cases where a canonical protocol specification describes a specific security requirement, that specification MUST be given precedence over this document. 7. IANA Considerations This document does not create any IANA considerations. 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2476] Gellens, R., and J. Klensin, "Message Submission", RFC 2476, December 1998. [RFC2595] C. Newman, "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999. [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. Hall & Klensin I-D Expires: January 2005 [page 14] Internet Draft draft-hall-email-srv-02.txt July 2004 [RFC2821] J. Klensin, "Simple Mail Transfer Protocol", RFC 2821, April 2001. [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002. [RFC3501] M. Crispin, "Internet Message Access Protocol - Version 4rev1", RFC 3501, March 2003. [STD53] Myers, J., and M. Rose, "Post Office Protocol - Version 3", RFC 1939, May 1996. 9. Informative References [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2244] Newman, C., and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997. [RFC3377] Hodges, J., and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002. [STD13] Mockapetris, P. "Domain Names - Concepts and Facilities", STD 13, RFC 1034 and "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987. Acknowledgments Funding for the RFC editor function is currently provided by the Internet Society. Authors' Disclaimer and Addresses By submitting this Internet-Draft, I accept the provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Hall & Klensin I-D Expires: January 2005 [page 15] Internet Draft draft-hall-email-srv-02.txt July 2004 Eric A. Hall ehall@ehsco.com John C. Klensin john-ietf@jck.com Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Hall & Klensin I-D Expires: January 2005 [page 16]