Hi William,
sorry for my very late reply. I must have missed this update and just
finally some had time to look through my open discusses. Thanks for
addressing my comments quickly and adequately; I just cleared my discuss.
Regarding the last point below, I think if that is an optimization the
MAY is okay.
Thanks and sorry again for the late response!
Mirja
On 02.08.18 02:24, William Denniss wrote:
Mirja,
Thanks for your feedback. Version 12 has been posted which
incorporates much of your feedback. Replies inline:
On Tue, Jul 24, 2018 at 11:50 AM, Mirja Kühlewind <i...@kuehlewind.net
<mailto:i...@kuehlewind.net>> wrote:
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
Please specify more clearly the (default) polling behavior to
ensure that the
polling does neither overload the network, nor the server, or is never
terminated. Ideally provide default values and an upper bound for
the polling
frequency, as well as a timer to terminate polling if no reply is
received (and
no expiration time is given). See further details below.
1) Sec 3.3: "until the user completes the interaction, the code
expires, or
another
error occurs."
What if not expiration time is given (as this optional) and no
reply is ever
received?
The expiration time is now required.
2) Sec 3.5: "the client should stop polling and react accordingly, for
example, by displaying an error to the user."
Maybe:
"the client MUST stop polling and SHOULD react accordingly, for
example, by displaying an error to the user."
Added, thanks!
3) sec 3.5 "If no interval was provided, the client
MUST use a reasonable default polling interval."
Can you please provide a default number for a "reasonable" polling
interval!
And in best case an upper bound!
We set a default of 5 seconds.
4) sec 3.5: "...increasing the time between polls if a
"slow_down" error is received. "
Maybe use a separate normative sentence instead:
"The client SHOUD increase the time between polls if a
"slow_down" error is received."
Or MUST? If so how much? Can you given further (default) guidance.
We now document that every slow_down message should increase the
interval by 5 seconds.
5) sec 3.5: "Clients MAY then choose to
start a new device authorization session."
Maybe make it clear that polling is stopped
"Clients MUST stop polling but MAY then choose to
start a new device authorization session."
This was revised, thank you!
6) sec 3.5: "then the
device MAY wait until notified on that channel that the user has
completed the action before initiating the token request."
Why not SHOULD (or MUST) here?
This is a non-normative discussion of a potential optimization,
perhaps we should drop the normative keyword completely?
The reason MAY was chosen is that the client would be free to follow
the rest of this document which allows for polling.
Best,
William
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
