Pavel Simerda wrote:
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.
We use hashes in XEP-0084 (User Avatar): http://www.xmpp.org/extensions/xep-0084.html So it might make sense to use them here as well.
You can use hash-based UUIDs.
Where are those specified? I see a bit of information about that in RFC4122 but not a lot of details.
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.
Well we don't want to discourage sending in such a venue.
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.
I don't think the per-JID caching rule means that the recipient needs to check the domain of the sender against the domain in the CID. But maybe I don't quite understand the concern.
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.
Or if people define emoticon bundles then the images could be identified by the domain of the entity that hosts the bundle, perhaps an open-source project or whatever.
/psa
smime.p7s
Description: S/MIME Cryptographic Signature
