some comments on DDs

3 files changed, 34 insertions, 7 deletions

diff --git a/design-documents/003-tos-rendering.rst b/design-documents/003-tos-rendering.rst
index 9b19ee02..d84a495f 100644
--- a/design-documents/003-tos-rendering.rst
+++ b/design-documents/003-tos-rendering.rst
@@ -22,6 +22,24 @@ way.
 Proposed Solution
 =================
 
+Internationalization
+--------------------
+
+The server will parse the ``Accept-Languages`` request header to determine
+which language the user will most likely want to read the terms of service
+in. If multiple languages are given, the server will check against the
+available languages and return the one with the highest preference.
+
+Additionally, the server will return an ``Avail-Languages`` header which
+details what other langauges the terms of service are available in. The
+user interface in the wallet should then allow the user to switch to one
+of these alternatives using some language switcher.
+
+
+Encoding
+--------
+
+
 The service providers can output legal agreements in various formats,
 determined via the ``"Accept: "`` request header.  The format provider **must**
 support the ``text/plain`` mime type.  The format provider **must** support
diff --git a/design-documents/038-demobanks-protocol-suppliers.rst b/design-documents/038-demobanks-protocol-suppliers.rst
index f4523d28..dcfd557e 100644
--- a/design-documents/038-demobanks-protocol-suppliers.rst
+++ b/design-documents/038-demobanks-protocol-suppliers.rst
@@ -150,3 +150,9 @@ subscriber that made the request.
    lead to **ambiguity**, in case two different demobanks host respectively
    one bank account under the same label.  This is not possible however
    in the current version, as Sandbox only admits one ``default`` demobank.
+
+
+Alternatives
+============
+
+Drop support for multitenancy banking. What is the benefit of this anyway?
diff --git a/design-documents/041-wallet-balance-amount-definitions.rst b/design-documents/041-wallet-balance-amount-definitions.rst
index a7c1202a..9a1eec79 100644
--- a/design-documents/041-wallet-balance-amount-definitions.rst
+++ b/design-documents/041-wallet-balance-amount-definitions.rst
@@ -53,24 +53,27 @@ For withdrawal:
 
 FIXME(dold): However, that does not really cover the user case where the merchant charges fees and the user has to pay for that. So in theory we could have a mode that withdraws enough to pay for some particular claimed order, but IMHO that's overkill.
 
-For deposits:
+For deposits (where there is no contract that already specifies an amount):
 
-* ``max-mode``: The instructed amount is ignored (can be zero in the request), and all coins are spent
+* ``max-mode``: The instructed amount is ignored (can be zero in the request), and all coins are spent (note that the calculation should be made available when the user is asked to specify an amount when using a template)
 * ``raw-mode`` (default): The instructed amount is what will be paid to the "merchant" (or the customer's bank account), ignoring wire fees
-* ``effective-mode``: The instructed amount is how the wallet's balance will be affected. Difficult to compute accurately because refresh is involved.
+* ``effective-mode``: The instructed amount is how the wallet's balance will be affected. Difficult to compute accurately because refresh is involved. Note that the calculation should ideally again be made available when the user is asked to specify an amount when using a template.
 
+  
 For peer-push-debit:
 
 * ``raw-mode`` (default): The instructed amount is what will be paid, deposit fees are covered by the sender, withdrawal fees from the reserve by the receiver
 * ``effective-mode``: Instructed amount is the effect on the material balance. Difficult to compute accurately because refresh is involved.
-* ``counterparty-effective-mode``: Instructed amount is the effect on the counterparty's wallet balance.
+* ``counterparty-effective-mode``: Instructed amount is the effect on the counterparty's wallet balance. Difficult to compute accurately because coin selection by receiver may not match our expectations.
 
-FIXME(dold): Should we also have a mode where withdrawal fees are covered by the side that does peer-push-debit? However, that assumes the other party has the same withdrawal coin selection algorithm
+FIXME(dold): Should we also have a mode where withdrawal fees are covered by the side that does peer-push-debit? However, that assumes the other party has the same withdrawal coin selection algorithm. FIXME(grothoff): isn't this the counterparty-effective-mode you described above, and that would seem to exactly have this issue?
 
 For peer-pull-credit:
 
-* ``raw-mode`` (default): Amount that the other party has to put in the reserve, where the other party has to pay deposit fees
-* ``effective-mode``: Amount that be added to on the initiator's balance
+* ``raw-mode`` (default): Amount that the other party has to put in the reserve. The payer has to pay any deposit fees on top. The receiver balance is increased by the specified amount minus any withdraw fees.
+* ``effective-mode``: Amount by which the initiator's balance is increased. Difficult to compute as the receiver has to simulate different coin selections and their effect on withdraw fees to arrive at the minimum total amount that must be deposited into the reserve.
+
+
 
 Illustrative Example
 --------------------