Re: Straw-man charter for http-bis

On 6/1/07, Mark Nottingham <mnot@mnot.net> wrote:
>
>
> > If, for some unforeseen reason, I am unable to make those drafts
> > happen, then nothing on your charter schedule needs to change.
> > If the WG chooses not to adopt the changed drafts after they
> > have been reviewed, then so be it.  I just don't want to burn
> > the time editing the drafts only to have someone declare
> > discussion of them to be out of scope.
>
> My personal preference would be to make a decision beforehand; a well-
> scoped charter can be frustrating, but it can also prevent many
> ratholes. Knowing what they're getting into raises people's comfort
> level considerably.

I think Roy's suggestion fits well within the charter you've just sent
out, which doesn't restrict the amount of editing that can be done.
The debate centers on the best way to *describe* HTTP 1.1 in a timely
manner. This is a good argument to be having. Perhaps people should
suggest concrete changes to the charter text instead of merely stating
their opinions. Seems to me like we need some text that states what we
don't have to accomplish regarding authentication, and some text that
explicitly allows large scale editorial changes.

> If you can get a draft in before Chicago, we could discuss it there
> and either get them built into the WG's scope, or decide that they're
> already within it, or even base the charter on your document.

That would be great, but it's a lot of work, and that's a tight
deadline. An outline sent to the list before the meeting would be
enough, I think.

> > BTW, structural changes have to be done first, using 2616 as
> > the basis.  There is no point of reviewing diffs of 2616 when
> > nobody bothers to read 2616 as a whole.  Diffs after restructuring
> > can then be viewed in their proper context, with all of the relevant
> > requirements in the same comprehensible space.
>
> That makes it seem that you're thinking of something more substantial
> than a straight rearrangement.

That's exactly the argument. If a "more substantial" rewrite does a
better job of documenting HTTP, we should consider it. This
possibility shouldn't cause discomfort, because our shared goal is to
accurately document HTTP 1.1, right?

On 6/1/07, Keith Moore <moore@cs.utk.edu> wrote:
>
> so basically if you argue that the HTTP spec is so bad that a major
> rewrite is needed, you're also arguing for
> the rewritten HTTP spec to have a Proposed Standard status.  (as was
> done for [2]822 and SMTP).

Personally, I don't care what color ribbon our pig wins at the county fair. :)

On 6/1/07, Keith Moore <moore@cs.utk.edu> wrote:
>
> is this because implementors tried to read the existing HTTP spec and
> failed to grasp it, or because they didn't even bother trying to read
> the spec?

Here's a concrete example:

<http://skrb.org/ietf/http_errata.html#post>

I am sick of questions about this from people who have only read
RFC2616. It's a waste of my time and theirs.

-- 

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

Received on Friday, 1 June 2007 15:09:30 UTC