ietf-nntp Standardization of LIST OVERVIEW.FMT

[Matthias Andree]

Russ Allbery <rra at stanford.edu> writes:

> [Q1] If you know how a reading client is implemented, does that reading
>      client ever send LIST OVERVIEW.FMT?

> [Q3] If you know how a server is implemented, does it implement LIST
>      OVERVIEW.FMT?

> [Q4] If the server does implement LIST OVERVIEW.FMT, what are its
>      semantics?  Does it follow (2) above, (3) above, or some other
>      meaning entirely?  And if the last, what meaning?

The current leafnode-1 and leafnode-2 readers ("fetchnews") do not send
overview.fmt, but rely on the server sending the [X]OVER data in the
order laid out in RFC-2980.

The leafnode-1 and leafnode-2 servers ("leafnode") do support
overview.fmt and return the fixed and non-configurable list Subject:
From: Date: Message-ID: References: Bytes: Lines: Xref:full (one per
line with the lone dot line, of course).

> [Q2] If the client does send LIST OVERVIEW.FMT, what does it use the
>      returned data for?

n/a

see above.

> And finally:
>
> [Q5] What approach do you think should be taken by the next NNTP
> standard?

The NNTP standard should standardize overview.fmt, but require that the
first seven fields (excluding the Xref:full) MUST always be present and
MUST always be in the order shown above (reference: the XOVER section
RFC-2980), for compatibility with existing implementations.

(Should the standard also mention the problem of TAB characters in the
original headers? Just as a reminder to the implementor. TAB is the
field delimiter in XOVER output, so it cannot be used in the headers
themselves. Leafnode just replaces any TAB with SPC in [X]OVER output.)

> Any and all feedback will be gratefully accepted.  Thank you!

-- 
Matthias Andree