Hi Dan, > Apologies to Goffi, I said at the last Council session I would pop a message > on list, and then didn't.
No worries, you did actually :) > - I think the introduction could use some more context. [SNIP] > - I think Design Decisions could use some more background [SNIP] Agreed. > - 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?> `jid` is required for Roster's Item, the proposed spec use a different element (but will reuse the group of Roster's <item> following discussion with Daniel). JID is a sensitive data (for now we can retrieve JID who send or receive message, but this may change in the future, notably with sealed sender). Roster mechanism is only used for presence data, or if use is willing to use it e.g. for blocking message from contacts out of roster. The sync is made with JID in this case, JID is still used in <identity>, it's just not mandatory. The idea is that the server only know the minimum required to do its job, but things such as groups or name are encrypted. > - 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? The contacts MUST be e2e encrypted, it the raison d'être of this specification. The rest just open the door to a future better encryption method, so we don't stay forever blocked on OX for pubsub. We have namespaces to deal with that, I don't see we need much more. Maybe the formulation can be improved, but the idea is to say that e2ee is mandatory, and that we have a method right now the must be used as long as there is no better alternative, and the door is open for better algorithm is any in the future. > I don't think all of these are blockers for progressing the XEP. I think The > compatible implementations feels like it might be though? The compatibility with RFC Roster is done though the <identity type="jid"> which is already specified. It could maybe be clear or explained in a dedicated section. Btw, I've named the spec "End-to-End Encrypted Contacts Metadata" where I've used "Contacts" instead of "Roster" to avoid the confusion with RFC roster. Of course I'm partial, but I don't think this is enough to block this spec. Thanks for your feedback. Best, Goffi
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
