[Standards-JIG] Re: [Members] Re: MOTION: JEP-0106 (JID Escaping)
richard at dobson-i.net
Wed Mar 31 08:49:23 UTC 2004
> > You dont seem to have read what I said properly, I didnt say that it
> > would
> > be represented as user at firstname.lastname@example.org in the interface
> > decoded, you would decode it as user at hotmail.com from the JID of
> > user%40hotmail.com at msn.domain.com, and only display user at hotmail.com as
> > the
> > ID (and maybe a helpful bit of text saying that it is on the
> > msn.domain.com
> > transport).
> How do you suggest clients detect in a generic way that they have to show
> it like this, and add this helpfull message? It's not much different from
> replacing %/@, and still nothing like the type of behaviour the user would
> expect from, for example, MSN.
Well you need to think about it more, when a client queries their server for
the list of services it provides (disco / browse / agents) it will detect
the available transports and if one of the transports is say msn.domain.com
and it can detect that it is an msn transport the client then knows that any
contacts with a domain of msn.domain.com are msn transport contacts, it can
then do the transport JID decoding and put in the helpful stuff I decribed
above, so see it can work in an easy and generic way.
> > They will once it is decoded as I describe above, all you need is an
> > extension to the jabber:x:roster to support sending non JID transport
> > contacts i.e. user at hotmail.com.
> The same is true for replacing %/@ or using iq:gateway.
I didnt say it wasnt, when did I?!?!?!?
> >> It also doesn't solve that
> >> we still don't have a good mechanism in use to represent the MSN
> >> to the user the way (s)he is used to it, the nickname chosen by that
> >> user.
> > I already solved that above ;)
> I'm not sure what you've suggested, but I'm just pointing out JID escaping
> won't solve that either.
Ah I see what you mean now, that can be easily solved too, you just disco
the MSN contacts when they come online to get their current name and then
update your roster if the name is different. Also longer term as this is a
general problem with Jabber in that you have no way of notifying your
contacts that you have changed your nickname we might want to develop a
pubsub mechanism to let people subscribe to your nickname and receive
immediate updates when you change it.
> My only point is you shouldn't rely on the form of the address of the JID
> in any case, whether it simply replaces @/%, uses iq:gateway or does JID
> escaping, to gather information to the user. You correctly point out the
> problem that some users (especially the ones that has been using legacy
> client before) expects more than just a JID when dealing with a contact on
> that network. So no matter how fancy the scheme for translating that JID,
> that won't solve your problem.
> Either 3 methods have their own advantages and disadvantages as already
> discussed (including load on the network and compatability with excisting
> solutions/problems), and all three could be used perfectly well in solving
> the problem I described above (and they can all be used in a
> jabber:x:roster extention too).
It certainly solves part of the problem that I outlined in an earlier email
in that it allows you to display in your client interface the native ID from
the legacy network, rather than the confusing transport JID, and also allows
you to have that ID to then resend to other people with the extension to
jabber:x:roster which stops all the problems you described with the user
having to be using the same transport.
> But it's pointless to argue about which
> scheme best translates (part of) the JID to something meaningfull, since
> that will never solve that problem.
What do you mean by this, as what I have described perfectly solves the
particular problem we are trying to solve, I dont understand why you think
More information about the Standards