[ietf-nntp] RE: How to organize the base NNTP draft

[Russ Allbery]

Scott Hollenbeck <sah at 428cobrajet.net> writes:

> However, the way the split is approached _might_ introduce a conflict
> with the WG's charter, which says:

> "2. Include in the same document some reasonable group of existing
>   commonly used extensions forming a new base functionality for NNTP."

> and

> "3. Upon completion of the RFC977 successor document, and presuming that
>   proposals for extensions to the NNTP protocol have been submitted
>   for consideration by IESG, the working group may be asked by the
>   IESG Applications Area Directors to review one or more extensions  
>   for NNTP."

> So, the base document is supposed to incorporate some commonly used
> extensions.  What makes sense to stay in the base document?

Under that charter, there's a strong argument that OVER and HDR should
stay in the base document.  They're extensions, yes, but they're
nigh-universally implemented (just currently under other names), and
clients expect them to be available.

It's honestly tempting to me to just publish the base document as it
stands and publish the STARTTLS and the AUTHINFO documents as separate
documents as they stand right now, but maybe that would be too confusing
to people.

There is the analogy with MIME, which is split into multiple documents,
but MIME is different.  MIME is split along significant distinctions
between areas of the protocol.  We wouldn't be splitting that way; we'd be
putting some commands in one document and some commands in another.
Putting STARTTLS and SASL in separate documents makes sense in that we'd
have everything widely implemented in one place and new work in a
different place.  Splitting between the base protocol and extensions
doesn't make as much sense; there's some stuff that everyone should be
implementing that would be in the extensions document.

> I can see the security extensions being in a second document per item
> #3.  We can then try to expedite review and approval of the second
> document so that the first doesn't get blocked in the RFC Editor's queue
> for longer than it needs to be there.

> Anyway, we have a way forward with the IESG.  What's the best way to
> deal with the extensions while staying within the charter?

I think that if we want to stay strictly within the charter, we need to
publish the base document as it stands and immediately move on to treating
STARTTLS and AUTHINFO SASL as extensions under point three.  Failing that,
we should probably recharter to include strong authentication and
encryption in our mission so that we can publish a combined draft with all
of it.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>