[NNTP] CAPABILITIES and LIST SUBSCRIPTIONS/LIST MOTD

[Urs Janßen]

On Tue, May 24, 2005 at 09:34:25AM -0700, Russ Allbery wrote:
> Urs Janßen <urs at tin.org> writes:
> 
> > What happend to LIST SUBSCRIPTIONS (RFC 2980) and LIST MOTD?
> > <Pine.LNX.4.44.0304262356390.4175-100000 at puck.litech.org> ff. didn't
> > show up any rejections (and e.g. tin uses "LIST SUBSCRIPTIONS" for
> > ages). At last if LIST SUBSCRIPTIONS now is deprecated this should
> > be noted in the appendix "Changes from RFC 977 / RFC 2980".
> 
> I'm not sure where to find that message ID.

<nntp://news.gmane.org/Pine.LNX.4.44.0304262356390.4175-100000@puck.litech.org>
<nntp://news.gmane.org/gmane.ietf.nntp/787>

| From: "Jeffrey M. Vinocur" <jeff at litech.org>
| Date: Sun, 27 Apr 2003 00:17:33 -0400 (EDT)
| Subject: ietf-nntp RFC 2980 replacement
[...]
|    - LIST SUBSCRIPTIONS
|
|    Do we want an extension for this?  Does anybody actually use it?
|    Anyway, certainly easy to include if desired.

> I don't think that either were ever in our draft, or at least I don't
> recall them being there.  They at least weren't in the draft as far back
> as base-13.  Which is odd, since as you point out, LIST SUBSCRIPTIONS is
> in RFC 2980.  The intent was not to deprecate LIST SUBSCRIPTIONS at least
> that I can recall, although we didn't end up standardizing it either.
>
> There is a generic mechanism for software to include additional LIST
> keywords, so we haven't outlawed either.  If I'd realized that LIST

draft26 3.3.3 says
| Each extension MUST define at least one new capability label
[...]
| An extension is either a private extension or else its capabilities
| are included in the IANA registry of capabilities
[...]
| A private extension MAY or MAY NOT be included in the capabilities
| list. If it is, the capability label MUST begin with "X"

I would read this as 'either LIST SUBSCRIPTIONS must be deprecated or
renamed or defined in this (or another RFC (in which case the draft
can't supersede RFC2980 till LIST SUBSCRIPTIONS is defined elsewhere ,-)',
but this point iof view might be too strong.

> SUBSCRIPTIONS wasn't in there a year back, I probably would have argued
> for inclusion; at this point, I'd argue for a supplemental RFC documenting
> it and other LIST extensions if folks want.

urs