ietf-nntp XOVER & LIST OVERVIEW.FMT; LIST [ACTIVE] and flags

[USENET news manager <[e-mail]>]

Looking at the new SEARCH extension draft has prompted me to notice a few 
points in the main NNTP draft which I think need some attention.

(1) Minor point, but 10.4.6 (LIST OVERVIEW.FMT) is written as though there
will always be a file called overview.fmt. Maybe there will, maybe there
won't, and we're stuck with the name, but I wonder if it should read e.g.

"The overview.fmt file (or equivalent) is maintained ..."

Or is that overstating the obvious? The important aspect is the information
that is returned (content and format), not where it came from. [The same
could be said of various of the other LIST variants which name files, I
suppose.]

(2) 10.4.9 (OVER, which I think is now back to being XOVER) does not provide
an adequate description of the format of the results. While 10.4.6 includes 
a reference to the NOV FAQ (presumably for background info), and that would
presumably provide adequate clarification, I don't think it's acceptable for 
an RFC to rely on an FAQ to fill in the missing details, when the content of
the FAQ may change, cease to exist, etc. 

The particular problem I noticed is that 10.4.9 states that fields are 
separated by TABs, but says nothing about the handling of TABs (in 
particular) or whitespace in general within the fields that are included in 
the results.

The NOV FAQ says that TABs and newlines in the original data are replaced by
spaces. It does not say whether (for example) multiple whitespace characters
should be compressed to a single space (which is probably desirable when a
continued Subject: header acquires multiple spaces from the indentation of
the continuation line, but may be undesirable for other spaces, explicitly
included (for a reason) by the author). NB the FAQ's definition is simply a
quoting from another source...

Anyway, I think the NNTP specification should include sufficient detail that 
the need to rely on the FAQ for clarification can be avoided!

(3) Prompted by considering the SEARCH draft's LIST XACTIVE command, I
realised that 10.4.1 (LIST [ACTIVE [wildmat]]) has an omission which could
cause confusion in general, and probably needs to be pinned down a bit in 
any case for the benefit of e.g. the SEARCH draft.

The only flags mentioned are single characters, but both C-news and INN have 
for many years supported =group.name as a way of aliasing one group to 
another. While I've avoided using that (after getting the impression the 
effects were less than desirable, though maybe only with specific 
implementations), I have the impression that it is very widely used. 

This suggests that even if variation between implementations may mean we
can't define the precise semantics (I'm unclear on that), the widespread
use of =group.name should be recorded. Newsreaders must handle it since 
servers will include it in e.g. LIST ACTIVE output (it is not purely an 
internal matter within the server).

It is also relevant to the LIST XACTIVE command of the SEARCH proposal, 
since that allows for multiple flags, but does not specify the order in 
which they appear (I've already mentioned that on the extensions list). That
is fine if they are all single characters, but if they are multicharacter
strings it matters greatly. Adding letters to the end of an alias "flag"
value would simply extend the group name, whereas if added to the front they
could be identified as distinct flags! It is clearly important to document 
for the benefit of those defining extensions that the flags may not (as the 
examples quoted suggest) always be single characters.

Finally, the draft does mention the "typical" flags, but that doesn't seem a 
strong enough form of words. Since server and client must both understand 
the meaning of the core (y/n/m) flags, simply noting "typical" use is surely 
inadequate? As well as specifying the letters and their meanings, it should 
be indicated whether flags are case-sensitive. I've no idea how newsreaders 
handle that, but suspect that servers should always send lowercase for those
flags (an alias must presumably be mixed-case for a mixed-case group name, 
and mixed-case group names do exist, like it or not...) but at the same time
should not assume that newly-defined uppercase versions would be recognised 
as distinct. Unless we can be reasonably confident that no existing client 
implementations use case-insensitive matching...

                                John Line
-- 
Cambridge University Computing Service - USENET news manager. Usually John Line
[e-mail]    (alias {newsmaster,news,usenet}@news.cam.ac.uk)