[NNTP] Suggestions for NNTP extensions (CAPABILITIES)

Julien ÉLIE julien at trigofacile.com
Sat Sep 20 06:46:25 PDT 2008


Hi,

In order to properly advertise a few (legacy) recognized commands in CAPABILITIES,
some more extensions are needed, as you all know.  They should be standardized.
Here is what I suggest:


1/ Additions to LIST.

    * LIST DISTRIBUTIONS (with a wildmat for the area?)
    * LIST MODERATORS
    * LIST MOTD
    * LIST SUBSCRIPTIONS

    * Define the meaning of some other status fields of LIST ACTIVE.
      I do not know how to advertise it.  Maybe we could have LIST ACTIVE.STATUS
      where the return would be:
        y Posting is permitted.
        n Posting is not permitted.
        =* Alias group.
      because it might be different in implementations.  Or should we have another
      capability name (like EXTENDED-STATUS) which imposes the meaning of the defined
      status(?)
      Perhaps EXTENDED-STATUS is a better idea than LIST ACTIVE.STATUS because only
      humans will be able to understand the result of LIST ACTIVE.STATUS.

    * Say in the introduction that LIST EXTENSIONS is deprecated in favour of CAPABILITIES.

Available references:
    http://www.eyrie.org/~eagle/nntp/drafts/draft-hernacki-nntplist-02.txt
    http://www.eyrie.org/~eagle/nntp/rfcs/rfc2980.txt



2/ PAT capability.

    * The legacy syntax is kept:
      PAT header range|message-ID pattern [pattern ...]

    * New metadata :body to specify that PAT will search in bodies.
      It would be advertised as PAT BODY in CAPABILITIES.  (Or by default in PAT?)

    * Maybe another metadata :text to search in the whole article (headers+body)?
      It would be advertised as PAT TEXT in CAPABILITIES.   (Or by default in PAT?)

    * Support for existing :bytes and :lines metadata, like what is currently
      implemented in INN 2.5 (for XPAT):
        XPAT :lines 112- *
        221 Header or metadata information for :lines follows (from overview)
        112 7
        113 8
        .
        XPAT lines 112- *
        221 Header information for lines follows (from articles)
        112 Not a number!
        113 1789
        .

    * I do not know how to deal with encoding problems...  For instance,
      if I search the word "trouvé", it can be encoded in lots of ways
      in bodies, as well as in headers (QP...).

    * What for a search in folded headers?  May we assume they are in the same
      format as in the overview database?  Therefore, we cannot search for
      tabulations...

    * Hmm...  Should PAT be more extensible?  Allowing to find articles matching
      several conditions?  (header Path: contains "server" AND metadata :lines
      is LARGER than 20...)

Available references:
    http://www.eyrie.org/~eagle/nntp/drafts/draft-ballou-nntpsrch-03.txt



3/ Something to deal with large article numbers.  What can be done?
   An extension?  But what kind of capability and use?

Available references:
    http://lists.eyrie.org/pipermail/ietf-nntp/2005-July/005720.html
    http://lists.eyrie.org/pipermail/ietf-nntp/2005-July/005802.html
    [...]



4/ Something to deal with compressed feeds.
   Maybe we could define BATCH there (the legacy XBATCH command) along
   with another command(?)



5/ Something to deal with cancels.  Maybe the CANCEL capability?
   A basic CANCEL <message-ID> command.



6/ Something to deal with headers feeds.  It should be great to have
   a standard for that.
   MODE HEADFEED is normally used.  I thought MODE commands began to
   be deprecated (MODE STREAM and MODE READER) but I do not see well
   how we could have a headers feed without a special mode...



7/ I also see QUOTA there:
    http://lists.eyrie.org/pipermail/ietf-nntp/2007-February/005989.html

   Is it useful to go on with it?



8/ INN also implements a wider syntax for wildmats (with "[" and "]" for
   instance).  Ranges like "-12" and "-" are also recognized in order to
   be more symmetric with the already defined "12-".
   Notwithstanding, I do not think it needs an extension for that...



If someone knows other references or thinks about other extensions,
please complete this mail.


Could someone *briefly* explain me the process to follow in order to
write a draft for these extensions?
I admit I am a bit lost when I try to find information on rfc-editor.org
when there is an available working group.

Thanks beforehand,

-- 
Julien ÉLIE

« Omnia uincit Amor et nos cedamus Amori. » (Virgile)



More information about the ietf-nntp mailing list