IPTEL Working Group                                           R.Brandner
Internet-Draft                                                 Siemens
                                                              L.Conroy
                                                               Siemens
                                                              R.Stastny
                                                               OeFEG
Expires:  August, 2003                               February 24th, 2003

                       'The "enum:" URI scheme'
                     draft-brandner-enum-uri-01.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.

   This Internet-Draft will expire on August 24, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.


Abstract

    This document specifies the "enum:" URI scheme. This URI is intended for
    use where a resource address can be returned by evaluating the URI value
    using the ENUM DDDS application. Syntactically, it uses a subset of the
    format defined for the "tel:" URI scheme.


.  Introduction

    The tel: URI is specified in RFC2806bis [1]. This holds a telephone
    number and optional parameters. It can be used to initiate a telephone
    call to the number it holds as its value, or may be used within a SIP
    session setup (e.g. it may be used in the from: or to: fields of a SIP
    Invite message; see RFC3261 [2] for more details). The "tel:" URI does
    not specify whether or not an ENUM [3] query should be made prior to
    initiating a call; thus a "tel:" client may or may not generate a
    request to the ENUM infrastructure.

    It is convenient to have a URI that appears very similar in format to
    the "tel:" URI, but with which a compliant client MUST generate a query
    on the ENUM system. That is the role for the "enum:" URI scheme, as
    specified in this document.

1.1.  Expected Usage

    A URI is not appropriate for all situations in which a telephone number
    may be found, and this is as true for an "enum:" URI as a "tel:" URI.
    Some situations where URIs can't be used are:

    -  Call delivered to a Media Gateway has a Destination Number only.

    -  PSTN Signaling System No.7 messages have Source and Destination
       Numbers or Digits; they do not have URIs.

    -  In the interface to a telephone, normally the user enters a
       destination 'phone number or identifier, not a URI

    The "enum:" URI is expected to find use on Web Pages and in email
    signatures, for example. Whilst it would be possible to publish the URIs
    that were generated by the NAPTRs (NAPTRs are defined in [4]) stored
    within ENUM, this would miss the selectivity by enumservice that ENUM
    provides, and could easily lead to a lack of synchronization between the
    various URI values.

    As a URI, in principle it may appear anywhere that another URI might.
    However, its use in other services such as in H.323 or SIP systems (for
    example, in the To: field of a SIP Invite message) is NOT recommended
    here - such use would at least require further consideration and may
    well require further standardization.

    An "enum:" URI can appear as the constructed value that is the result of
    ENUM processing (as can any other URI).

1.2.  Document Content

    The syntax for this URI-scheme is covered in the next section. The
    subsequent section covers the expected client behavior, whilst section
    4 covers the security and privacy issues associated with this scheme,
    and this is followed by the IANA considerations for this document.


.  Syntax for the "enum:" URI scheme

    The syntax of this scheme is a subset of that defined for the "tel:"
    scheme defined in RFC2806bis. In particular, the local-number form is
    excluded, and the global-number form excludes the optional
    isdn-subaddress parameter.

    enum-uri             =   enum-uritoken enumref

    enum-uritoken        =   "enum:"

    enumref              =   global-number-part

    (global-number-part as defined in RFC2806bis)


.  Expected Client Behavior

    This URI scheme encloses a value in the form of an E.164 telephone
    number. The intention is that a client MUST use this E.164 number to
    generate a query to the ENUM infrastructure in order to evaluate this
    URI.

    The essential difference between this URI scheme and the "tel:" scheme
    is that, in this case, the client MUST generate an ENUM query to resolve
    the resource, whilst in the case of the "tel:" scheme, the client may
    generate such a query or instead directly set up a phone call to the
    "tel:" URI value using a local or shared GSTN connection - its behavior
    in this is undefined.

3.1.  URI parameters

    This URI scheme does not use parameters - its sole purpose is to be
    passed to an ENUM client processor. The E.164 number that is the URI
    value is used as input to the ENUM process; no other parameters are
    relevant in this case. Thus, when processing this URI, any parameters
    appended to it SHOULD be ignored with the URI value being passed to an
    ENUM process alone.

