ietf-nntp Backfill: not again.

[Jack De Winter]

>All very interesting (many thought-provoking points), *but* the charter for
>the working group and hence this list is to document how NNTP works at
>present (plus an extension mechanism for future use), and hence how it
>should be used by servers and clients unless/until extensions or changes are
>agreed. *Requiring* clients or servers to change to some new way of doing
>things, with the possible exception of ignoring oddball implementations
>which do something in an unusual way that's (by some definition) just plain
>broken, is outside the scope of what we're doing here - though recommending
>one or other of the currently-used ways of doing something in preference to
>others is OK.

Gack... this again.  We are supposed to document existing practice and
to fix existing bugs.  This does not mean inventing a new mechanism to
do something new.  For example:

- getting SASL support... this is needed and is broken in the spec.  The
	spec says to use the same authentication mechanism as POP and IMAP,
	which are now using SASL
- article numbering/empty groups/backfill - a lot of people consider this
	to be broken... it was not specified enough in the original spec.

If one of these existing practices or fixed bugs breaks something and
we need to change something else to make sure that it doesn't break, I
think that it may fall within the charter.  If one of the ADs or if
the WG Chair is listening, perhaps they can speak about this?

>My understanding is that whether clients *could* be changed to handle 
>backfill is irrelevant - virtually all current clients would not, so 
>defining that servers may do something which requires it is simply not an
>option.

I agree on this point.  It is far easier to make the server handle
something than the client... and easier to replicate.  But in our
'fixes' we should make sure that we are not breaking anything too
bad.  For example, breaking the parallel master/slave feeds by banning
backfill means we have to address it by:

1) providing an alternative mechanism that allows the master/slave
   circumstance to work, including descriptions on how to handle
   missing articles, etc.
2) allow backfill, and thus place the onus on the clients, which is
   going to be difficult to handle at best.

We need to speak to the present in 977bis, not the future.  Let's just
try and document existing practice, and fix existing bugs.

regards,
Jack
-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
(519) 576-3873		http://www.wildbear.on.ca/

Author of SLMail for 95 & NT (http://www.seattlelab.com/)