[standards-jig] 5 new JEPs

Jacek Konieczny 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
  documented.

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

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

  6. Addressing

  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.

  6. Addressing

    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
they should:

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

Greets,
        Jacek











More information about the Standards mailing list