3.2.  "enum:" URI usage within ENUM domain space

    This section covers the specific case where an "enum:" URI is present as
    the value constructed from processing a NAPTR "under" e.164.arpa. using
    the ENUM process, and the interactions with the ENUM client application
    this involves.

    As a general principle, an ENUM client SHOULD NOT re-submit a query to
    the ENUM system if it receives a "tel:" URI in response to its current
    query. However, if an "enum:" URI is the result of ENUM processing, then
    the client MUST re-submit it (i.e. use the "enum:" URI value to generate
    a new ENUM query).

3.2.1.  "enum:" URI - comparisons with uses of other approaches

*    "enum:" versus "tel:"

    The difference between "tel:" or "enum:" URIs that are generated as the
    result of ENUM processing is that evaluation of the "enum:" URI MUST
    initiate a re-submission of a query to the ENUM system (using the
    enclosed global-number-part), whilst a client SHOULD NOT re-submit the
    contents of a "tel:" URI to the ENUM infrastructure.

*    "enum:" versus CNAME

    An "enum:" URI differs from the use of a CNAME within a sub-domain of
    e164.arpa in that a redirection to another part of the ENUM domain space
    can be effected for an individual NAPTR that meets the matching
    criteria. With CNAME, it is the only Resource Record for a DNS domain,
    so that ALL queries would be redirected.

*    "enum:" versus non-terminal NAPTR

    An "enum:" URI differs from the use of the "replacement" field of a
    non-terminal NAPTR in that with a replacement field the DDDS application
    continues its processing, whilst an "enum:" URI is the result of a query
    - it is part of a "terminal" NAPTR and allows the client application to
    evaluate its requirements prior to re-submission.

    The global-number-part syntax used with "enum:" URIs has certain
    advantages in REGEXP processing within "terminal" NAPTRs when selective
    redirection within the e164.arpa. "golden tree" is required. The URI
    takes phone numbers as its value. REGEXP processing of the ENUM
    Application Unique String (see [3] for details) to generate a different
    phone number is more straightforward than attempting to generate a
    domain name within e164.arpa. space.

    Use of "enum:" URIs allows a Registrant (ENUM Subscriber) of several
    ENUM domains (each associated with a different number) to redirect
    queries temporarily to a single domain associated with a phone number
    and so within e164.arpa. space without recourse to requesting changes to
    Tier1 NS records for the domains, and to do so selectively for different
    enumservice-specialised entries. This can be done using "non-terminal"
    NAPTRs and explicit domain names within the e164.arpa. space. However,
    experience in Trials has shown that the "reversed number" domains that
    requires are not as intuitively obvious as phone numbers. Customer-
    provisioning is much easier if a simple URI is to be installed; CNAMEs
    and "reversed domain" replacement fields are prone to "user error".


3.2.2.  Example of use of "enum:" URI in e164.arpa.

    Redirection from one part of the e164.arpa. tree (associated with one
    E.164 number) to another part of the tree (associated with another
    number) can be difficult, particularly with variable length numbers.
    For example, converting from the number +432221234567890 to the
    number +4311234567890 without "hard coding" the REGEXP (or the
    replacement field, in a "non-terminal" NAPTR) is not easy.

    If a domain name within e164.arpa is to be constructed using a REGEXP
    from the ENUM Application Unique String (effectively, the input phone
    number), then the digits have to be reversed; not easy and perhaps
    impossible with variable length digit strings.

(i) As an alternative to constructing a domain name within e164.arpa., an
    "enum:" URI could be readily constructed using simple REGEXP processing,
    and re-submission of this would have a similar effect. For example,

    0.9.8.7.6.5.4.3.2.1.2.2.2.3.4.e164.arpa.
        IN NAPTR 10 10 "E2U+esx"  "!^43222(.*)$!enum:+431\1!" .

    would suffice to redirect an ENUM query of +432221234567890 to look at
    the domain associated with number +4311234567890 for queries that
    matched the enumservice "esx".

