headers
Mark Nottingham | 1 Jun 02:57
Favicon
Gravatar

Re: Straw-man charter for http-bis

On 01/06/2007, at 8:59 AM, Roy T. Fielding wrote:

> It is not "if I don't get my way".  Who appointed you to be the
> determinant of group consensus in the first place?  I am not going
> to support an IETF working group that says "nobody is allowed
> to do a better job describing HTTP than what is in our charter."
> If you don't allow people to produce drafts, and allow the working
> group to evaluate those drafts on the basis of whether the contents
> are better or not, then all you are doing is dictating the content
> of the specification based upon some imagined position of authority.

You spoke about forking the HTTP spec if the IETF decided to go in a  
direction that you didn't like. Working outside the process is very  
different to working within it, whether that be in the charter  
discussions or the WG. Don't try to make this about me.

> So, you should decide whether your work item is to replace 2616
> or to produce a list of errata to be published in RFC form.  If it
> is the former, than I know a lot more about this subject than you
> and I know for a fact that just making small changes around the
> edges is not sufficient.

That's a naked appeal to authority, and I'll give it as much credence  
as it deserves.

> We already tried that twice.

I believe the circumstances are different; time changes things.

> If I make the real changes that are needed in draft form and submit
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Nottingham | 1 Jun 03:12
Favicon
Gravatar

Re: Straw-man charter for http-bis


On 01/06/2007, at 11:04 AM, Robert Sayre wrote:

> I don't understand why the two approaches are mutually exclusive. I
> think the best way to start is by doing exactly what has been done so
> far. I agree with Roy that we shouldn't rule out large scale
> restructuring at some point, but it might be better to let everyone
> look at a few rounds of diffs before any major structural changes are
> made. The issues list is already getting a little big.

Agreed. As I said earlier, we've already talked about rearranging  
sections, and maybe rewriting parts of the caching section.

Perhaps we're just talking past each other -- Roy, are you really  
talking about a wholesale rewrite, or rearranging parts, or what? If  
you gave us an idea of what you want to do, it might help make this  
discussion more productive.

--
Mark Nottingham     http://www.mnot.net/
Permalink | Reply | 9 comments |
headers
Mark Nottingham | 1 Jun 06:19
Favicon
Gravatar

Re: Straw-man charter for http-bis


On 01/06/2007, at 12:25 PM, Roy T. Fielding wrote:

Taking a stab at what that might look like in 2616 terms:

> I am talking about splitting the document into
>
>    messaging

4, 5, 6, 7, 9, 10, various parts of 3, parts of the relevant header  
defs in 14

>    conditional requests and range requests

3.12, parts of 10.3.5 and 10.2.7, parts of the relevant header defs  
in 14

>    caching and cache control

13, parts of the relevant header defs in 14

>    content negotiation

12, parts of the relevant header defs in 14

>    http and https URIs

3.2

>    HTTP implementation guide for TCP transports
(Continue reading)

Permalink | Reply | 7 comments |
headers
Mark Nottingham | 1 Jun 07:17
Favicon
Gravatar

Re: Straw-man charter for http-bis


On 01/06/2007, at 2:19 PM, Mark Nottingham wrote:

> One more question (not necessarily for Roy): at what point does  
> rewrite/rearrangement affect the transition from Proposed to Draft?

*shakes head at self*

Let me re-phrase that: does a rewrite/rearrangement affect the Draft  
Standard status? Considering:

>    A Draft Standard is normally considered to be a final  
> specification,
>    and changes are likely to be made only to solve specific problems
>    encountered.  In most circumstances, it is reasonable for  
> vendors to
>    deploy implementations of Draft Standards into a disruption  
> sensitive
>    environment.

--
Mark Nottingham     http://www.mnot.net/
Permalink | Reply | 1 comment |
headers
Keith Moore | 1 Jun 09:55
Picon

Re: Straw-man charter for http-bis

>  Let me re-phrase that: does a rewrite/rearrangement affect the Draft
> Standard status? 
one of the main purposes of the document status is to show how much
confidence there is in the specification's clarity and accuracy.  if you
substantially rewrite a specification, whatever confidence you had in
the original specification no longer applies to the new specification. 
and you need to reestablish confidence in the rewritten specification. 
that implies a reset to Proposed.

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).
Permalink | Reply | 0 comments |
headers
Robert Sayre | 1 Jun 03:04
Picon
Gravatar

Re: Straw-man charter for http-bis

On 5/31/07, Roy T. Fielding <fielding <at> gbiv.com> wrote:
>
> I am not going
> to support an IETF working group that says "nobody is allowed
> to do a better job describing HTTP than what is in our charter."
...
>
> If I make the real changes that are needed in draft form and submit
> them to the WG, then I will expect them to be evaluated without bias
> or the WG to be closed.  If the answer is "that's too much
> for me to review, so you aren't allowed to do that in the IETF"
> then I won't.  I will do it elsewhere and the IETF specification
> will become irrelevant.

I think application of forking pressure is OK. It is always present anyway.

I don't understand why the two approaches are mutually exclusive. I
think the best way to start is by doing exactly what has been done so
far. I agree with Roy that we shouldn't rule out large scale
restructuring at some point, but it might be better to let everyone
look at a few rounds of diffs before any major structural changes are
made. The issues list is already getting a little big.

>
> I don't hear anyone else saying that 2616 needs to be revised before
> 2617, yet you continue to take that as an assumption.

The order is irrelevant, and they don't need to be undertaken by the same group.

> 2616 doesn't *need* to be revised at all.
(Continue reading)

Permalink | Reply | 11 comments |
headers
Roy T. Fielding | 1 Jun 04:25
Favicon
Gravatar

Re: Straw-man charter for http-bis

On May 31, 2007, at 6:12 PM, Mark Nottingham wrote:
> On 01/06/2007, at 11:04 AM, Robert Sayre wrote:
>
>> I don't understand why the two approaches are mutually exclusive. I
>> think the best way to start is by doing exactly what has been done so
>> far. I agree with Roy that we shouldn't rule out large scale
>> restructuring at some point, but it might be better to let everyone
>> look at a few rounds of diffs before any major structural changes are
>> made. The issues list is already getting a little big.
>
> Agreed. As I said earlier, we've already talked about rearranging  
> sections, and maybe rewriting parts of the caching section.
>
> Perhaps we're just talking past each other -- Roy, are you really  
> talking about a wholesale rewrite, or rearranging parts, or what?  
> If you gave us an idea of what you want to do, it might help make  
> this discussion more productive.

I am talking about splitting the document into

    messaging
    conditional requests and range requests
    caching and cache control
    content negotiation
    http and https URIs
    HTTP implementation guide for TCP transports

to go along with

    authentication and access control
(Continue reading)

Permalink | Reply | 8 comments |
headers
Keith Moore | 1 Jun 16:42
Picon

Re: Straw-man charter for http-bis


>> 2616 doesn't *need* to be revised at all.
>
> Disagree. The document is losing usefulness as a reference because it
> is poorly structured, crawling with inaccuracies, and the net is full
> of things that claim to be HTTP but aren't.
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?  (seriously, at least for SMTP it's pretty obvious that a lot
of authors of bad implementations never bothered to read the spec, they
just copied what they saw someone else do. )

revising 2616 will help the implementors who are actually trying to get
it right, and for that reason it is probably a worthwhile effort.  but
it won't do anything for the remainder of the implementations.
Permalink | Reply | 0 comments |
headers
Keith Moore | 1 Jun 16:48
Picon

Re: Straw-man charter for http-bis


> I am not going
> to support an IETF working group that says "nobody is allowed
> to do a better job describing HTTP than what is in our charter."
that's your choice, of course.  but the charter wording is up to the
IESG, and they have the authority to make decisions about what kinds of
activities are in scope and which kinds of activities are out of scope. 
(the draft charter being discussed is just someone's idea of a proposal
to be given to IESG and it's reasonable to debate it, or to suggest your
own draft charter to the applications ADs)

for better or worse, there's a lot of investment in the current prose. 
a drastic rewrite might remove some ambiguities but would certainly
create others - and also create questions about exactly what was
changed.  if HTTP is updated by making relatively minor tweaks where
possible, and major changes to text only when necessary, it's much
clearer what was changed than if there's a major restructuring/rewriting
of the document.  that, and rewriting would force a reset to Proposed
Standard and create an ambiguity over whether the Proposed or Draft
version were authoritative.

Keith
Permalink | Reply | 0 comments |
headers
Keith Moore | 1 Jun 18:55
Picon

Re: Straw-man charter for http-bis


> 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?
The catch is that HTTP is (currently) specified by RFC 2616, and the
most accurate documentation about HTTP is in RFC 2616.  If you replace
2616 with a completely different specification, you're not "accurately
documenting" HTTP, you're _changing_ the specification.   You will
inevitably create incompatibilities between "old" HTTP and "new" HTTP.

I'm not saying it's inherently a bad idea to do that, I'm saying that a
rewrite is going to cause some interoperability issues even if you end
up with a much clearer and/or more precise specification.

People contemplating a rewrite of HTTP should really look hard that the
experience from the DRUMS working group that updated RFC 822 and SMTP. 
It took a very long time, and while the results are clearer in many ways
than the original specifications, IMHO they are not an improvement in
every respect.  For instance, a lot of effort was spent in  rewriting
the ABNF that describes internet messages.  The new ABNF is perhaps more
precise but it's _much_ harder to write a correct parser for the new
grammar - and there's very little benefit to doing so because new mail
readers still need to be able to parse pre-RFC2822 messages.  So in
practice, to write a good mail reader, you now need to refer to BOTH RFC
822 and RFC 2822 - because the RFC 822 grammar is the best one to write
a parser from, and 2822 has the grammar that you should use when writing
code to generate new messages.   (And they're in different notations!)
This means _more_ work for the implementor, a higher barrier to
producing a correct  implementation, and a greater temptation to not
(Continue reading)

Permalink | Reply | 3 comments |

Gmane