Subject: [Enum] 2916bis

From: Patrik Fältström <[email-masked]>
Date: Thu, 21 Feb 2002 21:29:12 +0100

Here is the first version of the 2916bis document. Note, it is _NOT_
submitted to the Internet-Draft archive yet. It will be before cut-off
tomorrow (friday). This is so you can give _fast_ constructive comments
that we might have time to update before the cutoff.

Otherwise (default) is for me to collect issues you all have and send them
to Richard so they end up being discussion points.

As you can see there are three important changes from RFC 2916:

(1) The service field in the NAPTR is now the following

        service_field = [ "E2U" 1*("+" enumservice)]

    This is _NOT_ backward compatible. Reason for this is that
    one could register for example sipvoice, sipgaming and
    sipimpp and then have the service field which is

         E2U+sipvoice+sipgaming+sipimpp

(2) A registration is mandatory for _any_ service which is added
    to the E2U facet

(3) An empty flag field in the NAPTR is allowed, and means
    that another lookup is to be done, i.e. we don't
    force all NAPTR to be terminal

There are probably inconsistencies in the document, because Michael and
myself have worked hard on both getting this done, being active on the
mailing list _and_ updating according to comments on the mailing list.

2916bis will be a recycle on proposed, because too many changes are needed
to go to draft standard.

          paf

Network Working Group                                       P. Faltstrom
Internet-Draft                                         Cisco Systems Inc
Expires: August 22, 2002                                     M. Mealling
                                                                VeriSign
                                                       February 21, 2002

                   The E.164 to URI DDDS Application
                   draft-ietf-enum-rfc2916bis-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.

   This Internet-Draft will expire on August 22, 2002.

Copyright Notice

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

Abstract

   This document discusses the use of the Domain Name System (DNS) for
   storage of E.164 numbers.  More specifically, how DNS can be used for
   identifying available services connected to one E.164 number.  It
   specifically obsoletes RFC 2916 to bring it in line with the Dynamic
   Delegation Discovery System (DDDS) Application specification found in
   the document series specified in RFC WWWW.  It is very important to
   note that it is impossible to read and understand this document
   without reading the documents discused in RFC WWWW.

Faltstrom & Mealling     Expires August 22, 2002                [Page 1]

Internet-Draft                    ENUM                     February 2002

Table of Contents

   1.      Introduction . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1     Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   1.2     Use for these mechanisms for private dialing plans . . . .  3
   1.3     Application of local policy  . . . . . . . . . . . . . . .  3
   2.      The ENUM Application Specifications  . . . . . . . . . . .  4
   2.1     Application Unique String  . . . . . . . . . . . . . . . .  4
   2.2     First Well Known Rule  . . . . . . . . . . . . . . . . . .  4
   2.3     Expected Output  . . . . . . . . . . . . . . . . . . . . .  4
   2.4     Valid Databases  . . . . . . . . . . . . . . . . . . . . .  4
   2.4.1   Flags  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.4.2   Services Parameters  . . . . . . . . . . . . . . . . . . .  5
   2.4.2.1 ENUM Services  . . . . . . . . . . . . . . . . . . . . . .  6
   3.      Registration mechanism for ENUM Services . . . . . . . . .  7
   3.1     Registration Requirements  . . . . . . . . . . . . . . . .  7
   3.1.1   Functionality Requirement  . . . . . . . . . . . . . . . .  7
   3.1.2   Naming requirement . . . . . . . . . . . . . . . . . . . .  7
   3.1.3   Security requirement . . . . . . . . . . . . . . . . . . .  7
   3.1.4   Publication Requirements . . . . . . . . . . . . . . . . .  8
   3.2     Registration procedure . . . . . . . . . . . . . . . . . .  8
   3.2.1   IANA Registration  . . . . . . . . . . . . . . . . . . . .  8
   3.2.1.1 Location of ENUM Service Registrations . . . . . . . . . .  8
   3.2.1.2 Change Control . . . . . . . . . . . . . . . . . . . . . .  9
   3.2.2   Registration Template  . . . . . . . . . . . . . . . . . .  9
   4.      Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10
   4.1     Example 1  . . . . . . . . . . . . . . . . . . . . . . . . 10
   4.2     Example 2  . . . . . . . . . . . . . . . . . . . . . . . . 10
   4.3     Example 3  . . . . . . . . . . . . . . . . . . . . . . . . 10
   5.      IANA Considerations  . . . . . . . . . . . . . . . . . . . 12
   6.      Security Considerations  . . . . . . . . . . . . . . . . . 13
   7.      Acknowledgments  . . . . . . . . . . . . . . . . . . . . . 14
           References . . . . . . . . . . . . . . . . . . . . . . . . 15
           Authors' Addresses . . . . . . . . . . . . . . . . . . . . 15
           Full Copyright Statement . . . . . . . . . . . . . . . . . 17

