On Thu, 14 Aug 2008 13:26:00 +0200 "Zenon Kuder jr." <[EMAIL PROTECTED]> wrote:
> 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. You can use hash-based UUIDs. > 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. You may use non-random UUIDs if this is the concern. > - 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). This could be solved by renaming the image when reusing it in the reciever's client. > 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) Yep, it should be. I'm afraid we can't just leave it out (CIDs are defined by a RFC, not this XEP). > > >> 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. Possibly. Or "maxint" which is compatible with the current spec. > 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) Yes, it's breaking this use case in favor of simplicity. We were not sure whether the global-sharing feature is wanted by the developer community and it can be added in a backwards-compatible matter. What I suggest to satisfy the Jabbim developers (and possibly others with similar needs) the following two modifications: 1) Only force UUID if we use the domain part of the JID and forbid re-using these names. 2) Add one additional form of CID: "hash-value"@"hash-function".xep0231.xmpp.org. (the concrete syntax serves as an example, not final syntax) The hash functions would be "sha1", "sha256" and possibly other ones too and the computed hash value would be based on both *content type* and *content data* (needs more precise spec.). This would also be an exception from forced "per JID" caching. > Thanks for your time and sorry if I ask for something answered before. > Zenon Kuder jr. You're most welcome! Pavel -- Web: http://www.pavlix.net/ Jabber & Mail: pavlix(at)pavlix.net OpenID: pavlix.net
