[standards-jig] 5 new JEPs

Dave Smith dizzyd at jabber.org
Sun Jun 29 16:08:14 UTC 2003

Hash: SHA1

On Sunday, Jun 29, 2003, at 04:11 America/Denver, Jacek Konieczny wrote:

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

Jacek, I did a little digging this morning and found the document you 
are referring too:


(I must confess, the URI gave me a good laugh).

The intent of JEP-100 is to provide a specification that transport 
authors can write to, thus ensuring a standard transport "experience" 
for all client devs. As it stands right now, every transport behaves 
slightly differently  -- most don't even comply with the document you 
used as a baseline. If we want to provide solid, reliable transports 
one of the first tasks we must take on is to ensure that the interfaces 
to them are consistent. Will this break existing transports? Yes. 
However, we're not trying to complete redo the way transports work, 
just get them to be consistent.

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

This could be clearer. That was the intent. :)

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

The point of making this required was to ensure that foreign contacts 
look as much like a Jabber contact as possible, in terms of protocol 
interaction. It's completely permissible for the transport/gateway to 
"fake" the subscription to ensure the semantics are right. Again, the 
point is to ensure consistency -- we want a transport to behave as much 
like another Jabber server as possible.

>   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 "old" specification was broken in this regard of requiring the 
"/registered" resource. It recommended that you store your username and 
password in the resource of the subscription -- this practice was 
abandoned long ago by most transport writers due to security issues. 
(Historical note: the reason the old spec recommended that methodology 
was due to the fact that transports at that time did not have access to 
storage services such as XDB).

It is possible to distinguish the transport as a transport by disco-ing 
an items in your roster that do not have a username -- this implies 
that they are a service of some type (see JEP-100, Section 7, Item 2).

Insofar as supporting multiple registration per gateway, I'm not aware 
of any current gateways that do this...or if so, any current clients 
that can support this? Perhaps the gateway and client authors can 
enlighten us?

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

I tend to agree with your point here.

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

We probably want to look into integrating the "old" jabber:iq:gateway 
protocol into this at some level. The whole section on determining 
remote addresses and ensuring they are "node-preppable" needs some work.

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

Eh...I thought you were concerned with backwards compatibility?! We 
want to fix the "warts" on current transports, in terms of protocol 
consistency -- but a change of this magnitude would break A LOT of 

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

This is the point of the JEP -- to specify exactly what a transport 
must do in order to behave as much like a Jabber entity as possible.

I disagree that gateways must use resources in legacy user JIDs -- even 
some Jabber clients don't do that.

Thanks for your comments, Jacek.

Version: GnuPG v1.2.1 (Darwin)


More information about the Standards mailing list