[Standards-JIG] Re: [Members] Re: MOTION: JEP-0106 (JID Escaping)
thoutbeckers at splendo.com
Tue Mar 30 16:14:05 UTC 2004
On Tue, 30 Mar 2004 16:21:10 +0100, Richard Dobson <richard at dobson-i.net>
>> > using a standard escaping mechanism
>> > allows you do decode the addresses in a reliable way so when users
>> > at
>> > the properties of a transport user it will show user at hotmail.com
>> > than
>> > a rather complicated and confusing user%40hotmail.com at msn.domain.com,
>> > talking with novice users who I get to take a look at Jabber this is
>> > definately a point of confusion that using escaping can eliminate.
>> Why would the user have to look at the JID to find this out?
>> user at firstname.lastname@example.org is still almost (if not more) as
>> confusing as user%40hotmail.com at msn.domain.com for a novice user.
> You dont seem to have read what I said properly, I didnt say that it
> be represented as user at email@example.com in the interface once
> 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
> ID (and maybe a helpful bit of text saying that it is on the
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.
>> And the
>> user still won't be able to send an MSN contact to another jabber user,
>> unless that user uses the same MSN transport.
> 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.
>> It also doesn't solve that
>> we still don't have a good mechanism in use to represent the MSN contact
>> to the user the way (s)he is used to it, the nickname chosen by that
> 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.
>> The problem involves more than illegal characters in a JID (for wich JID
>> escaping could be a solution)
>> , it's based on the fact that some of your
>> contacts are not on the jabber network but another network.
>> jabber:iq:gateway doesn't solve much more than JID escaping, at least it
>> starts of on the right foot by recognizing that fact.
> Well JID escaping allows you to decode and encode the transport address,
> jabber:iq:gateway only allows encoding transport JID's it doesnt support
> decoding (according to the only docs that I could find), so JID escaping
> does offer far more than bog standard jabber:iq:gateway and also has the
> benefit of no delays/latence or unnecessary bandwidth use as there is no
> need to use any wire protocol.
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). 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.
More information about the Standards