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

["Richard Shockey" <[e-mail]>]

In line..

 

From: [e-mail] [mailto:[e-mail]] On Behalf
Of [e-mail]
Sent: Monday, January 11, 2010 12:46 PM
To: Cartwright, Kenneth
Cc: [e-mail]; Bernie Hoeneisen; [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. 

 

Don't hold your breath on that one. 


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. 

It actually is and in fact it is the major market driver for using the E2M
ENUM LUF. 



> 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. 

 

E2M+foo defines what you may ultimately look at. 


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

 

Right ..



> 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? 

Not necessarily .. for the peering function the LUF might return a different
URI based on the source. 


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. 

 

IMHO put the E2M structure in place and let people see what they want to use
if for. Any one of these preliminary use cases justifies the Development of
E2M. 

 



kind regards, 

Ray