[NNTP] CAPABILITIES and LIST SUBSCRIPTIONS/LIST MOTD

Russ Allbery rra at stanford.edu
Tue May 24 10:11:58 PDT 2005


Urs Janßen <urs at tin.org> writes:

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

Hm.  It looks like we dropped the ball on this a couple of years back,
since I don't recall any follow-up to that as well.

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

In this case (and Clive, please correct me if I'm wrong, since you're more
familiar with the wording), LIST is the capability label and there's a
general, blanket permission granted to add additional list types to that
capability label.  Those additions don't have to begin with X.

I don't entirely trust my memory, but I think that was done that way
intentionally since we know that existing servers support LIST extensions
that we didn't want to either document or outlaw.

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



More information about the ietf-nntp mailing list