Faltstrom & Mealling     Expires August 22, 2002                [Page 2]

Internet-Draft                    ENUM                     February 2002

1. Introduction

   Through transformation of E.164 numbers into DNS names and the use of
   existing DNS services like delegation through NS records, and use of
   NAPTR records in DNS, one can look up what services are available for
   a specific domain name in a decentralized way with distributed
   management of the different levels in the lookup process.

   The domain "e164.arpa" is being populated in order to provide the
   infrastructure in DNS for storage of E.164 numbers.  In order to
   facilitate distributed operations, this domain is divided into
   subdomains.  Holders of E.164 numbers which want to be listed in DNS
   should contact the appropriate zone administrator in order to be
   listed, by examining the SOA resource record associated with the
   zone, just like in normal DNS operations.

   Of course, as with other domains, policies for such listings will be
   controlled on a subdomain basis and may differ in different parts of
   the world.

1.1 Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.

   All capitalized terms are taken from the vocabulary found in the DDDS
   algorithm specification found in RFC ZZZZ [3].

1.2 Use for these mechanisms for private dialing plans

   This document specify how "ENUM" works, that is how to handle numbers
   allocated according to the ITU-T standard E.164.  But, a similar
   mechanism can be used also for other numbers, such as private dialing
   plans.  Suggested change is that (a) a different domain, well-known
   for all parties using the same dialing plan, is selected and (b) the
   application unique string (see section 3.1 below) is to be the full
   number as specified but without the leading '+'.

1.3 Application of local policy

   The priority field in the NAPTR is a request from the holder of the
   E.164 in what order the records are to be used.  It is to be noted
   that the party looking up the records MAY apply a local policy for in
   what order the records are to be used based on a combination of the
   service fields and URI schemes.

Faltstrom & Mealling     Expires August 22, 2002                [Page 3]

Internet-Draft                    ENUM                     February 2002

2. The ENUM Application Specifications

   This template defines the ENUM DDDS Application according to the
   rules and requirements found in [3].  The DDDS database used by this
   Application is found in [4] which is the document that defines the
   NAPTR DNS Resource Record type.

2.1 Application Unique String

   The Application Unique String is a fully qualified E.164 number minus
   any non-digit characters except for the '+' character which appears
   at the beginning of the number.  The "+" is kept to provide a well
   understood anchor for the AUS in order to distinguish it from other
   telephone numbers that are not part of the E.164 namespace.

2.2 First Well Known Rule

   The First Well Known Rule for this Application is the identity rule.
   The output of this rule is the same as the input.  This is because
   the E.164 namespace is organized in such a way that it is possible to
   go directly from the name to the smallest granularity of the
   namespace directly from the name itself.

2.3 Expected Output

   The output of the last DDDS loop is a Uniform Resource Identifier in
   its absolute form according to the 'absoluteURI' production in the
   Collected ABNF found in RFC2396 [7].

