ietf-nntp HDR

[Charles Lindsey]

In <87pu4jjzk3.fsf at erlenstar.demon.co.uk> Andrew Gierth <andrew at erlenstar.demon.co.uk> writes:

>Please, let's leave OVER alone, as simple standardization of existing
>practice, and concentrate on defining HDR in a sane and useful
>fashion. Once this draft is done, we can think about doing a HEADERS
>extension along the lines of the proposal in n.s.nntp (which is what
>this whole discussion is rapidly moving towards).

>I _would_ prefer to see the article header and metadata namespaces
>separated for HDR, because I think it would be more useful in the long
>run (new extensions could add new metadata fields without worrying
>about conflicts). But I'm not that bothered about it, and I definitely
>think that having Lines/Bytes as a special case is better than hacking
>with OVER.

Might have worked with Bytes, but not with Lines. There are two things
wrong with Lines in the present setup:

1. "Lines" is an ordinary-looking word in the response that looks as though it
refers to a genuine header, but is actually metadata.

2. But Ooops! There is also a genuine Lines header, which we explicitly
DON'T want to see.

One might tolerate one special case property as an aberration but, as Lady
Bracknell would have said, getting it wrong twice is going too far.

In any case, no current document (AFAIK) actually defines the behaviour
currently implemented by some systems. So we should just fix the problem
by
1. Returning something syntactically different (e.g. lines:count) for
metadata, and
2. Avoiding the word "Lines" in any form.

This is only the response of obligatory part of the OVERVIEW.FMT we are
talking about. Is any client actually going to notice if we make it
different from what some current systems return? Note that this makes no
difference at all to the OVER command (though it may affect HDR).

>(Another suggestion is whether there should be a LIST subcommand to
>identify what headers are available via HDR. Along the same lines,
>the extension keyword for HDR could have a parameter, say "ALL", if
>HDR on arbitrary headers is supported.)

Actually, there is already a way around this, since the LIST EXTENSIONS
command allows responses with parameters in them (though we have not
constructed any actual examples yet). So we define the new HDR extension
in two flavours, giving:

	[C] LIST EXTENSIONS
	[S] 202 Extensions follow
	    ...
	[S] HDR All
or
	[S] HDR Over-only
	[S] .

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