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

diff -r 7cf0c76e9749 -r 28fb3e434f00 satp-core-review.txt
--- a/satp-core-review.txt	Wed Oct 21 11:01:35 2026 +0100
+++ b/satp-core-review.txt	Wed Oct 21 13:35:04 2026 +0100
@@ -96,8 +96,19 @@
 8., 9., 10.
 
   remove and/or replace 'client', 'server' and 'receiver' so that all
-  and only 'sender gateway' and 'recipient gateway' are used
+  and only 'sender gateway' and 'recipient gateway' are used.
+
+8.3. and others
+
+  Starting here there are many sentences of the form
 
+   "This message is sent from ... to the ... Endpoint at ... ."   
+
+  The typography implies that these are formal properties of SATP, but
+  as far as I can see there is no definition of 'endpoint' or how the
+  many different ... Endpoints are to be identified between the two
+  gateways.  Is this information meant to be included in the 'transfer
+  context' as defined in 5.3.6?
 
 *Nits*
 
@@ -111,6 +122,25 @@
 
   'uses Hashed Time-lock' => 'use Hashed Time-lock'
 
+8.1., 8.2., 8.6., 9.1, 10., 11.3., 11.4.
+
+  must => MUST [throughout]
+
+8.4., 8.6. and 9 others
+
+  The example JSON ends with a comma, which is strictly speaking not
+  allowed, and may cause errors in some tools (e.g. jq).  It would be
+  best to remove them.
+
+11.3.
+
+  The example JSON is missing a comma after
+  "urn:ietf:params:satp:core:msgtype:transfer-proposal-msg"
+
+ 12.
+
+  'such a' => 'such as'
+
 15.1
 
  RFC 8446 is obsolete, should refer to 9846.