Internet Engineering Task Force                                   SIP WG
Internet Draft                                     Schulzrinne/Rosenberg
draft-ietf-sip-srv-02.txt                        Columbia U./dynamicsoft
March                                 J.Rosenberg,H.Schulzrinne
draft-ietf-sip-srv-03.txt                        dynamicsoft,Columbia U.
December 24, 2001
Expires: June 2001 May 2002

                       SIP: Session Initiation Protocol -- Locating SIP Servers

STATUS OF THIS MEMO

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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

   To view the list Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.

Abstract

   This document describes how

   The Session Initiation Protocol (SIP) makes use of DNS procedures to
   allow a SIP client locates to resolve a SIP URI into the IP address, port, and
   transport of the next hop to contact. It also uses DNS to allow a
   server based
   on to send a response to a backup client in the Request-URI or event of a preconfigured outbound proxy server.
   failure of the primary client. This document updates the process described describes those DNS pro-
   cedures in RFC 2543. detail.

1 Introduction

   This document updates Sections 1.3 and 1.4.2 and supersedes Appendix
   D of RFC 2543 [1]. Inter alia, it defines

   The Session Initiation Protocol (SIP) [1] is a client-server protocol
   used for the term outbound proxy initiation and
   replaces references management of communications sessions
   between users. SIP end systems are called user agents, and intermedi-
   ate elements are known as proxy servers. A typical SIP configuration,
   referred to as the obsoleted RFC 2052 with current references
   to RFC 2782.

1.1 Terminology SIP "trapezoid" is shown in Figure 1. In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALLNOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are
   diagram, a caller, UA1 wishes to be interpreted as described in RFC 2119 [2] and
   indicate requirement levels for compliant SIP implementations.

1.2 Definitions

        Outbound proxy: A call joe@B. To do so, it communi-
   cates with proxy that is located near 1 in its domain (domain A). Proxy 1 forwards the originator of
             requests. It receives all outgoing requests from a
             particular UAC, including those requests whose Request-URLs
             identify a host other than
   request to the outbound proxy. The outbound proxy sends these requests, after any local processing, to for the address indicated in domain of the Request-URI. (All other called party (domain B),
   which is proxy
             servers are simply referred as proxies, not inbound
             proxies.) 2. Proxy 2 Locating a SIP Server

   When a client wishes forwards the call to send a request, the client either sends it called party, UA
   2.

   As part of this call flow, proxy 1 needs to determine a locally configured SIP server
   for domain B. To do this, proxy server, 1 makes use of DNS procedures, using
   both the so-called outbound proxy ,
   independent SRV [2] and NAPTR [3] records. This document describes the
   specific problems that SIP uses DNS to help solve, and provides a
   solution.

