Added auto-archiving warning for legacy clients; corrected examples
A client discovers whether its server supports this protocol using &xep0030;.
For each feature defined herein, if the server supports that feature it MUST return a <feature/> element with the 'var' attribute set to 'http://jabber.org/protocol/archive#name', where "name" is "auto" for the Automated Archiving feature, "encrypt" for the server-side encryption feature (see Automated Archiving), "manage" for the Archive Management feature, "manual" for the Manual Archiving feature, or "pref" for the Archiving Preferences feature.
In order to determine its user's current Save Mode(s) and OTR Mode(s), a client sends an empty <pref/> element to its server:
A client may set the default Modes:
A client may use a similar protocol to set the Modes for a particular contact or domain of contacts (bare JID, full JID or domain). Note: It is STRONGLY RECOMMENDED for the value of the 'jid' attribute to be a bare JID (&BAREJID;).
The collection of messages and notes to be uploaded are encapsulated in the <store/> element.
If the server cannot service a store request because the collection is too large then it MUST return a ¬acceptable; error:
The client MAY specify an absolute time for any message by providing a longer 'utc' attribute (which MUST be UTC and adhere to the DateTime format specified in Jabber Date and Time Profiles) instead of a 'secs' attribute. The absolute time MAY be before the start time of the collection:
A client MAY archive messages that it receives from &xep0045; rooms. The 'with' attribute MUST be the bare JID of the room. The client MUST include a 'name' attribute for each <from/> element to specify the room nickname of the message sender:
If the client specifies a new value for the 'subject' attribute of any existing collection then the server MUST update the existing value. Note: The client cannot specify new values for the 'with' or 'start' attributes. The only way to change these values is to delete the collection (see Removing a Collection) and then create a new one.
Note: A collection that contains <EncryptedData/> or <EncryptedKey/> elements MUST NOT contain <to/> or <from/> or <note/> elements.
A client MAY enable or disable automatic archiving for messages sent over its stream. Automatic archiving MUST default to disabled for each new stream that is opened, unless administrator policies require that every message is logged automatically (see Security Considerations). Once automatic archiving is switched on then the server MUST automatically archive messages only according to the user's general Archiving Preferences.
-Note: Both parties to an ESession (see &xep0116;) MUST either disable archiving or use an archiving method other than automatic, since ESession decryption keys are short-lived - making it impossible to decrypt automatically archived messages.
+If server administration policies require that every message is logged automatically (see Security Considerations) then:
+Otherwise:
+If the client switches off all auto-archiving then the server MUST close and store all active collections.
Servers (and clients) SHOULD support the encryption (and decryption) of automatically-archived collections (although early implementations of this protocol MAY prefer to defer encryption and decryption to later versions).
@@ -480,7 +501,7 @@If the 'with' attribute is omitted then collections with any JID are returned. If only 'start' is specified then all collections on or after that date should be returned. If only 'end' is specified then all collections prior to that date should be returned.
The client SHOULD use Result Set Management to limit the number of collections returned by the server in a single stanza, taking care not to request a page of collections that is so big it might exceed karma limits.
The server MUST list the collections (empty <store/> elements including all attributes) in chronological order when responding to any request. If the collection contains <EncryptedData/> or <EncryptedKey/> elements then the 'crypt' attribute of the <store/> element MUST be set to 'true':
If no collections correspond to the request the server MUST return an empty <list/> element:
To request a page of messages from a collection the client sends a <retrieve/> element. The 'with' and 'start' attributes specify the participating full JID and the start time (see Jabber Date and Time Profiles). Both attributes MUST be included to uniquely identify a collection:
The client SHOULD use Result Set Management to limit the number of messages returned by the server in a single stanza, taking care not to request a page of messages that is so big it might exceed karma limits.
If the specified collection does not exist then the server MUST return an ¬found; error:
If the requested collection is empty the server MUST return an empty <store/> element:
The items in encrypted collections are typically larger - since each <EncryptedData/> element typically contains many messages. So the client SHOULD take even more care not to request a page of <EncryptedData/> elements that is so big it might exceed karma limits.
In addition to the requested <EncryptedData/> elements, the server MUST return all the <EncryptedKey/> elements that it possesses for the user whose symmetric key name (wrapped in its <CarriedKeyName/> child) is referenced by the <KeyName/> child of the <KeyInfo/> child of any of the <EncryptedData/> elements in the returned page.
The client MAY limit the number of <EncryptedKey/> elements that it receives by specifying the name of one or more public keys for which it holds the associated private keys. The name of each public key MUST be wrapped in a <KeyName/> element.
To request the removal of a single collection the client sends an empty <remove/> element. The 'with' (full JID) and 'start' attributes MUST be included to uniquely identify the collection.
The client may remove several collections at once. The 'start' and 'end' elements MAY be specified to indicate a date range. The 'with' attribute MAY be a full JID, bare JID or domain.
If the end date is in the future then then all collections after the start date are removed.
If the start date is before all the collections in the archive then all collections prior to the end date are removed.
If the value of the optional 'open' attribute is set to 'true' then only collections that are currently being recorded automatically by the server (see Automated Archiving) are removed.
If the specified collection (or collections) do not exist then the server MUST return an ¬found; error:
If a private key becomes obsolete or compromised then it may be necessary for a client to replace all <EncryptedKey/> elements that contain symmetric keys encrypted with the public key that is associated with the obsolete private key.
The client first requests a list of the affected <EncryptedKey/> elements from all collections by sending a <keys/> element to the server:
The server MUST return only <EncryptedKey/> elements whose symmetric encryption key is encrypted with the obsolete public key specified in the <KeyName/> child of the request:
The client decrypts each symmetric key with the obsolete private key and encrypts it again with the new public key. The client then wraps each symmetric key in an <EncryptedKey/> element and asks the server to store it in its associated collection on the server (see Encryption):
Finally, the client asks the server to delete from each collection all <EncryptedKey/> elements whose symmetric encryption key is encrypted with the obsolete public key:
-The client MUST request each page of the list using the Result Set Management protocol embeded in a <modified/> element. The content of the <after/> element SHOULD be a UTC time (see Jabber Date and Time Profiles) that it has previously received from the server (see below). When synchronizing for the first time, the client MAY choose a suitable time for the first page request (e.g. 1970-01-01T00:00:00Z).
The server MUST return the changed collections in the chronological order that they were changed (most recent last). If a collection has been modified, created or removed after the time specified by the <after/> element then the server MUST include it in the returned result set page of collections (unless the specified maximum page size would be exceeded). Each <changed/> or <removed/> collection element (for modified/created, or removed collections respectively) in the returned list MUST include only 'with' and 'start' attribues. The server MUST set the content of the <last/> element to the UTC time (see Jabber Date and Time Profiles) that the last collection on the page was modified.