2.4 Valid Databases

   At present only one DDDS Database is specified for this Application.
   "Dynamic Delegation Discovery System (DDDS) Part Three:  The DNS
   Database" (RFC ZZZZ) [4] specifies a DDDS Database that uses the
   NAPTR DNS resource record to contain the rewrite rules.  The Keys for
   this database are encoded as domain-names.

   The output of the First Well Known Rule for the ENUM Application is
   the E.164 number minus all non-digit characters except for the +.  In
   order to convert this to a unique key in this Database the string is
   converted into a domain-name according to this algorithm:

   1.  Remove all characters with the exception of the digits.  Example:
       4689761234

   2.  Put dots (".") between each digit.  Example: 4.6.8.9.7.6.1.2.3.4

   3.  Reverse the order of the digits.  Example: 4.3.2.1.6.7.9.8.6.4

Faltstrom & Mealling     Expires August 22, 2002                [Page 4]

Internet-Draft                    ENUM                     February 2002

   4.  Append the string ".e164.arpa" to the end.  Example:
       4.3.2.1.6.7.9.8.6.4.e164.arpa

   This domain-name is used to request NAPTR records which produces new
   keys in the form of domain-names.

   DNS servers MAY interpret Flag values and use that information to
   include appropriate SRV and A records in the Additional Information
   portion of the DNS packet.  Clients are encouraged to check for
   additional information but are not required to do so.  See the
   Additional Information Processing section of RFC YYYY for more
   information on NAPTR records and the Additional Information section
   of a DNS response packet.

   The character set used to encode the substitution expression is UTF-
   8.  The allowed input characters are all those characters that are
   allowed anywhere in a URI.  The characters allowed to be in a Key are
   those that are currently defined for DNS domain-names.

2.4.1 Flags

   This Database contains a field that contains flags that signal when
   the DDDS algorithm has finished.  At this time only one flag, "U", is
   defined.  This means that this Rule is the last one and that the
   output of the Rule is a URI [7].

   If a client encounters a record with an unknown flag, it MUST ignore
   it and move to the next Rule.  This test takes precedence over any
   ordering since flags can control the interpretation placed on fields.
   A novel flag might change the interpretation of the regexp and/or
   replacement fields such that it is impossible to determine if a
   record matched a given target.

   If this flag is not present, clients must assume that another Rule
   exists at the Key produced by the current Rewrite Rule.

2.4.2 Services Parameters

   Service Parameters for this Application take the following form and
   are found in the Service field of the NAPTR record.

                    service_field = [ "E2U" 1*("+" enumservice)]
                    enumservice   = ALPHA *31ALPHANUM
                    ; The protocol and rs fields are limited to 32
                    ; characters and must start with an alphabetic.

Faltstrom & Mealling     Expires August 22, 2002                [Page 5]

Internet-Draft                    ENUM                     February 2002

   In other words, a non-optional "E2U" (used to denote ENUM only
   Rewrite Rules in order to mitigate record collisions) followed by 1
   or more or more Enum Services which indicate what class of
   functionality a given end point offers.  Each Enum Service is
   indicated by an initial '+' character.

   The empty string is also valid.  This will typically be seen at the
   beginning of a series of Rules, when it is impossible to know what
   services and protocols will be offered at the end of a particular
   delegation path.

