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

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.

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.

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.

Note that the gateways can be positioned in many places: the originating
domain, the terminating domain, or anywhere in the middle.  The same
problems as described above would exist in any of those situations.

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.

*****
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...

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

----- Original Message -----
From: "Pekka Pessi" <[email protected]>
To: <[email protected]>
Cc: "Jonathan Rosenberg" <[email protected]>;
<[email protected]>; <[email protected]>
Sent: Tuesday, November 19, 2002 1:09 AM
Subject: Is cpim-srv document necessary at all? (Re: NAPTR and CPIM)


> Hello all,
>
> Based on today's discussion in IMPP I now have came to the
> conclusion that the SRV lookup does no good (slow thinker, that
> I am).
>
> If a client can send the IM using the protocol that they have
> picked, they send the IM using it. Otherwise, they use a
> preconfigured gateway. In any case, they don't need a
> CPIM-specific DNS lookup but they will use the protocol-specific
> (SIMPLE, XMPP, Jabber, AIM, WV, what ever) method to resolve IM
> URIs.
>
> This has problems, however:
>
>      1) When we know that the destination domain does not support our
> protocol of choice? Is it enough that there is no NAPTR/SRV
> records (or whatever) for our protocol, or should we try to
> resolve an AAAA record and send IM to the address there? What if
> the destination domain supports only legacy IP, should we
> resolve also A record and try send IM there, too? Who should try
> to do send IM to AAAA/A? Client? Gateway? Both? Do they try each
> IM protocol that they know?
>
> This problem applies to the current SRV-solution, too. A client
> or gateway simply cannot lookup SRV record for *all* possible
> CPIM protocols
>
> (I should mention here that if NAPTR was used, you could get a
> list of all IM protocols supported by a domain. If the DNS
> server was up-to-date, the response message to the initial NAPTR
> lookup would also contain SRV records *and* corresponding AAAA/A
> records of the preferred IM service.)
>
>      2) The destination domain supports our protocol of choice, but
> how we know if it supports IM URLs using that protocol? For
> example, the destination domain uses SIP for telephony but
> Jabber for IM.
>
> I really don't know if this is a usual or even reasonable
> scenario, but in any case, I think this is a problem specific to
> the protocol, not a problem for CPIM.
>
>
> So, I propose that CPIM just settles on a solution for problem
> #1, and leaves the problem #2 to be solved by the protocols in
> question.
>
> Of course, this would be bad news for CPIM editor Jon Peterson
> (no more srv document? what I'm going to do with all this free
> time) but good news for SIMPLE chair Jon Peterson (kewl, yet
> another document to charter).
>
> Pekka
>
>
>
>   [reminder: [email protected] for non-technical discussions, please]
>
>













  [reminder: [email protected] for non-technical discussions, please]