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

Well, two points about this.

First, the message operation currently has an attribute called
'destination'. We don't specify anything about the syntax of that attribute,
but we do rely on an assumption that any protocol gatewayable by CPIM
supports the concept of a 'destination'. Some protocols that we hope to
interwork through CPIM gateways support URIs as 'destinations' today. There
may be protocols that do not support URIs, or certain URI schemes, as
destinations (where your F cannot easily translate the IM URI into a
FOO-native form, especially when factoring in the 'source' as well). But
maybe we can say that the IM URI is only applicable to those protocols that
would support it. After all, when the IM URI is dereferenced into SRV
records, it would be a little silly to have an
_im._unsupported-protocol.example.com record returned - why would
example.com ever create an SRV record for IM corresponding to a protocol
that doesn't support IM URIs? But just because some protocols might not be
able to support the IM URI, I don't think this requires a fundamental
rethinking of the whole business.

Second, there are uses of the IM URI unrelated to gatewaying cases in which
the sorts of concerns you raise below don't arise. If I merely happen to
support a number of different IM clients at my domain, I might distribute an
IM URI and create the appropriate SRV records in order to let messengers
choose the protocol over which they will contact me - in this case the IM
URI just serves as a more compatible identifier than some protocol-specific
URI. While this is not directly related to the CPIM gatewaying effort, it
does provide a useful function that I think is worth documenting.

Does this seem like a reasonable direction to go with this? Instead of
essentially starting over from scratch?

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Graham Klyne [mailto:[email protected]]
> Sent: Friday, November 29, 2002 3:23 AM
> To: [email protected]
> Subject: 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]
> 
> 



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