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

> -----Original Message-----
> From: ext Peterson, Jon [mailto:[email protected]]
> Sent: Monday, December 02, 2002 2:17 PM
> To: 'Graham Klyne'; [email protected]
> Subject: 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.

I agree. A service provider might support 2 protocols, eg. sip and xmpp. I might be a sip user, but decide to change to xmpp. By me distributing my im: address, I don't need to redistribute my new address.

/Hisham


> 
> 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]
> 
> 
> 



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