# HG changeset patch
# User Henry S. Thompson <ht@inf.ed.ac.uk>
# Date 1792592834 -3600
# Node ID f2743a0a4eb7f223026d7a5319eda41c9c78556a
# Parent  28fb3e434f00f1117bb700bda929e9059647bac5
more

diff -r 28fb3e434f00 -r f2743a0a4eb7 satp-core-review.txt
--- a/satp-core-review.txt	Wed Oct 21 13:35:04 2026 +0100
+++ b/satp-core-review.txt	Wed Oct 21 15:27:14 2026 +0100
@@ -110,6 +110,46 @@
   gateways.  Is this information meant to be included in the 'transfer
   context' as defined in 5.3.6?
 
+8.4. and others
+
+  8.3. and 8.4. define the *Transfer Proposal Message* and *Transfer
+  Proposal Receipt Message*. There are a number of message pairs with
+  similar pairs of names, with the second part being variously named
+  ... Receipt Message or ... Response Message.
+
+  Language along the lines of "The message is sent from the [recipient
+  gateway] to the ... EndPoint at the [sender gateway]" appears in
+  many if not all of them
+
+  It's never made clear if this just e.g. requires *Transfer Proposal
+  Receipt Message* as the form which the HTTPS response body should
+  adopt when responding to an HTTPS POST request in the *Transfer
+  Proposal Message* form or, as I read it at first, actually means a
+  _seperate_ HTTPS POST request in the *Transfer Proposal Receipt
+  Message* format is sent from the recipient gateway.
+
+  That is, are we being told about a single HTTPS exchange, or two?
+  Or is the intent to allow for either?  I think either at the
+  beginning of section 8, or somewhere earlier, perhaps section 6,
+  this should be explained.  Indeed Figure 2 in section 6 might
+  encourage one to think that the Transfer Proposal exchange requires
+  one HTTPS exchange, whereas the Lock Assertion exchange involves
+  two.
+
+11.
+
+  The discussion of time-outs and aborts leaves it unclear whether a
+  gateway which times out waiting at some point in a session should
+  send a session-abort-msg or not, but I would think it should.
+
+  Note that the phrase "time-outs due to gateway crashes" doesn't make
+  any sense: from the point-of-view of a gateway (G1) which times out
+  waiting for a response, there is no way to detect the _reason_ for
+  the timeout.  In case a timeout is _not_ because of a crash on the
+  part of the other gateway (G2), surely notification that the session
+  is being terminated by G1 should be sent, to enable an orderly
+  close-down by G2, instead of it having to time-out itself.
+
 *Nits*
 
 3.
@@ -118,7 +158,7 @@
 'originator' and 'beneficiary' here.
 
 5.3.15
-  'immobile' => 'immobilize' [twice]
+  immobile => immobilize [twice]
 
   'uses Hashed Time-lock' => 'use Hashed Time-lock'
 
@@ -137,7 +177,19 @@
   The example JSON is missing a comma after
   "urn:ietf:params:satp:core:msgtype:transfer-proposal-msg"
 
- 12.
+11.3.
+
+  errror => error
+
+11.4.
+
+  I think *Protocol Error Codes* would be better...
+
+11.5.
+
+  'maybe' => 'may be'
+
+12.
 
   'such a' => 'such as'