2 Problems DNS is Needed to Solve

   DNS is needed to help solve several aspects of the Request-URI, or sends general call flow
   described in the Introduction.

   First off, proxy 1 needs to discover the SIP server in domain B, in
   order to forward the call for joe@B. Specifically, it needs to deter-
   mine the IP address and address, port corresponding to and transport for the Request-URI. The outbound proxy server in domain B.
   Transport is particularly noteworthy. Unlike other protocols, SIP can be
   configured by any mechanism,
   run over a variety of transports, including DHCP [3] TCP, UDP, TLS/TCP and can be specified
   either as
   SCTP. Therefore, discovery of transports for a particular domain is
   an important part of the processing. The proxy sending the request
   has a particular set of parameters such as network address or host name,
   protocol port transports it supports (all proxies must
   implement both TCP and UDP) and transport protocol, or as a preference for using those tran-
   sports. Proxy 2 has its own set of transports it supports (the
   minimal overlap is UDP and TCP in this case), and relative prefer-
   ences for those transports. Some form of DNS procedures are needed
   for proxy 1 to discover the available transports for SIP URI.

   If services at
   domain B, and the Request-URI is used, relative preferences of those transports. This
   information can be merged with the client needs supported transports and prefer-
   ences at proxy 1, resulting in a selection of a transport.

   It is important to note that DNS processing can be used multiple
   times throughout processing of a call. In general, an element that
   wishes to send a request (generally called a client) may need to per-
   form DNS processing to determine the
   protocol, port and IP address address, port, and transport
   of a next hop element, generally called a server (it can be a proxy
   or a user agent). Such processing could, in principle, occur at every
   hop between elements.

   Since SIP is used for the establishment of interactive communications
   services, the time it takes to which to send complete a transaction between a
   caller and called party is important. Typically, the
   request. A client SHOULD follow total delay
   between when a user initiates the call, and when they get an indica-
   tion that the steps below called party is being alerted to obtain this
   information.

   Clients MUST re-run the above selection algorithm, re-drawing any
   random numbers involved, once per transaction rather call, needs to be
  ............................          ..............................
  .                          .          .                            .
  .                +-------+ .          . +-------+                  .
  .                |       | .          . |       |                  .
  .                | Proxy |------------- | Proxy |                  .
  .                |   1   | .          . |  2    |                  .
  .                |       | .          . |       |                  .
  .              / +-------+ .          . +-------+ \                .
  .             /            .          .            \               .
  .            /             .          .             \              .
  .           /              .          .              \             .
  .          /               .          .               \            .
  .         /                .          .                \           .
  .        /                 .          .                 \          .
  .       /                  .          .                  \         .
  .   +-------+              .          .                +-------+   .
  .   |       |              .          .                |       |   .
  .   |       |              .          .                |       |   .
  .   | UA 1  |              .          .                | UA 2  |   .
  .   |       |              .          .                |       |   .
  .   +-------+              .          .                +-------+   .
  .              Domain A    .          .   Domain B                 .
  ............................          ..............................

   Figure 1: The SIP trapezoid

   less than for each
   request, i.e., requests within the same transaction MUST a few seconds. Given that there can be sent multiple hops, each
   of which is doing DNS processing in addition to other potentially
   time-intensive operations, the same network address. Thus, the same address is used amount of time available for the
   request, any retransmissions, any associated CANCEL requests DNS pro-
   cessing at each hop is limited.

   Scalability and ACK
   requests for non-2xx responses. However, ACKs for 2xx responses use
   another iteration high availability are important in SIP. SIP services
   scale up through clustering techniques. In a more realistic version
   of the selection algorithm. (Indeed, network in many cases,
   they may have different request URIs.)

   A stateless Figure 1, proxy can accomplish this, 2 would typically be a cluster of
   homogeneously configured proxies. DNS needs to provide the ability
   for domain B to configure a set of servers, along with prioritization
   and weights in order to provide a crude level of capacity based load
   balancing.

   High availability is accomplished in SIP through detection of
   failures by upstream elements. For example, proxy 1 would send a
   request to proxy 2.1 (one of the proxies in the "cluster" proxy 2).
   This request would fail, and that would be detected by using proxy 1. Proxy
   1 would then try another of the proxies, proxy 2.2. In many cases,
   such as the one above, proxy 1 will not know which domains it will
   ultimately communicate with. That information would be known when a
   user actually makes a call to another user in that domain. Proxy 1
   may never communicate with that domain again after the call com-
   pletes. Proxy 1 could communicate with thousands of different domains
   within a few minutes, and proxy 2 could receive requests from
   thousands of different domains within a few minutes. Because of this
   "many-to-many" relationship, it is not generally possible for an ele-
   ment to perpetually maintain dynamic availability state for the prox-
   ies it will communicate with. When a proxy gets its first call with a
   particular domain, it will try the servers in that domain in some
   order until it finds one thats available. The identity of the avail-
   able server would ideally be cached for some amount of time in order
   to reduce call setup delays of subsequent calls. However, the client
   cannot actively "ping" the failed servers to determine when they come
   back alive, because of scalability concerns. Furthermore, the availa-
   bility state must eventually be flushed in order to redistribute load
   to recovered elements when they come back online.

   It is possible for elements to fail in the middle of a transaction.
   For example, after proxy 2 forwards the request to UA 2, proxy 1
   fails. UA 2 sends its response to proxy 2, which tries to forward it
   to proxy 1, which is no longer available. Ideally, we would like
   proxy 2 to use DNS procedures to identify a backup server for proxy 1
   that it can use to forward the response. This problem is more realis-
   tic in SIP than it is in other transactional protocols. The reason is
   that a SIP response can take a *long* time to be generated, because a
   human user frequently needs to be consulted in order to generate that
   response. As such, it is not uncommon for tens of seconds to elapse
   between a call request and its acceptance.

