[Standards] Re: [jdev] XEP-0115: Entity Capabilities

Rachel Blackman rcb at ceruleanstudios.com
Wed Jun 27 03:58:52 CDT 2007


On Jun 27, 2007, at 1:42 AM, Sergei Golovan wrote:

>> But the high cost is primarily -- indeed, I would say almost /
>> exclusively/ -- when someone logs on and probes their entire roster.
>> Or when someone logs in for the first time in a day or so, and all
>> their contacts probe them; usually the cache will be gone for at
>> least some of the contacts by then, as many people restart their
>> clients (and thus lose the cache) every few days due to a Windows
>> reboot or wanting to play a game and not be bothered, or whatever.
>
> When I think about caching I think about long-term caching (on-disk,
> not in-memory, memory caches are even more dangerous for me as someone
> may simply send me new presence every few seconds and eventually
> overfull the memory (or there should be some sort of cache expiration,
> which leads to extra network load)).

Forcing the cache to be on-disk won't work well for mobile or  
embedded clients, however.  And what about the flash-based web  
clients people have done?  Those usually just read the roster from  
the server, and all other data is transient.  Are they required now  
to keep these caches on the webserver's storage space, or are they  
exempt and allowed to start with an empty cache every time you reload  
the Flash application?

If so, doesn't that open the route to other entity-probing attacks,  
such as someone changing their client/version information over and  
over very quickly to try and force the on-disk cache to fill up?  To  
me, that seems a potential flaw; cache contamination goes away, but  
an attack to try and fill up disk could cause more trouble, as an  
example.  There are solutions, but the problems should be examined  
and addressed.

Similarly with the MD5 thing, it doesn't allow well for clients that  
support plugins adding new capabilities; you now have to change the  
MD5 for the entire client when you add new namespaces to the disco.   
Under the current entity caps, you just add a new token to 'ext.'   
Sure, the MD5 thing could be changed to support separate plugin MD5s  
as well; that's fine, but it needs to be specced out.

These are points which could be hashed out and addressed if someone  
interested in the protocols were to write up a reference  
implementation and a prototype version of a XEP.

>> Your proposal addresses neither of those.
>
> If the cache is long-term than it does.

Not simply; disk storage isn't a magic bullet for the problem.  See  
above.

>> First option, in your implementation you can just individually probe
>> each of your contacts (or, even, just disco and cache based on jid
>> and client/version, as you suggested) and suffer the potential
>> network-karma penalty if a user logs in and has 200 contacts online
>> to probe.  Just keep in mind that many people still consider putting
>> avatar hash data into presence to be too much potential network spam,
>> so you may face some opposition from mobile client users who pay for
>> their bandwidth by the megabyte.  (I.e., the same argument about high
>> cost that led to entity caps in the first place.)
>
> The contacts could be probed by disco requests on demand, and not on
> every login (though this approach will lead to undesirable lags in
> user interface).

Some clients try this.  It does, as you say, lead to lags in user  
interface.

Though there are ways around that.  In Astra, I actually probe folks  
who don't have caps only when you either open a message window to  
them, or mouse-over the contact; by the time you click to get the  
context menu, or actually hit enter to send a message, I've usually  
been able to probe the capabilities in the background.  It's not  
perfect, but it works when I cannot get caps data.

I notice you still don't address point two of my suggestions, which  
was 'write up your idea as a XEP.'

You have an idea for an on-disk permanent capabilities cache per-jid,  
as an alternative to caps.  You should write a XEP.  Jacek can write  
a XEP for the MD5-caps idea.  They can both be put forward, the  
reference implementations compared, and people can decide which one  
to go with.

Not having a XEP means nothing happens.  It's the issue we have right  
now with file transfers; we have a XEP specifying stream-initiation  
which works for file transfer, but we do NOT have any XEP specifying  
the Jingle-based file transfer that Google Talk uses.  Thus, no one  
can even assess (much less interoperate with) the Google Talk method;  
we're stymied on that, and so everyone stays with stream-initiation  
for now.

If you want a new protocol, write a XEP and a reference  
implementation.  I'm not, really, arguing the points of either  
suggested implementation... just that it's less productive to wave  
around one-paragraph definitions of ideas, instead of turning them  
into useful XEPs.

Anyway, I'm going to sleep. :)

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




More information about the Standards mailing list