Subject: [dispatch] E2M -- what's the delay?

From: Lawrence Conroy <[email-masked]>
Date: Sat, 23 Jan 2010 23:33:40 +0000

Hi Folks,
  I've just read through the E2M thread in the archive, and "am  
puzzled".

This is a lookup, mapping from an E.164 number, to stuff. Not from  
email, not from alphabetic SIP URIs, but from phone numbers.
This lookup is extremely likely to be done before, during, or after a  
call. In at least the former two cases, that means now -- both NOW, as  
in the IETF "get off their encounter suited butts and do something",  
and NOW, as in "I do not want to grind through some RDF meta- 
meditation before I can find out who's calling".

Had I not been through years of joy with Void/Unused, I would have  
been amazed at the data: URL being considered unacceptable. I'm all  
out of amazement now. However, suggesting that IRIS might be used for  
these near-real-time lookups is plain silly. Likewise LDAP or other  
means of lookup up vcards or other rich information. These are  
entirely different uses, with entirely different performance  
requirements. It's like saying that DNS is in competition with SOAP.

The folk proposing E2M are playing by the rules rather than just going  
off and doing it anyway. They have immediate requirements -- CNAM (as  
in "who's calling"), the NICC-driven "depends on which operator's  
asking" metadata case, and the stunningly obvious void/unused. These  
use cases are pretty narrow; few people are ever going to be  
interested, but those that are need them badly. Any use case either  
fits to the DNS model or it isn't going to be using E2M and so is out  
of scope for the proposed work.

Of course, if someone wants to go off and do an XML-based Web 2.0  
compliant solution, that's good; yellow pages is useful. It is  
however, not at all what Bernie and the chaps have been talking about.  
In what used to be IETF terms, it's not just a different "small bite",  
it's an entirely different meal. The proposed work is very focused,  
and as long as it stays that way, is eminently do-able in a reasonable  
time (before I retire, I hope). I will be happy to help knock this  
through -- it really should not be hard. I assume that E2M can use all  
of the work already done on E2U, so whilst it doesn't need to be an  
exact clone, it's pretty close.

Do I think that E2U DDDS is perfect? Nah; it's a pain in the parts.  
However, it's the least pain in the parts for a single exchange UDP  
lookup to return useful data, over a system that scales to global  
calling levels (both in volume and in frequency). E2M is very very  
similar.

So ... given that these initial use cases can be spelt out quickly,  
AND that those use cases fit to the (simple metadata, carried over DNS  
in a single query) model, AND that there are folk willing to do the  
work, why is it so hard to find a home for this?

all the best,
   Lawrence
[speaking entirely for myself]

---

From: Dean Willis <[email-masked]>
Date: Sat, 23 Jan 2010 20:32:33 -0600

> I've just read through the E2M thread in the archive, and "am  

Not as puzzled as I am.

I'm still tracking a SIP wg milestone for "E2M", which is "end to  
middle". By this we mean data inserted by a SIP UA for consumption at  
a specific intermediate proxy. The SIP working group has been working  
on it for about five years.

So what we have here is an unfortunate acronym collision. Any chance  
we can call this something else?

--
Dean

---

From: Bernie Hoeneisen <[email-masked]>
Date: Sun, 24 Jan 2010 11:33:20 +0100 (CET)

Hi Dean

On Sat, 23 Jan 2010, Dean Willis wrote:

> I'm still tracking a SIP wg milestone for "E2M", which is "end to middle". By 
> this we mean data inserted by a SIP UA for consumption at a specific 
> intermediate proxy. The SIP working group has been working on it for about 
> five years.
>
> So what we have here is an unfortunate acronym collision.

Ouuuups! Mea Culpa.
Thanks for spotting this!

> Any chance we can call this something else?

We are not yet fixed on the acronym, so it might be a good idea to change 
the acronym of the proposed new work:

How about to call the new work E2MD (E.164 to MetaData)?
Or do we just run into another conflict, e.g. with DDDS or whatever?
I hope not...otherwise, please holler now!

Have fun!

cheers,
  Bernie

---

From: Lawrence Conroy <[email-masked]>
Date: Mon, 25 Jan 2010 11:06:33 +0000

Hi Bernie, Dean, folks,
   I think E2D would be better (E.164 to Data, with aspirate meta :).
That matches the 3 character DAIs (Ddds Application Identifiers) we have
for 2916/3761/3761bis, and 3263.
 From painful exposure to the "million monkey march" approach to coding,
I no longer assume that a 4 character token won't tickle a bug  
somewhere.

Seriously, Dispatch (or its archive) does look a lot like Sipping^2, so
it IS odd having a proposal for a DDDS application here. [Hence my plea
to find it a home soon :].

all the best,
   Lawrence

On 24 Jan 2010, at 10:33, Bernie Hoeneisen wrote:
>> middle". By this we mean data inserted by a SIP UA for consumption  
>> at a specific intermediate proxy. The SIP working group has been  
>> working on it for about five years.
>>
> We are not yet fixed on the acronym, so it might be a good idea to  
> change the acronym of the proposed new work:
>

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Mon, 25 Jan 2010 11:20:14 -0500

Hello,
Just to restate and clarify...