2.4.2.1 ENUM Services

   A service MUST be registered with the IANA via a description in an
   RFC.  ENUM Services specifications contain the functional
   specification (i.e.  what it can be used for), the valid protocols,
   and the URI schemes that may be returned.  For example, the Enum
   Service "presence" would define the various URI schemes ("im:",
   "mailto:") can be used and what the service can be used for ("Where
   is the owner of this E.164 number?").  Another example might be
   "sipvoice" which specifies that the URI must use the 'sip:' URI
   scheme and use the SIP protocol to make a voice call (as opposed to a
   voice mail call or fax call).

   The only exception to the registration rule is for services used for
   experimental purposes, and those are to start with the facet "X-".
   These types are unregistered, experimental, and should be used only
   with the active agreement of the parties exchanging them.

   The registration mechanism is specified in Section 3.

Faltstrom & Mealling     Expires August 22, 2002                [Page 6]

Internet-Draft                    ENUM                     February 2002

3. Registration mechanism for ENUM Services

   Registration of services requires approval by the IESG and
   publication of the service registration as some form of RFC.

3.1 Registration Requirements

   Service registration proposals are all expected to conform to various
   requirements laid out in the following sections.

3.1.1 Functionality Requirement

   A Service registered must be able to function as a selection
   mechanism when choosing one NAPTR resource record from another.  That
   means that the registration MUST specify what is expected when using
   that very NAPTR record, and the URI which is the outcome of the use
   of it.  One example is when the URI resolution process gives an E.164
   number as output, and it MUST be specified whether a new ENUM lookup
   should be done or not.

   Specifically, a registered Service MUST specify the URI scheme(s)
   that may be used for the Service, and, when needed, other knowledge
   which have to be transfered into the URI resolution process itself
   (LDAP DNs, tranfering of the AUS into the resulting URI, etc).

3.1.2 Naming requirement

   The name of a Service MUST be unique, conform to the ABNF specified
   in Section 2.4.2, and MUST NOT start with the facet "X-" which is
   reserved for exeprimental, private use.

3.1.3 Security requirement

   An analysis of security issues is required for for all Services
   registered.  (This is in accordance with the basic requirements for
   all IETF protocols.)

   All descriptions of security issues must be as accurate as possible
   regardless of registration tree.  In particular, a statement that
   there are "no security issues associated with this Service" must not
   be confused with "the security issues associates with this Service
   have not been assessed".

   There is absolutely no requirement that Services registered must be
   secure or completely free from risks.  Nevertheless, all known
   security risks must be identified in the registration of a Service.

   The security considerations section of all registrations is subject

Faltstrom & Mealling     Expires August 22, 2002                [Page 7]

Internet-Draft                    ENUM                     February 2002

   to continuing evaluation and modification.

   Some of the issues that should be looked at in a security analysis of
   a Service are:

   1.  Complex Services may include provisions for directives that
       institute actions on a users resources.  In many cases provision
       can be made to specify arbitrary actions in an unrestricted
       fashion which may then have devastating.  Especially if there is
       a risk for a new ENUM lookup, and because of that an infinite
       loop in the overall resolution process of the E.164.

   2.  Complex Services may include provisions for directives that
       institute actions which, while not directly harmful, may result
       in disclosure of information that either facilitates a subsequent
       attack or else violates the users privacy in some way.

   3.  A Service might be targeted for applications that require some
       sort of security assurance but not provide the necessary security
       mechanisms themselves.  For example, a Service could be defined
       for storage of confidential medical information which in turn
       requires an external confidentiality service.

3.1.4 Publication Requirements

   Proposals for Services registered must be published as RFCs.  IANA
   will retain copies of all Service registration proposals and
   "publish" them as part of the ENUM Service Registration tree itself.

3.2 Registration procedure

   Normal IETF processes should be used for publication of the RFC which
   is the basis of the registration of the Service itself.

3.2.1 IANA Registration

   Provided that the Service has obtained approval that is necessary,
   and the RFC is published, IANA will register the Service and make the
   Service egistration available to the community in addition to the RFC
   publication itself.

3.2.1.1 Location of ENUM Service Registrations

   Service registrations will part from be published as an RFC be posted
   in the anonymous FTP directory "ftp://ftp.isi.edu/in-
   notes/iana/assignments/enum-services/".

Faltstrom & Mealling     Expires August 22, 2002                [Page 8]

Internet-Draft                    ENUM                     February 2002

3.2.1.2 Change Control

   Change control of Services stay with the IETF via the RFC publication
   process.  Especially, Service registrations may not be deleted;
   Services which are no longer believed appropriate for use can be
   declared OBSOLETE by publication of a new RFC and a change to their
   "intended use" field; such media types will be clearly marked in the
   lists published by IANA.

3.2.2 Registration Template

   Service Name:

   URI Scheme(s):

   Functional Specification:

   Security considerations:

   Intended usage: (One of COMMON, LIMITED USE or OBSOLETE)

   Author:

   Any other information that the author deems interesting:

Faltstrom & Mealling     Expires August 22, 2002                [Page 9]

Internet-Draft                    ENUM                     February 2002

4. Examples

   The examples below use theoretical services which have the same names
   as the URI schemes.  That was the specification in RFC 2916, but this
   default specification of a Service is no longer allowed.  All
   services need to be registered explicitly by the procedure specified
   in section NN.

4.1 Example 1

   $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa.
      IN NAPTR 100 10 "u" "sip+E2U"    "!^.*$!sip:[email-masked]!"     .
      IN NAPTR 102 10 "u" "mailto+E2U" "!^.*$!mailto:[email-masked]!"  .

   This describes that the domain 4.3.2.1.6.7.9.8.6.4.e164.arpa is
   preferably contacted by SIP, and secondly by SMTP.

   In both cases, the next step in the resolution process is to use the
   resolution mechanism for each of the protocols, (SIP and SMTP) to
   know what node to contact for each.

4.2 Example 2

   $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa.
     IN NAPTR  10 10 "u" "sip+E2U"     "!^.*$!sip:[email-masked]!"    .
     IN NAPTR 102 10 "u" "mailto+E2U"  "!^.*$!mailto:[email-masked]!" .
     IN NAPTR 102 10 "u" "tel+E2U"     "!^(.*$)$!tel:\1!"     .

   Note that the preferred method is to use the SIP protocol.  The URI
   is resolved as described in RFC 2543 [6].  In the case of the "tel"
   URI scheme [7], a replacement "\1" is used.

   The rest of the resolution of the routing is done as described above.

4.3 Example 3

      $ORIGIN 6.4.e164.arpa.
      * IN NAPTR 100 10 "u" "ldap+E2U" "!^+46(.*)$!ldap://ldap.se/cn=\1!" .

Faltstrom & Mealling     Expires August 22, 2002               [Page 10]

Internet-Draft                    ENUM                     February 2002

   We see in this example that information about all E.164 numbers in
   the 46 countrycode (for Sweden) exists in an LDAP server, and the
   search to do is specified by the LDAP URI [8].

Faltstrom & Mealling     Expires August 22, 2002               [Page 11]

Internet-Draft                    ENUM                     February 2002

5. IANA Considerations

   This memo requests that the IANA delegate the E164.ARPA domain
   following instructions to be provided by the IAB.  Names within this
   zone are to be delegated to parties according to the ITU
   recommendation E.164.  The names allocated should be hierarchic in
   accordance with ITU Recommendation E.164, and the codes should
   assigned in accordance with that Recommendation.

   Delegations in the zone e164.arpa (not delegations in delegated
   domains of e164.arpa) should be done after Expert Review, and the
   IESG will appoint a designated expert.

   IANA is to create a registry for ENUM Services as specified in
   Section 3.  Whenever a new ENUM Service is registered by the RFC
   process in the IETF, IANA is at the time of publication of the RFC to
   register the Service and add a pointer to the RFC itself.

Faltstrom & Mealling     Expires August 22, 2002               [Page 12]

Internet-Draft                    ENUM                     February 2002

6. Security Considerations

   As this system is built on top of DNS, one can not be sure that the
   information one get back from DNS is more secure than any DNS query.
   To solve that, the use of DNSSEC [9] for securing and verifying zones
   is to be recommended.

   The caching in DNS can make the propagation time for a change take
   the same amount of time as the time to live for the NAPTR records in
   the zone that is changed.  The use of this in an environment where
   IP-addresses are for hire (for example, when using DHCP [11]) must
   therefore be done very carefully.

   There are a number of countries (and other numbering environments) in
   which there are multiple providers of call routing and number/name-
   translation services.  In these areas, any system that permits users,
   or putative agents for users, to change routing or supplier
   information may provide incentives for changes that are actually
   unauthorized (and, in some cases, for denial of legitimate change
   requests).  Such environments should be designed with adequate
   mechanisms for identification and authentication of those requesting
   changes and for authorization of those changes.

   A large amount of Security Issues have to do with the resolution
   process itself, and use of the URI's produced by the DDDS mechanism.
   Those have to be specified in the registration of the ENUM Service
   used, as specified in Section 3.1.3.

Faltstrom & Mealling     Expires August 22, 2002               [Page 13]

Internet-Draft                    ENUM                     February 2002

7. Acknowledgments

   Support and ideas leading to RFC 2916 have come from people at
   Ericsson, Bjorn Larsson and the group which implemented this scheme
   in their lab to see that it worked.  Input has also come from ITU-T
   SG2, Working Party 1/2 (Numbering, Routing, Global Mobility and
   Service Definition), the ENUM working group in the IETF, John Klensin
   and Leif Sunnegardh.

   This update of that RFC is created with input from (in alphabetical
   order): David Conrad, James Yu, Jim Reid, Joakim Stralmark, Randy
   Bush and Richard Hill.

Faltstrom & Mealling     Expires August 22, 2002               [Page 14]

Internet-Draft                    ENUM                     February 2002

References

   [1]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
        One: The Comprehensive DDDS Standard", RFC WWWW, draft-ietf-urn-
        ddds-toc-02.txt (work in progress), February 2002.

   [2]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
        Two: The Algorithm", RFC XXXX, draft-ietf-urn-ddds-06.txt (work
        in progress), February 2002.

   [3]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
        Three: The DNS Database", RFC ZZZZ, draft-ietf-urn-dns-ddds-
        database-08.txt (work in progress), February 2002.

   [4]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
        Four: The URI Resolution Application", RFC YYYY, draft-ietf-urn-
        uri-res-ddds-06.txt (work in progress), February 2002.

   [5]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
        Five: URI.ARPA Assignment Procedures", RFC VVVV, draft-ietf-urn-
        net-procedures-10.txt (work in progress), February 2002.

   [6]  Mealling, M., "URI Resolution Services Necessary for URN
        Resolution", RFC 2483, January 1999.

   [7]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
        Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

   [8]  Petke, R. and I. King, "Registration Procedures for URL Scheme
        Names", RFC 2717, BCP 35, November 1999.

