[Standards] LAST CALL: XEP-0398 (User Avatar to vCard-Based Avatars Conversion)

Jonas Schäfer jonas at wielicki.name
Tue Feb 25 16:14:57 UTC 2020


On Mittwoch, 12. Februar 2020 17:22:49 CET Jonas Schäfer wrote:
> This message constitutes notice of a Last Call for comments on
> XEP-0398.
> 
> Title: User Avatar to vCard-Based Avatars Conversion
> Abstract:
> This specification describes a method for using PEP based avatars and
> vCard based avatars in parallel by having the user’s server do a
> conversion between the two.
> 
> URL: https://xmpp.org/extensions/xep-0398.html
> 
> This Last Call begins today and shall end at the close of business on
> 2020-02-26.
> 
> Please consider the following questions during this Last Call and send
> your feedback to the standards at xmpp.org discussion list:
> 
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?

Kind of. It helps with a transition path needed to a new technology.

> 2. Does the specification solve the problem stated in the introduction
> and requirements?

Yes.

> 3. Do you plan to implement this specification in your code? If not,
> why not?

Yes [1].

> 4. Do you have any security concerns related to this specification?

There is the obvious issue that the vCard is world-readable, which has 
in the past caused surprise with XMPP users from the instant messaging 
world. Moving the data to PEP allows the user to control who is able to 
read it.

The document currently states that:

> In the future services MAY decide to perform PEP to vCard conversion 
only if the access model of the 'urn:xmpp:avatar:data' node has been set 
to 'open' as described in Publish-Subscribe (XEP-0060) [5]. However the 
ability to change the access model of nodes isn’t widely implemented yet 
and thus this paragraph exists only to act as a reminder that the 
privacy implications described in the previous paragraph can be avoided

I don’t think this is necessarily true anymore. I’d love to get feedback 
from server developers on this one, so that we can get the rules changed 
before moving on to Draft.

Specifically, I would prefer if we could get this changed so that the 
server always does the conversion, but uses the access model from the 
PEP node to answer vCard requests. I.e. if the PEP node is set to 
`whitelist` or `presence`, it should only answer vCard requests based on 
that.

And maybe re-define XEP-0292 to use PEP as backing storage so that users 
(clients) can control the vCard permissions independently from the 
avatar permissions.

> 5. Is the specification accurate and clearly written?

Yes.

   [1]: https://github.com/horazont/aioxmpp/issues/230
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200225/293147b9/attachment.sig>


More information about the Standards mailing list