1.1 --- a/README.txt Sun Jan 12 18:12:22 2014 +0100
1.2 +++ b/README.txt Sun Jan 12 18:39:15 2014 +0100
1.3 @@ -485,6 +485,57 @@
1.4 representations. Alternatively, a single message part may describe a single
1.5 representation.
1.6
1.7 +The Message Fetching Request and Response Formats
1.8 +-------------------------------------------------
1.9 +
1.10 +Requests made to fetch or manipulate messages via the FetchMessages action or
1.11 +equivalent service should have the text/x-moinmessage-fetch content type and
1.12 +contain a newline separated sequence of commands resembling those described in
1.13 +the POP3 specification (RFC 1939). However, the actual commands supported are
1.14 +as follows:
1.15 +
1.16 +STAT return the number of accessible messages
1.17 +
1.18 +RETR [ <number to retrieve> ] retrieve the given number of messages
1.19 + (starting from the first message in the store)
1.20 + or all messages if the number is omitted
1.21 +
1.22 +DELE [ <number to delete> ] delete the given number of messages (starting
1.23 + from the first message in the store) or all
1.24 + messages if the number is omitted
1.25 +
1.26 +Additional commands may be implemented in future. Note that the transactional
1.27 +commands in POP3 are not supported since the protocol is not intended to be
1.28 +used interactively and there is no notion of a session that is preserved over
1.29 +many requests.
1.30 +
1.31 +Requests should be signed and encrypted in order to preserve the privacy of
1.32 +the requester and the nature of their request.
1.33 +
1.34 +Responses to such requests should have the text/x-moinmessage-fetch-response
1.35 +content type and contain a complete message in the response body that should
1.36 +be the result of signing and encrypting a response message. (The inclusion of
1.37 +an entire message in the body is intended to work around HTTP limitations,
1.38 +even though HTTP should really be - or have been - MIME compatible.)
1.39 +
1.40 +The response message (before signing and encryption) is a multipart/mixed
1.41 +message constructed similarly to collections of message updates. Each part of
1.42 +this multipart message contains either a command result or a retrieved
1.43 +message.
1.44 +
1.45 +Command results should have the text/x-moinmessage-fetch-result content type
1.46 +providing the following headers:
1.47 +
1.48 +Request-Type the command that was provided
1.49 +Request-Status the status of the command (OK or ERR)
1.50 +
1.51 +Any specific result value may be provided as the payload of the command result
1.52 +message part.
1.53 +
1.54 +Retrieved messages should have the multipart/mixed content type and provide a
1.55 +retrieved message in each part, where such messages may themselves be signed
1.56 +or encrypted message representations.
1.57 +
1.58 HTTP Methods
1.59 ------------
1.60