Re: v10-spec-00 comments

> Comments on draft-ietf-http-v10-spec-00. The comments on Accept, Message-ID 
> and Version are more important than the others.
> 
> 3.2 Universal Resource Identifiers
> 
> Should refer to RFC1738 as the standard for URLs including the http scheme, 
> escaping rules and allowed characters.

RFC1738 is not yet a standard, but it will indeed be referenced in that
section.  RFC1738 does not fully define http URLs -- it assumes that
they will be defined within the HTTP specification.

> 3.3.1 Full Date
> 
> RFC 1123 (5.2.14) says:
>         "There is a strong trend towards the use of numeric timezone
>          indicators, and implementations SHOULD use numeric timezones
>          instead of timezone names.  However, all implementations MUST
>          accept either notation."
> "+0000" should at least be permitted as an alternative to "GMT" in the 
> "updated by RFC 1123" case.

I have received two comments to that effect.  Since HTTP has never allowed
"+0000" and no application uses it, I will not put it in the HTTP/1.0 spec.
However, we can talk about it for 1.1.

> 4.3.2 Forwarded
> 
> The final sentence about hiding internal hosts should say that existing 
> Forwarded headers (added by proxies inside the firewall) should be removed.

okay

> 4.3.3 Message-ID
> 
>   The first paragraph specifies that this is a unique identifier for the 
> message, presumably the HTTP request or response message. The final paragraph 
> says that an HTTP response should only include a Message-ID header if the 
> entity has one. Since it is possible to retrieve a Mail/News message more than
> once, the HTTP Message-ID cannot be the Message-ID of the enclosed entity as 
> this would violate the unique identification property for the HTTP response 
> message.

No it would not.  There is only one message in that case.  This situation
is identical to the handling of messages by proxies.

> My preferred solution is to remove Message-ID from HTTP altogether, but if it 
> is retained it cannot be both a unique identifier for an HTTP message and 
> imported from Mail/News/etc. by a gateway.

It can if the HTTP server is a gateway to Mail/News/etc.

> 4.3.4 MIME-Version
> 
> I would have classified this as an entity-header rather than a general-header.

It has nothing to do with the entity -- only the message syntax.

> 7.1.1 Allow
> 
> I would have classified this as a response-header rather than an 
> entity-header; it is required with 405 Method Not Allowed and will not be 
> meta-information about the entity containing an explanation of the error.

Unless it is included in a PUT or POST of a new resource.

> 7.1.14 Version
> 
> "A user agent can request a particular version of an entity by including its 
> tag in a Version header as part of the request." How should Version be 
> interpreted in a POST request? It could refer either to the version of the 
> entity, or to the version of the resource to which the entity is to be made 
> subordinate. What is the existing practice in this case?

It should be interpreted as the suggested version of the entity.
The above quoted sentence will be changed to refer only to non-content
requests.


 ....Roy T. Fielding  Department of ICS, University of California, Irvine USA
                                       <fielding@ics.uci.edu>
                      <URL:http://www.ics.uci.edu/dir/grad/Software/fielding>

Received on Thursday, 23 March 1995 22:36:23 UTC