Subject: [Enum] New version of rfc2916bis

From: Patrik Fältström <[email-masked]>
Date: Sun, 24 Nov 2002 12:25:10 +0100

Please check this carefully. There is one section missing, changes 
since RFC 2916, which I need to add.

Changes since previous version:

(a) Grammar cleaned up
(b) References cleaned up (1st try) and split into normative and 
non-normative
(e) Only one example still in the document, and one h323 URI is added

As usual, proposed changes with constructive comments (so I can do cut 
and paste) are appreciated.

     paf

ENUM                                                        P. Faltstrom
Internet-Draft                                         Cisco Systems Inc
Expires: May 25, 2003                                        M. Mealling
                                                                 VeriSign
                                                        November 24, 2002

                 The E.164 to URI DDDS Application (ENUM)
                    draft-ietf-enum-rfc2916bis-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 May 25, 2003.

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 3401.  It is very important to
    note that it is impossible to read and understand this document
    without reading the documents discussed in RFC 3401.

Faltstrom & Mealling      Expires May 25, 2003                  [Page 1]

Internet-Draft                    ENUM                     November 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  . . . . . . . . . . . . . . . . . . . .  6
    3.    Registration mechanism for Enumservices  . . . . . . . . . .  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.2 Registration Template  . . . . . . . . . . . . . . . . . . .  9
    4.    Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
    4.1   Example  . . . . . . . . . . . . . . . . . . . . . . . . . . 10
    5.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 11
    6.    Security Considerations  . . . . . . . . . . . . . . . . . . 12
    7.    Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 13
          Normative References . . . . . . . . . . . . . . . . . . . . 14
          Non-normative references . . . . . . . . . . . . . . . . . . 15
          Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15
          Full Copyright Statement . . . . . . . . . . . . . . . . . . 16

Faltstrom & Mealling      Expires May 25, 2003                  [Page 2]

Internet-Draft                    ENUM                     November 2002

1. Introduction

    Through transformation of E.164 [4] numbers into DNS names and the
    use of existing DNS services like delegation through NS records and
    NAPTR records, 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 3403 [1].

1.2 Use for these mechanisms for private dialing plans

    This document specifies 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.  To implement that (a) a different domain, well-known
    for all parties using the same dialing plan, SHOULD be selected and
    (b) the application unique string (see section 3.1 below) SHOULD 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 May 25, 2003                  [Page 3]

Internet-Draft                    ENUM                     November 2002

2. The ENUM Application Specifications

    This template defines the ENUM DDDS Application according to the
    rules and requirements found in [1].  The DDDS database used by this
    Application is found in [2] 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.

    For example, the E.164 number could start out as "+1-770-923-9595".
    To ensure that no syntactic sugar is allowed into the AUS, all non-
    digits except for "+" are removed, yielding "+17709239595".

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 and this Applications databases are 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.

    Take the previous example, the AUS is "+17709239595".  Applying the
    First Well Known Rule produces the exact same string, "+17709239595".

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

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 3403) [2] 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:

Faltstrom & Mealling      Expires May 25, 2003                  [Page 4]

Internet-Draft                    ENUM                     November 2002

    1.  Remove all characters with the exception of the digits.  For
        example, the First Well Known Rule produced the Key
        "+4689761234".  This step would simply remove the leading "+",
        producing "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

    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 may contain
    the end result or, if the flags field is blank, produces new keys in
    the form of domain-names from the DNS.

    DNS servers MAY interpret Flag values and use that information to
    include appropriate resource 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 3404 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 an E.164 number.  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 [3].

    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 then this rule is non-terminal.  If a
    Rule is non-terminal then clients MUST use the Key produced by this
    Rewrite Rule as the new Key in the DDDS loop (i.e.  causing the
    client to query for new NAPTR records at the domain-name that is the
    result of this Rule).

Faltstrom & Mealling      Expires May 25, 2003                  [Page 5]

Internet-Draft                    ENUM                     November 2002

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   = "+" type 0*(subtype)
                     type          = 1*32(ALPHA / DIGIT)
                     subtype       = ":" 1*32(ALPHA / DIGIT)

    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 Enumservices which indicate what class of
    functionality a given end point offers.  Each Enumservice is
    indicated by an initial '+' character.

