Note: This ballot was opened for revision 07-00 and is now closed.
Ballot question: "Is this charter ready for external review?"
I appreciate the addition of QUIC-related work to this charter. I'm sympathetic to Mirja's comments about intentions, including her comment on not-optimal-timing. At a minimum, as I mentioned during discussions at IETF 103, I note that the current QUIC charter calls out HTTP/2, and if that's not what QUIC is going to call their deliverable (as per this charter), it would be nice to update the QUIC charter to reflect the new name. Keeping in mind that HTTPbis and QUIC currently share one co-chair, and that this might not always be true, you might consider a couple of "good fences make good neighbors" edits, as OLD The Working Group will review the QUIC Working Group's documents regarding the use of HTTP over the transport protocol they define, providing feedback and collaborating where necessary. NEW Upon request from the QUIC Working Group, the HTTPbis Working Group will review the QUIC Working Group's documents regarding the use of HTTP over the transport protocol they define, providing feedback and collaborating where necessary. END and OLD Once the QUIC Working Group publishes the expression of HTTP semantics in QUIC (HTTP/3), this Working Group will maintain and develop extensions for that protocol as necessary. This includes ancillary specifications (e.g. QPACK). NEW Once the QUIC Working Group publishes the expression of HTTP semantics in QUIC (HTTP/3), the HTTPbis Working Group will maintain and develop extensions for HTTP/3 as necessary. This includes ancillary specifications (e.g. QPACK). END And I notice that this is the first mention of HTTP/3 in the revised charter. Perhaps that's worth a sentence, on its own?
I have a few comments, but nothing worth blocking over at this stage: - Why the scare quotes around "core"? # HTTP/1.1 Revision, 2nd paragraph: What is the "they" in "since their publication"? Just the http/1.1 docs, or does it include http/2? The heading suggests the former, but the mention of http/2 confuses me. - Will the refinements to the "core" documents be in the form of updates or bis drafts? If the latter, can we constrain "Fix editorial problems" to "_only_ those which have led to misunderstandings" (or maybe "are likely to")? I would like to discourage the fairly common kind of "editorial fix" that involve new authors adapting text to their personal writing styles. They tend to make bis drafts diffs really hard to review.
I have no new comments to add that are not in other ballot positions already, but specifically call out the HTTP/1.1 vs. HTTP/2 question as being confusing
I don't think there is a reason to block the charter as currently proposed, however, I have a couple of questions. First an editorial one: should it be "HTTP/2 Revision" instead of "HTTP/1.1 Revision", or maybe just "HTTP Revision(s)"? Then regarding the HTTP and QUIC part. I found it a bit weird and probably also unecessary to mention review intentions in the charter. However, I guess we need at some point to discuss what to do with HTTP/3 after the QUIC group has finsihed their mapping document. Is the intention to do another re-charter then? Should we then maybe just wait until we have a better plan before we say anything about this in ther httpbis charter? The timing doesn't seem to be optional for me here but I assume the recharter is coming up because H2 is basically done...?
> # HTTP/1.1 Revision This seems a little confusing, as the HTTP/1.1 revision has already happened. Isn't this more like HTTP/1.1 and HTTP/2.0 maintenance? > * Incorporate errata > * Address ambiguities > * Fix editorial problems which have led to misunderstandings of the > specification * Clarify conformance requirements * Remove known ambiguities > where they affect interoperability * Clarify existing methods of extensibility > * Remove or deprecate those features that are not widely implemented and also > unduly affect interoperability * Where necessary, add implementation advice It looks like this list got wrapped somehow. Perhaps include blank lines between bullets? > The Working Group may define extensions and other documents related to HTTP as > work items, provided that: * They are generic; i.e., not specific to one > application using HTTP. Note that Web browsing by definition is a generic use. > * The Working Group Chairs judge that there is consensus to take on the item > and believe that it will not interfere with the work described above, and * The > Area Director approves the addition and add corresponding milestones. Same issue with bullet wrapping as above