ietf-nntp Where are we at?

[Charles Lindsey]

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

>In that case, it is trivial to try the first HDR and fall back on other
>mechanisms if it fails, so this is a bad example for where this would be
>useful.

I would say "easy" rather than "trivial". It is a njisance for the client
implementor to have to do it that way.

>> My proposal is not limited to the particular syntax I gave. Even if you
>> limit the possible parameters to the two common cases of "all" and
>> "overview" you will get most of the benefit.

>You cannot simplify it to that because you would be misrepresenting the
>server.  There are servers for which neither "all" nor "overview" are
>true.  Which means that there are both specialized tokens and header
>names, and a potentially unlimited number of header names, that you then
>have to parse into some data structure to answer your question.  Ick.
>Just asking and checking the return code is significantly simpler.

You could allow
    HDR all
    HDR overview
    HDR
where the last case would imply "we implement HDR, but will not, or
cannot say exactly which headers". But I think all known present
implementations would be able to respond with either the first or the
second.

>> But specifying the parameter is no burden on the implementor because,
>> for any given server, it is just a constant string that the implementor
>> has to write just once.

>This is not correct.

Why not? Is a given server implementation going to change the list of
header that it supports dynamically? Surely not. The response to be given
will simply be compiled into the program as a string constant.

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