[ietf-nntp] OVER message-id

[Andrew - Supernews]

>>>>> "Ken" == Ken Murchison <ken at oceana.com> writes:

 >> At some point we put "OVER message-id" back into the protocol.
 >> Andrew from Supernews is objecting to this, saying that it's
 >> impractical in "every major server design".

 Ken> Just out of curiosity, if its impractical in "every major server
 Ken> design", shouldn't more than one person be voicing displeasure?
 Ken> I'm sure Russ would've shot this down earlier if INN would have
 Ken> issues with it.

INN is only one of several server designs these days, and I haven't
seen anyone actively involved in Diablo development participating here
any time recently. Our server differs from both.

I objected specifically this is one of those cases that _seems_ easy if
you look at it only from the point of view of INN or any "naive" server
implementation, without considering the kinds of things that large-scale
systems need. Your comment here:

 Ken> If a server can fetch an entire article by msgid, is it that far
 Ken> of a reach to get the overview data?

is typical of that, because it _is_ a reach - a distributed server
design (such as, for instance, Diablo) separates the article store
(accessed by message-id) from all the per-group and overview
information (accessed by group/article number). In such a system it is
highly desirable to be able to store articles without knowing their
assigned article numbers (and hence not being able to store the Xref).

 >> He suggests, instead, an extension to NEWNEWS that would return
 >> overview fields along with the message-ids.

I suggested that as being the correct fix for a proposed class of
clients that used multiple OVER <id> commands in order to filter
NEWNEWS results to decide what to download. Note that _no such clients
currently exist_, because XOVER <id> (and even XHDR <id>) is not
commonly supported; clients that use NEWNEWS and which to pre-filter
articles currently do so using HEAD <id> commands.

 >> For the same technical reasons, he suggests that:
 >> HDR Xref <message-id>
 >> HDR :lines <message-id>
 >> may be problematical.

 Ken> Same as above, client authors should determine if its useful.

The current evidence here is that clients do not need HDR (anything) <id>,
because we've had it disabled for the past five years and nobody's ever
commented on it.

-- 
Andrew, Supernews
http://www.supernews.com