3 Client Usage

   Usage of DNS differs for clients and for servers. This section
   discusses client usage. The assumption is that the client is stateful
   (either a UAC or a stateful proxy). Considerations for stateless
   proxies are discussed in Section 3.4.

   The procedures here are invoked when a client needs to send a request
   to a server for which it does not already know an explicit IP
   address, port, and transport. This occurs when an element wishes to
   send a request to a server identified by a SIP URI, or when an ele-
   ment wishes to send a request to a specific configured server,
   independent of the SIP URI, but the configured server is identified
   by a domain name instead of a numeric IP address.

   The procedures here MUST only be done once per transaction. That is,
   once a server has successfully been contacted (success is defined
   below), all retransmissions of the request and the ACK for non-2xx
   responses MUST be sent to the same server. Furthermore, a CANCEL for
   a particular request MUST be sent to the same server that the request
   was delivered to.

   Note that, because the ACK request for 2xx responses constitutes a
   different transaction, there is no requirement that it be delivered
   to the same server that received the original request (indeed, if
   that server did not record-route, it will most definitely not get the
   ACK).

   If the request is being delivered to an outbound proxy, a temporary
   URI, used for purposes of this specification, is constructed. That
   URI is of the form sip:<proxy>, where <proxy> is the domain of the
   outbound proxy.

   The first step is to identify the TARGET.  The TARGET is set to the
   value of the maddr parameter of the URI, if present, otherwise, the
   host value of the hostport construction. It represents the domain to
   be contacted.

3.1 Selecting a Transport

   Next, a transport is selected.

   If the URI specifies a transport, that transport MUST be used.

   Otherwise, if no transport is specified, but the TARGET is a numeric
   IP address, the client SHOULD use UDP.

   Otherwise, if no transport is specified, and the target is not a
   numeric IP address, the client SHOULD perform a NAPTR query. This
   query is for the service "SIP+D2T", which provides a mapping from a
   domain to a transport for contacting that domain. The transport is of
   the form of an SRV record, using the "S" NAPTR flag. The resource
   record will contain a replacement value (not a regular expression),
   which is the SRV record for a particular transport. If the server
   supports multiple transports, there will be multiple NAPTR records,
   each with a different order value. The client MUST discard any
   records that contain an SRV value with a transport not supported by
   the client, but otherwise follow the processing rules of [3]. The
   result is that the most preferred transport of the server that is
   supported by the client will get used.

   As an example, consider foo.com. A client wishes to contact a SIP
   server in foo.com. It performs a NAPTR query for that domain, and the
   following records are returned:

   ;;       order pref flags service           regexp  replacement
    IN NAPTR 90   50  "s"  "SIP+D2T"           ""  _sip._tcp.foo.com
    IN NAPTR 100  50  "s"  "SIP+D2T"           ""  _sip._udp.foo.com
    IN NAPTR 110  50  "s"  "SIP+D2T"           ""  _sip._tls.foo.com

   This indicates that the server supports TCP, UDP, and TLS, in that
   order of preference. If the client supports UDP and TLS, UDP will be
   used, based on an SRV lookup of _sip._udp.foo.com.

        Somehow this doesn't seem right, since the client needs to
        look at the replacement values to discard entries. Perhaps
        the query should instead be done for sip.<domain>, and the
        service field is "TCP+D2T" or "UDP+D2T"?

   It is STRONGLY RECOMMENDED that the domain suffixes in the replace-
   ment field (i.e., foo.com above) match the domain of the original
   query. Without that, backwards compatibility between RFC 2543 and
   this specification will not be possible.

        THis is because RFC 2543 clients will go directly to SRV
        records using the domain suffixes. If these are non-
        existent, because the NAPTR replacement used a different
        suffix, communication will not take place.

   In the event that no NAPTR records are found, the client constructs
   SRV records for those transports it supports, and does a query for
   each. Queries are done using the service identifier "_sip". If the
   query is successful, it means that the particular transport is sup-
   ported. The client MAY use any transport it desires which is sup-
   ported by the server.

        This is a change from RFC 2543, which used to merge the
        priority values across different SRV records.

