[Simple] RE: [xmppwg] RE: Action Item: character mappings for interoperabi lity

[Joe Hildebrand <[e-mail]>]

You're right, that's our disconnect.  I hadn't even considered that.

Can you give me a concrete use case where I might want
sip:[e-mail] and im:[e-mail] to point to different
entities?  I can see the messages and presences addressed to the two
following different paths, perhaps using different protocols, but I can't
imagine a non-contrived reason for them going to completely different
endpoints, or being for completely different system entities.

In other words, it might be nice for completeness, but if it adds mad
complexity, and no one will ever use it, is it worth the effort?

-- 
Joe Hildebrand

 

> -----Original Message-----
> From: Adam Roach [mailto:[e-mail]] 
> Sent: Tuesday, December 16, 2003 12:46 PM
> To: 'Joe Hildebrand'; [e-mail]; '[e-mail]'
> Subject: RE: [xmppwg] RE: Action Item: character mappings for 
> interoperabi lity
> 
> Joe:
> 
> I think the fundamental disconnect here between what I was 
> trying to say and what you are hearing is this:
> 
>  - the JID "[e-mail]" is NOT necessarily
>    the same resource as "im:[e-mail]"
> 
>  - the JID "[e-mail]" is NOT necessarily
>    the same resource as "sip:[e-mail]"
> 
>  - The resource "im:[e-mail]" is NOT
>    necessarily the same resource as "sip:[e-mail]"
> 
> So, for any solution to work, the SENDER must have the 
> ability to select a *scheme* -- otherwise, there will be 
> resources that the sender cannot contact.
> 
> /a 
> 
> > -----Original Message-----
> > From: Joe Hildebrand [mailto:[e-mail]]
> > Sent: Monday, December 15, 2003 17:33
> > To: [e-mail]; '[e-mail]'
> > Subject: [xmppwg] RE: Action Item: character mappings for 
> > interoperability
> > 
> > 
> > Hm.  I guess I need to show more of my work.  I had assumed that on 
> > the XMPP side, the system entity that does server-to-server 
> delivery 
> > would do either something like draft-daigle-napstr-03.txt, or 
> > something even simpler, like draft-ietf-impp-srv-04.txt, 
> except with 
> > the "hard" DNS stuff moved to the server.
> > 
> > 1) SRV: do you support XMPP?  If so where?  (resend using XMPP S2S)
> > 2) No?  Ok, SRV: do you support SIMPLE?  If so, where? 
> > (protocol transcode,
> > resend using SIMPLE)
> > 3) No?  Ok, SRV: do you support Wireless Villiage?  If so, where? 
> > (protocol transcode, resend using the WV S2S protocol)
> > 4) No?  Ok, maybe you're an older or less sophisticated XMPP 
> > implementation.
> > I'll look up your A record, and connect on 5269/tcp.  (resend using 
> > XMPP
> > S2S)
> > 
> > <aside>
> > NAPTR may be overkill, since in practice, we find it hard enough to 
> > get customers to install SRV records...  The DNS admins 
> make the LDAP 
> > admins look helpful. :) </aside>
> > 
> > And something similar on the SIMPLE side.  More-or-less 
> obviously, the 
> > order of the above should be a policy decision on the part of an 
> > admin.  Given that, I'm not sure that allowing a user to 
> explicitly go 
> > around the site-wide policy is a good thing.
> > 
> > Really, the only question I had was on step 2) above.  If I 
> determine 
> > that the other side would rather talk SIMPLE than XMPP, 
> what address 
> > do I put on the message?  sips: or im:?
> > 
> > --
> > Joe Hildebrand
> > 
> >  
> > 
> > > -----Original Message-----
> > > From: Ben Campbell [mailto:[e-mail]]
> > > Sent: Monday, December 15, 2003 2:52 PM
> > > To: Adam Roach
> > > Cc: 'Joe Hildebrand'; [e-mail]; '[e-mail]'
> > > Subject: Re: [Simple] RE: [xmppwg] Action Item: character 
> mappings 
> > > for interoperability
> > > 
> > > Is the context of this thread IM only, or do we also care about 
> > > presence? I am not sure the issues are always exactly the same, 
> > > since IM addresses may be delivered as part of presence.
> > > 
> > > I wonder (vaguely) if draft-daigle-napstr-03.txt is
> > applicable here. 
> > > Also, if I recall we _do_ have guidance on how to map an im: 
> > > url to a concrete service using SRV, don't we? It seems 
> to me that 
> > > if I am a SIP user, the only real hope I have of cross-protocol 
> > > interoperability is to advertise a PRES or IM URI. Other 
> systems may 
> > > be able to reach SIP URIs on an ad-hoc basis, but the abstract 
> > > schema provide a more general approach.
> > > 
> > > More inline:
> > > 
> > > Adam Roach wrote:
> > > 
> > > > I'm cross posting this to SIMPLE to help cross-pollinate
> > some ideas
> > > > here.
> > > > 
> > > > Joe Hildebrand [mailto:[e-mail]] wrote:
> > > > 
> > > > [huge snip]
> > > > 
> > > > 
> > > >>Example: josé#26;bó[e-mail] becomes 
> > > >>im:jos%c3%a9&[e-mail]
> > > >>(note for the MIME-impaired: that's jose' and bo'b)
> > > >>
> > > >>Actually, it's not clear to me from RFC 3428 whether I
> > > should map into
> > > >>sip:, sips: or im:; I could use some guidance here from
> > the SIMPLE
> > > >>folk.
> > > > 
> > > > 
> > > > Well, they're all (potentially) different namespaces. In
> > > particular,
> > > > there's nothing (other than a possible site-local policy)
> > > that would
> > > > ensure that "im:[e-mail]" would map to the
> > same user as
> > > > "sip:[e-mail]" -- so, you need to have some
> > > mechanism by
> > > > which a distinction is performed. I'll get to that in a second.
> > > > 
> > > > By contrast, "sip:[e-mail]" and 
> > > > "sips:[e-mail]" *will* always refer to the same
> > > > user:
> > > > 
> > > >    Any resource described by a SIP URI can be
> > > >    "upgraded" to a SIPS URI by just changing the 
> scheme, if it is
> > > >    desired to communicate with that resource securely.
> > > > 
> > > > So, when you get to a gateway that is going from XMPP to
> > > SIP, I would
> > > > posit that selection of "sip:" would be appropriate when
> > SASL isn't
> > > > being used on the XMPP side, and that "sips:"
> > > > would be appropriate when it is.
> > > > 
> > > > Now, for the issue I deferred: when a message arrives for a
> > > jid, how
> > > > do you know what to do with it? Let's imagine that I send
> > > an IM (from
> > > > an XMPP client) to the jid "[e-mail]". If my 
> > > > understanding is correct, this *must* end up being 
> routed to the 
> > > > server indicated by the xmpp-server SRV record for
> > > "jabber.com." So... 
> > > > does that server attempt to deliver it to an XMPP 
> account called 
> > > > "[e-mail]"? Does it gateway it to 
> > > > "im:[e-mail]"? Does it gateway it to 
> > > > "sip:[e-mail]"?
> > > > 
> > > > One answer would be "selection amongst those destinations
> > > is going to
> > > > be based on local configuration at the jabber.com XMPP
> > > server, since
> > > > it 'owns' the jabber.com namespace." And that would work,
> > > sort of, and
> > > > be consistent and simple.
> > > > 
> > > > But it's a very incomplete solution.
> > > > 
> > > > On a grander scale, we need to ask: if you are sitting 
> at an XMPP 
> > > > client as "[e-mail]", and want to send an IM to 
> > > > "sip:[e-mail]", how do you do that? Can we
> > assume that
> > > > "dynamicsoft.com" is running an XMPP to SIMPLE gateway? Can
> > > we assume
> > > > that jabber.com is? Should this be able to work if the XMPP
> > > to SIMPLE
> > > > gateway is owned by yet a third domain?
> > > > 
> > > > I think all three solutions need to be possible.
> > > > 
> > > > We've already discussed how the first would work; that's easy.
> > > > The scheme to use in translation is a matter of the
> > > destination server
> > > > configuration, potentially selected on a user-by-user basis.
> > > 
> > > I'm not sure I agree on this. As you mention above, even if 
> > > dynamicsoft.com maintains an xmpp to simple gateway, there is no 
> > > reason to expect that you can infer an identifier that 
> makes sense 
> > > to the xmpp side of the gateway from a SIP URI.
> > > If dynamicsoft maintains such a gateway, then it would make more 
> > > sense to advertise an xmpp identity in addition to the 
> SIP identity, 
> > > or perhaps an im: URI for both.
> > > 
> > > It seems to me that an xmpp device, presented with a SIP 
> URI, can do 
> > > nothing intelligent with it beyond submitting it to some xmpp-sip 
> > > gateway that it _already_ knows about, and it cannot use 
> the SIP URI 
> > > to discover that gateway.
> > > > 
> > > > The second would require some indication from your 
> client to your 
> > > > server (the host indicated by the xmpp-client SRV record for
> > > > jabber.com) that you want to break out to a SIP network.
> > > > I don't know enough about the formatting of jids to propose
> > > something
> > > > ideal, but I would think that using some sort of
> > locally-configured
> > > > prefix would provide that sort of indication (e.g. 
> > sending an IM to
> > > > "sip#x3A;[e-mail]" would indicate to your
> > > server, by the
> > > > presence of "sip#x3A;", that it should gateway to 
> > > > "sip:[e-mail]" using its SIMPLE gateway 
> functionality 
> > > > instead of finding the XMPP server for dynamicsoft.com). In
> > > this case,
> > > > the proper scheme to use is explicitly indicated by the user.
> > > > 
> > > > The third case will require using a jid that explicitly
> > > routes to the
> > > > third-party gateway; for example, 
> > > > "adam#40;[e-mail]". (Ideally, this 
> > > > ugliness would be hidden behind some sort of user interface
> > > construct
> > > > that allows users to configure their default SIMPLE
> > > gateway). For this
> > > > case, the scheme is decided by the gateway itself, and will
> > > typically
> > > > be specific to the protocol mapping provided by that
> > > gateway (i.e. a
> > > > gateway that translates to SIMPLE will always use sip: or
> > sips:, as
> > > > appropriate).
> > > > 
> > > > At least, that's my two cents on the topic.
> > > > 
> > > > /a
> > > > 
> > > > _______________________________________________
> > > > Simple mailing list
> > > > [e-mail]
> > > > https://www1.ietf.org/mailman/listinfo/simple
> > > 
> > > 
> > _______________________________________________
> > xmppwg mailing list
> > [e-mail]
> > https://jabberstudio.org/mailman/listinfo/xmppwg
> > 
> 

_______________________________________________
Simple mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/simple