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

From: [email-masked]
Date: Wed, 20 Nov 2002 21:27:15 +0200

It was mentioned in the discussion at the impp meeting.

What I was trying to ask is if the text in presence-07 is out of date now.

Compare the two:

From presence-07:
"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"

From Jonathan on a different thread:

> 1. client looks up _pres._sip.somewhere.com in DNS
> 2. client takes the resulting records, and sends the request there. The 
> r-uri remains a pres URI.
> 3. the somewhere.com proxy server understands the pres URI, and applies 
> some local policy to translate the URI.
> 4. Its all sip from there

These are contradicting, in some cases. Do I change the scheme before I send? or do I leave the scheme as is and send?

Regards,
Hisham

> -----Original Message-----
> From: ext Sean Olson [mailto:[email-masked]]
> Sent: Wednesday, November 20, 2002 6:03 PM
> To: Khartabil Hisham (NMP/Helsinki); [email-masked]
> Subject: Re: [Simple] who changes im: pres: to sip:
> 
> 
> 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.
> 
> 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?
> 
> /sean
> 
> --- [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
>

---

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

> From: Niemi Aki (NET/Espoo) 
> Sent: Thursday, November 21, 2002 12:03 AM
> To: 'ext Sean Olson'; Khartabil Hisham (NMP/Helsinki);
> Subject: RE: [Simple] who changes im: pres: to sip:
> 
> 
> 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.

When you do an SRV query on _im._sip.bar.com, you would expect the address returned to be for an entity that understands im scheme. So leaving the scheme as im is probably better. Or are there any scenarios where that is not the case?

Regards,
Hisham

> 
> 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.
> > > 
> > > 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.
> > > 
> > > I think the above translation would solve this
> > > problem.
> > > 
> > > Thoughts?
> > > 
> > > Cheers,
> > > Aki
> > >

---

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

Looks like Ryan pressed the "Reply" button instead of "Reply to All".

> From: ext Ryan Chapman [mailto:[email-masked]]
> Sent: Thursday, November 21, 2002 12:25 AM
> To: Khartabil Hisham (NMP/Helsinki)
> Because the snippet from Jonathan below was prompted by a 
> question I raised on the issue, I thought I'd wade in to the 
> discussion...
> 
> It seems that a fairly logical approach is to use recursive 
> SRV lookups to translate the URI.  The first lookup would 
> determine the domain associated with the particular URI.  So, 
> for example, im:[email-masked] would result in a query for:
> 
> _im._sip.somewhere.com
> 
> Which would give me a new domain associated with IM/SIP at 
> somewhere.com.  Assuming the result was something like 
> "im.somewhere.com", the SIP URI that would result would be:
> 
> sip:im.somewhere.com
> 
> ...at which point I proceed with normal SIP.  If the lookup 
> failed, I would just replace "im" with "sip".
> 
> Using this approach, nothing needs to be configured save for 
> the application itself and the name server of the appropriate 
> organization.  Proxies need never concern themselves with any 
> sort of translation.
> 
> I'm not an SRV pro, so the above may not be feasible, but it 
> has the benefit of being logical and clean.  It also allows 
> one to build arbitrarily complex protocols on top of SIP 
> (e.g., xyz -> abc -> im -> sip...).
> 
> Ryan
> 
> >

---

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

Hi Hisham,

[...]
> When you do an SRV query on _im._sip.bar.com, you would 
> expect the address returned to be for an entity that 
> understands im scheme. So leaving the scheme as im is 
> probably better. Or are there any scenarios where that is not 
> the case?

Yeah, that actually defeats the whole purpose of the translation. I agree, im URI in the Request-URI will do the trick.

Cheers,
Aki