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

[Peter Saint-Andre]

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.

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

(its servers emoticon service etc)

Disadvantages:
- I actually can't see what's better in this approach than in sending
ordinary HTTP URL, but I thought it was worth discussing. Maybe
advantage for clients with only one TCP connection possible (bombus)?

HTTP reveals IP address. And the second TCP connection and protocol
implementation servers as another example.

Yes, that's my concern. But since the idea is mainly about enabling auto-download only from trusted emoticon services I neglected this issue.

OK.

Peter

smime.p7s
Description: S/MIME Cryptographic Signature