Internet Draft                                              R. Stastny
Document: draft-stastny-enum-services-analysis-00.txt            OeFEG
Category: Informational                                    R. Brandner
                                                               Siemens
                                                             L. Conroy
                                                               Siemens
Expires: December 2002                                       June 2002


              Analysis of the Usage of ENUM and ENUM Services
               <draft-stastny-enum-services-analysis-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 [1].

   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 analyzes the usage of the URI-schemes, services and
   "enumservices" under discussion for the ENUM System. It tries to
   combine the existing proposals for "enumservices" and proposes
   examples of a compatible approach as a way forward for the definition
   of the "enumservices" to be used in the ENUM trials planned.










Stastny                Expires - December 2002               [Page 1]


           Analysis of the Usage of ENUM and ENUM Services  June 2002


Table of Contents

   1. The Usage of ENUM..............................................2
   2. Usage of the URI schemes only to identify services.............3
   3. The Usage of "enumservices"....................................3
   3.1 Simple URI Schemes............................................3
   3.2 Combined URI Schemes and Services.............................4
   3.3 Functional grouping of "enumservices".........................4
   4. Examples of "enumservices".....................................5
   4.1 The URI-schemes to be used in ENUM............................5
   4.2 The Services to be used in ENUM...............................5
   4.3 Simple and combined "enumservices"............................6
   4.4 Functional groups of "enumservices"...........................7
   4.5 Informational enumservices....................................8
   5. Maximum Packet Size Considerations.............................8
   6. Conclusion.....................................................9
   7. Security Considerations........................................9
   8. Acknowlegdements...............................................9
   9. References....................................................10
   10. Author's Addresses...........................................10


1. The Usage of ENUM

   The ENUM System as defined in Draft RFC2916bis [2] allows an ENUM End
   User to use the DNS to connect services on the Internet to an E.164
   number. Each service is identified with an URI contained in a NAPTR
   record, as described in the DDDS/URI Application in [3]. Any user on
   the Internet may contact the ENUM End User by retrieving this
   information via a DNS query.

   The ENUM End User may indicate his preferred services to be contacted
   by using the preference field in the NAPTR record. This may either be
   the primarily preferred service to be contacted in general, or the
   preferred service of similar or equivalent services listed.

   Note: The order field in the NAPTR record is used if more than one
   NAPTR record is necessary to evaluate the entries in the DNS.
   Currently no example of the usage of such a construct has been given.

   To indicate that a NAPTR record belongs to the ENUM System, the non-
   optional parameter "E2U" in the service field is used. The "U" flag
   in the flag field indicates, that this NAPTR record (rule) is the
   last one and the final outcome of the evaluated regexp field will be
   an URI.

   A user on the Internet may now query the domain related to the E.164
   number and retrieve the information contained within. In principle,
   the querying user or the application used by the user needs to match


Stastny                Expires - December 2002               [Page 2]


           Analysis of the Usage of ENUM and ENUM Services  June 2002


   the services offered by the ENUM End User and eventually the given
   preferences with the services he has available, is able to use and/or
   intends to use.


2. Usage of the URI schemes only to identify services

   As already mentioned, the NAPTR records are used to indicate services
   and these services are identified with an URI in the regexp field.
   Since an end-point indicated by a given URI may provide multiple
   services, or the same URI scheme used in different NAPTR records may
   provide different services, it is necessary to provide the querying
   user with additional information.

   This information may be given by additional parameters provided with
   the URI, e.g. the svc parameter. To select the proper service to be
   used, the user may retrieve the NAPTR records by querying the DNS for
   the given E.164 related domain, evaluate all retrieved NAPTR records
   to get the URIs and eventually the services (svc) and other
   parameters provided with a given URI.

   Some services may even require (or allow) to contact the end-point
   given with the URI to negotiate the services required and/or
   available.

   The advantage of this "peek-ahead" approach is, that no additional
   information is required in the NAPTR records, which reduces the size
   of the NAPTR records and therefore the size of the information to be
   transmitted or cached. Regarding the maximum UDP packet size
   limitation see also section 6.

   The disadvantage of this approach may be the additional processing
   power and time needed to evaluate the URI fitting to the service
   required and offered.

   It is therefore proposed in RFC2916bis to indicate the service(s)
   offered with a given NAPTR record in the service field of the NAPTR
   record in addition to the mandatory "E2U".


