ietf-nntp HDR

[Russ Allbery]

Clive D W Feather <clive at demon.net> writes:
> Charles Lindsey said:

>> P50. S9.5.3.1 (HDR)
>> There is a definite Bug here, and possibly some confusion also.

>> Suppose I am in group comp.foo, and ask for "HDR Subject 49". It gives
>> me

>> 	221 Subject fields follow
>> 	49 This is a subject

>> Now suppose I am in group comp.foo, and ask for "HDR Subject
>> <1234 at bar.com>", where the article requested is _not_ in that group
>> (hence no meaningful article number can be provided). It doesn't say
>> what is supposed to be returned. I can envisage two possibilities:

>> 	0 This is a subject
>> 	<1234 at bar.com> This is a subject

>> Giving '0' would accord with similar situations elswehere in the draft.

Furthermore, the current behavior described in the draft does not match
the behavior of INN.  Here's my note when I did the full audit:

  Summary: HDR can return message IDs rather than article numbers
 Standard: draft-ietf-nntpext-base-13.txt, section 9.5.3.1
  Version: 1.0 to CURRENT 2001-07-07
Reference: nnrpd/article.c CMDpat()
 Severity: Violates a protocol description

The standard says:

    The HDR command is used to retrieve specific headers from specific
    articles in the currently selected group.

and:

    A successful response consists of a 221 code followed by the output
    from the command.  The output consists of one line for each article
    where the relevant header line exists.  The line consists of the
    article number, a US-ASCII space, and then the contents of the header
    (without the header name).

This indicates that the first word of any response should be the article
number in the current group, that HDR can't be used outside the current
group, and that in the case of a message ID argument, the server is
required to map that to an article number.

nnrpd instead returns the message ID as the first word of the line when
HDR is given a message ID argument and allows use of HDR outside of any
group.

Impact:  A client may find having the article number useful for a later
OVER command.

Suggested fix:  Do nothing yet, as this section is still in flux in the
draft and it's not clear that the current text is the intended meaning.

> Again, I vote for consistency with ARTICLE. Look at how that's
> formatted: the two syntaxes are given as separate lines and, more
> importantly, with separate lists of response codes.

I definitely agree.  I think the current behavior of INN (returning
message IDs) is wrong, but I also think that the behavior madated in the
draft (figuring out an article number that may make no sense) is also
wrong.  Furthermore, I don't think one should have to be in a group to use
HDR; one doesn't have to be in a newsgroup to use XHDR in INN provided
that the article is specified using a message ID.

> Incidentally, what's wrong with making the range optional and having it
> return data for the current article ? This would require a 420 code to
> be added.

Not existing practice, mainly.  I don't see where this would be
particularly useful.

> However, now I think some more, I recall something. Did we say that this
> command could work for any header ? Or is it intended to work from the
> overview database ?

Ideally, it should work with any header.

The current text also says nothing about what the server should do if one
attempts to grab headers that aren't in overview and one supports only an
overview implementation.  Hm.  I thought we already talked about this, but
I don't remember what we decided.  Does anyone else?

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>