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. > >>> (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 > -- Web: http://www.pavlix.net/ Jabber & Mail: pavlix(at)pavlix.net OpenID: pavlix.net
