[standards-jig] 5 new JEPs
jajcus at bnet.pl
Sun Jun 29 10:11:53 UTC 2003
On Wed, Jun 25, 2003 at 12:07:07PM -0500, Peter Saint-Andre wrote:
> Sorry, catching up on a backlog of JEPs here:
> 0100 -- Gateway Interaction
I am particulary interested in this JEP as I am a gateway author.
I must say I don't like it much.
Surprisingly, the recommended behavior of such gateways, including the protocol
elements used by a client to interact with a gateway, has never been
It was documented. I have "transport-1.0.html" file, which I found some
time ago somewhere on www.jabber.org site. I was implementing my GG
trasport according to recommendations from this file. And JEP-100 is in
conflict this those recommendations. I guess most implementation based
on this document will be incompatible with JEP-100 and I see no reason
4.3 Log In
4.3.1 Primary Flow
4. Gateway passes through all subsequent presence stanzas except those of type "probe" and
those address to Gateway itself.
What does "those address to Gateway itself"? Presence directed to the
gateway? IMHO it should be passed to legacy system, as it is the
presence for the legacy system.
5. Legacy User Use Cases
5.1 Add Contact
5.1.1 Primary Flow
This whole point should be marked as optional, because many legacy IM
system doesn't provide subscription request to contact for
The address of a gateway itself SHOULD be a hostname only, and that hostname SHOULD NOT be
supplemented with a resource identifier when referring to the gateway's address (e.g., when storing
the gateway in a roster).
This conflicts with the old specification ("transport-1.0.html") which said that "/registered"
resource must be used. This was good, as allowed to distinguish transport for other domain-only
entities and allowed multiple registration to one gateway. The only problem was poor support
for roster items containing resources in some clients (I think Psi had such problem).
The hostname SHOULD be a subdomain of a primary Jabber host (e.g.,
icq.jabber.org might be the ICQ gateway run by the jabber.org server).
This should not be a requirement (even SHOULD). Gateway may work on its
own without any jabber server. Some day legacy IM providers may build
their own gateways, without own Jabber server.
2. Any spaces in the legacy address MUST be escaped within Jabber
identifiers by the appropriate UTF-8 equivalent of a space character.
What does this mean? UTF-8 equivalent of space (0x20 ASCII) character
is space character (0x20). UTF-8 is just an encoding not a character
set. It is only used if stream is encoded UTF-8, but it may be UTF-16.
So a character may be replaced by Unicode character (which will probably
be represented as UTF-8 sequence on the wire), not UTF-8 character.
There are also some things, that are not mentioned by the JEP, but IMHO
- old jabber:iq:register is often not apopriate for legacy IM systems
and using of jabber:x:data should be recommended. IMHO the old
jabber:iq:register should be made optional (it makes more problems
than it is worth)
- gateway should behave like regular Jabber server and gateway user
should behave like regular Jabber users. Of course as much as it is
possible. Pure XMPP client, which knows nothing about gateways should
be able to communicate via gateway without any problems (of course
user must be registered to the gateway first). I would recommend
gateways to use resources in legacy users' jids even if the legacy
system doesn't provide multiple logons.
More information about the Standards