[standards-jig] 5 new JEPs
dizzyd at jabber.org
Sun Jun 29 16:08:14 UTC 2003
-----BEGIN PGP SIGNED MESSAGE-----
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
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
> 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
> 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
> 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
> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (Darwin)
-----END PGP SIGNATURE-----
More information about the Standards