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

Julian Missig julian at jabber.org
Thu Oct 28 02:23:13 UTC 2004


On 27 Oct 2004, at 22:10, Chris Mullins wrote:

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


Nice little diatribe, and I certainly agree with you that the whole 
empty from thing is an issue, but that can't be solved by saying 
<length> should always be present, even when it no longer makes logical 
or semantic sense--if you require <length> you're not going to all of a 
sudden change all of the rest of Jabber and XMPP and XML. The entire 
nature of XML allows for optional elements, and I think that's a very 
good thing.

I agree that empty 'from' attributes are a bad thing and clients 
shouldn't be doing things like that. But to me that says we need some 
way to apply more pressure on client authors to get their stuff right.

You're basically arguing about a protocol decision throughout all of 
XMPP and Jabber--allowing optional attributes/elements rather than 
using some sort of NULL value ("0") to mean something else. That's 
certainly a valid argument to make, but it's not what was decided at 
the XMPP level, and thus is not what should be guiding minor decisions 
of minor Jabber extensions like this.

I'm not really going to say much more on this issue, because you and I 
can obviously go back and forth quite a bit for a while.

<length>0</length> means that the length of a song is zero. Not having 
a <length/> element at all means the length is unknown or not 
specified. Requiring a <length>0</length> addition just because you 
hate client authors for including from='' is just silly.

Julian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2102 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20041027/d7fc8390/attachment.bin>


More information about the Standards mailing list