Re: Round 2: moving HTTP 1.0 to informational

>  This specification is for informational purposes only. It reflects the
>  consensus of the IETF HTTP Working Group about which features would
>  normally be found in an HTTP/1.0 implementation. These features are
>  split into two sections. The features for which there was strong
>  consensus about how they are implemented, as well as implementations
>  of the features, are listed in the main body of this document.
>  Features for which there was not strong consensus, or for which there
>  were few implementations, are listed in Appendix D.

I wish I felt more confident that there was consensus on the exact
status of each individual feature as to whether it appears or doesn't
normally appear in an HTTP/1.0 implementation. However, I don't think
we have this consensus, would not want to pass the draft on to the
IESG with this wording without obtaining it, and do not think we
require it for an informational document. In any case, the IETF process
does not require consensus but only 'rough consensus', and I'd hate to
see you put *that* in the draft.

Thus, I'd like to see the wording about 'consensus of the IETF HTTP
Working Group' softened if not removed. I suggest:

#  This specification reflects the approximate state of those features
#  which are normally found in most HTTP/1.0 implementations. The
#  specification is split into two sections. Those features of HTTP
#  for which implementations are usually consistent are described in
#  the main body of this document. Those features which have few
#  implementations or inconsistent ones are listed in Appendix D.

To go through line by line: 'This specification is for informational
purposes only'  is added by the standard boilerplate when a document
becomes an Informational RFC. The 'features' aren't split into
sections, the document describing the features is split. (You could
say that the features are split into two groups, but the groups aren't
important, it really is a property of the document.) The attribute of
features that puts it in the first group is that they are consistently
implemented. That we come to consensus about that fact isn't the
relevant criteria; i.e., if a reviewer wanted to object to the draft
because a feature wasn't consistently implemented, we should accept
that criticism, even though the working group might have come to
agreement by all being wrong about the facts. Similarly, the features
that appear in Appendix D do so because implementations vary, and not
because we disagree.
	
> The URI in a POST request identifies the resource that will handle
> the enclosed entity as an appendage.

I know this language has been there forever, but 'as an appendage'
doesn't really correspond to what people do with POST.

The data sent with a POST usually corresponds to information that
results from an HTML form. I actually can't think of any other
application.  Are there in fact any applications that POST anything
other than form data? I'd suggest:

# The URI in a POST request identifies the resource that will handle
# the enclosed entity as data to be processed, e.g., values from a
# form that has been filled out.

Received on Monday, 8 January 1996 20:26:24 UTC