(ii) In fact, an identical REGEXP subsequent part could be used in any
    number of different e164.arpa. domains to map from one area of the tree
    to another. Thus, exactly the same REGEXP field (in fact, the same
    NAPTR content) within another domain under 2.2.2.3.4.e164.arpa. could
    be used to redirect a query to "its" equivalent number. Thus:

    9.0.1.2.3.4.5.6.7.8.2.2.2.3.4.ea64.arpa.
        IN NAPTR 10 10 "E2U+esx"  "!^43222(.*)$!enum:+431\1!" .

    would redirect an ENUM query of +432228765432109 to look at the domain
    associated with number +4318765432109 for queries that matched the
    enumservice "esx".

(iii) Finally, this is how an "enum:" URI might be used in a "wildcard"
    Resource Record. Note that the use of DNS wildcards is NOT recommended
    here; this merely shows how a wildcard MIGHT be used with an "enum:"
    URI.

    2.2.2.3.4.e164.arpa.
    *  IN NAPTR 10 10 "E2U+esx"  "!^43222(.*)$!enum:+431\1!" .


    The intention here would be to redirect queries on any number "under"
    the area code +43-222 to the area code +43-1, for any ENUM query that
    matched the enumserevice "esx". This of course assumes that there are
    NO Resource Records "under" 2.2.2.3.4.e164.arpa.

        Note that a similar affect might be achieved by the use of a DNAME
        record. However, in that case the value returned would depend on
        whether or not the extended DNS option flags were set in the query,
        and the target suffix used in the DNAME Resource Record would be a
        "reversed domain".


.  Security Issues

    Our initial thought is that the "enum:" URI has no more security and
    privacy implications above any other use of ENUM. Also, it has similar
    privacy implications to the use of a "tel:" URI.

    Publication of an "enum:" URI, for example within a Web page, DOES
    indicate that there is an ENUM entry with this value as a key. This
    exposes some information, but as this can be found out anyway by the
    expedient of performing a test ENUM query, it is not seen as being
    important.


.  IANA Considerations

    This document specifies a URI scheme. To ensure that this URI scheme
    value does not collide with other uses, it is necessary to register this
    token.

    Thus this requests that this document be considered a specification for
    the 'enum:' URI scheme, and that a registration be made for this use.


.  Acknowledgments

        Jon Peterson gave constructive comments on the "enum:" URI.


.  History

Version - 0 , issued June 2002
  - Initial version.

Version - 1 , issued February 2003
  - removed reference to ENUM 'es' URI parameter

  - added recommendation to ignore any included parameters

  - removed reference to combination of 'es' parameter values with
    client selection


.  References

[]  H. Schulzrinne, A. Vaha-Sipila,
     "URIs for Telephone Calls",
     draft-antti-RFC2806bis-07.txt,
     Work in progress, December 2002

[]      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

[]  P. Faltstrom, M. Mealling,
     "The E.164 to URI DDDS Application (ENUM)",
     draft-ietf-enum-rfc2916bis-3.txt,
     Work in progress, January 2003

[]      M. Mealling, "Dynamic Delegation Discovery System (DDDS)
           Part Three: The Domain Name System (DNS) Database",
     RFC3403, Internet Engineering task Force, October 2002


.  Authors' Addresses

   Rudolf Brandner

   Siemens ICN
   Hofmannstrasse 51
   Munich
   Germany

   Email:  <mailto:rudolf.brandner@siemens.com>
   Phone:  <tel:+49-89-722-51003>
   URI:    <http://www.siemens.de>



   Lawrence Conroy

   Siemens Roke Manor Research
   Roke Manor
   Romsey
   U.K.

   Email:  <mailto:lwc@roke.co.uk>
   Phone:  <tel:+44-1794-833666>


   Richard Stastny

   OeFEG
   Postbox 147
   1103 Vienna, Austria

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


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.