3.2 Determining port and IP

   Once the transport has been determined, the next step is to determine
   the IP address and port.

   If TARGET is a numeric IP address, use that address. If the URI also
   contains a port, use that port. If no port is specified, use the
   default port for the particular transport.

   If the TARGET was not a numeric IP address, but a port is present in
   the URI, first check the cache to determine if a server has been pre-
   viously contacted successfully for that TARGET and port. If one has
   been, use that server. Otherwise, perform an A or AAAA record lookup
   of the domain name. The result will be a list of IP address, each of
   which can be contacted at the specific port from the URI and tran-
   sport determined previously. Processing then proceeds as described in
   Section 3.3.

        There is a weird case where, where the URI had a domain
        name and a port. SRV records will potentially be used to
        determine the transport, based on the algorithms above, but
        A records used for the actual lookup. That seems odd.

   If the TARGET was not a numeric IP address, and no port was present
   in the URI, first check the cache to see if a server had been previ-
   ously contacted successfully for that TARGET. If one had been, use
   that. Otherwise, perform an SRV query using the service identifier
   "_sip" and the transport as determined from Section 3.1, as specified
   in RFC 2782 [2]. The procedures of RFC 2782, as described in the Sec-
   tion titled "Usage rules" are followed, augmented by the additional
   procedures of Section 3.3.

        This is a change. Previously, if the port was explicit, but
        with a value of 5060, SRV records were used. Now, A records
        will be used. A result of this is that the URL comparison
        rules need to change to reflect that sip:user@foo and
        sip:user@foo:5060 are NOT equivalent any longer. I think
        this should not cause any serious interoperability issues,
        but further consideration is needed.

3.3 Details of 2782 process

   RFC 2782 spells out the details of how a set of SRV records are
   sorted and then tried. However, it only states that the client should
   "try to connect to the (protocol, address, service)" without giving
   any details on what happens in the event of failure. Those details,
   in the case of SIP, are described here.

   For SIP requests, failure occurs if the
   modulo N of transaction layer reports a
   503 error response or a hash transport failure of some sort (generally,
   due to ICMP errors or TCP connection failures). Failure also occurs
   if the Call-ID value transaction layer times out without ever having received ANY
   response, provisional or some other combination of
   transaction-identifying headers as final (i.e., timer B or timer F fires). If a
   failure occurs, the uniform random number
   described in client SHOULD create a new request, which is
   identical to the weighting algorithm previous, but has a different value of RFC 2782. Here, N the Via
   branch ID than the previous (and therefore constitutes a new SIP
   transaction). That request is sent to the sum
   of weights within next element in the priority class. list as
   specified by rfc2782.

   A client SHOULD be able server has been contacted "successfully" if a request sent to interpret explicit network notifications
   (such as ICMP messages) which indicate that a
   server is not
   reachable, rather than relying solely on timeouts. (For socket-based
   programs:  For TCP, connect() returns ECONNREFUSED if generates any kind of response, provisional or final. A map-
   ping of the client
   could not connect tuple (TARGET, input TRANSPORT, input PORT) to a specific
   server at (IP address, transport, port) that address. For UDP, the socket
   needs to was contacted successfully
   SHOULD be bound cached for a duration equal to the destination address using connect() rather
   than sendto() or similar so TTL of the A record for
   that a second write() or send() fails
   with ECONNREFUSED if there is no server listening) If itself. Note, in the above tuple, input TRANSPORT and
   input PORT refer to the transport and port values from the URI
   itself, if present.

   If a client
   finds attempts to contact the server listed in the cache, but
   the request fails, the server MUST be removed from the cache, and the
   entire DNS processing must restart by following the procedures in
   Section 3.1 again.

