WARNING: This server is unstable and will be retired in the next days.
If you want to keep this forum available, please request immediately a migration
on the Nabble Support forum.
Forums that don't receive any migration request will be deleted forever.
> 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.
>> Major issues:
>> 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
>> -- 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:
> 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
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.