Thank you very much for your eager interest and numerous replies *cough*, in other words, Thank you Florian for your reply :D
I'm not quite sure, how exactly the process of negotiating expected encrypted elements would look like. Do you think this may be done via or similar to Entity Capabilities (XEP-0115)? I can see that this would make it easier for adopters to gradually start implementing support for one feature at a time (like start with support for <body/> encryption and then successively add support for other elements as well), but at the same time I feel like this could enable "downgrade" attacks and would diminish the "encrypt *all* the sensitive things"-approach that I aim for. For now I'm trying to give useful sensible suggestions on what elements are allowed inside the envelopes content element. If later we learn that there are elements that are definitely not allowed at all, we might want to come up with some sort of incomplete list of forbidden elements. An alternative approach that some people suggested would be to replace the envelopes content element with a normal message stanza. That way implementations could simply decrypt that stanza, check it for forbidden elements and remove those and then feed the cleaned stanza back into the XML stream. That way the client wouldn't have to reimplement listeners for all the events. On the other hand, the client would probably want to somehow mark the decrypted stanza as end-to-end encrypted. What do you think of this approach? Is it better, worse than the current proposal? (reminder: http://geekplace.eu/xeps/xep-sce/xep-sce.html ) I hope that there will be some more feedback from participants of this list. I don't want to get the feedback only when the document lands in the inbox folder ;). If you think the idea behind the spec is a good idea - nice! If you think it is a bad idea - even better! But please let me know why and what you'd change. Happy Hacking! Paul _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________