3. The Usage of "enumservices"

3.1 Simple URI Schemes

   The simplest proposal is, as hinted in the examples of RFC2916bis, to
   indicate the scheme of the resulting URI of the regexp, by using the
   same name for the enumservice as for the URI-scheme: +mailto, +sip,
   +h323, +tel, etc.



Stastny                Expires - December 2002               [Page 3]


           Analysis of the Usage of ENUM and ENUM Services  June 2002


   Since some URI schemes may point to different services or one URI may
   provide more then one service, additional information may be required
   to select the proper NAPTR record and to eliminate false positives.

3.2 Combined URI Schemes and Services

   It was therefore proposed to define a combination of the URI-scheme
   and the service provided by this URI-scheme as enumservice, e.g.:

   +telvoice, +telfax, +telsms, +sipvoice, +sipvideo, etc.

   The names for these enumservices may be defined easily by using on
   one side the names of the URI-schemes and on the other side the names
   of the services, provided that the names used for the services are
   different from the URI-schemes. Also the same service names shall be
   used for the equivalent services with different URI-schemes. This
   implies, that the names of this enumservices should be self-
   explaining, even if the exact functions still have to be described in
   in the URI-schemes and in the ENUM registration template.

   All enumservices related to one URI may be defined in one template
   (as defined in RFC2816bis) and preferably by the specialists and/or
   workgroup dealing with this URI-scheme.

   These two approaches of enumservice definitions could be used
   together, since different names are used. So the enumservices +sip,
   +tel, +mailto, +h323, etc. may be used in addition to the
   enumservices +telfax, +telvoice, etc.


3.3 Functional grouping of "enumservices"

   It was pointed out during the discussions, that some functional
   grouping of the enumservices may be helpful for evaluating,
   especially from the user point of view.

   If this is not considered as an alternative, but as additional
   information to the selection process, all three approaches to the
   definitions of enumservices may exist and may be used in parallel.

   So the definitions of the functional groups of services may be added
   to the above mentioned simple and combined enumservices, provided
   that different names are used e.g.:

   +talk, +message, +info, +chat, +srs, +certificate, etc.,.

   The functional groups of enumservices may be defined based on already
   defined enumservices, re-using their definitions, so it may be not
   necessary to define them based on the URI-schemes themselves, e.g.:


Stastny                Expires - December 2002               [Page 4]


           Analysis of the Usage of ENUM and ENUM Services  June 2002



   talk may be defined using the enumservice definitions +tel, +sip,
   +telvoice, +sipvoice, +h323voice, etc.


4. Examples of "enumservices"

4.1 The URI-schemes to be used in ENUM

   In principle any URI-Scheme may potentially be used in ENUM.

   Nevertheless, at least for the ENUM trials and also for compatibility
   of the ENUM client-SW, it does make sense to define the URI-schemes
   valid for ENUM, e.g.:

   mailto:
   ldap:
   smtp:
   sip:
   h323:
   tel:
   http:
   https:
   ftp:
   sftp:
   enum:
   etc.

   Of course, the list may be expanded at any time.

   Note: For the use and purpose of the URI Scheme enum, see <draft-
   stastny-enum-scenarios-00.txt>, section 7.2 [4].


4.2 The Services to be used in ENUM

   If an URI-Scheme may provide different services, either separate or
   in parallel, the services and how they are indicated need to be
   defined. This shall be done in the definition of the URI-scheme.

   In addition, there need to be defined, which of these services may be
   used with ENUM.

   The URI tel: may e.g. point to a voice-only phone number, to a fax-
   only phone number, to a sms-only phone number, or to a phone number
   providing all three services (see also [5]).

   The definitions of the services are URI specific, so only examples
   are given here:


