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

[[e-mail]]

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

That's kind of my point.  Portability of non-E.164 is a massive topic and 
I, for one, don't want to see E2M caught up in it.
 
> | 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. 

I thought that was probably the case - thanks for clarifying.
 
> E2M+foo defines what you may ultimately look at. 

Indeed.

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

Is that actual agreement, or do you mean "right" in the sense that you 
could, but probably shouldn't? ;-)

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

OK, useful to know, but still no case (IMHO) for encumbering E2M with it 
when E2U doesn't.

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

+1, but don't complicate it with unspecified future use cases.  They'll 
likely need something completely different.

Ray