Why is Message-ID header in HTTP?

Message-ID seems to me to be out of place as an HTTP header. I think it should 
be removed, and if there is any existing use problem that needs to be 
described, do this in an appendix treating it as an extension-header.

Here is the reasoning that prompted this; quoted text is from Section 4.3.3 of 
draft-ietf-http-v10-spec-00.

   The Message-ID field is normally not generated by HTTP applications 
   and is never required.

This seems to be suggesting that Message-ID does not really belong in HTTP.

                          It should only be generated by a gateway 
   application when the message is being posted to some other protocol 
   that desires a Message-ID.

The word "only" is notorious for introducing ambiguity so I shall start with 
alternative wordings that I hope clarify the possible meanings.

(1) "It should be generated only by a gateway application, and only when the 
message is being posted to some other protocol that desires a Message-ID." If 
this is the intended meaning then Message-ID exists only in the "other 
protocol" and does not occur on the HTTP side of the gateway.

(2) "A gateway application should generate it only when the message is being 
posted to some other protocol that desires a Message-ID." For gateways the 
situation is as for (1), but this wording leaves more scope for things that 
are not gateways to use Message-ID in HTTP.

I assume that (2) is closer to the intended meaning, and that the idea is that 
non-gateway applications that are aware both of the other protocol and that 
they are using HTTP to interact with a gateway, will insert Message-ID headers.

                              HTTP responses should only include a 
   Message-ID header field when the entity being transferred already 
   has one assigned to it (as in the case of resources that were 
   originally posted via Internet Mail or USENET).

(Move "only" immediately before "when" to avoid the silly but possible 
"include nothing but" meaning.)

This seems to support the idea of an application that is aware both of the 
other protocol use of Message-ID and that the message is being delivered by a 
gateway.

This suggests that the other protocol message is being transmitted with its 
body as the HTTP message entity, and at least one of its headers merged with 
the HTTP headers. Why single out Message-ID for this special attention? In 
general there are several headers that need to be passed on, depending which 
protocol is involved. Receiving Mail or News in an HTTP response is going to 
be difficult unless the From header is reclassified as a general header, and 
the conflicting use of Date is resolved (it cannot be both the Date from the 
original message and the date/time at which the status line was generated).

Given these problems, sending and receiving message/* entities looks like a 
more stable strategy for gateways to other protocols. It has the great benefit 
that it does not try to push HTTP into being the union of all other protocols 
that use RFC822 style headers.

Regards,
  Owen Rees <rtor@ansa.co.uk>
Information about ANSA is at <URL:http://www.ansa.co.uk/>.

Received on Monday, 20 March 1995 07:06:38 UTC