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? > Advantages: > - the sender isn't bloated by multiple requests for the file Who's contacted then? > - receiver doesn't leak its jabber id to arbitrary room occupant This is usually possible to achieve in MUC communications. > - receiver can have enabled downloads only from trusted jabber ID This is always possible, isn't it? > (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. > Best regards, > Zenon Kuder jr. -- Web: http://www.pavlix.net/ Jabber & Mail: pavlix(at)pavlix.net OpenID: pavlix.net
