Hello, I have a few questions regarding BoB which came up in our Jabbim client development room. I have read throught the mails regarding it in this list (more or less thoroughtfully, so please excuse me if I missed something), but haven't followed the chat sessions Pavel and Peter had.
I'm sorry that the email didn't stay as brief as I planned ;-) I quote this mail here: http://mail.jabber.org/pipermail/standards/2008-July/019390.html 30 of July 2008 03:49:01 Peter Saint-Andre wrote: >Pavel Simerda wrote: >> I further propose we add some informational section about generation >> of CIDs. Although it's specified elsewhere, I believe this XEP will be >> very useful and will be referenced from many future XEPs (and maybe >> improved as well - possibly some server caching etc). I think the >> informational section could suggest UUIDs generated by hashing the >> actual content. >Yes I think that would be helpful. Since developers of Jabbim would like to use BoB for emoticons exchange (possibly in a way similar to the one used by Pidgin developers, might be neat to spec it out sometime), I'd like to ask whether it would be possible to reconsider using hashes instead the UUID for identification. The use case is as follows: - There are/will be some databases full of emoticons, which people can download and use - When user sends an xhtml-im message containg <img> referencing a particular cId and the receiving entity doesn't have the image, it asks for it. - Advantage of using hash in this case would be that the same image would have the same identification, always and ever. Using unique random identifiers instead of hashes would complicate distribution of the same image through different channels and/or through chain of different users. - I'm not a crypto-geek, so I don't know about the poisoning possibility, but I believe that when we need to hash something like caps to increase security, we should hash binary data too ;-). Also, we have concerns about the domain part being sender's domain. Is it necessary only to satisfy some specifiactions needs (rfc2111?) or does it have some functionality? At first glance I thought the domain would be checked against stanza's from, but that would disallow sending emoticons into MUC rooms. One of the developers (Lolek) who, as I understood, showed interest in ressurecting emoticons XEP also thought that making someone's domain distributing across network (by resending the image to different users) doesn't seem right (although domain isn's anything secret after all). If the domain part is to be replaced in every hop I think this should be made more clear in the spec. (in case the domain part isn't removed completely from the spec) >> cache="unlimited" >> - we suggest the client picks the longest time it allows (it could >> possibly cache some small pieces of data permanenty) >Perhaps a commonly-used emoticon? Regarding caching, I agree with both of you that caching should be allowed for unlimited time (for emoticons in particular) and it seems this isn't in the current spec. Although rfc2965 defines Max-Age to be non-negative integer, I guess -1 for unlimited might be useful. Secondly, caching per-JID seems to be breaking the principle of the emoticon distribution use case and I think that forementioned per-hash caching would remove the need to do that. (as long as applications check the hash) Thanks for your time and sorry if I ask for something answered before. Zenon Kuder jr. -- Stop Skype Plague XMPP Jabber ID: [EMAIL PROTECTED]
