[Standards] LAST CALL: XEP-0232 (Software Information)

Peter Saint-Andre stpeter at stpeter.im
Wed Feb 25 18:46:22 UTC 2009


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/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090225/e7b0e9ea/attachment.bin>


More information about the Standards mailing list