Incorporate fixes by roker or add suggestions as TOOD, respectively.

pep-email/draft-pep-email.mkd

@@ -150,12 +150,12 @@ Examples:
   actors to learn a user's social graph. This is also problematic 
   security-wise, as centralized cryptographic key subversion at-scale is made 
   cheaper. Instead, key distribution MUST be handled in-band while communicating  with other peers. 
-* No trust information MUST be attached to the communication partner's public
+* Trust information MUST NOT be attached to the communication partners' public
   keys. This is metadata which MUST be held locally and seperately from the 
   keys. Trust is established between the peers directly (peer-to-peer) and no 
   trust information is held centrally (no support for the Web 
   of Trust): that is, while pEp MUST be able to work with OpenPGP keys which 
-  carry trust information, this trust information MUST not be used to signal 
+  carry trust information, this trust information MUST NOT be used to signal 
   any trust level.
 * pEp-enabled MUAs MUST either engage in a signed-and-encrypted communication 
   or in unsigned plaintext communication. While the signatures attached to 
@@ -195,14 +195,20 @@ fields are transport-relevant and thus might be copied to the wrapper.
 ## Interoperability
 
 Implementers of pEp SHOULD be liberal in accepting non-pEp formats to encrypt 
-email contents and metadata, but MUST use the strict and interoperable 
-pEp format (cf. {{pef-1-0}}) for any outgoing communication to non-pEp users.
+email contents and metadata and MUST use the strict and interoperable 
+pEp Email Format 1.0 (cf. {{pef-1-0}}) for any outgoing communication to
+non-pEp users. For communication between pEp users, more privacy-preserving
+formats (cf. {{pep-email-formats}}) MUST be used. pEp Email Formats 2.0 and 
+newer SHOULD NOT be used towards users which were not recognized as 
+pEp users (cf. {{protocol-negotiation-for-format-selection}}), because for such
+non-pEp users those formats are likely to produce unwanted visual artefacts.
 
 ## End-to-End {#end-to-end}
 
-An email endpoint in pEp is the MUA on a user's end-device: that is,
-encryption and decryption of messages MUST be executed on a user's end-device 
-and MUST NOT happen on a server infrastructure.
+For interpersonal messaging, an email endpoint in pEp is the MUA on a user's 
+end-device: that is, encryption and decryption of messages MUST be executed on 
+a user's end-device and MUST NOT depend on any third-party network 
+infrastructure (i.e., any infrastructure outside a user's direct control).
 
 \[\[ **TODO**: Add enterprise settings with Key Escrow / Extra Keys \]\]
 
@@ -216,6 +222,9 @@ themselves. Email servers (like, SMTP or IMAP) are only used as transport
 infrastructure for messages, but MUST not be relevant to hold actual state 
 between peers.
 
+\[\[ TODO: Make clear there is a way to synchronize trust in a peer-to-peer 
+fashion, by using the Trust Sync mechanism. \]\]
+
 ## User Experience (UX) {#ux}
 
 \[\[ **TODO**: Add here what is specific to email \]\]
@@ -288,7 +297,7 @@ identity.
 The pEp Email Formats 1.0, 2.0 and 2.1 are restricted MIME-based email
 formats, which ensure messages to be signed and encrypted. In accordance with
 pEp's privacy (and not security) focus, signed-only messages MUST NOT be 
-supported (cf. {{privacy-by-default}}). pEp-enabled clients MUST be able to
+produced (cf. {{privacy-by-default}}). pEp-enabled clients MUST be able to
 render all pEp Email Formats properly: for outgoing communications, 
 the most privacy-preserving format available is to be used, taking 
 interoperability (cf. {{interoperability}}) into account.
@@ -337,6 +346,11 @@ A simple plaintext email looks like the following:
 {::include examples/pef-0.mkd}
 {::include ../shared/fence-line.mkd}
 
+\[\[ TODO, feedback roker: the size parameter is redundant, useless and can
+   even be counter-productive: it should not be necessary that the receiver 
+   relies on this parameter; OpenPGP has own mechanisms to ensure a key is
+   protected against damages \]\] 
+
 ### pEp Email Format 1.0 {#pef-1-0}
 
 pEp Email Format 1.0 (PEF-1.0) is an encrypted and signed MIME format, which 
@@ -732,6 +746,10 @@ binding archivign regulations, pEp implementations MUST provide a
 unencrypted copies of the Messages MUST be held on the mail servers 
 controlled by the organization.
 
+\[\[ TODO, feedback roker: Discuss the importance of full-disk encryption, also
+  for the option to save messages locally in unencrypted form; that is even
+  more important to protect secret keys (mentioned in pEp's general draft). \]\]
+
 # Key Management
 
 ## Key Generation
@@ -765,7 +783,9 @@ MUST be generated.
 ## Public Key Distribution
 
 By default, public keys MUST always be attached to any outgoing message
-as described in {{pep-email-formats}}.
+as described in {{pep-email-formats}}. If this is undesired, e.g., to reduce
+display artefacts or (temporary) spam alerts on the receiving side, Passive 
+Mode (cf. {{passive-mode}}) can be activated.
 
 ## Key Reset
 
@@ -773,7 +793,7 @@ as described in {{pep-email-formats}}.
 
 # Trust Management
 
-The following example roughly describes a pEp Email scenario with a
+The following example roughly describes a pEp email scenario with a
 typical initial message flow to demonstrate key exchange and basic
 trust management:
 
@@ -913,7 +933,7 @@ implementation on pEp and the ideas leading to this draft.
 
 The author would like to thank the following people who provided
 substantial contributions, helpful comments or suggestions for this
-document: Claudio Luck and Bernie Hoeneisen.
+document: Claudio Luck, Bernie Hoeneisen and Lars Rohwedder.
 
 This work was initially created by pEp Foundation, and was initially reviewed 
 and extended with funding by the Internet Society's Beyond the Net Programme on