Internet DRAFT - draft-brandner-enum-categorical-enumservices
draft-brandner-enum-categorical-enumservices
ENUM Working Group R.Brandner
Internet-Draft Siemens
L. Conroy
Siemens
R. Stastny
OeFEG
Expires: December, 2002 June 21st, 2002
"Categorical enumservices"
<draft-brandner-enum-categorical-enumservices-00.txt>
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.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document defines the set of enumservices describing "high level"
communications categories. These are used as elements within the services
field of NAPTR resource records within ENUM domain space. Each category
identifies a kind of communications service in which an end user might
want to engage using the associated resource. It includes the expected
"low level" service that comes under each category, together with a list
of the URI schemes that are appropriate for use with each categorical
enumservice.
Brandner, Conroy, Stastny Expires December, 2002 [Page 1]
Internet-Draft Categorical enumservices June 2002
1. Introduction
Enumservices can be classified in a number of different ways. For a
summary of the discussion on options available, see [2]. In addition to
the scheme of the URI associated with a NAPTR and the DDDS application
identifier ("E2U", in the case of ENUM [1]), there are two main ways of
indicating the services supported by the identified resource.
These are "low level" or specific services, of which there could be a
large number, or higher level categories. This document focusses on the
latter, and shows how the existing low level services may be mapped to
the higher level categorical enumservices.
Low level enumservices define the specific service offered via the
associated resource. These are much "closer" to the URI scheme, and
indicate the way in which a communication is to be carried out.
High level (or categorical) enumservices are intended to reflect the kind
of communication in which an end user wants to engage. The goal is to
provide a small list of the kinds of communication appropriate rather than
the protocol (or implementation) used to execute that communication; they
are intended to reflect the "end user's view" of what they want to
do, rather than the protocol used to effect that service.
1.1. About this document
The following sections each describes a category of communication in which
an end user may want to engage, and might be passed from the end user
interface to the DDDS Application, where it could be used to sieve a
NAPTR resource set returned for a particular zone within the ENUM domain
space. The goal here is to use this passed list as a filter, rejecting
NAPTRs that do not have matching indications in their service field.
In each of the sections, the categorical service is described, along with
any expected client behaviour, the "low level" services that fall into
this category (and so should be matched against the "interesting
categorical enumservices"), the URI-schemes that can be associated with
the category and any features that they have when used in this way.
2. 'talk' categorical enumservice
This enumservice indicates that the associated resource can be used for
interactive (media stream exchange) calls; it can be used to "talk" to the
owner.
2.1. 'talk' Expected client behaviour
The end user, having selected the talk category as being of interest, will
expect their client agent to filter the NAPTRs to those that include
either this categorical service or the specific services that it implies.
Given that this category is concerned with interactive calls, the querying
clients agent should present the options available and supported locally
to the end user. This is particularly important for calls that are
delivered via a local PSTN connection, as there may well be a cost
involved.
Brandner, Conroy, Stastny Expires December, 2002 [Page 2]
Internet-Draft Categorical enumservices June 2002
2.2. 'talk' Implied "low level" services
This sub-section describes the low level services that can be classified
under this category. Proposals so far have been similar to those included
in the 'tel-svc' draft [4], and, for the 'talk' related services, include:
- voice
- video
2.3. 'talk' Associated URI schemes
This sub-section describes the URI-schemes for which this category would
be appropriate, together with a description of any special issues with
each URI scheme used with this category. Note that, although it is
possible that VPIM voice messages or video clips could be sent, this is
NOT the meaning of the 'talk' category. Thus the URI schemes appropriate
for this enumservice category include only those usable to exchange
interactive media.
2.3.1. talk with "sip:" URI
This combination implies that the associated URI may be used to initiate
interactive telephony calls to the destination using SIP [6]. Note that
SIP has its own negotiation method within the protocol, so that the client
MAY be offered another kind of communication session after negotiation.
However, this combination gives more information to the querying user than
would be the case for the 'srs' enumservice (see section 6.3.1).
The implication of the NAPTR with the 'talk' and 'sip' combination is
that, if selected, the querying user can engage in an interactive call;
thus the registrant SHOULD include such an entry only for those cases
where this is possible.
2.3.2. talk with "tel:" URI
The talk category is one of the two main uses for the "tel:" URI [3]. In
this case, the querying client might use this to trigger a voice call via
local "dialer" software that controls a PSTN interface (such as a software
controlled telephone). If the client has no support for local PSTN
connection, then it may submit the "tel:" URI to a local SIP user agent,
if the user has a relationship with an external gateway provider that can
support "tel:" URIs as destination end points. However, a "tel:" URI is
intended for use where the destination party is connected via the PSTN or
a network that uses E.164 numbers natively, and by preference the client
should attempt to make a PSTN connection if possible.
Note that the "tel:" URI may include a svc parameter, specifying the low
level services this resource supports. This category implies voice or
video services may be used; if one is specified then this may define which
service can be used. If there is no such parameter or it includes both
video and voice as supported, then the client is able to choose.
However, it is recommended that voice be considered the default service
and the one to be attempted first, in lack of further information
Brandner, Conroy, Stastny Expires December, 2002 [Page 3]
Internet-Draft Categorical enumservices June 2002
2.3.3. talk with "h323:" URI
In principle, interactive calls could be made using the H.323 set of
protocols. Within the ENUM system, this requires a URI-scheme to be
defined for this protocol set, but once this is done, the talk category
may be used with such an "h323:" URI.
2.3.4. talk with "enum:" URI
The "enum:" URI scheme [7] is intended to indicate the E.164 number that
should be used in a re-submission to the ENUM system. In this combination,
the interpretation should be that this URI may be used to find further
information from the ENUM system by re-submission for clients that are
interested in the 'talk' enumservice category only.
3. 'msg' categorical enumservice
The msg enumservice is intended to indicate that the associated resource
is capable of receiving a discrete (non-session related) message or
document. This category may be selected by a querying client if they want
to deliver a message (such as a Fax) to a correspondent.
3.1. 'msg' Expected Client Behaviour
Where a querying end user is interested in the 'msg' communication
category, it is expected that they will select a NAPTR that is so
identified and will generate the URI from this. Once this URI is
available, the client would be expected to send a message using the
protocol indicated by the URI-scheme.
3.2. 'msg' Implied "low level" services
The msg category includes a number of specific services. These are:
- Fax
The Fax service will be associated with a "tel:" URI. As negotiation
of particular fax classes (G2, G3, G4) is done within the Fax
protocol itself, there is no specification for this needed within the
ENUM system. This is considered the default service within this
category when used with a "tel:" URI, so if the URI does not include
a 'svc' parameter then this may be assumed from the category and URI
scheme.
- SMS or MMS
These services will be associated with a "tel:" URI, and the
particular service may be identified within the URI using a 'svc'
parameter. If there is no such indication, then an attempt should not
be made to use these services (i.e. an SMS or MMS message should not
be sent).
- email
This category, when used with a "mailto:" URI, indicates the email
service is supported at this resource. An email may be sent using the
associated "mailto:" URI. See [5] for more details on this scheme.
- IM
Where this is used to send a message rather than initiate a session
during which Instant Messages can be exchanged (for that, see section
5 of this document).
Brandner, Conroy, Stastny Expires December, 2002 [Page 4]
Internet-Draft Categorical enumservices June 2002
3.3. 'msg' Associated URI schemes
3.3.1. msg with "sip:" URI
Whilst in the general case one would expect a "sip:" URI to be associated
with the 'srs' category (see section 6 for details), it is possible for a
registrant to decide to have a separate "sip:" URI specifically as a
destination for Instant Messages (or for email). Thus, this categorical
enumservice may be associated with a "sip:" URI - if so, then this "sip:"
URI should not be used for categories not listed within the services
field. For example, if a NAPTR includes the 'msg' category and no others,
then this NAPTR should be used only for communications that involve
sending a message to that resource; not for other sessions such as those
associated with 'chat' or 'talk' categories.
Although Instant Messages or emails might be sent without using a "sip:"
URI, there is a benefit to doing this; the sender may be authenticated
using the standard SIP techniques prior to returning the actual
destination contact address, so "hiding" that contact address to
non-authenticated would-be correspondents. This should be considered, as
the ENUM domain space may be a good source of "junk mail" targets.
3.3.2. msg with "tel:" URI
There are two main ways in which a telephone number can be used to send a
message to a destination. These are to send a telefax to a device
contactable via this telephone number, and to send a short message to an
appropriate device.
Although Short Message Service was designed for use with mobile
telephones, there is a move to provide SMS service to landline telephones
as well, either via a dial-out service node (for generating an SMS message
from a landline telephone), or via a Universal Message service (for
reception and storage of SMS messages, and transcoding to voice on
demand). For this reason, it may be possible for two end users, both of
whom have landline telephones, to send and receive SMS messages; it should
NOT be assumed that this is only possible from mobile telephones.
Note that the "tel:" URI may contain a 'svc' parameter. This is used to
indicate the specific services supported via this resource. If there is no
such parameter, but this NAPTR indicates the 'msg' category, then the
"tel:" URI may be assumed to support Fax service.
Only if the SMS or MMS service is indicated explicitly within the "tel:"
URI should such a message be sent to that destination.
3.3.3. msg with "mailto:" URI
This category is appropriate to indicate that email messages may be
sent to the resource identified in the associated URI. In this case the
"mailto:" URI is likely to be used (but a "sip:" URI may be chosen
instead, particularly if the registrant wants to authenticate the sender
using the SIP infrastructure).
Brandner, Conroy, Stastny Expires December, 2002 [Page 5]
Internet-Draft Categorical enumservices June 2002
Existence of a "mailto:" URI within the globally-accessible ENUM
infrastructure may well lead to reception of unwanted "junk email", as the
ENUM infrastructure is trawled for potential target email addresses.
Whilst this is not an issue with the 'msg' category itself, it should be
considered by registrants when populating their domains.
3.3.4. msg with "enum:" URI
The "enum:" URI scheme is intended to indicate the E.164 number that
should be used in a re-submission to the ENUM system. The client should
interpret this combination and process the URI only if it matches a
"client interest" in sending a message.
4. 'info' categorical enumservice
The info enumservice indicates that the associated resource can act as a
source for information. It acts as the "opposite" of the msg enumservice,
in that this indicates a source for data whilst that indicates a sink for
data.
4.1. 'info' Expected Client Behaviour
The 'info' enumservice is used by the registrant to indicate to potential
correspondents a source of information. The implication for a client is
that the registrant will allow any data indicated by the URI to be passed
to the client.
Note that, particularly in the case of use with the "tel:" URI, it is
important to display the destination URL to the querying end user before
acting on it. Telephone information services are often charged at a
higher rate from other calls, and so the end user should have the chance
to confirm the action.
Also, an entry of this kind states that information is available from this
URI. It does not guarantee access to everyone. The client may be called on
to authenticate itself before access is granted.
4.2. 'info' Implied "low level" services
The info enumservice is used for sources of information. The current list
of low level services does not seem to fit with this category, so that the
URI scheme is the only other identifier that can be used to help select
between a set of NAPTRs.
4.3. 'info' Associated URI schemes
The info enumservice can be used with several URI schemes. The most common
is likely to be that with the "http:" URI-scheme.
4.3.1. info with "tel:" URI
This combination may seem strange at first, but might be used where a
recorded announcement or "information line" can be reached by dialling a
particular telephone number. This is not an interactive call in that the
recording is being played to the client rather than the client talking
with a correspondent.
Brandner, Conroy, Stastny Expires December, 2002 [Page 6]
Internet-Draft Categorical enumservices June 2002
>From the perspective of client software, it seems likely that this
combination will be treated very similarly to a normal 'talk' enumservice;
the difference lies in the user and registrant's intent for this contact
and the communication that will result.
4.3.2. info with "http:" URI
This combination is used where the registrant wants to store a URI to a
web site within their domain space.
4.3.3. info with "https:" URI
This combination indicates that TLS or Secure Socket Layer connections are
required to retrieve the information indicated.
4.3.4. info with "ftp:" URI
This combination indicates that the information is retrieved using FTP.
4.3.5. info with "enum:" URI
This combination implies that the URI value can be processed in an ENUM
re-submission to find more information on communications contacts that fit
with the 'info' category.
5. 'chat' categorical enumservice
This category is used where the registrant is capable of engaging in a
text chat session during which Instant Messages can be sent. It differs
from the 'msg' category in that this category implies a session-oriented
message exchange, whilst 'msg' implies a discrete message can be sent to
the resource at this contact address.
5.1. 'chat' Expected Client Behaviour
This category indicates that session oriented chat exchanges can be made
via the associated URI. Presence of a chat/tel combination may suggest
that the registrant prefers text communication; it SHOULD be displayed to
the querying end user so they can choose how to proceed.
5.2. 'chat' Implied "low-level" services
At present, the 'chat' category is associated only with one low-level
service -IM. It is unclear whether or not text telephony would be expected
with the IM service, whilst it is one option for the chat category.
5.3. 'chat' Associated URI schemes
Initially, this category is likely to be used with two URI schemes; "sip:"
and "tel:". There may well be other session oriented text 'chat' protocols
developed, and these should be included in future updates of this
document.
Brandner, Conroy, Stastny Expires December, 2002 [Page 7]
Internet-Draft Categorical enumservices June 2002
5.3.1. chat with "sip:" URI
This combination indicates that, by using this address of record, the
client can initiate a session during which Instant Messages can be
exchanged. It may be appropriate to include a NAPTR with this combination
if the registrant has more than one address of record with different
(competing) providers for voice and instant messaging services.
SIP has its own mechanisms for negotiating the kind of communications
session to be initiated, so one would expect the 'srs' category to be used
in many cases; where there are other reasons that the two addresses of
record cannot be combined within one SIP service, discrete (category-
specific) entries can be used.
5.3.2. chat with "tel:" URI
This combination indicates that text chat sessions can be initiated over
the telephone network to the destination. It is used, for example, to
indicate a telephone number to which a text phone (such as a 'Minicom' or
Telecommunications Device for the Deaf - TDD) unit is attached.
The querying client SHOULD be informed that textphones are available if
this combination is available within a NAPTR. It is difficult to determine
whether or not text communication should be preferred over voice, and the
end user SHOULD be able to choose.
Note that there may be a privacy issue; including this data might be an
indication that the registrant is hard of hearing, information that may be
considered sensitive.
6. 'srs' categorical enumservice
This category is used for entries that exit the ENUM system and continue
communication service selection using external protocols. These external
schemes are called "Service Resolution Services" (or SRS). Information on
the kind of communication available is not stored within one of these
ENUM entries; instead this may be delivered using the inbuilt procedures
of the protocol specified by the associated URI scheme.
6.1. 'srs' Expected Client Behaviour
This category indicates that the associated URI can be used for further
negotiation on the available communications options available. Thus the
protocol-specific mechanisms are used. It is assumed that, if the querying
client can support these protocols, then the standard protocol handler
techniques will be used.
6.2. 'srs' Implied "low-level" services
By definition, a Service Resolution Service does not have a specific or
"low level" service; the srs is used to negotiate outside of the ENUM
system. This category does not fit with the concept of "low level"
services indicated within ENUM.
Brandner, Conroy, Stastny Expires December, 2002 [Page 8]
Internet-Draft Categorical enumservices June 2002
6.3. 'srs' Associated URI schemes
Initially, the two main protocols used with this category are SIP and
LDAP. For details of the SIP negotiation mechanisms, see [6].
6.3.1. srs with "sip:" URI
This combination is likely to be commonly used. It avoids some potential
privacy issues with publishing data within the (global) DNS. Full
negotiation of session or contact is available within the SIP protocol,
including authentication of the querying user.
As mentioned in the sections on the 'msg' and 'talk' categories, it may be
difficult to use a single entry within an ENUM domain. A registrant may
have, for example, two discrete addresses of record for two categories and
may choose to not combine these. However, where this is possible, an entry
with 'srs' and "sip:" can be used to "off load" the negotiation to the SIP
protocol rather than relying on the DDDS application.
6.3.2. srs with "ldap:" URI
This combination indicates that further information can be gleaned by
queries to the LDAP resource indicated by the URI.
7. 'all' categorical enumservice
This is a special case of enumservice category. It may be used to indicate
that the querying user is interested in any kind of communication, and so
all NAPTRs should be considered (i.e. no filtering of NAPTRs based on
enumservices should be applied by the DDDS application).
This special category may also be used by a registrant who whishes to
include a NAPTR or NAPTRs but does not want to specify (within the
services field) the services for which each of the NAPTRs is valid. In
this case, all NAPTRs are valid regardless of any querying client
specified list of categories of interest.
7.1. 'all' expected client behaviour
If a client receives a NAPTR that indicates that it is to be considered
for all enumservices, then it is forced to act in a set of default
behaviours. These behaviours are defined by the scheme of the associated
URI, and are covered in section 7.3.
There are two choices in the filtering behaviour of the client. In the
first, a 'NAPTR' with an 'all' enumservice is treated first, before NAPTRs
with a defined category or specific service set. This may be convenient
for use with an "enum:" URI, so that the NAPTR is similar to a registrant
using a CNAME to redirect requests to some other domain within ENUM space.
The other choice is to attempt to match against the enumservices of
interest, and only to treat a NAPTR with an 'all' enumservice if the
others are not appropriate. This may be convenient if the querying user is
Brandner, Conroy, Stastny Expires December, 2002 [Page 9]
Internet-Draft Categorical enumservices June 2002
attempting to initiate a communication; they are interested in a
particular kind of communication, and might consider the 'any' enumservice
as a "less good" match.
It seems that both choices are convenient for different URI schemes (the
first where an "enum:" URI is used, the second for all others). Thus, it
is proposed that the "order of processing" is that a NAPTR with an 'all'
enumservice be treated first if and only if the associated URI scheme is
"enum:", whilst it is treated last for all other URI-schemes.
7.2. 'all' Implied "low level" services
By definition, the 'all' category implies that any "low-level" service
might work. Which ones are not specified, and the client has to use the
URI-scheme to select the appropriate action.
7.3. all with Associated URI schemes
The 'all' category does not specify a particular enumservice, so the
client behaviour will reflect default rules that must, perforce, be based
on the associated URI scheme.
7.3.1. all with "sip:" URI
This indicates that the associated SIP address of record can be used as
a contact for all kinds of communications. This combination should be
treated as a "fallback" case. NAPTRs with 'sip' and 'talk' or 'msg' or
'srs' should be compared to the category in which the querying user is
interested, and only if there is no "more appropriate" NAPTR should
this be chosen.
7.3.2. all with "tel:" URI
The default behaviour for a "tel:" URI is to use it to initiate an
interactive telephony call to a destination specified with the enclosed
phone number. Note that the "tel:" URI may have a svc parameter, and this
may indicate the specific services supported at this resource. If so, then
the services indicated will specify the services (and kinds of
communication) that can be used, and these should be displayed to the end
user for their selection (or offered to some caller preference scheme
within the client end point).
7.3.3. all with "mailto:" URI
When used with the all category, this URI has the default meaning that the
resource address can be used to send an email. In this case, this NAPTR
acts as if it held the 'msg' categorical enumservice.
7.3.4. all with "http:"/"https:" URI
In this case, the http or https URI has its default meaning, and the
client can use this to extract a document (or other information) available
at the resource location indicated. This behaviour is the same as if this
NAPTR held the 'info' category.
Brandner, Conroy, Stastny Expires December, 2002 [Page 10]
Internet-Draft Categorical enumservices June 2002
7.3.5. all with "ftp:" URI
In this case, the "ftp:" URI has the default meaning that a document can
be extracted from the resource indicated. In this case, the NAPTR can be
treated as if the category were 'info'.
7.3.6. all with "ldap:" URI
The "ldap:" URI indicates that a query can be made using the associated
URI. This can be treated in a similar way to the 'srs' category, in which
detailed communications contact information is available using an LDAP
query.
7.3.7. all with "enum:" URI
One use of this category is to "re-direct" requests to another domain
within the ENUM space. If the associated URI-scheme is "enum:" then this
means that searches for all classes of communication contact information
should be re-submitted using the "enum:" URI value.
Note that the enum URI may have its own set of enumservice filters (held
in the 'es' parameter). This should be combined with the set of
'enumservices of interest' passed by the querying client, and the set
intersection of these two should be used for subsequent ENUM queries.
8. Security issues
There are not thought to be any more security issues over and above those
described in RFC2916bis.
Note that there is a privacy issue in the use of enumservice identifiers.
Including category information within the NAPTR makes it accessible to any
querying user without authentication, and so exposes data that the
registrant may consider sensitive.
9. IANA Considerations
The categorical enumservices described in this document are enumservices
within the meaning of RFC2916bis, and so this document forms a request for
registration of these enumservice labels under the ENUM tree, as specified
in sections 2.4.2.1 and 3 of RFC2916bis.
10. Acknowledgments
Many thanks to the correspondents on the ENUM WG mailing list for their
assistance and cajoling to refine these categories. Clive Feather pointed
out that TDD phones are used for a session oriented text "chat" system.
Brandner, Conroy, Stastny Expires December, 2002 [Page 11]
Internet-Draft Categorical enumservices June 2002
11. Bibliography
[1] P. Faltstrom, M. Mealling, "ENUM",
draft-ietf-enum-rfc2916bis-0.txt,
Work In Progress, February 2002
[2] R. Stastny, R. Brandner, L.Conroy, "Analysis of the Usage of ENUM and
ENUM Services",
draft-stastny-enum-services-analysis-00.txt,
Work In Progress, June 2002
[3] H. Schulzrinne, A. Vaha-Sipila, "URIs for Telephone Calls",
draft-antti-RFC2806bis-04.txt,
Work in progress, May 2002
[4] R. Brandner, L.Conroy, R. Stastny, "The 'tel:' URI 'svc' parameter",
draft-brandner-tel-svc-00.txt,
Work in Progress, June 2002
[5] P.Hoffmann, L. Masinter, J. Zawinski, "The mailto URL scheme",
RFC2368, Internet Engineering Task Force, July 1998
[6] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson,
R. Sparks,M. Handley,E. Schooler, "SIP: session initiation
protocol", RFC3261, Internet Engineering task Force, June 2002
[7] R. Brandner, L.Conroy, R. Stastny, 'The "enum:" URI scheme',
draft-brandner-enum-uri-00.txt, June 2002
Brandner, Conroy, Stastny Expires December, 2002 [Page 12]
Internet-Draft Categorical enumservices June 2002
12. Authors' Addresses
Rudolf Brandner
Siemens ICN
Hofmannstrasse 51
Munich
Germany
Msg - <mailto:rudolf.brandner@icn.siemens.de>
Talk - <tel:+49-89-72251003>
Info - <http://www.siemens.com>
Lawrence Conroy
Siemens Roke Manor Research
Roke Manor
Romsey
U.K.
Msg - <mailto:lwc@roke.co.uk>
- <tel:+44-796-7609505;svc=sms>
Talk - <tel:+44-1794-833666>
Richard Stastny
OeFEG
Postbox 147
1103 Vienna
Austria
Msg - <mailto:richard.stastny@oefeg.at>
Talk - <tel:+43-664-420-4100>
Brandner, Conroy, Stastny Expires December, 2002 [Page 13]
Internet-Draft Categorical enumservices June 2002
Full Copyright Statement
Copyright (C) The Internet Society (2000). 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.
Brandner, Conroy, Stastny Expires December, 2002 [Page 14]
