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]