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

[[e-mail]]

> 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