2.4.2.1 ENUM Services

    An enumservice MUST be registered with the IANA via a description in
    an RFC.  Enumservices specifications contain the functional
    specification (i.e.  what it can be used for), the valid protocols,
    and the URI schemes that may be returned.  Note that there is no
    implicit mapping between the textual string "type" or "subtype" in
    the grammar for the Enumservice and URI schemes or protocols.  The
    mapping, if any, have to be made explicit in the specification for
    the Enumservice itself.  A registration of a specific Type also have
    to specify the Subtypes allowed.

    The only exception to the registration rule is for Types and Subtypes
    used for experimental purposes, and those are to start with the facet
    "X-".  These elements 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 May 25, 2003                  [Page 6]

Internet-Draft                    ENUM                     November 2002

3. Registration mechanism for Enumservices

    Registration of Enumservices requires approval by the IESG and
    publication of the Enumservice 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

    An Enumservice 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.

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

3.1.2 Naming requirement

    The name of an Enumservice 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 experimental, private use.

3.1.3 Security requirement

    An analysis of security issues is required for for all Enumservices
    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 Enumservice" must
    not be confused with "the security issues associates with this
    Enumservice have not been assessed".

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

    The security considerations section of all registrations is subject
    to continuing evaluation and modification.

Faltstrom & Mealling      Expires May 25, 2003                  [Page 7]

Internet-Draft                    ENUM                     November 2002

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

    1.  Complex Enumservices 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 results.  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 Enumservices 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.  An Enumservice might be targeted for applications that require
        some sort of security assurance but not provide the necessary
        security mechanisms themselves.  For example, a Enumservice could
        be defined for storage of confidential medical information which
        in turn requires an external confidentiality service.

3.1.4 Publication Requirements

    Proposals for Enumservices registered must be published as RFCs.
    IANA will retain copies of all Enumservice registration proposals and
    "publish" them as part of the ENUM Enumservice 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 Enumservice itself.

3.2.1 IANA Registration

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

3.2.1.1 Location of ENUM Enumservice Registrations

    Enumservice registrations will be published in the IANA repository
    and made available via anonymous FTP at the following URI: "ftp://
    ftp.isi.edu/in-notes/iana/assignments/enum-services/".

Faltstrom & Mealling      Expires May 25, 2003                  [Page 8]

Internet-Draft                    ENUM                     November 2002

3.2.1.2 Change Control

    Change control of Enumservices stay with the IETF via the RFC
    publication process.  Especially, Enumservice registrations may not
    be deleted; Enumservices 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

    Enumservice Name:

    Type(s):

    Subtype(s):

    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 May 25, 2003                  [Page 9]

Internet-Draft                    ENUM                     November 2002

4. Examples

    The examples below use theoretical services which uses Enumservices
    which might not make sense, but they are still used for educational
    purposes.  For example, the protocol used is in some cases exactly
    the the same string as the URI scheme.  That was the specification in
    RFC 2916, but this default specification of a Enumservice is no
    longer allowed.  All Enumservices need to be registered explicitly by
    the procedure specified in section Section 3N.

4.1 Example

    $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa.
      IN NAPTR 100 10 "u" "E2U+sip"            
"!^.*$!sip:[email-masked]!"     .
      IN NAPTR 101 10 "u" "E2U+h323:voice"     
"!^.*$!h323:[email-masked]!"    .
      IN NAPTR 102 10 "u" "E2U+message:mailto" 
"!^.*$!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, secondly via H.323 for voice, and
    thirdly by SMTP for messaging.  Note that the tokens "sip",
    "message", "h323", "voice" and "mailto" are Types and Subtypes
    registered with IANA, and they have no implicit connection with the
    protocols or URI schemes with the same names.

    In all cases, the next step in the resolution process is to use the
    resolution mechanism for each of the protocols, (specified by the URI
    schemes sip, h323 and mailto) to know what node to contact for each.

Faltstrom & Mealling      Expires May 25, 2003                 [Page 10]

Internet-Draft                    ENUM                     November 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.

    IAB is to coordinate with ITU-T TSB if the technical contact for the
    domain e164.arpa is to change, as ITU-T TSB has an operational
    working relationship with this technical contact which needs to be
    reestablished.

    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 Enumservices as specified in
    Section 3.  Whenever a new ENUM Enumservice is registered by the RFC
    process in the IETF, IANA is at the time of publication of the RFC to
    register the Enumservice and add a pointer to the RFC itself.

Faltstrom & Mealling      Expires May 25, 2003                 [Page 11]

Internet-Draft                    ENUM                     November 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 URIs produced by the DDDS mechanism.
    Those have to be specified in the registration of the ENUM
    Enumservice used, as specified in Section 3.1.3.

Faltstrom & Mealling      Expires May 25, 2003                 [Page 12]