Authors' Addresses

   Patrik Faltstrom
   Cisco Systems Inc
   170 W Tasman Drive SJ-13/2
   San Jose, CA  95134
   USA

   EMail: [email-masked]
   URI:   http://www.cisco.com

Faltstrom & Mealling     Expires August 22, 2002               [Page 15]

Internet-Draft                    ENUM                     February 2002

   Michael Mealling
   VeriSign
   21345 Ridgetop Circle
   Sterling, VA  20166
   US

   EMail: [email-masked]
   URI:   http://www.verisignlabs.com

Faltstrom & Mealling     Expires August 22, 2002               [Page 16]

Internet-Draft                    ENUM                     February 2002

Full Copyright Statement

   Copyright (C) The Internet Society (2002).  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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Faltstrom & Mealling     Expires August 22, 2002               [Page 17]


_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 21 Feb 2002 21:38:24 +0100

>      IN NAPTR 102 10 "u" "tel+E2U"     "!^(.*$)$!tel:\1!"     .

Ok, I see myself that the examples are wrong. I forgot to change them. The
correct ones should be:

      IN NAPTR 100 10 "u" "E2U+sip"    "!^.*$!sip:[email-masked]!"     .
      IN NAPTR 102 10 "u" "E2U+mailto" "!^.*$!mailto:[email-masked]!"  .

      IN NAPTR  10 10 "u" "E2U+sip"     "!^.*$!sip:[email-masked]!"    .
      IN NAPTR 102 10 "u" "E2U+mailto"  "!^.*$!mailto:[email-masked]!" .
      IN NAPTR 102 10 "u" "E2U+tel"     "!^(.*$)$!tel:\1!"     .

    paf

