RE: Comments on Section 3 of the Requirements Document

Requirements documents are first and foremost goal posts. They defined
what success is, they do not define how to succeed. So while I think the
question of what we are going to do w/HTTP is critical, I do not believe
that discussion should be included in the requirements doc. The
requirements doc should state that we must use HTTP as our base but
where we take it is the whole point of this group.

As for when to discuss what we are doing to HTTP, I would strongly
suggest that we discuss this on a case by case basis. Simply stating
"free for all" or "no alterations" only guarantees that original ideas
will be killed.

	Yaron

> -----Original Message-----
> From:	Judith Slein [SMTP:slein@wrc.xerox.com]
> Sent:	Wednesday, February 12, 1997 8:34 AM
> To:	Yaron Goland
> Cc:	w3c-dist-auth@w3.org
> Subject:	Re: Comments on Section 3 of the Requirements Document
> 
> I'd like to see more discussion of whether we are extending HTTP, and
> if so
> what that means.  Both the charter and the requirements describe what
> we are
> doing as extending HTTP.  Maybe they should be changed to say
> something
> broader, like "make extended authoring capabilities available on the
> Web" or
> "on the Internet".  Or maybe we can be precise enough about what it is
> to
> extend HTTP that it becomes a clear design guideline.
> 
> At 05:05 PM 2/11/97 PST, Yaron Goland wrote:
> >	3.2. Legacy Client Support
> >
> >	WebDAV-compliant servers should be able to interoperate with
> >non-WebDAV clients.
> >
> >Without a careful statement of the ramifications of this requirement
> I
> >move that it be removed from the requirements.
> >
> >	3.4. HTTP Compatibility (new)
> >
> >	Our aim is to make extended authoring capabilities available
> >through
> >	HTTP.  In extending HTTP, we are obligated to follow its design
> >	conventions and stay within its spirit.  This means, for
> >example, that
> >	methods should operate only on resources.  It means that
> >parameters
> >	should be communicated in headers.  These and other conventions
> >should
> >	be observed in the design of the extensions.
> >
> >HTTP has a spirit? Who will interpret this spirit? HTTP is a
> >specification. Words written on a piece of paper. For us to declare
> that
> >we are somehow the keepers of the spirit of HTTP is absurd. Our only
> >obligation is to have this specification accepted by the IETF. If
> that
> >should require changing HTTP and the IETF buys off on the idea, then
> so
> >be it. We should not restrict ourselves when there is no compelling
> >reason to do so.
> >
> >			Yaron
> >
> >
> >
> Name:			Judith A. Slein
> E-Mail:			slein@wrc.xerox.com
> Internal Phone:  	8*222-5169
> External Phone:		(716) 422-5169
> Fax:			(716) 265-7133
> MailStop:		128-29E
>

Received on Wednesday, 12 February 1997 19:37:55 UTC