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

At 10:06 PM 11/27/02 -0500, Tony Hansen wrote:
>below
>
>Jonathan Rosenberg wrote:
>>...
>>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.

*AND* also be able to recover the IM URI from the native protocol -- either 
by supporting a round-trip mapping, or my preserving the original URI 
within the native protocol.  Without this, you won't be able to satisfy the 
CPIM gateway interface requirements.

Example:

   FOO client ... ----FOO---> gateway ----BAR---> ... BAR client
       F                         G                        B

FOO and BAR are any two CPIM-compliant protocols.

F clearly needs to translate the IM URI to a FOO-native form.  This is 
comparable with (say) IP-to-ethernet address resolution in the lower 
layer.  The gateway G needs the original IM URI to find the BAR-native 
form, so it can forward to B using BAR.

Dave Crocker said something in the Atlanta meeting about CPIM having 
developed to be a service overlay rather than just a gateway specification 
(did I get the words right?).  I didn't understand that at the time, but I 
now see that the required ability to use an IM URI to address any 
CPIM-compliant instant message sent using any protocol does force a level 
of service uniformity that goes beyond gatewaying capabilities.  (As does 
the common format for end-to-end security.)

Thus we need a global framework for mapping IM URIs both outbound from a 
domain (for protocol gateway selection) and inbound (similar to MX 
routing).  (In the email (MX) model, we can go direct to the target domain 
using a single Internet-wide protocol.)  I think these are issues that need 
to be clear before discussing SRV vs NAPTR, or something else.

#g


-------------------
Graham Klyne
<[email protected]>




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