Stastny                Expires - December 2002               [Page 5]


           Analysis of the Usage of ENUM and ENUM Services  June 2002



   voice, fax, sms, ems, mms, tdd, ivoice, etc. for tel:
   mail, key, etc. for ldap:
   voice, video, etc. for sip: and h323:
   etc.

   Remark: it should be noted, that e.g a sip- or h323-client may use
   tel, sip and h323 URIs, if the application service provider allows
   it. This may also be valid for other URI-schemes.


4.3 Simple and combined "enumservices"

   Now for each URI-scheme the simple and/or combined enumservices are
   defined.

   For all URI-schemes providing (currently) only one service within
   ENUM, the same name for the enumservice as for the URI-scheme may be
   sufficient, e.g. "mailto".

   For all URI-schemes allowing potentially more than one service to be
   used, combined enumservices are defined e.g.:

   telvoice, telfax, telsms, telems, telmms, telivoice, etc.
   telrn, telcic, teldn, etc.
   sipvoice, sipvideo, etc.
   h323voice, h323video, etc.
   ldapmail, ldapkey, etc.
   etc.

   Each block of enumservices related to one URI-scheme could be defined
   in one template.

   Note: the enumservices telrn, telcic and teldn are primarily required
   for infrastructure ENUM-like Systems and may be defined separately
   (see also [4]).

   An open question is whether the definition of a simple enumservice is
   required in addition, if combined enumservices are defined for an
   URI-scheme and what the functional specification of such an simple
   enumservice should be.

   There are some choices of definitions possible:

   a. All possible services of the URI-scheme are implemented with this
   enumservice.





Stastny                Expires - December 2002               [Page 6]


           Analysis of the Usage of ENUM and ENUM Services  June 2002


   b. All possible services of the URI-scheme that are not implemented
   with another enumservice explicitely are implemented with this
   enumservice.

   c. The services related to this URI-scheme may be negotiated.

   d. A default service is defined in the functional specification of
   the related enumservice.

   e. The service is obvious together with the functional group used in
   conjunction with this simple enumservice(see below)

   There may even exist different approaches for different simple
   enumservices, described in the functional description.


4.4 Functional groups of "enumservices"

   The functional groups proposed so far are:

   "talk" (or "phone" or "rtc") used with:
   tel, telvoice, sipvoice, sipvideo, h323voice, h323video, etc.,
   for any kind of two-way realtime mediastream communication.

   "msg" (or "message") used with:
   mailto, smtp, ldap, ldapmail, telsms, telems, telmms, etc.,
   for any kind of store-and-forward or instant messaging application.

   "info" (or "file") used with:
   http, https, ftp, sftp, etc.,
   to point to any kind of information, either on a web-page or at
   document.

   "cert" (or "certificate") used with
   "ldap, ldapkey, etc.,
   to point to any kind of certificate, eg. a public key.
   Note: Is there a possibility to store a public key directly in DNS?

   "srs" (or "enquire/inquire") used with:
   sip, h323, etc.,
   if the services are not defined explicitly, but need to be
   negotiated.

   "pres" (or "presence") used with:
   sip, etc.,
   for any kind of presence or location information.

   "chat" (or "textchat") used with:
   sip, etc.,


Stastny                Expires - December 2002               [Page 7]


           Analysis of the Usage of ENUM and ENUM Services  June 2002


   to be used for real-time text communication.

   "streaming" (or "broadcast") used with:
   rtsp, etc.,
   for any kind of one-way streaming broadcast, e.g audio or video
   broadcast. This may also be used for announcements.


   "any" used with:
   enum, or any other functional group, if a user wants to redirect all
   or parts or the services to another number.

   For each functional group a template needs to be defined, but since
   these templates may refer to the already defined templates of the
   simple and/or combined enumservices, the creation of these templates
   may be simple.

   This may also solve some of the above mentioned problems of the
   definition of single-URI enumservices, e.g.:

   a. a functional group enumservice may only be defined if a related
   simple or combined enumservice exists.

   b. a simple enumservice may be used, if it is selfexplaining together
   with a functional group enumservice, e.g.: "E2U+talk+tel".

   c. if the services are to be negotiated, the functional group
   enumservice "srs" has to be used, e.g. "E2U+srs+sip"


