Re: [Standards] LAST CALL: XEP-0231 (Bits of Binary)

[Peter Saint-Andre]

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. :)

And since we use hash now, we don't need to cache per JID.

Nifty.

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


I hope I got it right and clear :-).

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.

Yes, that seems good. I'll update the spec.

/psa

smime.p7s
Description: S/MIME Cryptographic Signature