Find JSRs
Submit this Search

Ad Banner

Summary  |  Proposal  |  Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 161: JAINTM ENUM API Specification

Stage Access Start Finish
Public Review Download page 11 May, 2004 10 Jun, 2004
Community Draft Ballot View results 29 Oct, 2002 04 Nov, 2002
Community Review Login page 30 Sep, 2002 04 Nov, 2002
Expert Group Formation   25 Dec, 2001 17 May, 2002
JSR Review Ballot View results 11 Dec, 2001 24 Dec, 2001
Status: Dormant
JCP version in use: 2.1
Java Specification Participation Agreement version in use: 1.0

The JAINTM ENUM API Specification defines a standard, portable application programming interface to query and provision E.164 telephone numbers and their service-specific Uniform Resource Identifiers (URI).

Please direct comments on this JSR to the Spec Lead(s)

Specification Leads
  Christopher John NetNumber, Inc.
Expert Group
  Ericsson AB NetNumber, Inc. Sun Microsystems, Inc.

This JSR has been Dormant
Reason: The Executive Committee voted to list this JSR as dormant in May 2012.

Original Java Specification Request (JSR)

Identification | Request | Contributions | Additional Information

Section 1. Identification

Submitting Member: NetNumber, Inc

Name of Contact Person: Bob Walter

E-Mail Address:

Telephone Number: +1 978 848 2831

Fax Number: +1 978 454 5044

Specification Lead: Rodger Mattlage

E-Mail Address:

Telephone Number: +1 978 848 2854

Fax Number: +1 978 454 5044

Initial Expert Group Membership:

Individuals from the following organizations are being considered: BroadSoft, Cisco, Dynamicsoft, Inc, Ericsson, Longboard, NetNumber, NexTone , Sprint, Sun Microsystems, Telcordia, Ubiquity Software.

Supporting this JSR:

Sun Microsystems

Section 2: Request

2.1 Please describe the proposed Specification:

The JAINTM ENUM API specification enables applications to query and provision ENUM entries (i.e. E.164 telephone numbers and their service-specific URIs) into an ENUM registry.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

JavaTM Standard Edition

2.3 What need of the Java community will be addressed by the proposed specification?

The JAINTM ENUM API Specification defines a cross-platform, portable API that enables Carriers, Service Providers and Communications Equipment Vendors to rapidly integrate ENUM-compliant resolution, as well as, ENUM provisioning functionality into their Java applications and platforms.

2.4 Why isn't this need met by existing specifications?

ENUM is a Domain Name System (DNS) based protocol defined by the IETF in [RFC2916]. General DNS resolver APIs and implementations expose the low-level protocol of DNS and do not encapsulate the specialized processing required by ENUM. The JAIN ENUM API hides the complexities of DNS resolution and Dynamic DNS provisioning (DDNS) [RFC2163], while encapsulating the higher-level services of ENUM, including POSIX Regular Expression Handling, Resolution Service and Protocol Filtering, Security (DNSSEC) [RFC2535], Extended DNS Support (EDNS0) [RFC2671, etc.

2.5 Please give a short description of the underlying technology or technologies:

The ENUM protocol is based on DNS technology and POSIX Extended Regular Expression Handling. DNS is a client-server application protocol built on top of both UDP and TCP communications protocols. DNS is a core networking technology on the Internet and is designed to be extremely lightweight and efficient in both platform resource (i.e. memory, disk, processor) and network bandwidth consumption.

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)


2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?


2.8 Are there any security issues that cannot be addressed by the current security model?

The reference implementation must provide for HMAC-MD5 hashing algorithm in support of DNS security requirements [RFC2104].

2.9 Are there any internationalization or localization issues?

ENUM entries are based on domain names that [RFC1035] defines character strings as ASCII 8-bit unsigned octets.

2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?


2.11 Please describe the anticipated schedule for the development of this specification.

Initiation: Dec 2001
Community Review: March 2002
Public Review: April 2002
Final Draft Proposal: June 2002

2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.

Primary form of collaboration will be via email and augmented by scheduled conference calls when necessary. The expert group will draw upon the experts in the ENUM and JAIN industry and face-to-face meetings will be coordinated under the JAIN Initiative. The regularly scheduled meetings of this initiative, will facilitate fluid exchange of information and encourage participation by the experts of this expert group.

Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1997.
[RFC2163] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound "Dynamic Updates in the Domain Name System", RFC 2136, April 1997.
[RFC2916] Faltstrom, P, "E.164 number and DNS", RFC 2916, September 2000.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2671] Vixie,P., "Extension Mechanism for DNS (EDNS0)", RFC 2671, August 1999
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2535] Wellington, B., Domain Name System Security (DNSSEC) Signing Authority, RFC 2535, November 2000

3.2 Explanation of how these items might be used as a starting point for the work.

The items listed in 3.1 are IETF specifications from which this work is derived.

Section 4: Additional Information (Optional)

4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.