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

Can you please elaborate on the differences between protocol and service
gatewaying?  I think we may be in agreement using different words.

Thanos
---
Thanos Diacakis
Openwave Systems
[email protected]
+1-303 385 6705

----- Original Message -----
From: "Peterson, Jon" <[email protected]>
To: "'Thanos Diacakis'" <[email protected]>; "Jonathan Rosenberg"
<[email protected]>
Cc: <[email protected]>
Sent: Wednesday, November 27, 2002 12:13 AM
Subject: 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]