ietf-nntp Section 8
Clive D.W. Feather
clive at demon.net
Wed Jan 10 08:28:37 PST 2001
Stan O. Barber said:
>> The present section 8 is formatted in a completely different way from other
>> commands. Instead of having an introduction, a description of responses,
>> and then some examples, each response gets its own section.
>
> Section 8 was based on an existing RFC (1869) using that format and style. It
> can certainly be written in a different style, but again, getting such a change
> done before IETF is unlikely. It can be worked on after San Diego.
<http://www.davros.org/nntp-texts/section-8.txt> shows my suggested changes
to draft 12.
> As for the 402 Vs. empty list issue, that was also based on 1869's mechanism. I
> chose that because it was an existing practice. We can do something different,
> but having it based on
> a practice that was already existing seemed to me to make it something folks in
> the field
> of writing clients would already have knowledge about.
Doing it that way means that a server needs to special-case it instead of
just generating an empty list. I can imagine a server design that goes:
issue 202 response code
for each module
ask it to list any extensions it is providing
issue the terminating dot
Certainly we should allow an empty list, even if we say it SHOULD use 402.
Otherwise such code has to be rewritten to do something like:
set "blank list" flag
for each module
if "blank list" flag is set
ask it if it is providing any extensions
if so:
issue 202 response code
clear "blank list" flag
ask it to list any extensions it is providing
if "blank list" flag is set
issue a 402 response
else
issue the terminating dot
Does anyone know of a client that would be upset if given an empty list ?
--
Clive D.W. Feather | Work: <clive at demon.net> | Tel: +44 20 8371 1138
Internet Expert | Home: <clive at davros.org> | Fax: +44 20 8371 1037
Demon Internet | WWW: http://www.davros.org | DFax: +44 20 8371 4037
Thus plc | | Mobile: +44 7973 377646
More information about the ietf-nntp
mailing list