[standards-jig] 5 new JEPs
jajcus at bnet.pl
Mon Jun 30 10:04:04 UTC 2003
On Sun, Jun 29, 2003 at 07:30:39PM +0200, Sebastiaan Deckers wrote:
> >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.
For registration with existing account on GaduGadu network GG number and
password is enough. But in client supporting jabber:x:data user of my
transport may set many more things using the registration form:
- set preferred language for interaction with transport (English is
default, but most GaduGadu users will prefer Polish)
- request user list import from GaduGadu server
- setup initial "invisible" and/or "friends only" mode
After user is registered to transport jabber:iq:register + jabber:x:data
form is used for:
- changing options set while registering
- changing user info in GaduGadu public directory
Everything is done in clear interface, without tricks like adding new
fields to jabber:iq:register (illegal, but some clients support this and
it was the only way to pass some data to the public dirrectory) or
overriding fileds with totaly different meaning.
I still have to keep old jabber:iq:register form because of clients
which still don't have jabber:x:data implemented (which have been FINAL for a
long time now). But this functionality is very limited, and I will
probably drop it one day.
> >>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.
Disco is the right way to do check features. Such workarounds may be
used if disco fails.
> If a contact does not have a resource, then the client can not send an
> <iq> to it.
But some <iq/> may be processed by the transport without problems (eg.
> 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!
But the transport may have the jabber:iq:oob implemented. And having the
resource or not is not the way which should be used to test for this or
any other feature.
Pure XMPP implementation may not work well with users without resources
and this is OK - no XMPP user session may exist without resource.
Gateways should not behave differently, unless we assume it is a special
case which should be supported specialy or not at all.
More information about the Standards