[standards-jig] 5 new JEPs
cbas at screaming3d.com
Sun Jun 29 17:30:39 UTC 2003
Nice discussion, good points are being raised.
This is an important discussion. Most users come to Jabber for the
cross-network IM capability. Anything done to improve transports will
greatly add to the popularity of Jabber/XMPP.
I will comment from my perspective, a client developer.
Jacek Konieczny wrote:
>On Sun, Jun 29, 2003 at 10:08:14AM -0600, Dave Smith wrote:
>>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).
>Yes, I understand this. That's why my GG transport uses "/registered"
>resource without any parameters. I think I don't like your requirement
>mainly because it breaks my implementation - and I know this is bad :-)
>But when I change this I could break existing user rosters.
The "/registered" trick is annoying for client developers but it is
embedded in most clients and transports so changing it would break a lot
I do not immediatly see anything can be gained by changing this
behaviour so I would reccommend leaving it in the JEP. It would also
take years to update every server's transports and every client out
>>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).
>Now the disco spec and Jabber Registar don't even specify category and
>type for regular Jabber server so indentity checking using disco doesn't
>seem very serious now. But you are right Disco is the right way to do
>this and I have implemented disco in my transport (as well as I could
>with the limited number of categories/types available).
I already mentioned this to Ryan in a direct conversation but the
iq:agents and iq:browse protocols are not mentioned anywhere. Many
clients and servers still use these and I think they should be mentioned
in the document. No need to start another "disco vs browse vs agents"
war but please mention these (useful) namespaces and their (historical?)
>>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
>I am not aware of any such implementations neither, but it seems
>possible (but not very practical).
Agreed, it is unpractical. This is not what the standard registration
procedures in XMPP/Jabber were designed for. Something like this could
still be achieved in a backwards-compatible way by hosting the transport
on multiple addresses. Eg. aim1.host, aim2.host, aim3.host, etc.
>>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.
>IMHO jabber:iq:gateway is the right way to do this and should be a part
>of your JEP.
Agreed. Most clients support this. Add this to the JEP please.
>>>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)
>>Eh...I thought you were concerned with backwards compatibility?!
>With current transport implementation. I don't see a reason why future
>transports should use tricks like mapping user number to "username" and
>even stranger things, when power of jabber:x:data is available. Old
>jabber:iq:register usage should be left as backward-compatibility
>option. 100% pure XMPP implementation will not be 100% Jabber compatible
>and this doesn't mean it is bad.
In all cases I know of, the transport only needs a username and a
password. Some transports (eg. MSN) allow you to enter a nickname but
what more can you need?
Please explain what else Gadu-Gadu requires.
>>>- 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.
>Jabber client can't work without resource - this is illegal in XMPP. So
>why don't use resource in legacy user JIDs?
Not having resources for contacts on a transport is a convenient way to
disable filetransfers and other features in the client.
If a contact does not have a resource, then the client can not send an
<iq> to it.
For example my client sends a regular jabber:iq:oob for filetransfer to
Jabber contacts, and sends the file URL in a message body when the
contact does not have a resource. This way transport contacts simply
click the URL in their chatwindow and they receive the file. Works great!
More information about the Standards