ietf-nntp Status report

[Ken Murchison]

Russ Allbery wrote:
> 
> Here's a brief status report on where I think we are:
> 
> The <0> message ID issue has been resolved and requisite changes made.  We
> can sort out any remaining fine details after the next draft.
> 
> I think we're reaching a consensus on how to handle the advertising of
> which headers are available via HDR, namely the LIST HEADERS proposal.
> I've not seen any objections to that; if you don't like that approach,
> please do speak up.  About the only question that I have left is whether
> there should additionally be some way of indicating that certain headers
> are "faster" than others.  It's a good idea, but also may be unnecessary
> extra complexity.

I don't see what benefit this info would provide.  If a client
needs/wants a set of headers, its going to fetch them one way or the
other, whether they are slow or not.  If a server's implementation of
HDR for a certain set of headers is so slow as to make it noteworthy,
then I would suggest that those headers not be listed at all (let the
client fetch them by som other means).

> There's still an open question about what to do about 480/483 response
> codes.  I think that needs more discussion.

I would propose that we just describe 48x in general terms as
authentication/security codes.  Documentating individual codes seems
unnecessary, since the client doesn't need to know the exact details if
it doesn't implement the extensions corresponding to the codes.  In
other words, why do I care to know that I have to do AUTHINFO or
STARTTLS if I can't do either?  In either case, I can't fix the problem.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp