On 3/12/12 11:16 AM, Julian Reschke wrote: > On 2012-03-12 17:15, Ben Campbell wrote: >> I am the assigned Gen-ART reviewer for this draft. For background on >> Gen-ART, please see the FAQ at >> < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >> >> Please wait for direction from your document shepherd >> or AD before posting a new version of the draft. >> >> Document: draft-reschke-http-status-308-05 >> Reviewer: Ben Campbell >> Review Date: 2012-03-12 >> IETF LC End Date: 2012-03-16 >> IESG Telechat date: 2012-03-15 >> >> Summary: This draft is basically ready for publication as an >> experimental RFC. I have a few minor comments that might be worth >> considering whether they would improve the document prior to publication. >> >> Note: Since this draft is on a Telechat that precedes the end of the >> IETF Last Call, this review serves as both the LC and Telechat review. > > Thanks. > >> Major issues: >> >> None: >> >> Minor issues: >> >> -- General: I see some discussion about existing UA behavior, but >> nothing about what a UA should do with a 308 other than as an >> implication the fact that this is a "permanent version of 307". It's >> probably worth describing that explicitly. (Or is that what the >> "clients with link-editing capabilities" statement is intended to >> do?If so, does that cover everything?) > > The draft uses *exactly* the same words as the base spec (HTTPbis), > except that it combines aspects of 302 (permanence) with those of 307. I > thought that's clear enough. > >> -- section 1, last paragraph: >> >> The fact that a 308 can't change the method is left as an implication >> of being based on 307. It would be good to state that explicitly and >> normatively here. > > We don't state it in HTTPbis either. 301, 302, and 303 are exceptions. > See the new introduction in > <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-18.html#rfc.section.7.3>. > > >> -- section 3, 1st paragraph: "Clients with link-editing capabilities >> ought to..." >> >> Should that be stated normatively? > > No. Again, this is consistent with the text in HTTPbis for status code 302. > >> -- section 3, third paragraph: "The new permanent URI SHOULD be given..." >> >> I'm curious why that is not a MUST. Is there a reasonable (i.e. >> interoperable) way to send a 308 _without_ a URI in the location >> field? Is the meta refresh directive something that can be used >> _instead_ of the Location header field? > > Again, consistency with RFC 2616 and HTTPbis. > >> -- section 4: >> >> The example uses _both_ the location field and the HTML<meta> refresh >> directive. Is this considered a recommended practice to the degree you >> might normatively recommend it in the text? > > No, it's a hack that makes deployment easier until all UAs do the right > thing; we don't want to make that permanent. > >> Nits/editorial comments: >> >> None > > Note that I have an updated version waiting to be submitted in two weeks > (or earlier, if the AD allows me to). It updates references, and adds an > informative ref to the HTML spec, as suggested during LC. See > <http://greenbytes.de/tech/webdav/draft-reschke-http-status-308-latest.html>. <hat type='AD'/> Julian, I think it would be helpful for you to submit your latest copy before the deadline today, so that we don't need to wait until March 26. Peter -- Peter Saint-Andre https://stpeter.im/ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf