Re: [dispatch] E2M: Proposed Charter (draft version only)

["Cartwright, Kenneth" <[e-mail]>]

a)       On Non-TN lookup keys, what you refer to as the "use of non-E.164 identifiers in next-generation-networks ... where portability is a requirement" is not on my radar screen.  So I'm not sure what you are referring to there.  What I was getting as was, for example, how would you envision looking up a calling name or a vcard using an email address, as apposed to a telephone number?  Having to have a separate protocol and a separate registry just because the lookup key takes a different form is not good.  Imo, E2M would necessitate the review of all the ENUM services that have been approved, and those currently under evaluation, such that all those services that are more appropriately under the e2m rather than e2u are moved over to e2m.  Aren't there many current and future ENUM services that are useful even for non-telephone-number lookup keys?  For example, wouldn't you want the ability to lookup a vcard or a calling name for an email like URI, just like you might want to look one up for a telephone number?
b)       On source identification, there is not yet a standardized approach to it for ENUM, but it is certainly commonly "hacked in" and done in practice using a couple different means.  As you alluded to, Drinks discussed a couple approaches that are used in practice.  And with respect to your question about the LUF, I do not think that source identification can be *disallowed* for a LUF service.  However, it is certainly true that some LUF services may not need/want to use it.
c)       On more rich response structures and query criteria, I guess there are they types of partial solutions and workarounds like those used in vcard that can be made to work for some cases.

On the whole, however, it sounds like you have your path set, and I see you have a need for urgency to get the solution in place to meet the uses case identified asap (which I can certainly sympathize with).  So as long as the distinction between E2U and E2M name spaces are clear then I guess the need that I see for a more full featured address-to-metadata-lookup-protocol is more appropriately somewhere other than the immediate E2M name space.

Ken

________________________________
From: [e-mail] [mailto:[e-mail]]
Sent: Monday, January 11, 2010 12:46 PM
To: Cartwright, Kenneth
Cc: Bernie Hoeneisen; [e-mail]; [e-mail]
Subject: RE: [dispatch] E2M: Proposed Charter (draft version only)

> I hear ya on the time frame.  Your need for something *now* for a
> specific sub-set of use cases can certainly trump a broader desire
> to cover the additional use cases that the three items in my
> previous response would cover.

Looking at those three items:

> 1) Telephone calls and the services that surround them (e.g. calling
>    name, e911, etc, etc) need to work for both TN and URI lookup key
>    use cases.  If I understand your E2M/DDDS proposal, it will only
>    be usable if a TN (turned into a domain name) is the lookup key.
>    Do I understand your proposal correctly here?  It seems that allowing
>    a lookup key to be an arbitrarily formed string (rather than a
>    domain name) is a relatively minor change, so maybe E2M can be
>    designed to support that.

I've been involved with an NICC study on use of non-E.164 identifiers in next-generation-networks, which should be published shortly - it's real hard, particularly where portability is a requirement.

If this is a goal then there should be _separate_ and very wide ranging work at IETF about peering and routing for non-E.164-based calling.  I believe Otmar has called for this before.

In any event, the three known use cases for E2M are rather E.164 specific.  Send-N and Void are certainly 100% E.164 specific.  I'm not so sure about CNAM.

> 2) The response structure of a meta-data protocol should be allowed
>    to be fairly rich and nested (e.g. XML like).  Otherwise folks will
>    find yucky hacks in order to accomplish that within a protocol that
>    does not support it.  Perhaps E2M can be designed to support this.

Yes, trivially, by mirroring E2U+vcard, and allowing indirection to "rich" data sources.

> 3) It would be very good to be able to identify and use the source of a
>    lookup when formulating the response.  So at a *minimum*, it would
>    good to make sure that the solution proposed allows for a source
>    identification scheme to be overlaid.  This seems like a feasible feature
>    that perhaps E2M could support.

Umm, why, exactly?  E2U doesn't have it, so why should E2M?  None of the three established use cases need it.

If you're thinking of DRINKS, didn't the design team ultimately conclude that the LUF (which happens to map nicely to ENUM) doesn't need this feature?

> ... snipped ...
> However, these monikers do not mean that one should not attempt to
> solve the problem.  So we've basically debating *what* sub-set of
> problems need to be solved in what time frame.
>
> So getting back to the point, perhaps an approach would be a phased
> one, where the first phase is to solve what folks determine to be
> the immediate needs, and the second phase is to build on that to
> meet a broader set of use cases.  Because I think you are right that
> E2M as proposed does definitely meet the need of some important use cases.

I think that we need to determine whether those other potential problems are in the same class as those that E2M is designed to solve.

I don't believe that they are even remotely in the same class, and would not like to see E2M being held up because of unrelated (and frankly, far larger) issues.

kind regards,

Ray

________________________________
This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.