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]