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

I think that at least some of our historical confusions about this matter
come down to whether a gateway interworks between protocols or between
services (or both).

I suspect that the original conception of the IM URI may have been concerned
with service interworking. For example, consider a case in which there is a
monolithic operator of an IM service (say, aol.com). In order to interwork
with aol.com using SIMPLE, you must find the SIMPLE gateway associated with
AOL's service. In this case, a gateway operated by aol.com is likely to be
the only way to reach the service. An IM URI of the form 'im:<screen
name>@aol.com' would therefore be used to reach AOL's service. In this
respect, the SRV record for, say, SIMPLE at _im._sip.aol.com would behave
much like an MX record (perhaps this inspired some of the comments to that
effect during the Atlanta meeting). This also maps roughly to Thanos'
scenario 3 below.

However, I think gatewaying between services doesn't solve all of the
problems we're interested in here in IMPP. The fact is that (for example)
SIMPLE is not a monolithic service, it's a protocol that might be used by
any number of independent domains in the Internet. The IM URI would
therefore have a different meaning in this context - that doesn't mean it's
useless, merely different. Nor is this meant to say that we should tailor
the SRV draft to preclude the service gatewaying case - service gatewaying
is potentially valuable, but it's not the only value proposition with IM
URIs. 

To my mind, the use of SRV that we do need to document in the draft is a bit
higher level than the categories below; we need to document the use of SRV
records by a domain to indicate protocols that can be used to reach the
domain for IM and presence (which may or may not entail gateway location).
That covers both the service gatewaying case and the protocol gatewaying
case. The draft should be silent about the translation of these URI schemes
to any schemes native to various target protocols. There is no obvious
technical difference in how the interpreter of an SRV record behaves in
regard to these two cases. 

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Thanos Diacakis [mailto:[email protected]]
> Sent: Monday, November 25, 2002 5:24 PM
> To: Jonathan Rosenberg
> Cc: Pekka Pessi; [email protected]; [email protected];
> [email protected]
> Subject: Re: Is cpim-srv document necessary at all? (Re: 
> NAPTR and CPIM)
> 
> 
> Understood, thanks!  Just to restate briefly:
> 
> The flaw in the argument is that receiver's protocols cannot 
> be used to
> locate the receiver as only the receiver can translate the 
> im: / pres: URI
> in its own schema, something that is required before one can use the
> receiver's schema.
> 
> I now see the clarification we need to add (maybe in the form of some
> scenarios in or around Section 3), to get the SRV resolution 
> in context:
> 
> Four things need to be done for two CPP/CPIM compiant systems to
> interoperate, when they do not speak the same protocol.  (It 
> is assumed that
> the originating system has a client request containing an im: 
> or pres: URI
> or has translated the URI within a client request to the im: 
> or pres: URI.)
> 
> (a)  locate destination of originating request (in original protocol)
> (b) translate request to receiver's native protocol
> (c)  locate destination of translated request (in receiver's 
> protocol) and
>     send request
> (d) translate im: / pres: to receiver's native URI (always 
> done at receiver)
> 
> There are four general scenarios (mapped to the above 4 steps):
> 
> Scenario 1 (Originator translates)
>   (a) skipped
>   (b) Originator translates protocol
>   (c) Originator uses SRV to locate destination of translated 
> request and
>     send request
>   (d) Receiver translates URI schema
> 
> Scenario 2 (Originator's intermediary translates)
>   (a) Intermediary located using originator's protocol or manual
>     configuration
>   (b) Intermediary translates
>   (c) Intermediary uses SRV to locate destination of 
> translated request and
>     send request
>   (d) Receiver translates URI schema
> 
> Scenario 3 (Receiver's intermediary translates)
>   (a) Intermediary located using SRV
>   (b) Intermediary translates
>   (c) Intermediary located receiver using manually or 
> otherwise configured
>     data and send request
>   (d) Receiver translates URI schema
> 
> Scenario 4 (Receiver translates)
>   (a) Receiver located using SRV
>   (b) Receiver translates protocol
>   (c) skipped
>   (d) Receiver translates URI schema
> 
> Thanos
> ---
> Thanos Diacakis
> Openwave Systems
> [email protected]
> +1-303 385 6705
> 
> 
> ----- Original Message -----
> From: "Jonathan Rosenberg" <[email protected]>
> To: "Thanos Diacakis" <[email protected]>
> Cc: "Pekka Pessi" <[email protected]>; <[email protected]>;
> <[email protected]>; <[email protected]>
> Sent: Monday, November 25, 2002 4:34 PM
> Subject: Re: Is cpim-srv document necessary at all? (Re: 
> NAPTR and CPIM)
> 
> 
> > inline.
> >
> > Thanos Diacakis wrote:
> > > We've been looking at the wrong problem - at least 
> according to the SRV
> doc:
> > >
> > >
> > >>  This document provides guidance for locating the 
> resources associated
> > >
> > >  >  with URIs that employ these schemes. [im: and pres:]
> > >
> > > It appears that SRV is indeed not required, as Pekka 
> described, we can
> use
> > > the individual protocol's mechanism to locate the remote 
> resource that
> > > "speaks" it.
> >
> > I disagree, for the same reasons I disagreed during the meeting.
> >
> > SIP talks about how to resolve a SIP URI. SIP doesn't know anything
> > about IM URIs. So, in order to use SIP (or any other 
> protocol - xmpp,
> > apex, etc.) to resolve an IM URI, you need to convert that 
> URI into a
> > URI in the native protocol.
> >
> > Such translation can only be done by an entity that is 
> authoritative for
> > that domain. Thats because there are lots of ways to do the 
> translation,
> > and its policy specific. For example, it should be possible to have:
> >
> > im:[email protected] -> 
> sip:[email protected]
> >
> > only a dynamicsoft.com server can do this.
> >
> > So, we need to get a request from the client, to the dynamicsoft.com
> > domain, containing that IM URI, so it can translate it. Thus, the
> > problem becomes this: how to find the FQDN of a server 
> which speaks SIP
> > that can receive an IM URI. That is the purpose of the SRV draft.
> >
> > The alternative is for the domain to place NAPTR records 
> which tell the
> > client how to do the translation. I think this is way too 
> complicated,
> > and in any case, cannot represent the range of possible translations
> > (regexp only goes so far...).
> >
> >
> > >
> > > Thinking about it more carefully, we really have three 
> distinct problems
> > > that we were attempting to solve and SRV would only have 
> solved one or
> two
> > > of them (the 3rd one, and in a not so very nice way, the 1st one):
> > >
> > > 1. Figure out which protocols the other/remote domain supports
> > > 2. Locate a resource that can translate from what the local domain
> supports
> > > to something that the remote domain supports (assuming 
> they don't speak
> the
> > > same thing).
> > > 3. Locate the resource of the remote domain that the 
> translating gateway
> > > would need to talk to
> > >
> > > We've sort of been focusing on 3, but in the wrong way, 
> as this can be
> done
> > > by the actual destination protocol's mechanims.
> >
> > To me, its simpler than that.
> >
> > I've got an IM URI. I got it one of many ways. Maybe I'm a 
> PC client and
> > someone clicked on this URI in a web page. Maybe I'm a 
> gateway, and I
> > received a request in PRIM containing this URI. In either 
> case, the next
> > step is the same: locate a server which is authoritative for that
> > domain, which can process a request containing this URI. 
> Part of that is
> > to determine which protocols to use to talk to that domain.
> >
> > >
> > > We don't really have a mechanism to do 1 (unless we go 
> the NAPRT way -
> as I
> > > understand it or we exhaustively perform 3 on all known 
> protocols) and
> we
> > > really have no mechanism to do 2.  The latter can of 
> course be solved by
> > > manually configuring a particular domain with one or more 
> gateways that
> will
> > > do the translation and the opinions are so far divided on that.
> >
> > We determine which protocol is supported by searching 
> through the ones
> > supported by the client. In practice I doubt this will be 
> so  bad, as I
> > pointed out during the meeting.
> >
> > > Also, there seems to be an implicit requirement that 
> perhaps we should
> make
> > > explicit: CPP/CPIM compliant protocols need to be able to 
> handle im: and
> > > pres: URIs by either passing them through, or translating 
> them to their
> own
> > > and/or gatewayed schemes.
> >
> > Yes. But, its not implicit. I stated this several times during the
> > meeting, and its even documented in the minutes. Agree it 
> needs to be
> > explicit in the specification. That was the main output of 
> the meeting -
> > for Jon to document this.
> >
> >
> > >
> > > *****
> > > Going forward, I think we need to answer two questions:
> > >
> > > a) Do we need to have an automated mechanism to locate a 
> resource that
> will
> > > perform protocol translation?
> > > b) Can we get away with figuring out what protocol a remote domain
> "speaks"
> > > by serially trying each of the protocols that the 
> originating domain
> and/or
> > > translating gateway speak?  (this would be done by using 
> the native
> protocol
> > > mechanisms, not the CPP/CPIM SRV)
> > > *****
> > >
> > > Note, that if the answer to (b) is yes, there is no way 
> of finding a
> gateway
> > > based on the remote domain's capabilities, as those are 
> not known until
> the
> > > "serial" interrogation by the gateway is complete).  So 
> the process
> would
> > > look like this (instead of the 1, 2, 3 above):
> > >
> > > (i) Locate a gateway resource that can translate from 
> what the local
> domain
> > > supports to any/all other protocols
> > > (ii) Send our request to that gateway
> > > (iii) Have the gateway try (serially) locating the remote 
> domain using
> the
> > > native mechanims for each of the protocols it supports
> > > (iv) If one works then use it, else fail or repeat with a 
> different
> gateway.
> > >
> > > How interesting...
> >
> > I always thought that discovery of third party gateways was out of
> > scope; use SLP or something. DNS is hardly ideal for such discovery
> > mechanisms.
> >
> > The issue was how to find the servers (which may or may not 
> be gateways
> > - thats invisible to the client) for a specific domain and 
> protocol. The
> > client knows which ones it can do. The DNS tells which ones 
> the server
> > can do.
> >
> > -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]