HTTP Authentication
charter-ietf-httpauth-01

[Ballot comment]
I absolutely think this working group should be chartered.  Thanks for sorting out my blocking issues.  Version -00-02 also handles all my non-blocking comments.

[Ballot comment]
Looks good to go. A few non-blocking comments:

Is there any reason for any of the output of this WG to be Informational? Shouldn't it just be 2 x Standards Track and N x Experimental?

If we can figure out something to say in the charter about how the Experimental documents should "run the experiments", that'd be great. Otherwise, let's figure out something to tell them when the WG gets going.

I was shot down when I suggest mentioning PRECIS in the charter. At least mention it to the WG.

[Ballot block]
I absolutely think this working group should be chartered.  Thanks for sorting out my blocking issues.

I'm still holding the "block" on the first paragraph until it's properly wordsmithed (is that a verb?).  This will go away RSN.

[Ballot comment]
Almost all of my non-blocking comments are satisfied in the -00-01 version.  Two left:

Substantive:
In the bullet list at the end:

The fourth bullet is understandable, but needs to be rewritten, with something like real punctuation (not a bunch of comma splices).

The fifth bullet should be clearer.  Perhaps, "any mechanism of web authentication, such as HTML-form-based login, that is not at the HTTP layer" ?

[Ballot comment]
I don't believe that we had consensus on whether or not the goals/milestones section is part of the charter (this was discussed at the last IETF). However, I personally find this information useful, to understand the milestones, and to clearly express if a document should be standards track or informational. It's preferable to have those discussions at the charter discussion time.

[Ballot block]
This charter need a bunch of work before it is ready for external review:

On the 6th paragraph:

In addition, the WG will aim to get rough consensus on two drafts
that will obsolete the basic and digest schemes defined in RFC 2617
taking into account errata on that specification.

Here, do you simply mean that you want the group to produce 2 documents, one for basic and one for digest? The WG better *always* be aiming for rough consensus, no matter what the documents, and that bit makes it unclear what you're getting at. Is it that they're intended to be standards track? If so, say that. (BTW: The "In addition" seems unnecessary.)

In the next two paragraphs:

For the digest scheme, "more modern" algorithm agility and
internationalisation support will be developed as a standards-track
RFC. [...]

For the basic scheme, no technical changes are envisaged other than
to handle i18n of usernames and passwords [...]

When referring to i18n, I think a specific reference to "work with the PRECIS WG in order to..." would be useful. Also, neither of these paragraphs say what I believe is true from the rest of the context: Both of these documents will be standards track documents that obsolete 2617. Barry's additional rewrites are also necessary.

Other than the documents that aim to obsolete RFC 2617, the rest of
the WG output will be a set of informational or experimental RFCs.

Other than obsoleting RFC 2617 developing standards track solutions
is out of scope as none of the proposals are expected to be
sufficiently widely deployed to warrant that status before the WG
closes.

(Those two are a bit redundant.) I'd like to hear more about the status of the documents. If the only reason to make these things Experimental is because they're not going to have much deployment, leave them as Proposed. That's what "Proposed" means. If you think they actually need to be "experiments", I think the WG should come up with a plan of experimenting: For example, perhaps if nobody can be found (who makes the offer before publication) to write an implementation and report back, then we don't publish the document. If you're going with Experimental, I think the charter (and the documents) should anticipate what it will take to move these things to standards track in the end. Experimental should not simply be "Proposed-Lite".

- changes to HTTP, however, if some change is proposed
  that is clearly supported by the httpbis WG then that would
  be fine, for example, one might envisage that a new HTTP header
  field might be acceptable if both this and the httpbis wg
  had rough consensus for the addition of that header field,
  albeit that working solely within the existing authentication
  framework is preferable to defining new header fields
 
Simplify:

- changes to HTTP, except for those made in the httpbis WG

[Ballot comment]
I agree with Barry's Block 1.

I think Barry misread a couple of sections, but I think that's because the wording in those sections really needs some help:

- Block 2/complaint about "e.g.": I think they do need the e.g. as written, because D-H is but one example of the changes they *can* make. But that is not enough information to figure out what kinds of things they can change in draft-ahrens.

- Block 3: I think the intention of the paragraph was that the WG could come to consensus to throw out some of the input documents. Poorly worded.

[Ballot block]
I absolutely think this working group should be chartered.  But I don't think the charter is there yet.  I have three blocking points (up here), and a lot of other comments (down there).

Block 1:
"The starting points for work will be:" [followed by a list of documents]

