(Note the distribution change: added iesg, dropped the http list and
ietf general.)
When we talked about and implemented the status-change document type,
its purpose was to create a ballot-able artifact of the IESG's decision
to reclassify an RFC without republishing it. This improved our
transparency in a way we couldn't achieve with drafts, and avoided the
confusion that occurred when we apparently LCed an RFC.
Trying to use it to document a decision to republish an RFC with minor
changes (even if they are just to boilerplate) goes beyond that design,
and IMHO exposes us to a significant potential for unanticipated process
pitfalls.
Drafts are the tool to use when the bits in the document need to change.
As a separate, and lesser, point about Experimental->PS in general (this
is not an issue with this particular document) - feeling comfortable
with republishing an experimental document as PS without changing any of
the words in the document is probably a warning sign that the conditions
that warranted publishing the document as experimental in the first
place were insufficiently captured.
RjS
On 12/11/14 9:37 AM, Robert Sparks wrote:
-------------------------------------------------------------------
I am the assigned Gen-ART reviewer for this
draft^H^H^H^H^Hstatus-change. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: status-change-http-status-code-308-ps-01
Reviewer: Robert Sparks
Review Date: 11 Dec 2014
IETF LC End Date: 29 Dec 2014
IESG Telechat date: Not yet scheduled for a telechat
Summary: While 308 should move to Proposed Standard, this
status-change document has serious issues, and should be reconsidered.
Major issues:
There is a conflict between this status-change document's statement
that "the experiment is, therefore, over, and was a success" and the
instructions to republish RFC7238 without change except to the
boilerplate.
The status-change document argues that the successful implementation
of 308 in the vast majority of deployed browsers is sufficient to end
the experiment.
If so, the guidance in a republished RFC7238 section 4 would be
unclear (and inappropriate for general deployment on the Internet).
Isn't the restriction in the second paragraph the essence of the
experiment?
Specifically:
"Therefore, initial use of status code 308 will be restricted to cases
where the server has sufficient confidence in the client's
understanding the new code or when a fallback to the semantics of
status code 300 is not problematic."
The intent of this status change is to move us past this "initial use"
and loosen this restriction on application deployment is it not?
While I support moving 308 to Proposed Standard, I don't think this is
the right way to do it, and recommend a draft that updates section 4
instead.
(It might be tempting to address this (if people agree with it) by
adding an RFC Editor note to the status-change rather than using a
draft. Please don't.)
RjS
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
