Discourage use of 'password', provide a way to include SCRAM credentials, PEP nodes and message archives.
Each user is represented by a <user/> element under the <host/> element. The <user/> element MUST have a 'name' attribute, which contains the node part of the user's JID, and SHOULD have a 'password' attribute, which contains the user's password.
+Each user is represented by a <user/> element under the <host/> element. The <user/> element MUST have a 'name' attribute, which contains the node part of the user's JID.
+ +If the plaintext password of the user is known, it MAY be included in the 'password' attribute, although this is not recommended from a security perspective. For more information see Security Considerations. See also the SCRAM credentials section for an alternative.
Authentication secrets may be included that allow for authentication using the SCRAM family of mechanisms, as defined in &rfc5802;.
+ +Each set of credentials should be encapsulated within a <scram-credentials/> element in the 'urn:xmpp:pie:0#scram' namespace, and contained within the relevant <user/> element. The element should have a 'mechanism' attribute specifying the registered name of the mechanism that the credentials are used for (always without the "-PLUS" suffix), e.g. 'SCRAM-SHA-1'. The element MUST contain a single occurrence of each of the following child elements:
+ +There may be multiple occurrences of <scram-credentials/> for a single user, however they MUST all have a unique 'mechanism' attribute.
+ +Be aware of the Security Considerations when including credentials in a data export. Even though SCRAM credentials are stored in a hashed form, leaking them still allows an attacker to impersonate the user to other servers employing the same SCRAM parameters, and it also allows for offline dictionary or brute-force attacks.
+ +Each <user/> element SHOULD contain the user's roster in the form of a <query/> element qualified by the 'jabber:iq:roster' namespace. This element contains the user's roster in the same format as when retrieving the roster from the server, as described in section 7.3 of &xmppim;.
@@ -167,7 +210,7 @@A user's PEP data (as defined in &xep0163;) SHOULD be included if known.
+ +Node configuration and the actual node data are encapsulated separately, as described below. A typical export that contains both node configuration and the actual data contained within the node, will include two <pubsub/> elements (qualified by different namespaces).
+ +Many server implementations include support for additional pubsub features from &xep0060; beyond those required by XEP-0163. This specification aims to preserve this additional data also, when it is present and supported by both servers.
+ +Within the <user/> element there should be a single <pubsub/> element qualified by the 'http://jabber.org/protocol/pubsub#owner' namespace (note the '#owner' suffix). Within this element, there MUST be one <configure/> element for each exported node, with the node's name in the 'node' attribute. There MAY be additional elements included, at most one per node of each kind: <subscriptions/> and <affiliations>, following the syntax defined in XEP-0060.
+ +The format of the <configure/> is a &xep0004; data form, typically containing the fields documented in XEP-0060, encoding the configuration of the named node.
+ +As a general rule, importers SHOULD ignore node configuration options that the target server implementation doesn't recognise, to allow porting data between different implementations even in the presence of custom extensions. Exceptions to this requirement may be made for imports that are expected to be lossless, for example if the user has specifically requested a lossless import, or if the importer recognises certain configuration fields as critical to protect the node's security or integrity.
+Within the <user/> element there should be a single <pubsub/> element qualified by the 'http://jabber.org/protocol/pubsub' namespace (note the lack of any suffix). Within this element, there MUST be one <items/> element for each exported node, with the node's name in the 'node' attribute.
+ +Any node listed in this element MUST have a corresponding configuration included as described in the previous section.
+ +Each <items> element MUST contain zero or more <item/> elements as defined by XEP-0060.
+This example demonstrates an export for a user who has two nodes: a private bookmarks node with two bookmarks, and a public nickname node containing a single item.
+ +A user's &xep0313; message archive MAY be included in an export. If included, they MUST be formatted as a series of XEP-0313 <result/> elements within an <archive/> element qualified by the 'urn:xmpp:pie:0#mam' namespace. The result elements MUST be in chronological order (from oldest to newest).
+ +Exported data files are to be handled with care, since they contain data that users expect to be protected, in particular passwords. An exporting server SHOULD make sure that the generated file is not accessible to unauthorized persons, e.g. by enforcing strict file permissions.
+Exported data files are to be handled with care, since they contain data that users expect to be protected, in particular passwords. An exporting server SHOULD make sure that the generated file is not accessible to unauthorized persons, e.g. by enforcing strict file permissions. It may also apply suitable encryption before storing or transmitting the data.
XInclude <include/> elements which are indirect descendants of the <user/> element SHOULD be treated as opaque user data, and SHOULD NOT be processed.