In this case, is it really a good idea to specify these "starting points", rather than leaving the choice of where to start and which bits to pick up to the decision of the working group?  I would very much prefer, for this working group, to specify where they want to end up, and to let them decide how to get there.  If someone should develop a new proposal next week I wouldn't want the charter to block its adoption.  And if no one but the author thinks one of those proposals above has any merit, I would hate to have the working group bound to spend its time on it.

Block 2:
In the paragraph that starts "For the digest scheme", in the second sentence, the part after the "but" is odd: working groups are allowed to make whatever changes they like to starting-point documents.  Is the intent here to *restrict* what they can do?  Why is a D-H exchange explicitly called out?

Block 3:
For the paragraph that starts "The WG is not required to merge":
This is really odd to me.  Are we really proposing a working group that is *designed* to publish documents for which there is NOT rough consensus?  Does this really mean that if one of the documents in the list above is widely considered to be crap, the WG is supposed to publish it anyway?  This seems to allow the author to refuse to accept anything the WG says.

If that's not what's intended, this paragraph needs to be entirely re-written.

[Ballot block]
"The starting points for work will be:" [followed by a list of documents]

In this case, is it really a good idea to specify these "starting points", rather than leaving the choice of where to start and which bits to pick up to the decision of the working group?  I would very much prefer, for this working group, to specify where they want to end up, and to let them decide how to get there.  If someone should develop a new proposal next week I wouldn't want the charter to block its adoption.  And if no one but the author thinks one of those proposals above has any merit, I would hate to have the working group bound to spend its time on it.

In the paragraph that starts "For the digest scheme", in the second sentence, the part after the "but" is odd: working groups are allowed to make whatever changes they like to starting-point documents.  Is the intent here to *restrict* what they can do?  Why is a D-H exchange explicitly called out?

For the paragraph that starts "The WG is not required to merge":
This is really odd to me.  Are we really proposing a working group that is *designed* to publish documents for which there is NOT rough consensus?  Does this really mean that if one of the documents in the list above is widely considered to be crap, the WG is supposed to publish it anyway?  This seems to allow the author to refuse to accept anything the WG says.

If that's not what's intended, this paragraph needs to be entirely re-written.

[Ballot comment]
I find it hard to comment on charters; perhaps we should use line or paragraph numbers in them, in order to provide anchors for comments.  Anyway, a mixture of non-blocking but substantive comments, and editorial nits:

Substantive:
I find the opening paragraph to be puzzling; I'd rather see it be usable to people who don't already know what this is all about.  Maybe something like this?:
<<
Authentication of users to servers over HTTP has always been a weak point in web services.  The built-in HTTP authentication mechanism [suffers from X and Y], and consequently is now infrequently used.  Authentication through a web form is much more commonly used, but [has problems Q and R].  There is a need for improved mechanisms that can replace or augment basic HTTP authentication.
>>

Nit (pet peeve):
In the second paragraph, the "e.g." is unnecessary, and I suggest removing it.  If it stays, it needs a comma after it.

Semi-substantive:
In the paragraph after the document list, I suggest changing "drafts" to "Standards Track specifications".  This will matter especially in a later comment.

Substantive:
In the paragraph that starts "For the digest scheme", I suggest, 'For the digest scheme, the new specification will incorporate "more modern" algorithm agility and internationalization support.'  (And this use of "e.g." is even more awkward than the other one; please re-word this, if it needs to be kept.  For example, "but the WG may decide to add features such as a D-H exchange.")

Two nits and a substantive one:
In the paragraph that starts "For the basic scheme", please use "internationalization"; this is a charter, not email.  The comma after "passwords" needs to be a semicolon.  Substantively, I wonder whether you intend this to be more restrictive than it is.  As written, this would allow vastly more changes than are specified here.  Maybe "the goal will simply be" should be replaced by something stronger?

Substantive:
For this paragraph:
  Other than the documents that aim to obsolete RFC 2617, the rest of the
  WG output will be a set of informational or experimental RFCs.

I suggest moving this up to the top.  I suggest changing the second paragraph like this:

OLD
Each of
the RFCs produced should include a description of when it is appropriate
to be used, e.g. via a use-case or other distinguishing characteristics.
NEW
Each of
these RFCs will be Informational or Experimental, and should include a
description of when use of its mechanism is appropriate, via a use-case
or other distinguishing characteristics.
END

Nit:
For the paragraph that starts "Other than obsoleting RFC 2617", add a comma after "scope".

Substantive:
In the bullet list at the end:

The second bullet is awfully written and rambling, and I find it impregnable.  Please re-write this in proper sentences, so I can understand it.

The fourth bullet is understandable, but also needs to be rewritten, with something like real punctuation (not a bunch of comma splices).

The fifth bullet should be clearer.  Perhaps, "any mechanism of web authentication, such as HTML-form-based login, that is not at the HTTP layer" ?