Subject: [Enum] notes on draft-ietf-enum-enumservices-guide

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 5 Jul 2007 09:36:45 -0400

I've owed the working group some notes on this draft for some time; hopefully they'll be helpful.

If we're really serious about letting the enumservices-guide document be the yardstick against whch future enumservice registrations are compared, then it needs significantly more information about the circumstances in which new enumservices are needed. In the document, the following question is already posed (in 3.1): Is there any existing enumservice defined or in progress that satisfies this need? This is a good start, and definitely needs to be retained. But I think its also a bit of an oversimplification - how do you really assess whether or not an existing enumservice satisfies your needs? I would be more concerned getting new registrants to answer questions like the following:

Is the proposed enumservice used to invoke a protocol (like SIP, or HTTP) or a particular service or application (like voicemail, or Mapquest), or neither (like "unused", perhaps)? This distinction (at least between the first two) is described in 3.3, but it really needs more elaboration. For example:

- Does a client need to understand the application, or be aware of the application, in order to utilize it the enumservice? If not, then structuring your enumservice around the protocol that contacts the application may be sufficient. For example, imagine an enumservice intended for geographical mapping services like Mapquest or Google Maps, which are reached via HTTP. One might think that registering an enumservice called "e2u+map" would be appropriate. However, many clients that support HTTP would be able to use Mapquest or Google Maps - nothing about Mapquest requires an HTTP client to understand or be aware of the mapping application in order to use it. A more general enumservice like "e2u+http" would probably be a more appropriate way to reach Google Maps or Mapquest because it is more broadly compatible - it doesn't require existing clients to learn "e2u+map" in order for the service to be provisioned in ENUM. As a general design principle, we want to avoid cases in which a client that would be able to dereference the URI, and interface meaningfully with the resource, is barred from doing so because it don't happen to understand a particular enumservice. Understanding this trade-off is fundamental to enumservice design.

- Many real-time communications protocols have their own capability negotiation mechanisms that converge on the best way for two endpoints to communicate. These include rendez-vous protocols like SIP and XMPP which are commonly used for VoIP. Other examples of capability-negotiating services include the address resolution mechanisms for the im: and pres: URI schemes. Initiating communication through these protocols does not assume that any particular network service will end up being invoked.

Will the URI returned by a dip to your enumservice contain a telephone number? Will it be a different number than the one that kicked off the ENUM process, and if not, how does one prevent the ENUM process from becoming circular?

Will your enumservice be restricted to any private context, or is it useful (and safe) on the public Internet? Lately we've begun to see more and more registrations for enumservices that contain information that isn't intended for the consumption of ordinary Internet endpoints.

How should I name the enumservice? This is both a syntactical and a semantic question. For example, how and why is subtyping used for enumservices? Nothing in 3.4 really says why you would need one, though it does list a few reasons why not.

Does the URIs returned by your enumservice point to a resource that changes over time?

There are probably more of these, but this is enough to get the basic idea across. The draft should not only pose such questions, but provide some considerations culled from our long experience in reviewing enumservice registrations in the ENUM WG. Future authors of enumservices, and expert reviewers of enumservices, will thank us.

Jon Peterson
NeuStar, Inc.

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

---

From: lconroy <[email-masked]>
Date: Fri, 6 Jul 2007 14:28:35 +0100

Hi Jon, folks,
  Quick point - http is a Bad example.
We already have web:http and web:https in RFC 4002.
all the best,
   Lawrence

On 5 Jul 2007, at 14:36, Peterson, Jon wrote:
> Is the proposed enumservice used to invoke a protocol (like SIP, or  
> HTTP) or a particular service or application (like voicemail, or  
> Mapquest), or neither (like "unused", perhaps)? This distinction  
> (at least between the first two) is described in 3.3, but it really  
> needs more elaboration. For example:
<snip>