[Standards-JIG] UPDATED: JEP-0118 (User Tune)

Chris Mullins cmullins at winfessor.com
Thu Oct 28 02:10:42 UTC 2004


Julian Wrote:
 
> > The nodes (and attributes) not being there, versus the node being
> > there, with a value of "false", or "zero", has been problematic. It
> > complicates server code, SDK code, and client code.

[... ]
 
> > This is not something I would continue to encourage in
> > the protocol.  It's way too error prone.

> I don't know about your Jabber libraries, but I know building a client
> with the ones I've used, saying something like
> if (length)
> {
>   _lbl_length->set_text(length->get_text());
>   _lbl_length->show();
> }

Many client libraries get it wrong. I've send notes to several client developers saying "your client is sending empty 'from' stanza's on all IQ packets". This is so pervasive in the client world, that we had to put a configuration option into our server for "allow empty 'from' attributes". This has been across several clients, on several platforms, in several languages. 

The logical steps on both the client side and the server side are more complex due to the varying behavior of tags. 

You need to check:

1 - If the Tag / Attribute is present and not empty, follow rule #805.a

2 - if the Tag / Attribute is present and empty, follow rule #805.b

3 - if the Tag / Attribute is not present, follow rule #805.c

This obviously isn't rocket science, but a great number of clients get it wrong. A few servers do too. 

On the outbound side, client libraries need to be aware enough to activly strip out empty "from" tags from IQ stanzas. This means once the user is done manipulating the stanza they're about to send, that it need to be fully parsed for contextual rules before being sent out. This isn't rocket science either, but, again, based on the number of "broken" clients that have been pointed at our server, it's not being done. 

-- 

Chris Mullins



More information about the Standards mailing list