2.7.5 Telephone Number Mapping (enum)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.

Last Modified: 2005-01-17


Patrik Faltstrom <paf@cisco.com>
Richard Shockey <rich.shockey@neustar.biz>

Transport Area Director(s):

Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>

Transport Area Advisor:

Allison Mankin <mankin@psg.com>

Mailing Lists:

General Discussion: enum@ietf.org
To Subscribe: enum-request@ietf.org
In Body: subscribe
Archive: http://www.ietf.org/mail-archive/web/enum/index.html

Description of Working Group:

This working group has defined a DNS-based architecture and protocol
2916] by which an E.164 number, as defined in ITU Recommendation
be expressed as a Fully Qualified Domain Name in a specific Internet
Infrastructure domain defined for this purpose (e164.arpa). The result
the ENUM query is a series of DNS NAPTR resource records [RFC2915] 
can be used to contact a resource (e.g.URI) associated with that

The Working Group proposes to advance RFC 2916 from Proposed Standard
Draft Standard.


E.164 numbers are globally unique, language independent identifiers for
resources on Public Telecommunication Networks that can support many
different services and protocols. E.164 numbers are used to identify
ordinary phones, fax machines, pagers, data modems, email clients, text
terminals for the hearing impaired, etc.

A prospective caller may wish to discover which services and protocols
supported by the terminal named by a given telephone number. The
also require more information than just the telephone number to
with the terminal.

The holder of an E.164 number or device may wish to control what
associated with that number.

Working Group Revised Goals and Scope:

1. The working group will update RFC 2916 to reference the DDDS system
  (revision of RFC 2915) and advance RFC 2916 to Draft Standard.

2. The working group will examine and document various aspects of ENUM
  administrative and/or operational procedures as Informational.
  Issues to be considered include privacy and security considerations
  in storing ENUM related data as well as validation and
  authentication of data, including DDDS NAPTR records in the DNS.
  working group will coordinate activities in these areas with the
  DNSEXT WG and PROVREG WG when appropriate.

3. The Working Group will continue to maintain appropriate contact and
  liaison with standards bodies and groups, specifically ITU-T SG2,
  in order to provide technical or educational information as needed,
  such as the appropriate use of DNS.  The Working Group will
  encourage the exchange of technical information within the
  emerging global ENUM community as well as documentation on practical
  experiences with implementations or administration of RFC 2916.

Goals and Milestones:

