[standards-jig] 5 new JEPs

Jacek Konieczny jajcus at bnet.pl
Sun Jun 29 16:26:58 UTC 2003


On Sun, Jun 29, 2003 at 10:08:14AM -0600, Dave Smith wrote:
> 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.

But the introduction in your JEP suggested something else "noone haver
documented how transports work so this document will". That was may
point. Add there information about the old specs and that this will be
slightly incompatible and it will be OK.

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

That point didn't sound like "it is permissible to fake the
subscription".

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

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

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

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

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

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

Greets,
        Jacek



More information about the Standards mailing list