Some older NNTP standardization stuff

[Russ Allbery]

Extra Strength Flufferin <supersede at india.com> writes:

> As sven at tin.org noted, it might be nice to do something a little more
> elaborate with LIST EXTENSIONS.  But hat shouldn't co into the main
> command table -- there may be, for example, multiple extensions tied to
> the single AUTHINFO command.  LIST EXTENSIONS, as currently proposed, is
> kind of goofy anyway (what *is* with that leading space?), so doing it
> properly should probably wait until it is defined in a reasonable way.

I've raised the bit about the leading space several times on the IETF NNTP
list and it doesn't look like it's changing.  I think the current
specification is workable, so we should probably figure out how we want to
properly handle LIST EXTENSIONS.

I'd also at some point like to write up the extensions that INN supports
so that there's some real documentation of them, but that's a long-term
issue.

> There is still an unresolved question about how to handle "classic"
> AUTHINFO responses; the official response codes are supposed to somehow
> migrate from x8x to x5x, which breaks pretty much every client.  There
> was a suggestion floated to only use the new reponses if a LIST
> EXTENSIONS is issued, but as Andrew Gierth noted that still breaks
> Netscape 4.x.

This was discussed on the IETF NNTP list and in the current draft the code
assignments were changed so that x8x is now authentication and private
codes have moved to x9x.  So the response codes no longer have to change.

> Also, there is some ambiguity on how LISTGROUP is supposed to work.  The
> current implementation changes the active nersgroup, but nntpext doesn't
> specify that this is supposed to happen.

The current draft says that LISTGROUP is supposed to change the active
newsgroup just like GROUP, so I think we're right on that one.

> Thre is an open question on how swervers that only partially implement
> XHDR/XPAT should respond (only thing for sure is that the Typhoon
> approach of successfully returning nothing is b0rken).

PAT is a big mess that's still being discussed.

> Finally, there was talk of making wildmat(3) support Unicode in some
> fashion.  I seem to remember somebody mentioning that they had
> implemented this one, but darned if I can remember who that was now.

I have a start on that done and checked in; there's still some discussion
about allowing escapes something like \u0fff or something.

> (BTW, the SENDME stuff, when it's done enough to come begging for
> inclusion in real INN, will need to be enabled in readers.conf anyway,
> so it shouldn't be a problem for anyone who doesn't want to offer it.)

Cool.

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