Re: any more comments?

OK, so let's stipulate that it takes an 8 dimensional table to 
*completely* describe HTTP as a table.

I wasn't suggesting that the complete table needed to be constructed, 
or that it would be an alterative to the current spec.

If one did construct it, one would notice that a lot of spatially 
nearby entries were the same. One would assuredly want to 
compress/flatten these: what you call "conditional statements". The 
question is, what's the clearest way to do it?

I was suggesting some extra info, in each subsection of section 5.2.x, 
the ones where the methods are described, that would be a little more 
explicit than the current spec about the allowable header fields and 
entity information in each direction.

Let me try to motivate this. Take GET as an example. Is there ever an 
entity-header or entity-body in a GET request? Normally, one would 
expect not -- it doesn't seem to make sense. But are there edge cases, 
clever uses, or whatever, where practitioners have come up with a use 
that implementors are expected to know about? For someone coming fresh 
to the spec, like me, who hasn't implemented HTTP clients or servers, 
the answer isn't easy, and I believe that it is not explicit anywhere 
in the current spec.

Other examples: are accept* header fields legal in POST, PUT, DELETE, 
LINK, UNLINK request headers? Are entity bodies allowed in responses to 
these methods? (I think the answer to the first question is "no", and 
to the second is definitely "sometimes, depending on status code".)

The form of the "man page" that Howard provided could answer many of 
these questions quickly and definitively. As Roy points out, there are 
still questions that it can't answer. These could be flagged, to refer 
to the detailed writeup elsewhere in the spec.  To take the GET x 304 
example, either a note by the 304 entry saying its only legal if IMS 
was specified, or simply a "*" to indicate that the reader needs to go 
to the section on the 304 status code (6.2.3).

I would estimate that such a description for one method would be about 
30 lines or so, times 6 methods.  I believe that it would be useful.  
If there are enough people who agree, I volunteer to produce them so 
that the rest of the list can see if there's consensus to include them 
-- if not in the main body, then perhaps as an appendix. I will do this 
by next Monday if the feedback comes in positive today or tomorrow.

Paul
----------
] From: Roy Fielding  <fielding@beach.w3.org>
] To: Howard Melman  <melman@osf.org>
] Cc:  <netmail!http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
] Subject: Re: any more comments?
] Date: Thursday, August 24, 1995 12:20AM
]
	[excisions...]

] For example, (GET x 304) is only possible if (GET x IMS),
] yet that information is not describable by the format above.
]
] Now, the choice is either enumerate all possibilies (which would
] make the spec several hundred pages long) or include conditional
] statements within a sparse table (which is exactly what the current
] spec is).
]
] The reason people must read every line of the spec carefully in
] order to determine what is and what is not defined is because
] the entire spec is the defintion of that table of defined
] behavior -- leave a line out, and you do not define HTTP.
]

Received on Thursday, 24 August 1995 11:05:45 UTC