Subject: RE: [Simple] who changes im: pres: to sip:

From: [email-masked]
Date: Thu, 21 Nov 2002 00:02:37 +0200

Hi,

> To take your analogy for tel: URIs to completion,
> wouldn't we want to represent the entire im: URI in
> the user portion of the sip: URI and tack on a
> "user=im" parameter?

I'm not sure we'd have to follow the tel URI conventions all the way. The im and SIP URI schemes seem to be pretty similar anyway. And unlike tel, the im URI can't include any URI parameters (I think...) However, if we did follow the tel URI way, we'd run into the problem you describe below. 

> This seems like an interesting approach but I'm
> concerned that the user=im parameter would *have*
> to be interpreted by the proxies to do the right
> thing. In that case, we would be better off with
> sticking with an im: URI in the Request-URI. 

I think having the im URI in the Request-URI is even worse. It would mean that all the proxies in the path of this request would have to support the im URI scheme to be able to route the message at all. With the user-parameter, at least these intermediary proxies would still be able to route the request normally to the owner domain.

The owner proxy of the Request-URI would then have to interpret the user-parameter to do the right thing, at least if the tel URI conventions were applied as they are right now.

However, my preference would be to specify the translation such that the right thing could be done even when ignoring the user-parameter. This would require a translation which doesn't include the escaped im URI in the user part of the SIP URI.

Cheers,
Aki 

> --- [email-masked] wrote:
> > Hi,
> > 
> > inline.
> > 
> > > It sounds like the text you reference answers 
> > > the question. Do it as soon as possible, 
> > > preferably before you send the request. Different
> > > environments and clients may do this at different
> > > times depending on your view of "as soon as
> > possible".
> > > I think (1) is the right answer, though that might
> > > be identical to (2) is some rare cases.
> > 
> > Well, I would argue that the translation can *never*
> > happen before the request is sent. We can't mandate
> > a direct translation from an IM URI to a SIP URI,
> > and any other translation would be local policy to
> > the GW.
> > 
> > So the Request-URI would always need to have the
> > original im: URI in it. This of course causes
> > problems for proxies that don't recognize the im URI
> > scheme.
> > 
> > My proposal is that the client uses a translation
> > similar to when translating tel URIs. Namely, the im
> > URI is translated into a SIP URI by simply replacing
> > the scheme. Additionally, the URI parameter 'user'
> > is populated with the original scheme which in this
> > case is 'im'.
> > 
> > If I need to contact 'im:[email-masked]', I resolve the
> > next hop using SRV, and in the request line have the
> > following: 
> > 
> > 	MESSAGE sip:[email-masked];user=im SIP/2.0
> > 
> > This will enable both cases (1 and 2 below) since a
> > GW can fall back to the direct translation by
> > ignoring the user param. If the local policy
> > dictates some other translation, the user parameter
> > gives enough information to also do that at the GW.
> > 
> > > The SRV resolution that was discussion in IMPP
> > > solves the next hop problem. It did not directly
> > > address translation of an im: *URI* to a sip:
> > *URI*.
> > > Shouldn't this be left to local
> > policy/implementation?
> > 
> > I think the above translation would solve this
> > problem.
> > 
> > Thoughts?
> > 
> > Cheers,
> > Aki
> > 
> > > --- [email-masked] wrote:
> > > > Hi,
> > > > 
> > > > Most of us heard the discussion at impp wg
> > meeting
> > > > about schemes, but there was no consensus on who
> > > > changes the scheme.
> > > > 
> > > > There are 2 suggestions:
> > > > 
> > > > 1. change it to sip as soon as possible, as
> > > > instructed by presence-07
> > > > 2. Leave it to the terminating domain. I.e. the
> > > > domain responsible.
> > > > 
> > > > Which one of the above should we do? If we
> > choose 2,
> > > > should presence I-D be changed to reflect that?
> > > > 
> > > > I'm referring to the text:
> > > > 
> > > > "When subscribing to a presentity, the
> > subscription
> > > > can be addressed
> > > >    using the protocol independent form or the
> > SIP or
> > > > SIPS URI form. In
> > > >    the SIP context, "addressed" refers to the
> > > > Request-URI. It is
> > > >    RECOMMENDED that if the entity sending a
> > > > SUBSCRIBE is capable of
> > > >    resolving the protocol independent form to
> > the
> > > > SIP form, this
> > > >    resolution is done before sending the
> > request"
> > > > 
> > > > Regards,
> > > > Hisham
> > > > _______________________________________________
> > > > simple mailing list
> > > > [email-masked]
> > > >
> > >
> >
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > 
> > > 
> > > __________________________________________________
> > > Do you Yahoo!?
> > > Yahoo! Web Hosting - Let the expert host your site
> > > http://webhosting.yahoo.com
> > > _______________________________________________
> > > simple mailing list
> > > [email-masked]
> > >
> >
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > 
> 
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Web Hosting - Let the expert host your site
> http://webhosting.yahoo.com
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 21 Nov 2002 02:49:18 -0500

inline.

[email-masked] wrote:
 > Hi,
 >
 >
 >> To take your analogy for tel: URIs to completion, wouldn't we want
 >> to represent the entire im: URI in the user portion of the sip: URI
 >> and tack on a "user=im" parameter?
 >
 >
 > I'm not sure we'd have to follow the tel URI conventions all the way.
 > The im and SIP URI schemes seem to be pretty similar anyway. And
 > unlike tel, the im URI can't include any URI parameters (I think...)
 > However, if we did follow the tel URI way, we'd run into the problem
 > you describe below.

Careful!!!

There is a HUGE difference between the im and tel URIs. Thats the 
presence of the domain part. The domain part says something terribly 
important. It says that the user part has an interpretation that can 
ONLY be done by an entity in that domain. Nothing outside of that domain 
can use it. A tel URI doesn't have that property. THe "user part" is 
well defiend everywhere.

Translating a URI cannot be done if you cannot understand the resource 
that URI points to. In the case of the IM URI, only the server in that 
domain can understand, and thus, translate it. Not so for tel URI.

As an example, a valid translation is:

im:[email-masked] -> sip:[email-masked]

only dynamicsoft.com can do that.

 >
 >
 >> This seems like an interesting approach but I'm concerned that the
 >> user=im parameter would *have* to be interpreted by the proxies to
 >> do the right thing. In that case, we would be better off with
 > I think having the im URI in the Request-URI is even worse. It would
 > mean that all the proxies in the path of this request would have to
 > support the im URI scheme to be able to route the message at all.
 > With the user-parameter, at least these intermediary proxies would
 > still be able to route the request normally to the owner domain.

Not so. Remember that you are looking up the IM URI in DNS, and sending 
it there. Thus, the domain which needs to interpret it is the one on the 
RHS of the IM URI. Since its the one that created that URI in the first 
place, it clearly means it can understand and process it.

Now, there is this issue of the outbound proxy you raise in another 
note, which I'll respond to there. Not an easy issue.

THe net/net, however, is that the text in the presence spec as written 
is probably wrong, and needs to be updated to reflect the current 
thinking on the pres URI.

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