[NNTP] NNTP working group status

[ned.freed at mrochek.com]

> First of all, where we are formally:

>  * The base protocol document (version -23, I believe) passed IETF last
>    call and has now passed IESG approval.  If we believed it was the right
>    thing to do, it's actually at the stage where we would send it to the
>    RFC editor for publication.  I don't think that's the right thing to
>    do (see below), but I wanted everyone to know what the actual status of
>    it is.

As you say, we've waited this long, if waiting a bit longer will result
in substantial improvement, I'm for it.

>  * We have three other documents in progress.  The AUTHINFO and STARTTLS
>    documents are, I believe, done changing, except for the outcome of the
>    current discussions (more on that in a moment).  Except for the whole
>    LIST EXTENSIONS issue that we're debating now, they would be ready for
>    working group and then IETF Last Call.

I agree with this assessment, although I have yet to review the STARTTLS
draft to see if it meets all of the newer things the security folks want
out of TLS in more recent protocols.

>  * I believe that the STREAMING document is essentially done, although
>    since it hasn't baked as much as the other two, it's more likely to
>    turn up some additional comments in a working group last call.

Sure.

>  * I think it is to our advantage to publish all four of these documents
>    around the same time, since together they comprise pretty much all of
>    the significant and useful extensions that are currently in use by
>    deployed NNTP clients and servers.

As a purely practical point, if all of them get to the RFC Editor within a
reasonably close period of time the RFC Editor is likely to lump them together
in terms of the RFC numbers they get. They're smart this way... Although if we
got a move on we might even be able to get RFC 3977 as the number for the
revised NNTP specification ;-)

>  * We are significantly overdue on all of our outstanding milestones,
>    many of which have already been moved multiple times.

Yes, well, I suppose its not PC to say, but we're far from the only group with
this problem!

> ...

> Now, I view the role of a working group chair to be somewhat similar to
> the role of a release manager, in that I have to try to balance the
> competing priorities of making the standard as good as we can and getting
> something out the door.  While we have a lot of energy and activity right
> now, I mistrust (based on past experience) our ability to maintain that
> energy level for very long, and therefore think we need to get documents
> out the door before we lose energy again.  We have to strike a balance
> between getting the documents just right and getting them published so
> that people can actually start benefiting from them.

I'm nominally the process weenie here, but FWIW I agree.

> I do think that if we can get an extension mechanism that would make Mark
> happy, that is a significant improvement to the document and is worth
> delaying it for another three months (which is probably going to be the
> minimum delay if we go back, change it in a fundamental way, and put it
> forward again for Last Call, which I assume would be the procedure).

That's correct, although it will probably end up being mostly a formality.

> Mark's points about nailing down exactly what the server will let one do
> in the LIST EXTENSIONS response are very well-taken, as is the point about
> adding some sort of protocol token to avoid known-bad implementations.

> Accordingly, I think it's right to ask Scott if he also feels like we
> should reopen discussion on LIST EXTENSIONS (more formally than we have so
> far) and make modifications to the standard in order to meet the above
> three goals.  This would likely also result in some changes to the LIST
> command to try to resolve the issues with the current draft where some of
> the commands are optional and there's no advertised way of knowing whether
> they will work.  It will also probably mean dropping LIST DISTRIBUTIONS
> from the standard entirely and leaving it as a separate extension that we
> don't document in this initial set of documents, and making LIST
> NEWSGROUPS mandatory.

FWIW, I have no problem with pursuing this course. I note, however, that
I have precious little skin in this particular game, and others that
do may feel differently. (And if so should chime in now...)

> However, I think that if we're going to go back and revisit things we've
> already decided, even for very good reasons, we need to sharply limit the
> scope of that discussion so that we can complete it and move forward.
> This means that we're not going to fix everything that could be fixed, and
> it means that the next version of the standard is likely to require more
> work, but it does mean that we'll get the standard out the door faster so
> that people can start using it.

Absolutely right.

> Accordingly, I would strongly prefer to reopen discussion *only* on LIST
> EXTENSIONS and what should be contained in it and on the LIST command and
> what LIST subcommands we choose to document (so that we can fix up the
> issues related to optional commands there).  This means leaving MODE
> READER alone for now, which includes the following admonition:

>    Servers are encouraged to not require this command even though clients
>    SHOULD send it when appropriate.  It is present to support some news
>    architectures that switch between modes based on whether a given
>    connection is a peer-to-peer connection with another server or a news
>    reading client.

> but not removing the command from the standard entirely.  I do think we
> can document 433 as an alternate port for NNTP servers that can be used
> only by peers, which is one way in which some servers have avoided MODE
> READER, but I don't really want to have an extended discussion about that
> either.

> Now, in the interests of full disclosure, please note that I maintain a
> free news server (INN) which is essentially the only software package that
> requires MODE READER at present.  I didn't add it, don't particularly like
> it, and configure my own servers to not require it, but there is certainly
> the possibility of bias in my own feelings on the subject.  I'm
> uncomfortable making a working group chair decision on this because of
> that, and I want to make sure Scott knows about that and also say that I'm
> quite happy for some third party to make the decision about whether to
> reopen discussion of or remove MODE READER from the NNTP standard, and
> I'll happily abide by the decision of that person.

All things being equal I'd prefer to only reopen MODE READER if there
was obviously potential benefit from doing so. I see the potential
benefit for LIST EXTENSIONS, but not for MODE READER.

				Ned