---

From: "Maynard Kang" <[email-masked]>
Date: Fri, 22 Feb 2002 10:00:22 +0800

Hi Patrick et al,

>          E2U+sipvoice+sipgaming+sipimpp

Just one minor issue:

URI is denoted by "I" and not "U", according to the [RFC 2483] rs
convention.
If we want to keep to this convention, then E.164-to-URI should be "E2I" and
not
"E2U".

Other rs using an E164 number as the operand can then be defined
according to the same convention (e.g. E2C, E2L, E2R).

If we don't really need to keep to this convention then I guess the point is
moot.

regards,
maynard

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 22 Feb 2002 07:41:57 +0100

As you now understand the view I have collected from people is that we need
separate documents which is the actual registration of enumservices. To
"test" 2916bis, and also get some more documents rolling, I would like
people trying to write such I-D's as soon as possible.

That is for example what I personally belive the sipping draft about use of
ENUM and SIP should turn into. I have also heard rumors of someone working
on one which describes some enumservice which use the tel URI.

    paf

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 22 Feb 2002 07:39:17 +0100

--On 2002-02-22 10.00 +0800 Maynard Kang <[email-masked]> wrote:

> If we want to keep to this convention, then E.164-to-URI should be "E2I"
> and not
> "E2U".
> 

Interesting. I have personally been working a lot with RFC 2483 and others,
but this is the first time I hear someone binding the NAPTR service field
to that RFC.

