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

Tony,

No one is proposing an username change based on SRV lookup, the proposal actually says that the uri should remain unchanged until it arrives at its home domain. Liasing, as you mention, is done there.

Regards,
Hisham

> -----Original Message-----
> From: ext Tony Hansen [mailto:[email protected]]
> Sent: Friday, November 29, 2002 5:49 PM
> Cc: [email protected]
> Subject: Re: Is cpim-srv document necessary at all? (Re: 
> NAPTR and CPIM)
> 
> 
> [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].
> 
> (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.
> 
> Is this a feature of the MX lookup performed for the original mailto 
> URI? No, not at all.
> 
> Similarly, I feel that username aliasing, while a fine idea, has no 
> business being a part of the im: SRV lookup.
> 
> Is this a feature that many people would want? Sure. And it 
> can be done 
> using aliasing services at the XYZ protocol interface.
> 
> 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]. 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].
> 
> 	Tony Hansen
> 	[email protected]
> 
> 
> 
> 
>   [reminder: [email protected] for non-technical 
> discussions, please]
> 
> 
> 



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