Hiya, On 04/12/2013 10:03 PM, Justin Richer wrote: > Hi Stephen, > > I didn't respond as I didn't have anything to add to your comments, but > what little details I have are inline.
Thanks:-) > On 04/12/2013 04:53 PM, Stephen Farrell wrote: >> Hi, >> >> I'm surprised there've been no responses. I thought >> there was more interest in this one. >> >> Ta, >> S. >> >> On 04/09/2013 06:27 PM, Stephen Farrell wrote: >>> Hi, >>> >>> I've done my AD review of this draft. I have two quick questions >>> I'd like to get answered before I start IETF LC. Depending on the >>> answers maybe we should re-spin or just fire ahead, let's see... >>> >>> (1) 2.1: "upon the return of the request" isn't right is it? I >>> think you mean the response at least. And what about HTTP error >>> handling? What if I get a 503 error? Is the client supposed >>> to re-send ever? Don't you need to say? > Should this read "upon receipt of an HTTP 200 response from the server" > instead? Seems like it needs some fix anyway. I'll mark the draft as revised I-D needed. > If there's a 503, the client can't assume the token is gone, > but it also probably shouldn't try spamming the endpoint, either. So what is a client supposed to do if it gets a 503? >>> (2) 2.2: what's in the response body with a 200 response? If it >>> doesn't matter please say so. > Doesn't matter. All information is conveyed in the response code. That'd be fine. But doesn't it need saying? Like I said the rest are nits. But to be clear: I think we (me and the WG) need to figure out the above before IETF LC starts. Cheers, S. > >>> >>> I see from the write-up one author hasn't confirmed there are >>> no IPR issues. I've sent a Marius a mail so hopefully we >>> can sort that as we go. >>> >>> I also have the following nits that can be fixed (if need >>> be) whenever the draft is next changed: >>> >>> - intro: "app" isn't really a great term to use, can you replace >>> with something from 6479. > "app" was chosen because the application to use here could be either the > Client or the Resource Server in RFC6749, so neither is really the right > fit. It's whoever's revoking the token. > >>> >>> - section 2: the "MAY include a query component" is sort of >>> dangling there, maybe it'd be better moved elsewhere? > Don't see where else this could fit. Basically we're saying the endpoint > URL can be defined as "/endpoint?type=revoke" just as easily as "/revoke". >>> >>> - section 2: "MUST be obtained from a trustworthy source." might >>> generate comment from IESG members who don't like using 2119 >>> terms in ways that don't affect interoperability. (I'm fine with >>> it fwiw, and have nearly cured 'em of that craze;-) Consider >>> s/MUST/need to/ here. > WFM. >>> >>> - 2.1: ought there be a registry for token_type_hint values? It >>> looks like maybe there ought be. > I think a registry is overkill for this kind of thing, but I suppose it > could be set up. It's meant to be a *hint* to the server as to what kind > of token it is. If it does get set up, the Introspection draft will use > it (if that ever can get either pulled into the WG or moved through as > an individual submission). > >>> - 2.1: "A client compliant with [RFC6749] must be prepared" was >>> that meant to be a 2119 MUST? > This is informative, not normative. You could easily replace "must" with > "needs to" here and get the same intended meaning, which is that tokens > can disappear when you're not looking. > >>> >>> - section 6: maybe s/shall/need to/ in the last para > > Same as above. > >>> >>> Cheers, >>> S. >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