4.5 Informational enumservices

   Customers may require additional optional enumservices to tag certain
   NAPTR records for specific use.

   One example may be derived from the convention how to put different
   phone numbers on a business card, e.g. "Home", "Office", "Mobile",
   etc.

   Therefore an enumservice field may look like "E2U+talk+sip+home" or
   "E2U+msg+mailto+office"


5. Maximum Packet Size Considerations

   DNS uses primarily UDP to transmit requests and responses. As per
   RFC1035 [6] the maximum UDP packet size for DNS is 512 Octets.




Stastny                Expires - December 2002               [Page 8]


           Analysis of the Usage of ENUM and ENUM Services  June 2002


   The UDP max packet size limit for UDP has implications on two
   parameters, which are not independent. Up to some 7 NAPTRs can be
   transmitted in a single DNS response, dependent on how long the RR
   is. The longer the NAPTR is the fewer NAPTRs RR can be put into a
   domain, if UDP has be used. Thus, long enumservice fields like

       "E2U+tel+telvoice+telvideo+telfax+telsms+telems+telmms"

   are highly discouraged. In defining the enumservices for ENUM this
   has to be taken into account.

   The DNS UDP maximum packet size limit can be overcome by using TCP.
   However using TCP additional latency is introduced due to
   establishing a TCP connection prior to the data transfer.


6. Conclusion

   This draft may show a way forward in the definition of enumservices,
   at least for the planned ENUM trial period.

   The examples of the enumservices given are compatible and usable in
   the ENUM trials either independently or combined, even if finally the
   experience of the ENUM trials may show, that not all of the
   enumservices described here may be required or some combinations of
   enumservices may be redundant.

   The ENUM trials will also provide information on the number of NAPTR
   RR and "enumservices" used by the typical ENUM End Users and if there
   are any problems with the above mentioned packet size limitations.


7. Security Considerations

   This document does not introduce new security implications other than
   those associated with the ENUM Service as defined in Draft
   RFC2916bis.

   If there are specific security considerations related to an URI-
   scheme, service or an "enumservice", this should be covered with the
   definition of the URI-scheme or the "enumservice".


8. Acknowlegdements

   The author would like to thank Rich Shockey, Patrik Faltstrom,
   Michael Mealling, Andrew Zmolek and Clive Feather for their comments
   and invaluable help.



Stastny                Expires - December 2002               [Page 9]


           Analysis of the Usage of ENUM and ENUM Services  June 2002



9. References

   1  Scott Bradner, RFC2026, "The Internet Standards Process รป
      Revision 3," October 1996.

   2  P. Faltstrom, "The E.164 to URI DDDS Application",
      draft-ietf-enum-rfc2916bis-01.txt,
      Work in Progress, March 2002.

   3  M. Mealling, "Dynamic Delegation Discovery System  (DDDS) Part
      Three: The DNS Database"
      draft-ietf-urn-dns-ddds-database-08.txt,
      Work in Progress, February 2002.

   4  R. Stastny, "Scenarios for ENUM and ENUM-like Systems",
      draft-stastny-enum-scenarios-00.txt,
      Work in Progress, June 2002.

   5  R. Brandner, "The 'tel:' URI 'svc' parameter",
      draft-brandner-tel-svc-00.txt,
      Work in Progress, June 2002.

   6  P. Mockapetris, RFC1035, "Domain Names - Implementation and
      Specification", November 1987.


 10. Author's 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>
        Talk:  <tel:+44-1794-833666>



Stastny                Expires - December 2002              [Page 10]


            Analysis of the Usage of ENUM and ENUM Services  June 2002




    Richard Stastny
        OeFEG
        Postbox 147
        1103 Vienna
        Austria

        Msg:  <mailto:richard.stastny@oefeg.at>
        Talk:  <tel:+43-664-420-4100>









































 Stastny                Expires - December 2002              [Page 11]