On Thu, 14 Aug 2008 10:38:42 -0600 Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
> 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. Yep, they would be good to incorporate in ConentID. Btw, the hash would be enough itself (without CID) but we want to use CID URIs. > > 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. They are only hash-based and they are (hopefully) unique to a particular sequence of bytes. They don't serve the same purpose as e.g. sha1 mostly because the full sha1 hash doesn't fit in UUID. > > >> 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. It's some sort of privacy problem... but in the "do not leak anything at all". It's better not to send original domain names if they have no real meaning to new recipients (when forwarding or reusing data). > > > 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 This would break the hash function use case. We want same data (including type) to have same ContentID uri for global sharing (most probably with a constant domain part). -- Web: http://www.pavlix.net/ Jabber & Mail: pavlix(at)pavlix.net OpenID: pavlix.net
