[Standards] Entity Capabilities Woes

[Rachel Blackman]

>> Well as my illustrious co-author said, the intent was that ext is  
>> stable
>> across application versions. If we make that a MUST in the spec  
>> then we
>> can save more packets. Seems like a good idea to me.
>
> I can sense this causing a headache further down the track.  Some  
> client will
> put in an "ft" feature for file transfer on version 1.0, and then  
> in version
> 2.0 they will add Jingle support.  Clients who happen to query  
> version 2.0
> first will cache that "ft" means Jingle FT, and then interesting  
> things will
> happen when they encounter a version 1.0 client.
>
> It seems like it would be easier for everyone (except disk space,  
> which is
> cheap anyway) if it were assumed that ext is completely free of  
> semantics.

Why?  If ext is defined with specific semantics, why is it better to  
assume people will implement it wrongly than to try and educate them  
to implement it correctly?

In your example, they should define a new 'jft' (Jingle File  
Transfer, or whatever) and have that as an ext.  Then, 'http:// 
example.com/xmpp/caps#ft' represents the old file transfer, 'http:// 
example.com/xmpp/caps#jft' represents the new file transfer.  In  
version 1.0 when they have just the old file transfer, they have 'ft'  
in the ext.  In version 2.0 when they support both, they have 'ft  
jft' in ext.  In version 3.0, when old file transfer has been  
deprecated, they have just 'jft' in ext.

Everything works smoothly, everything is cached properly, and  
everything just works.

We should not be writing/designing XEPs on the assumption that people  
will implement them wrong.  We should, I agree, be writing XEPs /more  
clearly/ so that people don't implement them wrong, but we shouldn't  
be designing with the assumption that they will do it in a broken  
manner.

If they DO actually implement it in a broken manner, it is a bug in  
the client and should be logged as such.


-- 
Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillianastra.com/