Hi all,
Please, see below my comments to -02.
Best,
Marco
[Section 5]
* In Section 5.1, the steps from 1 to 6 show the actions performed by the
Authorization Server each time the TRL changes. I suggest to complete the
list of actions by adding a last step saying something like this:
7. The Authorization Server notifies the observers with a response
compliant to their original request. It can be either a diff query or a
diff query with 'cursor'.
[Section 7]
* In Figure 7, would it be worth specifying that the Authorization Server
producing the response does not support the "Cursor" extension?
It has to be so since 'cursor' and 'more' are not included in the response.
[Section 8]
* Consider changing Section 8 title (i.e., "Using the "Cursor" extension").
That title, according to my understanding, refers mainly to the
Authorization Server and the responses it produces when supporting the
"Cursor" extension.
An Authorization Server supporting the "Cursor" extension always includes
'cursor' in full query responses and both 'cursor' and 'more' in diff query
responses, even if the request does not contain the 'cursor' parameters,
according to Section 8.2.1. A requester not supporting the "Cursor"
extension will silently ignore 'cursor' and 'more'.
Therefore, I would suggest changing the title of Section 8 to clarify that
the discussion is about an Authorization Server supporting the "Cursor"
extension.
* In Section 8.2.3., I would extend the sentence:
"... When receiving this diff query response, the requester should send a
new full query request to the Authorization Server, in order to fully
retrieve the current pertaining portion of the TRL."
with:
"as well as a valid value of cursor, as specified in Section 8.1.".
After all, the main reason why the requester is making a full query request
--in this specific case--, is to learn the value of LAST_INDEX. Then, it
can use that value, or a value in the range [LAST_INDEX < N_MAX ? 0 :
LAST_INDEX - N_MAX, LAST_INDEX] to perform a new diff query request with
'cursor'. In such a case, the Authorization Server will process a request
as per Case B of Section 8.2.3.
[General]
* Following the reasoning at the previous bullet point, I noticed a
probably unwanted behaviour of the mechanism:
A requester can never obtain the first diff entry (the one with 'index'
equal to 0) if it specifies 'cursor'.
Accepted values for 'cursor' are 0 and positive integers, as per Section
5.2, bullet point 'cursor'.
Moreover, when the Authorization Server receives a request including
'cursor' with value P, the first diff entry (if any) it includes in the
response is P+1, as explained in Section 8.2.2.:
"As defined in Section 8.2.3, this would result in the Authorization Server
transferring the following subset of series items as diff entries, thus
resuming from where interrupted in the previous transfer."
Having the first series item ever added to an update collection with
'index' equal to 1 would solve this behaviour, but it will probably require
modifications elsewhere.
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
