[NNTP] Additions to LIST commands

[Julien ÉLIE]

Hi Russ,

>      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.

Yes, you're right.  Thanks.


> 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.

OK.


>      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).

OK.


> 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.

But what for that MUST in RFC 3977?

   "Each extension MUST define at least one new capability label (this
   will often, but need not, be the name of one of these new commands)."


> 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.

While we're at it, it does not take much time to define them (especially "l").
One could have the need for it in the future.

I do not know whether "l" can be used with INN because innd injects the
article and it does not always have the information about the source
(depending on the presence of Unix domain sockets, or a different
nnrpdposthost) to decide if it is local.  (?)
Anyway, other news servers may know that better.

As for "r", is it OK to have either "r" or "r1258739643" (time since epoch)?

-- 
Julien ÉLIE

« Les idées fausses ne sont pas toujours mauvaises. » (Marcel Aymé)