Apologies to Goffi, I said at the last Council session I would pop a message on list, and then didn't. 

Until now...

- I think the introduction could use some more context. It mentions privacy implications as a key driver for the XEP, but doesn't expand on how. Inferring from stuff later in the document, I think it's when you don't trust your server operator, but I think it could be explicit about the problem being solved.

- We briefly discussed how this could be Step 1 of N towards serverless operation, where your contact doesn't have a stable JID and/or is permanently addressable by something that isn't a standard JID.

    - I think Design Decisions could use some more background on the bigger picture of what this is contributing to, and if necessary, how this contributes toward that goal. I know that's not normal XEP territory, but given the section is already about background and rationale, I think it makes sense

    - This XEP states "Contact data must not be tied to a JID or any domain-specific identifier", and RFC 6121 says "The 'jid' attribute of the <item/> element specifies the Jabber Identifier (JID) that uniquely identifies the roster item. The 'jid' attribute is REQUIRED whenever a client or server adds, updates, deletes, or returns a roster item.". The business rules say that "roster mechanism is still used, as it is necessary". Does that mean that there's an unspecified sync, or that the client is maintaining two lists?

- I'm a bit uncomfortable with the text about encryption. "Both node items MUST be end-to-end encrypted", but then goes on to loosely recommend one method, and add a MAY that something that isn't a MUST or SHOULD might change in the future. Does this need either one MUST/SHOULD mechanism to enable compatible implementations, or a metadata layer to inform the client of the mechanism?

I don't think all of these are blockers for progressing the XEP. I think The compatible implementations feels like it might be though?

HTH,

Dan