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

I didn't mean to imply that those are the only scenarios.  However, I think
*some* scenarios are useful to put the SRV resolution in context, in line
with the other clarifications we discussed last week.

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: Tuesday, November 26, 2002 3:27 PM
Subject: Re: Is cpim-srv document necessary at all? (Re: NAPTR and CPIM)


>
>
> Thanos Diacakis wrote:
> > 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.
>
> Right.
>
> >
> > 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
> >
>
> I am sure there are many other architectures that can be used here. I
> would prefer that the srv spec merely document the piece we need to
> standardize - the means by which a client takes an IM/PRES URI and
> figures out where to send it.
>
> -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]