- From: Jim Davis <jrd3@alum.mit.edu>
- Date: Tue, 04 Jan 2000 14:16:48 +0100
- To: w3c-dist-auth@w3.org
At 11:50 AM 1/3/00 -0800, Yaron Goland wrote: >...Let us first see if we can establish agreement on some very basic >precepts. I will start with just one precept and see if we can get agreement >on just that... This is a good strategy to clarify the issues. But there are two things I am unclear on. First is procedural. RFC 2518 exists, and has a fixed and known set of authors. When we have discussions like this, is the underlying assumption that the conceptual model of RFC 2518 was either unclear, internally inconsistent, or mistaken (perhaps because it can't be extended to support new ideas like BIND?) another way to say this, are we trying to retroactively induce a consistent conceptual model for something that already exists, or design something for the future. Second concerns Precept #1 > >Precept #1 - HTTP clients send HTTP request messages to resources that >respond with HTTP response messages. This seems reasonable, but there is at least one alternative. Precept #1a - An HTTP client sends an HTTP request message to a server (which is a process running on a specific host at a specific port). The server interprets the URL in the request. If the URL identifies a resource, the server relays the method to the resource. If not, server interprets the method. For some methods, a 404 is issued. For others, something else happens. What that something else is depends, on a case by case basis. This precept is more complicated, but does not require the ficticious "null resource" neeed in Corollary #1.3 >Corollary #1.3 - Since HTTP request messages can only be handled by >resources which respond with HTTP response messages then even error messages >such as "Not Found" must have been generated by a resource. I have no position on whether 1a should be prefered to 1, nor do I claim that this is the only other alternative to #1.
Received on Tuesday, 4 January 2000 09:01:35 UTC