[standards-jig] 5 new JEPs

Sebastiaan Deckers cbas at screaming3d.com
Sun Jun 29 17:30:39 UTC 2003


Hi,

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 
of stuff.
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 
there. :-(

>>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?) 
importance.

>>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?
>>    
>>
>
>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
>>>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?! 
>>    
>>
>
>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.
>>    
>>
>
>Great. 
>
>  
>
>>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!


Kind regards,
Sebastiaan




More information about the Standards mailing list