0) I have no idea why this work has not found a home.  Perhaps the ENUM WG should be re-chartered and re-awakened.  I'm not well schooled in the administrative practices of IETF and really have no place commenting on that subject, and did not attempt to do so.
1) I understand the immediate need for this solution.  And if it happens, there is a good likelihood that I/we can or will use it, as it meets part of an immediate need.  And if it does move forward the I/we will certainly read and review the drafts and provide feedback with that intent in mind.  And may even subsequently propose additional services that fit under an E2M namespace.  So please do not misconstrue my comments as suggesting a vote that this work should not move forward.  That being said, however, I think you cannot deny that there is a bigger picture here.  So....
2) Not sure why it would be puzzling that DDDS and DNS is not the only viable and good solution to the need to quickly look up information in real time.  That seems self evident to me.
3) Pointing out a meaningful short-coming or two of ENUM and DDDS and how it is used and proposed to be used should also not be puzzling.
4) Again, using an ENUMish standard to get data that is specific to TNs (e.g. to turn a TN into an AOR, to help interpret and traverse a TN number plan, etc) obviously makes perfect sense.  That is of course what ENUM was built for.  But to use an ENUMish solution to feed up other important data elements that have nothing to do with the fact that the lookup key is a TN (or a domain name), such as calling name information, is unfortunate.  Calling Name information, for example, of course exists for addresses that are not TNs.  So why would one propose a calling name lookup protocol that only allows lookup keys to be TNs (that are turned into domain names)?

But again, as you state, these are longer term and broader concerns.  And what is being proposed is immediate term and focused.  I get that.  However, that fact does not make some broader points "puzzling".

Thanks.
Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lawrence Conroy
Sent: Saturday, January 23, 2010 6:34 PM
To: [email-masked]
Subject: [dispatch] E2M -- what's the delay?

Hi Folks,

all the best,
   Lawrence

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

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.

---

From: [email-masked]
Date: Mon, 25 Jan 2010 16:31:17 +0000

> 4) Again, using an ENUMish standard to get data that is specific to 
> TNs (e.g. to turn a TN into an AOR, to help interpret and traverse a
> TN number plan, etc) obviously makes perfect sense.  That is of 
> course what ENUM was built for.  But to use an ENUMish solution to 
> feed up other important data elements that have nothing to do with 
> the fact that the lookup key is a TN (or a domain name), such as 
> calling name information, is unfortunate.  Calling Name information,
> for example, of course exists for addresses that are not TNs.  So 
> why would one propose a calling name lookup protocol that only 
> allows lookup keys to be TNs (that are turned into domain names)?

Ken,

Did my previous e-mail (and Richard's followup) not explain clearly enough 
how all three existing use cases for E2M are _specifically_ related to 
TNs?

kind regards,

Ray

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Mon, 25 Jan 2010 12:19:25 -0500

Hi Ray,

Calling Name was mentioned (which of course is not special to TNs).  But if that was mentioned just *tangentially*, then yes, you've explained how all of your envisioned use cases are specific to TNs as lookup keys.  And given that all of your envisioned use cases are apparently specific to TNs, the argument for an ENUMish solution is of course a strong one.

Thanks.
Ken

________________________________
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, January 25, 2010 11:31 AM
To: Cartwright, Kenneth
Cc: [email-masked]
Subject: Re: [dispatch] E2M -- what's the delay?

Ken,

Did my previous e-mail (and Richard's followup) not explain clearly enough how all three existing use cases for E2M are _specifically_ related to TNs?

kind regards,

Ray

________________________________

---

From: [email-masked]
Date: Mon, 25 Jan 2010 17:36:56 +0000

> Hi Ray,
> 
> Calling Name was mentioned (which of course is not special to TNs). 
> But if that was mentioned just *tangentially*, then yes, you’ve 
> explained how all of your envisioned use cases are specific to TNs 
> as lookup keys.  And given that all of your envisioned use cases are
> apparently specific to TNs, the argument for an ENUMish solution is 
> of course a strong one.

Richard clarified the "CNAM" use case, where in response to my uncertainty 
about whether it was E.164 specific he said:

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

For those not familiar with "void" and "send-n", they both relate to the 
structure and hierarchy of the E.164 numbering plan.

kind regards,

Ray

---

From: Lawrence Conroy <[email-masked]>
Date: Mon, 25 Jan 2010 22:26:31 +0000

Hi Folks,
  Me too.
(CNAM, ANI, CLIP, Caller Display) are all directly related to  
telephone numbers.
IMHO, so are other denizens like Calling Party Number, Called Party  
Number, Connected Party Number (and name), ...

They are not related to display names of SIP AORs, or display parts of  
Email addresses, or ...

That reminds me that I have not recently thanked God that we
no longer have COMPUSERVE email addresses, which I hereby do.
However, even these were not telephone numbers.

all the best,
   Lawrence

On 25 Jan 2010, at 17:19, Cartwright, Kenneth wrote:
> But if that was mentioned just *tangentially*, then yes, you've  
> Did my previous e-mail (and Richard's followup) not explain clearly  
> enough how all three existing use cases for E2M are _specifically_  
> related to TNs?
>
> kind regards,
>
> Ray
>
> are not the intended recipient, please contact the sender by reply e- 
> mail and destroy all copies of the original message.
>