Subject: [Gen-art] Gen-ART LC/Telechat review of draft-reschke-http-status-308-05

From: Ben Campbell <[email-masked]>
Date: Mon, 12 Mar 2012 11:15:25 -0500

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:

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?)

-- 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.

-- section 3, 1st paragraph: "Clients with link-editing capabilities ought to..."

Should that be stated normatively?

-- 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?

-- 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?

Nits/editorial comments:

None

---

From: Julian Reschke <[email-masked]>
Date: Mon, 12 Mar 2012 18:16:21 +0100

> 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.

> -- 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…

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.

> 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>.

> Should that be stated normatively?

No. Again, this is consistent with the text in HTTPbis for status code 302.

> 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 _in…

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.

> 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>.

Best regards, Julian

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 12 Mar 2012 11:48:26 -0600

On 3/12/12 11:16 AM, Julian Reschke wrote:
>> 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 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.
> 
>> 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?
> 
>> 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?
> 

<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/

---

From: Julian Reschke <[email-masked]>
Date: Mon, 12 Mar 2012 19:38:07 +0100

On 2012-03-12 18:48, Peter Saint-Andre wrote:
> ...

Done; I usually avoid changing drafts during LC; but I think it makes 
sense in this case.

Best regards, Julian

-- 
<green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
Amtsgericht Münster: HRB5782

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 15 Mar 2012 10:29:14 -0600

Hi Ben,

Do Julian's comments or the changes in version 06 address your concerns?

Peter

On 3/12/12 11:16 AM, Julian Reschke wrote:
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Ben Campbell <[email-masked]>
Date: Fri, 16 Mar 2012 16:06:04 -0500

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:

> 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.

> 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.

> 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.

> Again, consistency with RFC 2616 and HTTPbis.

You are correct.

> 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.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 16 Mar 2012 16:07:53 -0500

> Do Julian's comments or the changes in version 06 address your concerns?

Apologies for the late response. Please see my separate response to Julian. But also keep in mind that I don't think any of these items necessarily need to be showstoppers for an _experimental_ RFC.

Thanks!

Ben.

---

From: Julian Reschke <[email-masked]>
Date: Sat, 17 Mar 2012 10:21:05 +0100

> I assume you meant 301 and 307.

Yes.

> 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 ot…

The note in 307 was written to point out that the equivalent (308) is 
not defined in HTTPbis. That's why the equivalent text is not on the 
definition of 308.

But you are right in that it provides additional information not present 
in the statement for 308, and I can fix that.

> Finally, both 301 and 307 contain a paragraph about automatic redirection for "safe" methods.

Both of this is not true anymore in draft -19 of httpbis, where all 
these statements have been moved to the introduction of the redirect codes.

>> 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>.
>

7.3.2 (301), 7.3.3 (392) and 7.3.4 (303) have these notes because they 
are exceptions. Re: 7.3.8: see above.

> A comment to that effect in the text would be helpful.

I disagree with this. It's an example for a deployment strategy that can 
help in the short term. That's all.

Best regards, Julian