[taler-docs] branch master updated (4888588 -> 2367a35)

[gnunet]

This is an automated email from the git hooks/post-receive script.

ttn pushed a change to branch master
in repository docs.

    from 4888588  fix typo: s/structure/structures/
     new 13b0747  fix typo: s/from/form/
     new 1c7602e  add hyphen
     new 008c913  capitalize first word in sentence; add period at end of 
sentence
     new d58981a  capitalize first word in sentence
     new 38b8cec  change markup of ‘If-None-Match’ from " to ``
     new 30a0a5c  change markup of various things from " to `` (six instances)
     new 66ebc3c  change markup of ‘If-Match’, ‘If-None-Match’ from " to ``
     new 786771b  mark up ‘100 continue’
     new fcf262e  mark up ‘/$ACCOUNT-KEY’
     new 7ed371a  change markup of ‘If-Match’ from " to ``
     new 93c03c6  mark up ‘Content-length’
     new 036407a  change markup of ‘410 Gone’ from " to ``
     new 2367a35  fix typo: s/was/is/

The 13 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 core/api-sync.rst | 40 ++++++++++++++++++++--------------------
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/core/api-sync.rst b/core/api-sync.rst
index ba7fd8d..f72c385 100644
--- a/core/api-sync.rst
+++ b/core/api-sync.rst
@@ -25,7 +25,7 @@ The backup and synchronization service uses an EdDSA key
 to identify the "account" of the user.  The key is Crockford
 Base32-encoded in the URI to access the data and used to sign requests
 as well as to encrypt the contents (see below).  These signatures are
-provided in detached from as HTTP headers.
+provided in detached form as HTTP headers.
 
 Once the user activates backup or synchronization, the client should
 display the key as a QR code as well as in text format together
@@ -38,7 +38,7 @@ a padded and encrypted version of the data.
 
 However, there are a few general rules that will apply to
 any version of the backup.  Still, except for the
-32 byte minimum upload size, the synchronization service
+32-byte minimum upload size, the synchronization service
 itself cannot not enforce these rules.
 
 *  First, the database should be compressed (i.e. gzip), then
@@ -118,13 +118,13 @@ Receiving Terms of Service
   .. ts:def:: SyncTermsOfServiceResponse
 
     interface SyncTermsOfServiceResponse {
-      // maximum backup size supported
+      // Maximum backup size supported.
       storage_limit_in_megabytes: number;
 
       // Fee for an account, per year.
       annual_fee: Amount;
 
-      // protocol version supported by the server,
+      // Protocol version supported by the server,
       // for now always "0.0".
       version: string;
 
@@ -166,7 +166,7 @@ Receiving Terms of Service
 
   :http:statuscode:`304 Not modified`:
     The version available at the server is identical to that
-    specified in the "If-None-Match" header.
+    specified in the ``If-None-Match`` header.
 
   :http:statuscode:`404 Not found`:
     The backup service is unaware of a matching account.
@@ -196,28 +196,28 @@ Receiving Terms of Service
 .. http:post:: /backups/${ACCOUNT-KEY}
 
   Upload a new version of the account's database, or download the
-  latest version.  The request SHOULD include the "Expect: 100 Continue"
-  header.  The client then SHOULD wait for "100 Continue" before proceeding
+  latest version.  The request SHOULD include the ``Expect: 100 Continue``
+  header.  The client then SHOULD wait for ``100 Continue`` before proceeding
   with the upload, regardless of the size of the upload.
 
   **Request**
 
-  The request must include a "If-Match" header indicating the latest
+  The request must include a ``If-Match`` header indicating the latest
   version of the account's database known to the client.  If the server
-  knows a more recent version, it will respond with a "409 conflict"
+  knows a more recent version, it will respond with a ``409 conflict``
   and return the server's version in the response.  The client must
   then merge the two versions before retrying the upload.  Note that
-  a "409 Conflict" response will typically be given before the upload,
-  (instead of "100 continue"), but may also be given after the upload,
+  a ``409 Conflict`` response will typically be given before the upload,
+  (instead of ``100 continue``), but may also be given after the upload,
   for example due to concurrent activities from other accounts on the
   same account!
 
   The request MUST also include an "Sync-Signature" signing
-  the "If-Match" SHA-512 value and the SHA-512 hash of the body with
+  the ``If-Match`` SHA-512 value and the SHA-512 hash of the body with
   the account private key.
 
   Finally, the SHA-512 hash of the body MUST also be given in an
-  "If-None-Match" header of the request (so that the signature can be verified
+  ``If-None-Match`` header of the request (so that the signature can be 
verified
   before the upload is allowed to proceed).
 
   The uploaded body must have at least 32 bytes of payload (see
@@ -260,7 +260,7 @@ Receiving Terms of Service
 
   :http:statuscode:`304 Not modified`:
     The server is already aware of this version of the client.
-    Returned before 100 continue to avoid upload.
+    Returned before ``100 continue`` to avoid upload.
 
   :http:statuscode:`400 Bad request`:
     Most likely, the uploaded body is too short (less than 32 bytes).
@@ -268,7 +268,7 @@ Receiving Terms of Service
   :http:statuscode:`402 Payment required`:
     The synchronization service requires payment before the
     account can continue to be used.  The fulfillment URL
-    should be the /$ACCOUNT-KEY URL, but can be safely ignored
+    should be the ``/$ACCOUNT-KEY`` URL, but can be safely ignored
     by the client.  The contract should be shown to the user
     in the canonical dialog, possibly in a fresh tab.
 
@@ -277,9 +277,9 @@ Receiving Terms of Service
 
   :http:statuscode:`409 Conflict`:
     The server has a more recent version than what is given
-    in "If-Match".  The more recent version is returned. The
+    in ``If-Match``.  The more recent version is returned. The
     client should merge the two versions and retry using the
-    given response's "E-Tag" in the next attempt in "If-Match".
+    given response's "E-Tag" in the next attempt in ``If-Match``.
 
   :http:statuscode:`410 Gone`:
     The backup service has closed operations.  The body will
@@ -288,7 +288,7 @@ Receiving Terms of Service
     The user should be urged to find another provider.
 
   :http:statuscode:`411 Length required`:
-    The client must specify the "Content-length" header before
+    The client must specify the ``Content-length`` header before
     attempting upload.  While technically optional by the
     HTTP specification, the synchronization service may require
     the client to provide the length upfront.
@@ -297,7 +297,7 @@ Receiving Terms of Service
     The requested upload exceeds the quota for the type of
     account.  The client should suggest to the user to
     migrate to another backup and synchronization service
-    (like with "410 Gone").
+    (like with ``410 Gone``).
 
   :http:statuscode:`429 Too many requests`:
     This account has exceeded daily thresholds for the number of
@@ -344,7 +344,7 @@ service upon first withdrawal, suggesting one that is free 
or
 accepts payment in the respective currency. If none is available,
 the client should warn the user about the lack of available
 backups and synchronization and suggest to the user to find a
-reasonable service.  Once a synchronization service was selected,
+reasonable service.  Once a synchronization service is selected,
 the client should urge the user to print the respective key
 material.
 

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.