Hmmm...

Originally E2U was picked just because the string "E.164" start with 'E'
and "URI" start with 'U'. :-)

   paf

---

From: "Maynard Kang" <[email-masked]>
Date: Fri, 22 Feb 2002 17:41:01 +0800

> but this is the first time I hear someone binding the NAPTR service field

What was the original intention of that document anyway? I notice it is an
experimental RFC.

> and "URI" start with 'U'. :-)

Yup, guess that as much :-)

regards,
maynard

---

From: Michael Mealling <[email-masked]>
Date: Fri, 22 Feb 2002 09:18:06 -0500

> What was the original intention of that document anyway? I notice it is an

URI Resolution uses it as a way to grossly classify URI related services.
I personally think it has at least some applicability in the web world 
with things like web services since those are operations on URIs and
their Resources.

> Yup, guess that as much :-)

I have to agree. I really don't think 2483 is really applicable here.
Especially since the input isn't a URI. One of the main points of 2483 was
that a URI is self typing so you didn't need to specify the input, just
the operation and the output.

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | urn:pin:1
[email-masked]      |                              | http://www.neonym.net

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 22 Feb 2002 15:37:17 +0000

>       IN NAPTR 102 10 "u" "E2U+tel"     "!^(.*$)$!tel:\1!"     .

Should that last one really have two dollar signs ?

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:  +44 20 8371 1138
Internet Expert     | Home:  <[email-masked]>  | Fax:  +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            | NOTE: fax number change

---

From: Michael Mealling <[email-masked]>
Date: Fri, 22 Feb 2002 10:54:16 -0500

> Should that last one really have two dollar signs ?

You're right.... this is the correct record.... 

I apologize for the many typos. I had this, CNRP and DDDS documents
all open at the same time. You should be gratefull that I didn't start 
sticking XML in here! ;-)

       IN NAPTR 102 10 "u" "E2U+tel"     "!^(.*)$!tel:\1!"     .

-MM