Internet-Draft                    ENUM                     November 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 arrived from ITU-
    T SG2, Working Party 1/2 (Numbering, Routing, Global Mobility and
    Enumservice Definition), the ENUM working group in the IETF, John
    Klensin and Leif Sunnegardh.

    This update of RFC 2916 is created with specific input from: Randy
    Bush, David Conrad, Richard Hill, Jim Reid, Joakim Stralmark, Robert
    Walter and James Yu.

Faltstrom & Mealling      Expires May 25, 2003                 [Page 13]

Internet-Draft                    ENUM                     November 2002

Normative References

    [1]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
         Three: The DNS Database", RFC 3403, February 2002.

    [2]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
         Four: The URI Resolution Application", RFC 3404, February 2002.

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

    [4]  ITU-T, "The International Public Telecommunication Number Plan",
         Recommendation E.164, May 1997.

Faltstrom & Mealling      Expires May 25, 2003                 [Page 14]

Internet-Draft                    ENUM                     November 2002

Non-normative references

    [5]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
         One: The Comprehensive DDDS Standard", RFC 3401, February 2002.

    [6]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
         Two: The Algorithm", RFC 3402, February 2002.

Authors' Addresses

    Patrik Faltstrom
    Cisco Systems Inc
    Ledasa
    273 71 Lovestad
    Sweden

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

    Michael Mealling
    VeriSign
    21345 Ridgetop Circle
    Sterling, VA  20166
    US

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

Faltstrom & Mealling      Expires May 25, 2003                 [Page 15]

Internet-Draft                    ENUM                     November 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 May 25, 2003                 [Page 16]

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

---

From: "Stastny Richard" <[email-masked]>
Date: Tue, 26 Nov 2002 23:35:37 +0100

Rich Shockey wrote:
 
>ack... priority=preference ... I think Richard understands that now.
 
Thanks, you all are really so sympathetic to morons like myself ;-)

>Though some of us accept that the logical ordering is
>type=sip  subtype=voice et.al. and not the other way around.

>Richard ..now dont get started.. :-)
I keep cool now, but wait;-)

>But if a enumservice field 'voice' is established with subtypes sip and
>h323 then IMHO that there is functional equivalency between

>E2U+voice:sip    and
>E2U+sip:voice

>am I making sense here?
I understand what you mean, but IMHO there is no equivalency
automatically
and this comes out of the text of RFC2916bis and also the 
explanation I got from MM:
 
 -citation MM begin-
The three characters 's', 'i'
and 'p' that happen to appear in the Enumservice field are nothing more
than a pointer into a database managed by the IANA that contains a
document which explains rather explicitly what those three letters mean
when found in that field. 
-citation MM end-

So if a define an enumservice with type voice and subtype sip in a RFC 
according to RFC2916bis, so the characters voice:sip are just a pointer into
a database document .....
 
If you define an enumservice with type sip and subtype voice in another RFC
so the characters sip:voice are just a pointer to another document .....
 
I asked also:
 
> e.g voice:tel and sip:tel is possible to mean something
> (not necessarily completely) different and the same holds for
> voice:sip and sip:voice.
>
> Therefore "subtypes" tel and sip for enumservice(s)
> voice:tel and voice:sip are defined with "type" voice
>
> and
> "subtypes" tel and voice for enumservice(s)
> sip:tel and sip:voice are defined with "type" sip.
 
and got the answer:

MM: Correct. That's what the document says. The enumservice is unique. It
never says that subtypes are unique....

The descriptions in the two documents for voice:sip and sip:voice
MAY be equivalent, but need not to be.
 
And if they are different, I do not think that clients have a problems
to separate the functions.
 
Summary: you have two different enumservices voice:sip and sip:voice defined
If they are equivalent or not is depending on the description.
Since I know only the description for voice:sip and have none for
sip:voice, I do not know yet.

>That many of us would like to use sip and h323 as enumservices has to do
>with how the NAPTR records are processed by client user agents and that is
>where we still need clarification.

>This is a old problem that goes back quite a while and Richard is entirely
>correct is wanting a more concrete explanation. Jon James Yu and I brought
>this up a long time ago.

>I have always understood the parsing of the NAPTR records upon receipt to
>occur FIRST on the enumservice field to find the service(s) desired.  There
>is NO look ahead to the URI's in the regexp. Once those records for a
>enumservice are chosen a further selection can be made on the order field
>as you have in the example so that if a CU/A sees two sip enumservices it
>can properly select which one to process first.

>I thought we were agreeing that two similar services should maintain the
>same preference value.

