Re: Is cpim-srv document necessary at all? (Re: NAPTR and CPIM)

Tony, I actually think we agree but are talking past each other. More 
inline.

Tony Hansen wrote:
> [email protected] wrote:
>  > Why should it be? I could have an im address that looks like:
>  >     im:[email protected]
>  > that may translate to many forms. eg:
>  >     sip:[email protected]
>  > or
>  >     xmpp:[email protected].
>  > These things are local policy at the target domain. Common sense says
>  > that all should be the same, but this "should" is only to make life
>  > easier for users, but not a technical requirement.
> 
> Let's look at this from the email model. Someone has a URI such as
> 
>     mailto:[email protected]
> 
> Software package ABC that wants to contact [email protected] looks up the 
> MX record for example.com and finds that it needs to contact 
> host1.example.com and send the message to [email protected] there. There 
> is no translation of "foo" at all involved.
> 
> I THOUGHT the agreed upon scenario for SRV was comparable to this, with 
> the added feature that you also discover the protocol to use. Someone 
> has a URI such as
> 
>     im:[email protected]
> 
> After the lookup via SRV, we find that they need to use protocol XYZ and 
> contact host1.example.com. So they do so, and pass in as the name 
> XYZ:[email protected].

I agree with you up until the last sentence. What happens is that the 
look up in SRV, find that they need to use XYZ, and contact 
host1.example.com. Then, using the protocol XYZ, they send a request to 
host1.example.com, and the recipient is im:[email protected]. That is, 
using protocol XYZ does NOT imply translating the uri to an XYZ URI.

This introduces the requirement that any CPIM compliant protocol be 
capable of carrying the IM URI within it. I mentioned this several times 
during the meeting.

As an example, SIP can do that in this way:

---
MESSAGE im:[email protected] SIP/2.0
From: im:[email protected]
To: im:[email protected]
Content-Type: text/plain

Hey there!!
---

Note that the IM URI is carried within the SIP message. It has not been 
translated to a SIP URI.

> 
> (Note that one difference between the mail scenario and the SRV scenario 
> was that I did change the domain name in the username that is passed to 
> protocol XYZ. But not the username. More on this below.)
> 
> Now back to email. SOME mail sites have a mail gateway sitting at 
> host1.example.com such that the message is accepted, but username 
> aliasing is done and the message gets forwarded on to 
> [email protected]. This is purely a gateway function, 
> and this aliasing is done totally unbenownst to software package ABC.

Agree! That is my point! What you are talking about is URI translation. 
I am agreeing with you that this can only be done by the "gateway", and 
not by the client.

> Similarly, I feel that username aliasing, while a fine idea, has no 
> business being a part of the im: SRV lookup.

Agree.

> 
> One niggling difference between the SRV and MX scenarios was the change 
> in the SRV scenario from [email protected] to [email protected], which 
> does not exist in the MX scenario. (In MX, you *contact* 
> host1.example.com, but still pass in the username [email protected].) Some 
> people seem to want us to guarantee that protocol XYZ would never see 
> the im: URI name [email protected]. 

No, I think that is a bad idea. I do not believe it is a good idea to 
change the URI as a result of the SRV lookup.


I'm wondering if the shoe should be
> put on the other foot, and perhaps we need to mandate that all IM 
> protocols that want to play in the im: URI-space >>must<< be able to 
> handle im: URIs, such that protocol XYZ >>would<< accept [email protected] 
> in addition to XYZ:[email protected].

Yes! This is what I pointed out repeatedly during the meeting.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email protected]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com




  [reminder: [email protected] for non-technical discussions, please]