[Standards-JIG] Re: [Members] Re: MOTION: JEP-0106 (JID Escaping)

Tijl Houtbeckers 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 
>> look
>> > at
>> > the properties of a transport user it will show user at hotmail.com 
>> rather
>> > 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 40hotmail.com@msn.domain.com 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 
> would
> be represented as user at 40hotmail.com@msn.domain.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 
> 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.

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

>> The problem involves more than illegal characters in a JID (for wich JID
>> escaping could be a solution)
> Sure
>> , it's based on the fact that some of your
>> contacts are not on the jabber network but another network.
> Sure
>> Though
>> 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, 
> but
> 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 mailing list