[NNTP] Suggestions for NNTP extensions (CAPABILITIES)

[Charles Lindsey]

In <87zlm1z3mr.fsf at windlord.stanford.edu> Russ Allbery <rra at stanford.edu> writes:

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


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

>There are two main reasons why we didn't standardize PAT.  The first and
>most serious is whitespace handling in patterns.  Given the way that NNTP
>command parsing works, how would you search for a pattern containing two
>spaces?  And what do the spaces between patterns really mean?

Another reason is that wildmats are not really the right tool (and it is
not clear whether/where they are supposed to be anchored); and they may
not play very well with UTF-8. I think the view was that, to do the job
properly, we needed some kind of decent regular expression, but unless
there is some likelihood that someone would actually implement such a
thing, I think it better just to leave XPAT as it is (but ensure it is
documented somewhere, which it actually is). Leave PAT for some future.

>>    * 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?)

>Anything involving full body search should definitely be optional, since
>the server may not hold the full article locally until the user requests
>reading it and may not want to support expensive full search operations.

+1

If you want to search in bodies, then leave it to Google :-) .


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

>IIRC, Clive had an extension proposal for how to deal with this.

IIRC there was a scheme which involved setting the article numbers for an
about-to-overflow group back to some low value (but NOT zero) that might
not cause too much confusion with existing servers (for sure, ANY solution
will cause pain to SOME users, at least).


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

>The wildmat extensions would be nice to write up formally, but I'm not
>sure it's worth a full extension.

IIRC, the reason we removed the [...] feature was that it might not play
well with UTF-8.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: chl at clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5