Done  Initial draft of Service ENUM Requirements
Done  Initial draft of ENUM Protocol
Done  Revised draft of ENUM Protocol
Done  Submit ENUM Protocol document to IESG for publication as Proposed
Done  Revise and update RFC 2916 appropriate to DDDS (revision of 2915)
Done  ENUM service registrations for SIP and H.323
Aug 03  Document appropriate ENUM Security and Privacy Issues (Informational)
Nov 03  Document appropriate ENUM Registration and Provisioning Procedures (Informational)


  • draft-ietf-enum-epp-e164-08.txt
  • draft-ietf-enum-msg-04.txt
  • draft-ietf-enum-experiences-01.txt
  • draft-ietf-enum-void-00.txt
  • draft-ietf-enum-iris-ereg-00.txt

    Request For Comments:

    RFC2916 PS E.164 number and DNS
    RFC3482 I Number Portability in the Global Switched Telephone Network (GSTN): An Overview
    RFC3761 Standard The E.164 to URI DDDS Application (ENUM)
    RFC3762 Standard ENUM Service Registration for H.323 URL
    RFC3764 Standard enumservice registration for SIP Addresses-of-Record
    RFC3953 Standard Enumservice Registration for Presence Services
    RFC4002 Standard IANA Registration for ENUMservices web and ft

    Current Meeting Report

    Telephone Number Mapping WG (enum)

    IETF 62 Minneapolis, MN

    Wednesday, March 9 at 1300-1500

    CHAIRS: Patrik Faltstrom <paf@cisco.com>
    Richard Shockey <rich.shockey@neustar.biz>

    Transport Area Advisor:
    Allison Mankin <mankin@psg.com>

    Mailing Lists:
    General Discussion:enum@ietf.org
    To Subscribe: enum-request@ietf.org
    In Body: subscribe
    Archive: ftp://ftp.ietf.org/ietf-mail-archive/enum/

    SCRIBE : Spencer Dawkins <spencer@mcsr-labs.org>


    Report from APEET SIP/ENUM trial at Apricot 2005 at Kyoto.

    * Informational item - Yoshiro Yoneya
    * Goal of APEET is to conduct joint trials and promote ENUM and related technologies, including SIP
    * Trial goal was to provide ENUM/SIP experience for every Apricot attendee
    * Not providing telephony service - no warranties!
    * Provided 802.11 handsets and id/passwords for ENUM directory
    * Participants communicated with other attendees, overseas, registered ENUM information/opt-in phone book
    * About 100 participants registered in phonebook, about 30 with more than two URIs
    * Registration prototype now available as free software
    * Supported three common SIP phone types
    * 888-205-xxxx calls, overseas calls made with ENUM lookup
    * About 7800 200-OKs, 300 other responses
    * SIP really can use ENUM for call routing
    * Authentication mechanism from SIP server to MGW is different for each gateway - requires testing
    * Handover between access points is still difficult
    * RTP within same AP still difficult
    * Planning to offer same service at IETF 64 (500-2000 handsets) in Vancouver
    * Was this trial only on ENUM operation or on delegation, etc? Mostly providing experience for participants

    WG business.

    1. Discussion of the ENUM dip indicator on behalf of the IPTEL WG.

    * Left out an author in 00 draft - will add in 01 after blackout period
    * Enumdi syntax has not changed
    * Replaced MUST NOT retrieve with SHOULD NOT retrieve
    * Updated examples as example.com domain names
    * Recommending IPTEL WGLC on this document

    2. Status from Patrik on what is happening with the IANA and enumservice registrations.

    * Issues resolved on Monday of this week - everything has been sorted out with IANA
    * Are VPIM registrations consistent with what we want? Yes, with no additional changes identified on the mailing list - they have been approved by IESG and are good to go now
    * Enum+? This will be updated in RFCs

    2b. There seems to be a sense that we need to at least discuss some of the structure issues in enumservice registrations in general terms ..this seems to be a warm issue recently with various requirements coming out of 3GPP etc . In particular we do not have a TEL URL enum registration document as of yet and someone needs to take on that task.

    * VOPI registration draft? Make this a working group item, as informational document?
    * Still need a standards-track TEL URL document - we'll clarify all this on the list

    3. Issues related to IRIS for ENUM -- We have had no in-depth discussion of this draft on the list and we'd like to see more.


    * Who has read it? Not a lot of people in the room
    * Opinions or concerns about this document? ENUM administrations are looking at this document as a potential requirement
    * This is a wonderful document ...
    * Minimal changes since last revision, fourth version as WG document

    4. New Item Enumservice registrations for Conferencing Alan Johnston 20M

    A URL for this Internet-Draft is:

    * conf-web and conf-uri registrations
    * conf-web is discovery mechanism for web conferences - URI is a source of information about the conference
    * either HTTP or HTTPS
    * Value over RFC 4002 web? Don't know a web URI is about a conference
    * Will a single phone number route to a single person or to a conference? Why would a UA ever do this lookup?
    * My phone number might have a web page associated with it, but most callers won't bring up the web page unless they know it's part of the conference
    * Madness lies this way - there's no end to what we might treat as a special case
    * If both web and conf-web are present, they probably point to the same URI
    * Problem we're solving is telling a caller "this is a conference" - even if it doesn't exist on the IP network at all? Is this even an ENUM problem?
    * Do see difference between web and conf-web - should they refer to different phone numbers?
    * Not finding a resource, but providing information about the resource - this isn't how we want to use ENUM service tags
    * If the service provider needs to provide multiple URIs, multiple ENUM tags make sense
    * Is this a phone number that identifies a conference, or a conference server? If it's a conference server, that's ludicrous, if it's a conference, it makes more sense
    * Would a user go to a single web server to enter a PIN number? What about different PINs for different components of the conference?
    * We're moving along discovering how much information we want to publish for ENUM services, and there are lots of potential kinds of things to publish - "the client might want to know" doesn't let us draw the line anywhere
    * SIP has a negotiation capability so we don't need this in SIP - this is more about the kind of thing you'll find if you call the resource - picture of a dog on the web page? conversations about communism? What does a client do differently when they see this tag?
    * Is interpretation based on human intelligence, or does it accommodate automatons? Automatons would require a lot more structure than we're talking about here.
    * Isn't this the same as isfocus in SIP? If we needed that, we need this
    * We should be keying off a specific kind of XML document, not off an enumservice tag
    * Conf-uri is actually the controversial part of the proposal...
    * Says that the resource is a focus
    * How many telephone numbers are true conference URIs with no passcode or PIN needed?
    * Is it OK to have both a sip and a conf-uri URI?
    * Not hearing clear consensus on what to do with this document, or what to do with conferences in enumservice registrations (is it needed or is this part of normal SIP negotiation?)
    * Concern is that devices who don't understand this tag won't be able to connect to a conference - need to include sip if you include conf or conf-uri
    * What's wrong with just saying "isfocus" in the SIP URI returned from the lookup?
    * Is it necessary to know that it's a conference before you start negotiating?
    * Is there anything you'd differently before you contact the URI? That's the critical question
    * We're trying to create boundaries on what a service is, on an ad hoc basis, and that's not working well
    * Alan to respin this document with more use cases to see if we can move forward
    * We need to be a lot better at deciding what is a service than we are now... it can't be this painful every time someone proposes an enumservice!
    * We also need to worry about URI schemes defined by people who didn't think about any of this

    5. In private discussions with folks there seems to me a demonstrable need to create a SOAP binding for EPP-164. I believe this is an extremely important project and I'd like to see if there is A. sufficient interest in the project and if there is sufficient interest B. find some folks who would be willing to work on the draft.


    * Mostly enterprise-level interest, and their toolkits are based on SOAP. Anything that helps with provisioning is good.

    6. ENUM Validation update w/Bernie Hoeneisen

    * Ensure that ENUM owner == E.164 owner at registration time
    * Version 01 is adding requirements section, split into transport and content, handling renewal and transfer, adding acknowledgements and corrections/updates
    * Should this be a working group item? as Informational item? Room hum is "yes"

    7. Status of ENUM Operational Experiences draft?

    * No new items in document - can we WGLC a new revision before Paris? Yes

    8. WG next steps?

    * Enumdi loops when we're trying to prevent loops? discussion on mailing list - if you get the same tel URI back, this is just loop detection with one bounce - can we just cover the general loop case with hop count > 1? What do you do when you get a loop back with or without enumdi? Use first one, last one ...
    * GSMA or 3GPP may be requesting ENUM for GRX network - two NAPTR, one with SIP and one with e-mail for SMS messages. If there is an IMS enum service, should the enumservice be ims: or sip+ims:? This is another slippery slope - is this IMS release 5, IMS release 6, ... but it sounds really wrong. Do we need to take on a liaison on this? Slippery slope is about 80-percent incline. Doesn't matter if we have an official liaison or not - we need to know what to tell them, either way. ETSI has asked and we can give them our opinions. Why do you need to know that a user is within the IMS system? We have no idea. This is using the DNS as a replacement for negotiation. There's an IAB draft on DNS assumptions that's in last call - please look at this and comment! ENUM idea is that you look up one number and get back one URI - if you voice and IM from the same SIP URI, this has to come from one provider, right? Where do we multiplex- ENUM or SIP? How much SIP call routing do we put in DNS (suggested answer = none). If we don't want to do this, we need to make sure people can't try, or they'll try for sure.


    APEET ENUM/SIP Live Trial at Apricot 2005 Kyoto
    Enum dip indicator
    EREG – IRIS for ENUM
    EPP Extension Framework for ENUM Validation
    IANA Registration for ENUMservices ‘conf-web’ and ‘conf-uri’