3.4 Consideration for Stateless Proxies

   The process of the previous sections is not reachable at highly stateful. When a particular address, it SHOULD
   behave as if it had received
   server is contacted successfully, all requests for the transaction
   (plus a 400-class error response to CANCEL for that
   request.

   The client tries transaction) MUST go to find one or more addresses for the SIP same server. The
   identity of the successfully contacted server by
   querying DNS. If is a step elicits no addresses, form of transac-
   tion state. This presents a challenge for stateless proxies, which
   still need to meet the client continues requiretment for sending all requests in the
   transaction to the next step. However if a step elicits one or more addresses, but same server.

   The requirement is not difficult to meet in the simple case where
   there were no SIP server at any of those addresses responds, then failures when attempting to contact a server. Whenever
   the stateless proxy receives the client
   concludes request, it performs the server is down appropriate
   DNS queries as described above. Unfortunately, the procedures of RFC
   2782 and does RFC 2915 are not continue on guaranteed to the next
   step.

   If the client be deterministic. This is configured with
   because records that contain the address of an outbound proxy, same priority and weight (in the parameters
   case of the outbound proxy, including transport protocol SRV) or order and port, become preference (in the destination used below.

   If there is case of NAPTR) have no outbound proxy, the destination is the Request-URI.
   specified order. The destination address is stateless proxy MUST define a deterministic
   order to the maddr parameter if records in that case, using any algorithm at its dispo-
   sal. One suggestion is to alphabetize them, for example. To make life
   easier for stateless proxies, it exists and the
   host element if not. The transport protocol is RECOMMENDED that domain adminis-
   trators make the transport
   parameter.

   The service identifier for DNS weights of SRV records [4] is "_sip".

        1.   If the destination address is a numeric IP address, the
             client contacts the server at the given address with equal priority different
   (for example, using weights of 1000 and the
             port number specified in the SIP-URI or, 1001 if not specified,
             the default port (5060).

             If the destination specifies two servers are
   equivalent, rather than assigning both a protocol, the client
             contacts the server using that protocol. weight of 1000), and simi-
   larly for NAPTR records. If no protocol is
             specified, the client first tries UDP. If attempt fails, or server is contacted success-
   fully, things are fine. However, if the client does first server is not support UDP but supports other
             protocols, it tries those protocols in some
             implementation-defined order.

             The client then skips the remaining steps.

        2.   If the destination specifies no port number or port number
             5060, contacted
   successfully, and a subsequent server is, the transport protocol determines proxy cannot remain
   stateless for this transaction. This is because a retransmission
   could very well go to a different server if the use of failed one of
             the following three rules:

             - If the destination recovers
   between retransmissions. As such, whenever a proxy does not specify success-
   fully contact the first server, it SHOULD act as a transport protocol,
               DNS SRV records are retrieved according stateful proxy.

