A Telephone Number Mapping (ENUM) Service Registration for Instant Messaging (IM) Services
RFC 5028

Posted related IPR disclosure: Comcast IP Holdings I, LLC's Statement about IPR related to RFC 3953, RFC 4415, RFC 4759, RFC 4769, RFC 4002, RFC 4355, RFC 4414, RFC 4725, RFC 4969, RFC 4979, RFC 5028, RFC 5278, RFC 5346, RFC 5067, RFC 5076, RFC 5105, RFC 2168, RFC 3401, RFC 3402, RF...

[Ballot comment]
The example phone number '+12025332600' in Section 1 needs to
  be changed to a fictitious number.  See Section 3.6.D of the
  ID-Checklist.

[Ballot discuss]
The resolver needs to be able to verify that the published E.164
  record has not been tampered.  I think that the security
  considerations should suggest DNSSEC to provide this protection.

IANA Last Call Comments:

Upon approval of this document, IANA understands it
must complete a single action.

In the Enumservice Registrations registry located at:

http://www.iana.org/assignments/enum-services

a new registration will be added:

Enumservice Name:
"im"
Enumservice Type:
"im"
Enumservice Subtypes:
N/A
URI scheme(s):
"im:"
Functional Specification:
This Enumservice indicates that the resource identified
is an 'im:' URI. The 'im:' URI scheme does not identify
any particular protocol that will be used to handle
instant messaging receipt or delivery, rather the mechanism
in RFC 3861 [4] is used to discover whether an IM protocol
supported by the party querying ENUM is also supported by
the target resource.
Security considerations:
See section 3 of RFC XXXX.
Intended usage:
COMMON
Author:
Rohan Mahy (rohan@ekabal.com)

IANA understands that this is the only action required
upon approval of this  document.

PROTO Write-up

1. Have the chairs personally reviewed this version of the Internet Draft (ID), and in particular, do they believe this ID is ready to forward to the IESG for publication?

Yes the document has been reviewed by the WG chairs.

2. Has the document had adequate review from both key WG members and key non-WG members?

Yes, the document was reviewed by WG members as well as other persons. The concepts represented in this document have influence on other documents in the ENUM scene.

3. Do you have any concerns about the depth or breadth of the reviews that have been performed?

There are no concerns about depth or breadth of the reviews.

4.  Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)?

No.

5. Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or have concerns whether there really is a need for it. In any event, if your issues have been discussed in the WG and the WG has indicated it that it still wishes to advance the document, detail those concerns in the write-up.

No concerns.

6. How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The majority of the working group members have expressed their appreciation of the document. Suggestions from members have been incorporated into the document. It represents one of a series of enumservice registrations.
7. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email to the Responsible Area Director.

No, there are no known threats to appeal.

8. Have the chairs verified that the document adheres to all of the ID Checklist items?

Yes.

9 .Is the document split into normative and informative references? Are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? (note here that the RFC editor will not publish an RFC with normative references to IDs, it will delay publication until all such IDs are also ready for publication as RFCs.)

References are properly split, there are no normative references to IDs.

10. What is the intended status of the document? (e.g., Proposed Standard, Informational?)

The intended status is Proposed Standard.

1. For Standards Track and BCP documents, the IESG approval announcement includes a write-up section with the following sections:

o Technical Summary
o Working Group Summary
o Protocol Quality

Technical Summary (Same as Abstract):

This document registers a Telephone Number Mapping (ENUM) service for Instant Messaging (IM).  Specifically, this document focuses on provisioning 'im:' URIs in ENUM.

 
Working Group Summary:

The document represents another mapping of E.164 number to an application, in this case instant messaging services. This service might assist global operators in integrating IM and SMS services transparently.

Protocol Quality:


* Are there existing implementations of the protocol?

No.

* Is this protocol used in practice?

Not yet, but rapid adoption is anticipated.

Have a significant number of vendors indicated they plan to implement the specification?

There is strong interest in integrating Instant Messaging services among mobile carriers world wide.


Are there any reviewers that merit special mention as having done a thorough review (i.e., that resulted in important changes or a conclusion that the document had no substantive issues)?


Not really

+++

Sheparding WG Chair: Richard Shockey

Last Call Completed: August 14, 2006

NITS Reviewer Alexander.mayrhofer@enum.at>