Re: [OAUTH-WG] AD review of draft-ietf-oauth-revocation-06

Hi Stephen,

I just posted a new revision of the draft 
(http://tools.ietf.org/html/draft-ietf-oauth-revocation-07). I tried to 
address all the issues you raised (see below).

Am 09.04.2013 19:27, schrieb Stephen Farrell:
> 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.

adjusted wording to "upon receipt of an HTTP 200 response from the server"
> 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?

Added:
If the server responds with HTTP status code 503, the client must assume 
the token still exists and may retry after a reasonable delay. The 
server may include a "Retry-After" header in the response to indicate 
how long the service is expected to be unavailable to the requesting client.

>
> (2) 2.2: what's in the response body with a 200 response?  If it
> doesn't matter please say so.

Added:
The content of the response body does not matter as all information is 
conveyed in the response code.
>
> 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.

Assuming you meant 6749 I changed it to "application"
>
> - section 2: the "MAY include a query component" is sort of
> dangling there, maybe it'd be better moved elsewhere?

As Justin pointed out, the place is ok. I tried to improve wording a bit.

"The client requests the revocation of a particular token by making an 
HTTP POST request to the token revocation endpoint URL. This URL MAY 
include a query component."
>
> - 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.
done
>
> - 2.1: ought there be a registry for token_type_hint values? It
> looks like maybe there ought be.

Added registry in Section 5.1.2
>
> - 2.1: "A client compliant with [RFC6749] must be prepared" was
> that meant to be a 2119 MUST?
yep, changed it.
>
> - section 6: maybe s/shall/need to/ in the last para
done

regards,
Torsten.
>
> Cheers,
> S.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth