[jdev] An old pseudo standard, but is it still good?

[Michal 'vorner' Vaner]

Hello,
On Wed, Nov 15, 2006 at 09:05:42AM +0100, Carlo v. Loesch wrote:
> On the technical issue of user%host at msn.transport i must say I really
> dislike how Jabber cannot deal with a clean transparent notation
> like msn:user at host. These kludgy jid-deformations are both ugly and
> hard to understand for the end user. Why should she put the hostname
> into the user field and a fake hostname into the hostname field,
> when adding an MSN buddy to her roster? Also icq:12345 would be much
> nicer than the kludge that transports provide. Additionally, you
> leave it to the server to route to the transport. Why should you have
> a lot of new friendships just because you switched to a different
> transport (= the one you had broke down or you no longer trust his
> privacy promises).
> 
> I strongly support the idea of abandoning the user at host requirement
> for jids and let jids be opaque strings to be interpreted by the
> receiving entity.

That would change the idea of XMPP completely, which isn't a nice idea
IMHO. However, you could have reserved JIDs on a server like
icq:123456789 at jabber.org (which could be alias and the server could cope
with that correctly and nothing would change for the server) and
removing the server part would mean "On the same server". That is
however a problem, since it would collide with addressing server only.

Maybe something like 123456789 at icq would be acceptable as well and the
server could have alias that icq means icq.jabber.org or so. And it
would make sense as well, since it would read 123456789 at ICQ.

Anyway, how would you handle the JIds as any string, using some
heuristics?

Have a nice day

-- 
There's the light at the end of the the Windows.

   -- Havlik Denis

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://www.jabber.org/jdev/attachments/20061115/a729306e/attachment-0002.pgp>