4 Server Usage

   RFC 2543bis defines procedures for sending responses from a server
   back to the client. Typically, for unicast requests, the response is
   sent back to RFC 2782 [4].
               The results of the query or queries are merged and
               ordered based on priority, keeping only records with
               transport protocols that source IP address where the client supports.  Then, request came from, using
   the
               searching technique outlined port contained in RFC 2782 [4] the Via header. However, it is used important to
               select servers in order. Server selection across requests
               is independent of previous choices, except as noted above
               for stateless proxies. Message length or other
   provide failover support when the client element fails between send-
   ing the request
               properties do not influence and receiving the server selection. response.

   The procedures here are invoked when a server sends a response to the
   client attempts and that response fails. "Fails" is defined here as any
   response which causes an ICMP error message to contact each server in be returned, or when
   the order
               listed, at transport connection the port number specified request came in on closes before the SRV record.
               If none of the servers
   response can be contacted, sent.

   In these cases, the client gives
               up. If there are no SRV records (with any transport
               protocol), DNS address records are used, as described
               below.

             - server examines the value of the sent-by con-
   struction in the topmost Via header. If it contains a numeric IP
   address, the server attempts to send the response to that address,
   using the transport protocol is specified from the Via header, and this protocol is
               supported by the client, port from sent-by,
   if present, else the procedure in default for that transport.

   If, however, the paragraph
               above is used, limited to DNS resource sent-by field contained a domain name and a port
   number, the server queries for A records with that name. It tries to
   send the
               transport protocol specified in response to each element on the SIP-URI.

             - If resulting list of IP
   addresses, using the port from the Via, and the transport protocol specified is not supported by from the client,
   Via. As in the client gives up.

             If there are no SRV records, processing, the next step applies.

        3.   If entry in the destination specifies a port number other than 5060
             or list is tred
   if there are no SRV records, the client queries the DNS
             server for address records for the destination address.
             Address records include A RR's, AAAA RR's, or other similar
             records, chosen according to one before it results in a failure.

   If, however, the client's network protocol
             capabilities.

             If sent-by field contained a domain name and no port,
   the DNS server returns no address records, queries for SRV records using the client
             gives up. If there are address records, service identifier
   "_sip" and the same rules transport from the topmost Via header. The resulting
   list is sorted as described in step 2 apply.

   Clients MUST NOT cache query results except according [2], and the response is sent to the rules
   topmost element on the new list described there. If that results in
   RFC 1035 [5].

3 a
   failure, the next entry on the list is tried.

5 Security Considerations

   The authors do not believe that this specification introduces any
   additional security considerations issues beyond those already described in RFC 2543 [1] apply.

4 Authors' 2782
   and RFC 2915.

6 Registration of NATPR D2T Resolution Service

   Name: Domain Name to Transport
      * Mnemonic: D2T
      * Number of Operands: 1
      * Type of Each Operand: Each operand is a domain
      * Format of Each Operand: Each operand is a domain name in standard
        format
      * Algorithm: Opaque
      * Output: One or more SRV record keys
      * Error Conditions:
         o No overlap in transport between client and server

      * Security Considerations:

7 Author's Addresses

   Henning Schulzrinne
   Dept. of Computer Science
   Columbia University
   1214 Amsterdam Avenue
   New York, NY 10027
   USA
   electronic mail:  schulzrinne@cs.columbia.edu

   Jonathan Rosenberg
   dynamicsoft
   72 Eagle Rock Ave Avenue
   First Floor
   East Hanover, NJ 07936
   USA
   electronic mail:
   email: jdrosen@dynamicsoft.com

5

8 Bibliography

   [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, H. Schulzrinne, et al.  , "SIP:
   session Session initiation
   protocol," Request for Comments 2543, Internet
   Engineering Task Force, Mar. 1999.

   [2] S. Bradner, "Key words for use in RFCs to indicate requirement
   levels," Request for Comments 2119, Internet Engineering Task Force,
   Mar. 1997.

   [3] G. Nair and H. Schulzrinne, "DHCP option for SIP servers," Internet Draft, Internet Engineering Task Force, Apr. 2000. Oct.
   2001.  Work in progress.

   [4]

   [2] A. Gulbrandsen, P. Vixie, and L. Esibov, "A DNS RR for specifying
   the location of services (DNS SRV)," Request for Comments 2782,
   Internet Engineering Task Force, Feb. 2000.

   [5] P. V. Mockapetris, "Domain names - implementation

   [3] M. Mealling and
   specification," R. Daniel, "The naming authority pointer (NAPTR)
   DNS resource record," Request for Comments 1035, 2915, Internet Engineering
   Task Force, Nov. 1987.

   Full Copyright Statement

   Copyright (c) The Internet Society (2001). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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. Sept. 2000.