ietf-nntp Niggles

[Russ Allbery]

Charles Lindsey <chl at clerew.man.ac.uk> writes:

> P17.

>    o  A message-id MUST NOT contain octets other than printable US-ASCII
>       characters.

> Is is sufficiently clear that SP is "non-printable"? Some would argue
> that is it printed, but it just so happens that the amount of ink
> deposited is zero.  Would do no harm to clarify.

Printable characters are defined elsewhere in the draft, I believe.  We've
discussed this point before.

>    If the requested header is not present in the article or if it is
>    present but empty, a line for that article is included in the output

> That is not my understanding of the case when the requested header is
> absent from the article, and it is not consistent with what is said on
> the previous page:

We had a long conversation about this and I believe the above is correct.

>    If the information is available, it is returned as a multi-line
>    response following the 225 response code and contains one line for
>    each article where the relevant header line or metadata item exists
>    (note that unless the argument is a range including a dash, there
>    will be at most one line but it will still be in multi-line format).

I think this is the one that's incorrect; the output should contain one
line for each article that exists.

If someone has a chance to go back in the archives and find the
discussion, though, that would be useful.

> 8.6.2.1 Usage

>    Syntax
>       LIST HEADERS

> Why is this command not optional in the same way as LIST OVERVIEW.FMT?

The supported set of headers will vary a great deal more between servers
than it does for overview, where LIST OVERVIEW.FMT is basically a
formality nearly all the time.

> P96.

>       <abcd at example.com>
>       <"abcd"@example.com>
>       <"ab\cd"@example.com>

>    as being identical. Therefore an NNTP implementation handing email
>    articles must ensure that only one of these three appears in the
>    protocol and the other two are converted to it as and when necessary,
>    such as when a client checks the results of a NEWNEWS command against
>    an internal database of message-ids.

> That is a mess which one hopes some future revision of RFC 2822 will fix
> (by moving the 'bad' cases to its 'obsolete' syntax). So I would not
> encourage implementors to dally with that nonsense (better just to
> compare the bytes and if it breaks then the nonsense will be truly seen
> for what it is).

Regardless of your optimism about the future, I think the current text is
accurate and useful and I think it should be retained.

> More importantly, I think you should make it clear that this nonsense is
> NOT needed with Netnews,

I find that already sufficiently clear, but I don't really care if someone
feels the urge to add more language to that effect.

>    A common approach, and one that SHOULD be used for email and Usenet
>    articles, is to extract the message-id from the contents of a header
>    with name "Message-ID". This may not be as simple as copying the
>    entire header contents; it may be necessary to strip off comments and
>    undo quoting, or to reduce "equivalent" message-ids to a canonical
>    form.

> No, that is bad advice so far as Usenet is concerned.

The paragraph isn't only talking about Usenet.  I think it's fine.

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