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]