>The clarification as I see it is what is the proper relationship to order
>and preference (priority) in processing.

>We definitely need better text here.
 
Definitive, this is urgent. I am still awaiting an answer from MM
on these issues (see my other e-mail) and I need the answer this
week because we need to define the minimum requirements
for the clients and I have to submit asap to ETSI. And
I want the order and preference=priority also clarified.

> >
> > and I also consider the discussions we had in ATL: that it is not
> > allowed to look at the "right" for the URI scheme, it is obvious,
> > that the "type" or the "subtype" of an enumservices (if it may be
> > usable with more then one URI scheme and may eventually
> > require different selection mechanism when choosing one NAPTR
> > resource record from the other) needs to indicate the URI scheme.
>
>Incorrect. An enumservice defines what URIs can and might appear in the
>regexp field. If a particular enumservice limits itself to only allow
>one particular URI scheme then it must say so. But, IMNSHO, it MUST not
>replicate the URI scheme directly into the Services field. Those two
>concepts are not equivalent. A URI identifies a Resource within the
>systems of URIs. An Enumservice defines a set of inputs, outputs and
>processes using E.164 numbers and URIs. Those two things are orthogonal
>and thus REQUIRES an explicitly types mapping function between the two.

>Mike I'm lost with this comment. Could you elaborate?
 
I was lost too, especially with the MUST not replicate part
If I define voice:foo to be a voice service using only the sip URI
scheme and protocol, this is ok. According to the above wording voice:sip
is not ok (also sip:voice is not ok;-).

> >
> > Of course finally the "type":"subtype" combination
> > (in this order) has to be unique. I also defer that
> > a "type" MUST be unique, especially if the "type" is specifying
> > the "subtypes" (to be used within the type).
> >
> > I also defer from the discussion in ATL that a
> > "type" and a "subtype" need not to be unique,
> > e.g. we may have a "type"=sip and a "subtype"=sip.
> >
> > If now the registration of the "type" specifies
> > the specific "subtypes" allowed within this "types",
> > and also the mapping, the "subtypes" need NOT to be unique.
>
>Sure... hence the discussion about transitive subtypes.
>
> > e.g voice:tel and sip:tel is possible to mean something
> > (not necessarily completely) different and the same holds for
> > voice:sip and sip:voice.

>well this is the problem I have ... this could be very very confusing to
>implementers if it is held that these two could actually define different
>things assuming that a CU/A is going to look at these fields first.

>unless,as you point out, that in the registration document for 'voice' it
>is explicitly understood that these MUST be treated as equivalent.

as I explained above, its only pointers to a document and my designers are very
clever ;-)

> > > "!^.*$!mailto:[email-masked] <mailto:[email-masked]> !"  .
> >
> > Even if it is stated above that the examples might not make sense,
> > IMHO they should, and also referring to the discussion in ATL
> > and the search for a compromise between the proposals I would prefer
> > to have the following example:
> >
> > >       IN NAPTR 100 20 "u" "E2U+voice:h323"
> > >       IN NAPTR 100 30 "u" "E2U+message:mailto"
> > > "!^.*$!mailto:[email-masked] <mailto:[email-masked]> !"  .
>
>I actually like the previous version of the example. I would like some
>text discussing the fact that the h323 service subtypes based on
>function class while the last record defines function classes as
>services and then subtypes based on how that service is expressed.
>
> > See also the same order and different preference as mentioned above.
>
>Can you elaborate on that statement? The two examples above are actually
>doing very different things. The example in the document is saying that
>you have to match explicitly on each group's service field and you can
>only use the one that matches first. The second is saying that each
>service is 'equivalent' and the client gets to pick. That's two very
>different things.

>exactly
 
See my other e-mail, I am still having problems here.
I elaborated in the other e-mail.
I am happy with any explanation.
 
Richard Stastny

---

From: Richard Shockey <[email-masked]>
Date: Tue, 26 Nov 2002 20:51:30 -0500

>explanation I got from MM:

  I know ... MM can state that the two are functionally non-equivalent 
..but then If I was some poor software development manager trying to tell 
my code jockeys what to do ... I'd have a problem and you are right this is 
way too ambiguous for my tastes.

>so the characters sip:voice are just a pointer to another document .....

yep... it looks simple but it is not.

>to separate the functions.

tell that to a coder....

But Richard ..this also highlights the direction enumservices compendium 
needs to take.

Broken apart with clear and unambiguous definitions of type and subtype and 
what URI to expect for each option each document can stand on its own.

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
<mailto:[email-masked]> or <mailto:[email-masked]>
  <http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<