Mercurial > hg > ietf

comparison satp-core-review.txt @ 22:f2743a0a4eb7

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
more
author Henry S. Thompson <ht@inf.ed.ac.uk>
date Wed, 21 Oct 2026 15:27:14 +0100
parents 28fb3e434f00
children 2eda17d4debf
comparison
equal deleted inserted replaced
21:28fb3e434f00 22:f2743a0a4eb7
108 as far as I can see there is no definition of 'endpoint' or how the 108 as far as I can see there is no definition of 'endpoint' or how the
109 many different ... Endpoints are to be identified between the two 109 many different ... Endpoints are to be identified between the two
110 gateways. Is this information meant to be included in the 'transfer 110 gateways. Is this information meant to be included in the 'transfer
111 context' as defined in 5.3.6? 111 context' as defined in 5.3.6?
112 112
113 8.4. and others
114
115 8.3. and 8.4. define the *Transfer Proposal Message* and *Transfer
116 Proposal Receipt Message*. There are a number of message pairs with
117 similar pairs of names, with the second part being variously named
118 ... Receipt Message or ... Response Message.
119
120 Language along the lines of "The message is sent from the [recipient
121 gateway] to the ... EndPoint at the [sender gateway]" appears in
122 many if not all of them
123
124 It's never made clear if this just e.g. requires *Transfer Proposal
125 Receipt Message* as the form which the HTTPS response body should
126 adopt when responding to an HTTPS POST request in the *Transfer
127 Proposal Message* form or, as I read it at first, actually means a
128 _seperate_ HTTPS POST request in the *Transfer Proposal Receipt
129 Message* format is sent from the recipient gateway.
130
131 That is, are we being told about a single HTTPS exchange, or two?
132 Or is the intent to allow for either? I think either at the
133 beginning of section 8, or somewhere earlier, perhaps section 6,
134 this should be explained. Indeed Figure 2 in section 6 might
135 encourage one to think that the Transfer Proposal exchange requires
136 one HTTPS exchange, whereas the Lock Assertion exchange involves
137 two.
138
139 11.
140
141 The discussion of time-outs and aborts leaves it unclear whether a
142 gateway which times out waiting at some point in a session should
143 send a session-abort-msg or not, but I would think it should.
144
145 Note that the phrase "time-outs due to gateway crashes" doesn't make
146 any sense: from the point-of-view of a gateway (G1) which times out
147 waiting for a response, there is no way to detect the _reason_ for
148 the timeout. In case a timeout is _not_ because of a crash on the
149 part of the other gateway (G2), surely notification that the session
150 is being terminated by G1 should be sent, to enable an orderly
151 close-down by G2, instead of it having to time-out itself.
152
113 *Nits* 153 *Nits*
114 154
115 3. 155 3.
116 156
117 Since you use them both, I suggest including the ARCH definitions of 157 Since you use them both, I suggest including the ARCH definitions of
118 'originator' and 'beneficiary' here. 158 'originator' and 'beneficiary' here.
119 159
120 5.3.15 160 5.3.15
121 'immobile' => 'immobilize' [twice] 161 immobile => immobilize [twice]
122 162
123 'uses Hashed Time-lock' => 'use Hashed Time-lock' 163 'uses Hashed Time-lock' => 'use Hashed Time-lock'
124 164
125 8.1., 8.2., 8.6., 9.1, 10., 11.3., 11.4. 165 8.1., 8.2., 8.6., 9.1, 10., 11.3., 11.4.
126 166
135 11.3. 175 11.3.
136 176
137 The example JSON is missing a comma after 177 The example JSON is missing a comma after
138 "urn:ietf:params:satp:core:msgtype:transfer-proposal-msg" 178 "urn:ietf:params:satp:core:msgtype:transfer-proposal-msg"
139 179
140 12. 180 11.3.
181
182 errror => error
183
184 11.4.
185
186 I think *Protocol Error Codes* would be better...
187
188 11.5.
189
190 'maybe' => 'may be'
191
192 12.
141 193
142 'such a' => 'such as' 194 'such a' => 'such as'
143 195
144 15.1 196 15.1
145 197