Apologies for the delayed response--the day job got in the way this week.
Comments inline:
On Mar 12, 2012, at 12:16 PM, 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.
I assume you meant 301 and 307.
I note that all of the 3XX responses have their semantics explicitly described
in httpbis. While some reference other 3XX codes to contrast the behavior, none
seem to be defined in terms of each other. The 301 definition includes an
explicit note about the POST to GET behavior. The 307 definition includes an
explicit post about that behavior not being allowed. Section 3 of this doc does
neither.
Looking further, I see that both the 301 and 307 definitions have different
language about the response payload (they say if the method was not HEAD the
payload SHOULD contain short hypertext note, while this doc says the payload
can contain one. (which I read as equivalent to a MAY).
Finally, both 301 and 307 contain a paragraph about automatic redirection for
"safe" methods.
-- 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>.
HTTPbis sections 7.3.2, 7.3.3, 7.3.4, and 7.3.8 all contain explicit language
or notes about about GET and POST. I recognize that it is not stated
_normatively_ in each case, but it's at least mentioned.
-- 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.
I concur that it says that. I find it unfortunate that HTTPbis used
non-normative language there, but the text in this draft is consistent.
-- 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.
You are correct.
-- 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.
A comment to that effect in the text would be helpful.