addressing comments

articles/ui/ui.tex

@@ -280,8 +280,7 @@ code, and billing address; and {(4.)} (optionally) authorizing the
 transaction via mobile TAN, or by authenticating against the
 customer's bank, often on a Web site that is operated by the payment
 processor and {\em not} the customer's bank.  Figure~\ref{fig:cc3ds}
-% FIXME why "..on the Web today using.." and not just "..on the Web using.."
-shows a typical card-based payment process on the Web today using the
+shows a typical card-based payment process on the Web using the
 UML style of the W3C payment interest group~\cite{pigs}.  Most of the details
 are not relevant to this paper, but the diagram nicely illustrates the
 complexity of the common 3-D secure (3DS) process.
@@ -757,8 +756,7 @@ wallet, either via the status code HTTP 402 Payment Required, or via a
 JavaScript API.  The wallet then presents the contract to the user.  The format
 of the contract is in an extensible JSON-based format defined by Taler and not
 HTML, as the rendering of the contract is done by the wallet to ensure correct
-% FIXME(dold): specify what we mean by "correct visual representation"!
-visual representation.  In case that transaction fees need to be covered by the
+visual representation of the terms and price.  In case that transaction fees need to be covered by the
 customer, these are shown together with the rest of the proposed contract.
 
 If the customer approves the contract by clicking the ``Confirm
@@ -853,7 +851,6 @@ Various failure modes are considered:
  failure persists and is between the customer and the merchant, the wallet
  will try to recover control over the coins at the exchange by
  effectively spending the coins first using Taler's
- % FIXME(dold):  Do we properly introduce/discuss refreshing before?
  refresh protocol.  In this case, later deposits by the merchant
  will simply fail.  If the merchant already succeeded with the payment
  before the network failure, the customer can either retry the
@@ -868,20 +865,16 @@ Various failure modes are considered:
  the user to export the relevant cryptographic data to be used in
  court.  If the exchange's proofs were correct and coins were
  double-spent, the wallet informs the user that its database must have
- % FIXME what about giving an example of an out-of-date DB?  Put in
- % this way, it appears that Taler has viable ways to fail. In other
- % words, that it's normal to get such a failure. Instead, that failure
- % can occur due to coins not spent for *years* (or some other corner case),
- % that saves Taler from being "blamed"
- been out-of-date, updates the database and allows the user to retry
+ been out-of-date (e.g. because it was restored from backup),
+ updates the database and allows the user to retry
  the transaction.
 \end{itemize}
 
 
-While our design has a relatively high number of roundtrips,
+While our design has a few extra roundtrips,
 it has the following advantages:
 \begin{itemize}
-  \item It works in the confines of the WebExtensions API
+  \item It works in the confines of the WebExtensions API.
   \item It supports restoring session state for bookedmarked
     web resources when session state is cleared in the user agent.
   \item Sending deep links to other users has the expected behavior
@@ -1191,7 +1184,8 @@ payment.  Usually the wallet can trivially check this before beginning
 a transaction, but when double-spending is detected this may also
 happen after the wallet already initiated the payment. This would
 usually only happen if the wallet is unaware of a backup operation
-voiding its internal invariants.  If a payment fails in-flight due to
+voiding its internal invariant of knowing which coins have already
+been spent.  If a payment fails in-flight due to
 insufficient funds, the wallet can use Taler's refresh protocol to
 obtain a refund for those coins that were not actually double-spent,
 and then explain to the user that the balance was inaccurate due to