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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf