Re: Straw-man charter for http-bis

[Keith Moore <[e-mail]>]

Paul Hoffman wrote:
> It seems weird to do significant clarification work on 2616 and
> basically ignore 2617, given the normative reference to the latter. A
> better option would be to do full clarifications in 2617, including a
> discussion of the not-clarifiable internationalization issues. One
> such clarification is a list of the problems of HTTP Digest in the
> modern world.
>
> This probably should not take "a lot of time"; if it does, it means
> that the clarifications are all the more valuable. HTTP implementers
> who see a lot of work in 2616bis and nothing in 2617 will not
> necessarily come to the conclusion that the IETF wants; it would be
> better to have a 2617bis that says what we want to say.
2617 doesn't need clarification, it needs to be deprecated and replaced
with not only different schemes but an entirely different framework. 
I18N is the least of its problems.  Maybe it would be useful to have an
informational document that says what's wrong with 2617 and suggests how
to fix the parts that are fixable, for the sake of sites that continue
to use it, but I don't think such work should be critical path for
either htttpbis or httpsec.
> Knowing ahead of time whether or not the work of this proposed WG is
> likely to get smacked down at the end by the IESG would greatly affect
> the people working on HTTPbis.
by "at the end" do you mean at RFC publication time, or charter time? 
If the latter, I agree; if the former, I think that's how the process is
supposed to work.   but basically IESG understands that HTTP is
important and that it needs maintenance AND good security, and they're
also going to understand that security work needs to happen in a
separate group, so I think they're going to want to approve charters
that further these ends rather than smack them down .
> The status of the new document is *much* less important than its
> correctness and usability to HTTP implementers.
mostly agree, though it would be confusing to "outsiders" to have 2616
be at draft standard and a new, rewritten specification be at
proposed.   as for "correctness" that's fairly arbitrary.  does it mean:
the document that IETF says is correct (say via an applicability
statement), the document that best reflects the "intent" of the protocol
designers, the document that describes what works best in practice with
today's (perhaps not tomorrow's) browsers and servers, or what?

Keith