On Fri, 15 Aug 2008 20:15:35 -0600 Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
> Zenon Kuder jr. wrote: > > Dne Friday 15 of August 2008 23:45:44 Peter Saint-Andre napsal(a): > >> Pavel Simerda wrote: > >>> Btw, what I didn't know before... I have looked into the CID/MID > >>> rfc and there's nothing about requiring the at-sign. It's only > >>> written in the common practice sections but there they use. And > >>> they do use local hstnames, not shared strings. > >>> > >>> But then "xmpp.sha1.da39aee5e6b4b0d3255bfef95601890afd807099" (or > >>> similar syntax) is just as conforming as any other syntax. > >>> > >>> The interesting point of the RFC is that the CIDs must be globally > >>> unique but it apparently leaves it for the implementors to be > >>> clever enough not to have the same idea. > >>> > >>> It depends if you want to break common practice. > >> I don't think that's right. Looking at RFC 2111 we find: > >> > >> content-id = url-addr-spec > >> > >> and > >> > >> url-addr-spec = addr-spec ; URL encoding of RFC 822 addr-spec > >> > >> Then consulting RFC 822 we find: > >> > >> addr-spec = local-part "@" domain > >> > >> However, I think we don't have to use a UUID for the local-part, we > >> could use a hash. > >> > >>> The hostname is just useless for the XMPP purposes. But if we > >>> keep it for common practice, I'd suggest a constant one then (as > >>> it's useless anyway). > >> I don't see a use for it now, but that doesn't mean it's useless. > >> However, I'm OK with hardcoding it to bob.xmpp.org or something. > >> > >>> If we need metadata to specify the origin, we can add an > >>> additional optional metadata element inside the <data/>. > >> Sure, we could do that. So something like this? > >> > >> <data cid='[EMAIL PROTECTED]' > >> origin='http://bundles.jabbim.cz/'/> > >> > >> Peter > > > > Seems nice. We should specify the hash algorithm in the cid somehow > > though. I don't know what the common practice for that would be. > > We might do something like this: > > 1. [EMAIL PROTECTED] > 2. [EMAIL PROTECTED] > > I don't have a strong preference. I might have a slight preference > for #1, because it's possible that we might even host image bundles > at those domains via HTTP (so if your client supports SHA1 it can go > to the URL http://sha1.bob.xmpp.org/ and retrieve the public images > hosted there). Possibly. :) I prefer #2. We could possibly host on bob.xmpp.cz anyway. > > And since we use hash now, we don't need to cache per JID. > > Nifty. But we may if we don't want to check the hash or don't believe the hash functions (future consideration). Depends on the implementation and configuration. > > Actually the idea > > (I talked with Pavel by IM a bit) > > That's allowed. Not everything needs to happen on the list. :) > > > is that client > > a) either uses hash, checks the incoming data and caches per hash > > or b) doesn't know the hash or hash wasn't used or doesn't support > > hashes and then caches per JID and per the unique string. > > > > I hope I got it right and clear :-). > > Yes, that seems good. I'll update the spec. > > /psa > -- Web: http://www.pavlix.net/ Jabber & Mail: pavlix(at)pavlix.net OpenID: pavlix.net
