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

[Peter Saint-Andre]

Pavel Simerda wrote:

On Thu, 14 Aug 2008 11:18:23 -0600
Peter Saint-Andre <[EMAIL PROTECTED]> wrote:

Zenon Kuder jr. wrote:

Dne Thursday 14 of August 2008 17:00:37 Pavel Simerda napsal(a):

On Thu, 14 Aug 2008 15:40:14 +0200

"Zenon Kuder jr." <[EMAIL PROTECTED]> wrote:

Hi again, I came up with some more comments :-)

From introductory text of section 2.1:
"[...] If the data is not cached, the recipient would then
retrieve the data by sending an IQ-get to the sender (or
potentially some other entity) [...]"

I think the "potential other entity" might be an interesting use
case as well. As stated in my previous mail, I think about the
emoticons use case. This time for example in a MUC room:
-participant A sends an xhtml-im message to muc room containg the
<img> element to reference an emoticon
- participant B, C, D, E and F receive the message and since they
don't have the referenced image, they want to retrieve it.
- there exists a protocol to reference external resources, which
these entities use to download the referenced data

Maybe some example flows would help. Is this a comment to the
current specs with some changes needed or just another use case?

It's just an use case which came into my mind, which the current
spec doesn't cover, but does mention it might be covered in the
future. That's why I wanted to make sure it will be possible to add
in the future. Sorry for the confusion.

Right, I didn't want to disallow that kind of usage in the future.

Advantages:
- the sender isn't bloated by multiple requests for the file

Who's contacted then?

The "potential other entity", possibly trusted service which user
is not afraid to leak jabberID to.

Right.

- receiver doesn't leak its jabber id to arbitrary room occupant

This is usually possible to achieve in MUC communications.

Indeed. But if participant B wanted to request data from
participant A, he would have to send an IQ, which would reveal his
Jabber ID to user A.

I don't remember how IQ queries and MUC work together (will have to
learn more about MUC).

- receiver can have enabled downloads only from trusted jabber ID

This is always possible, isn't it?

Yop, but to make it effective you need a way for
[EMAIL PROTECTED] to reference an image at differenet JID (e.g.
emoticonService.barserver.org).

I don't think this is disallowed by the spec.

But the syntax is not defined.

/psa

I don't think the spec needs a special definition for this. If the message is broadcasted in the room, you ping another (trusted) person in the room for the binary, not the (untrusted) sender.

smime.p7s
Description: S/MIME Cryptographic Signature