RE: Specification Guidelines

Headers Vs. Body - I will be revisiting this issue in detail when I
respond to Jim's mega post.

Why This Spec Exists - Absolutely, and you have already agreed to be the
editor! =)

Watertight Specs - We're six versions in and we still don't have a clear
spec. I think one more unified spec should be released in order to make
absolutely sure we understand how the various parts interact and then we
should split the spec to allow for faster movement. I believe we can
close down on the distributed authoring issues much faster than the
versioning issues.

		Yaron

> -----Original Message-----
> From:	Judith Slein [SMTP:slein@wrc.xerox.com]
> Sent:	Friday, February 07, 1997 7:05 AM
> To:	Yaron Goland
> Cc:	'w3c-dist-auth@w3.org'
> Subject:	RE: Specification Guidelines
> 
> At 08:43 PM 2/6/97 PST, Yaron Goland wrote:
> >Judith, why does all of your mail come from
> >w3c-dist-auth-request@w3.org?
> 
> I have no idea.  Stuff from the mailing list always gets routed to me
> through w3c-dist-auth-request as well.
> 
> >
> >1. If we decide that we want to try to stay within the HTTP
> framework,
> >can
> >we try to model our spec on the HTTP 1.1 spec?  We could still keep
> the
> >functional divisions we have in the current spec, but within each
> >division,
> >assume HTTP request and response syntax and have a section on new
> >methods, a
> >section on new status codes, and a section on new headers.  Hopefully
> >there
> >wouldn't be any new MIME types, but if there are, then a section on
> new
> >MIME
> >types; and if there are any new name spaces, a section discussing
> them.
> >
> >The previous proposal only makes sense if we are going to continue
> using
> >bodies w/methods. If we intend to switch to a header only format then
> we
> >will be required to use method specific headers and those should
> clearly
> >not be in a section separate from the method definitions. What is the
> >group's feelings on the issue of body vs headers?
> 
> I favor headers, and don't have a strong feeling about where they
> should be
> defined.
> 
> >
> >3. Add a section on why this spec is needed anyway.
> >
> >I disagree. If the use of the protocol is not self evident then it is
> a
> >badly designed protocol.
> 
> I do think such a section is extremely useful.  I've been looking
> through
> attribute-related specs the past few days, and I've been very grateful
> to
> authors who say on the first page what problems they are trying to
> address,
> so that I don't have to read the rest of the spec if their problem set
> is
> different from mine.
> 
> >
> >As for your other points, I basically agree. The current spec is a
> mess
> >but that was to be expected. The authors severely screwed up their
> >scheduling and didn't give themselves enough time to prepare the spec
> >before the meeting. We shall not repeat that error.
> >
> 
> You did a huge amount of work, and I'm sure no one faults you for not
> having
> a polished, watertight spec in time for the Irvine meeting.  Thanks
> for all
> you've done!
> 
> --Judy
> 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 Friday, 7 February 1997 23:59:15 UTC