Remko Tronçon wrote: > This thread seems to have died down, so time to revive it, given that > it is in last call.
Thanks for the summary. > This was my understanding of the opinions on this XEP: > - Showing the different type of icons per-status is not something > people want to implement in clients. The only use I see is for this > might be transports, although I still think most clients even want > this to be implemented on their side, for better consistency with the > rest of the UI look. That seems appropriate to me. So we would remove all of the following fields: icon_available icon_away icon_chat icon_dnd icon_xa > - Some clients implement the per-client logo avatar, so the logo > sounds useful to at least these clients. So we would retain the "icon" field. > - There's a security issue with OOB images that at least needs to be > documented. Documenting is probably not enough, because I don't see a > client displaying client icons asking the user for every type of > client whether he wants to fetch the icon (which is different than > with 'occasional' OOB requests that need to be acknowledged). There > was a suggestion of mediated BoB solutions, which IMO makes sense > because it removes the burden of security checks off the clients, and > most clients will request the same images anyway. On this approach the client would ask its server for the data referenced by the cid: URI. We could even host the information at bob.xmpp.org. :) However, I think Joe's point is well-taken -- right now there is no defined method for including media elements from a data form into the algorithm for generating the entity capabilities hash. Perhaps that's not the end of the world because what we really want to capture in the caps hash is the software info (os, version, etc.), not the icon. Shall I edit XEP-0232 accordingly? Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
