Hi Torsten, That's great thanks.
We're still after a mail from Marius ack'ing no IPR. Be nice to get that. I'll ask for IETF LC in a day or so in case the WG have anything to say, but a couple of follow-ups below that you can take as LC comments from me. On 04/15/2013 09:09 PM, Torsten Lodderstedt wrote: > 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. I think it'd be worth looking at other HTTP consuming specs and maybe asking some folks about that. I suspect you might need to say 5xx rather than just 503 and "reasonable" is gonna set off transport area alarms bells probably. > >> >> (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 I'd encourage WG participants to check that and see what they think. We can fix it (if needed) after IETF LC. Cheers, S. >> >> - 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 > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
