[NNTP] Additions to LIST commands

[Russ Allbery]

Julien ÉLIE <julien at trigofacile.com> writes:

> I have just posted the following proposal for:

>    * LIST DISTRIBUTIONS
>    * LIST MODERATORS
>    * LIST MOTD
>    * LIST SUBSCRIPTIONS
>    * new status for newsgroups returned by LIST ACTIVE

> Comments are welcome!

> Especially on:

>    * how to advertise the meaning of new status;
>    * how to write an extension of RFC 3977 without defining
>      a new capability;
>    * how to deal with the fact that RFC 3696 limits the local part
>      of an e-mail address to 64 characters whereas USEAGE mentions
>      that a newsgroup name is limited to 66 characters (therefore,
>      what for the submission address of a moderated newsgroup whose
>      length is 66 characters?).

This looks very good.  A few comments:

      NOTE:  Periods are changed to dashes, and dashes are left alone.
      It implies that two moderated newsgroups whose names differ only
      by changing a period to a dash would go to the same address.
      Therefore, such moderated newsgroup pairs SHOULD NOT be created on
      a news server.

I think this is too strong, since this problem only occurs if %s patterns
are used for determining the moderation address.  That's the case for
world-wide hierarchies, but often not the case for local hierarchies.
Also, this draft is probably the wrong location for a general SHOULD about
moderated group naming.

I would instead say that if such moderated newsgroup pairs exist with
different submission addresses, a %s pattern rule cannot be used for the
moderation submission addresses for those groups and explicit entries
without a pattern will be required.

I wouldn't worry about +; any special interpretation is applied by the MTA
or MDA of the receiving site, and if they want to host a submission
address for a moderated group determined by a %s pattern rule, they'll
need to suppress that interpretation.

      Similarly, a news server SHOULD NOT carry two moderated newsgroups
      whose names differ only by the case of their characters.

USEFOR already covers this:

   A <component> SHOULD NOT consist solely of digits and SHOULD NOT
   contain uppercase letters.  Such <component>s MAY be used only to
   refer to existing groups that do not conform to this naming scheme,
   but MUST NOT be used otherwise.

so you probably want to reference USEFOR here (and here also this only
applies to groups using %s pattern rules).

For the new LIST ACTIVE flags, no CAPABILITIES line should be required,
since the client doesn't need to know whether or not the server might send
these flags before the server sends them.  That was intentional in how we
defined LIST ACTIVE in RFC 3977:

   Other values for the status may exist; the definition of these other
   values and the circumstances under which they are returned may be
   specified in an extension or may be private to the server.  A client
   SHOULD treat an unrecognized status as giving no information.

Since client behavior when seeing unknown flags is specified, there's no
need to do capability negotiation with them or to have a way to advertise
which flags might be used.  When there's an available specification, the
server can just start sending those flags; clients that don't implement
the specification are required to assume nothing about the group based on
the flag they see.

Both your "l" and "r" status flag proposals seem reasonable, but on the
other hand I don't recall anyone specifically asking for either feature,
so I'm not sure I'd go to the effort unless someone wants to use it.  "r"
does seem quite useful, though.

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