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

From: Adam Roach <[email-masked]>
Date: Tue, 16 Dec 2003 13:46:06 -0600

Joe:

I think the fundamental disconnect here between
what I was trying to say and what you are hearing
is this:

 - the JID "[email-masked]" is NOT necessarily
   the same resource as "im:[email-masked]"

 - the JID "[email-masked]" is NOT necessarily
   the same resource as "sip:[email-masked]"

 - The resource "im:[email-masked]" is NOT
   necessarily the same resource as "sip:[email-masked]"

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:[email-masked]]
> Sent: Monday, December 15, 2003 17:33
> To: [email-masked]; [email-masked]'
> 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:[email-masked]] 
> > Sent: Monday, December 15, 2003 2:52 PM
> > To: Adam Roach
> > Cc: 'Joe Hildebrand'; [email-masked]; [email-masked]'
> > 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:[email-masked]] wrote:
> > > 
> > > [huge snip]
> > > 
> > > 
> > >>Example: josé#26;[email-masked] becomes 
> > >>im:[email-masked]
> > >>(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:[email-masked]" would map to the 
> same user as 
> > > "sip:[email-masked]" -- so, you need to have some 
> > mechanism by 
> > > which a distinction is performed. I'll get to that in a second.
> > > 
> > > By contrast, "sip:[email-masked]" and 
> > > "sips:[email-masked]" *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 "[email-masked]". 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 
> > > "[email-masked]"? Does it gateway it to 
> > > "im:[email-masked]"? Does it gateway it to 
> > > "sip:[email-masked]"?
> > > 
> > > 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 "[email-masked]", and want to send an IM to 
> > > "sip:[email-masked]", 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;[email-masked]" would indicate to your 
> > server, by the 
> > > presence of "sip#x3A;", that it should gateway to 
> > > "sip:[email-masked]" 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;[email-masked]". (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
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/simple
> > 
> > 
> _______________________________________________
> xmppwg mailing list
> [email-masked]
> https://jabberstudio.org/mailman/listinfo/xmppwg
> 

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

---

From: Adam Roach <[email-masked]>
Date: Tue, 16 Dec 2003 13:46:06 -0600

Joe:

/a

---

From: Joe Hildebrand <[email-masked]>
Date: Tue, 16 Dec 2003 13:49:11 -0700

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:[email-masked] and im:[email-masked] 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

> From: Adam Roach [mailto:[email-masked]] 
> Sent: Tuesday, December 16, 2003 12:46 PM
> To: 'Joe Hildebrand'; [email-masked]; [email-masked]'
> 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:
> 
> > 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.
> > 
> > 3) No?  Ok, SRV: do you support Wireless Villiage?  If so, where? 
> > (protocol transcode, resend using the WV S2S protocol)
> > 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>
> > 
> 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.
> > 
> determine 
> > that the other side would rather talk SIMPLE than XMPP, 
> what address 
> > do I put on the message?  sips: or im:?
> > 
> > --
> > Joe Hildebrand
> > 
> >  
> > 
> > > 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.
> > > 
> > > 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:
> > > 
> > > 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, 
> > > 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.
> > > >

---

From: Adam Roach <[email-masked]>
Date: Wed, 17 Dec 2003 11:20:12 -0600

Joe Hildebrand [mailto:[email-masked]] wrote:

> sip:[email-masked] and im:[email-masked] 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.

Paul did a fairly good job of explaining how this sort
of thing happens. I just wanted to make two additional
points.

To give a concrete example that may make more sense to you,
the statements that I made are essentially the same as
saying:

  - the JID "[email-masked]" is NOT necessarily
    the same resource as "mailto:[email-masked]"

I note that you *tend* to make a distinction between 
the JID "[email-masked]" and the URI
"mailto:[email-masked]" when you write JEPs
(cf. JEP-0115).

The second point I wanted to make is:

> enough to get customers to install SRV records...  The
> DNS admins make the LDAP admins look helpful. :)
> </aside>

The people administering the IM systems are typically
going to be the same -- or at least, the same kind of --
people who administer the DNS. If you can't get them to
do something as obviously necessary as installing DNS
records to find the IM systems themselves, how on earth
do you expect to compel them to do something that is less
obviously necessary, like keeping user IDs aligned across
all of their systems?

/a

---

From: Adam Roach <[email-masked]>
Date: Wed, 17 Dec 2003 11:20:12 -0600

/a

---

From: Joe Hildebrand <[email-masked]>
Date: Wed, 17 Dec 2003 12:20:33 -0700

Do you feel the same way about im: as sip:?

-- 
Joe Hildebrand

> Sent: Wednesday, December 17, 2003 12:03 PM
> To: Joe Hildebrand
> Cc: [email-masked]'; [email-masked]'
> Subject: Re: [Simple] RE: [xmppwg] RE: Action Item: character 
> mappings for interoperabi lity
> 
> Joe Hildebrand wrote:
> 
> > sip:[email-masked] and im:[email-masked] 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.
> > 
> Let me take another angle at this. JIDs and and the "sip:" 
> scheme designate  two different name spaces, even if they are 
> resolved at the same domain. One domain _might_ choose to 
> synchronize them. But another domain might have two 
> completely distinct user sets between the two namespaces. 
> There is no requirement the two services be related in any 
> way. For example, an ISP might have some SIP users and some 
> XMPP users, where the sets are not identical. Furthermore, 
> the same user part could exist in both sets, but refer to 
> different people.
> 
> For example, HypotheticalISP.com might let its users sign up 
> for an xmpp service and/or a simple service. Furthermore, it 
> might let those users choose their user id for that service 
> on a first come first serve basis. 
> So, I might sign up for the jid of 
> [email-masked]. I later sign up for simple, 
> and find out some other person with the same name already has 
> "sip:[email-masked]" So, instead, I get 
> "sip:[email-masked]"
> 
> I don't think the standards can assume that services are synchronized.
> 
> 
>

---

From: [email-masked]
Date: Thu, 18 Dec 2003 10:54:38 +0200

Although I agree with Adam and others, I would like to point out that people usually try to make guesses about other people's sip addresses using their email addresses. So, if my email is [email-masked], people using SIP would assume that my sip address is the same [email-masked]. People using XMPP would assume that my JID looks the same, and so on.

Therefore I think it is in the service providers' interest that they don't allow different people to have the same URI but with different scheme. I see some security and confidentiality concenrs here. Some one might wronly assume that I have a JID that looks the same as my sip address and end up sending someone else a message that says "Nokia is planning on ...".

So, having said that, is it really worth spending the time on trying to get this working when it will not be used?

Regards,
Hisham

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Ben Campbell
> Sent: 17.December.2003 21:03
> To: Joe Hildebrand
> Subject: Re: [Simple] RE: [xmppwg] RE: Action Item: character mappings
> for interoperabi lity
> 
> 
> Joe Hildebrand wrote:
> 
> Let me take another angle at this. JIDs and and the "sip:" scheme 
> designate  two different name spaces, even if they are 
> resolved at the 
> same domain. One domain _might_ choose to synchronize them. 
> But another 
> domain might have two completely distinct user sets between the two 
> namespaces. There is no requirement the two services be 
> related in any 
> XMPP users, 
> where the sets are not identical. Furthermore, the same user 
> part could 
> exist in both sets, but refer to different people.
> 
> for an xmpp 
> service and/or a simple service. Furthermore, it might let 
> those users 
> choose their user id for that service on a first come first 
> serve basis. 
> [email-masked]. I 
> later sign up for simple, and find out some other person with 
> the same 
> name already has "sip:[email-masked]" So, 
> instead, I 
> get "sip:[email-masked]"
>