Re: Supersedes and Expires

On Wed, 1 Jul 1998, Henry Spencer wrote:

> > The specification defines what the message format is. It does not call for 
> > network wide use...
> 
> Sure it does -- or is it your contention that USEFOR is not intended to
> apply to Usenet?

USENET is not the whole network, nor is it the only "news network". Others
have already pointed out that putting requirements in USEFOR that are good
for USENET but not necessarily what regional or local hierarchies need to
do is wrong. For example, restrictions on content. This is another such
case.

> Quite true.  The point is not that everybody should be forced to use the
> same key-distribution system, 

If you put it in USEFOR and expect it to be "network wide", yes, indeed,
you will be trying to force everybody to use it.

> but that a key-distribution scheme capable
> of handling worst-case requirements should *exist* before we publish a spec
> that can't be implemented without one.

>  (In fact, simple manual handling of key lists should
> be viable in tightly-controlled private networks.)

Then it is not unreasonable to define a message format that allows this to
happen.

> nobody knows how to do it adequately in the Usenet environment.  This is
> perilously close to the sort of "nobody cares whether it's implementable" 
> idiocy that ISO is known for, which is utterly out of place in IETF. 

I challenge you to show where anyone has said that nobody cares if it can
be implemented or not. What I have said is that defining the message
format is not dependent on implementing the whole system. You think it has
to be done all at the same time. I think it is sufficient for a document
that defines message formats to simply define message formats.

> No, you've missed the point, although I plead guilty to stating it poorly.
> The moderator list works because it's not all that important that each
> site have a complete and current list.  (Indeed, most sites that I'm

And it is not all that important that each site have a full and complete
list of spam cancellers. Those who do not care need not have any list.
Those who want to be able to cancel spam on their own need the list.

What is the worst that happens if a site doesn't have the list? They don't
cancel some messages. Big deal. Some sites don't cancel ANY messages now.
Some sites are so far down the chain that they don't spend much time
cancelling things they do accept cancels for.

> familiar with don't bother -- they just point moderated-group postings at
> one of the big sites that maintains a full set of aliases.)  Manual update

So, there's a hint how to provide lists to those who don't want to keep
their own. "Point to a big site that maintains a full set..."

> That's fine for the moderators list, but useless for an application where
> having correct, current, trustworthy information almost everywhere is really 
> important.

Let's see. There might be a problem if someone gets his name on the
approved spam canceller list inproperly. Then he can cancel
indiscriminately. But this isn't likely to happen in a system where
changes are slow and manual, is it? The "problem" will be either someone
who has stopped depamming is still on the list or a new one isn't added
right away. If he was a spam canceller and you allowed him free reign, I
suppose he could break trust and cancel at will, but he can already do
that.

> Not quite.  What we want is not just a format for authenticated cancels,
> but a design for an authenticated-cancel system.  This is relevant here
> because the system design dictates the format -- you can't devise a format
> without having at least a general idea of how the system will work, and if
> you haven't filled in the details, there is serious danger that the format
> will be wrong or inadequate.  We should not be trying to specify the
> format without knowing what requirements it will have to satisfy.

You can know what requirements it will have to satisfy without knowing how
the background support data will be transported. We know that a cancel
will have to contain authentication data. We know that the articles will
have to contain a multi-valued header with secret data. We know how first
and third party cancels can be accomplished today. We know how fourth
party cancels can be accomplished.

What we don't know is how the list of fourth party authorized cancellers
will be distributed, or who will decide who gets on it. The latter is a
social issue, not a technical one. That list is NOT part of the message
standard (unless you think that distributing it via news is particularly
handy or viable), and even if it is, it does not need to be the same
format as cancels or user-included authentication data. 

> And the key-distribution problem is central to the system design.  It's
> *not* a separate issue.  A viable cancel-authentication system is maybe
> 10% authentication and 90% key distribution.  Because of this, designing
> such a system is harder than it looks.

Key distribution for first and third party cancels is already defined. How
the keys get distributed for fourth party cancels is not defined, and if
extra-news systems are going to used for distributing them, it doesn't
belong in a document that defines message formats for news.

> It doesn't happen *unless* some of the people who dismiss key distribution
> as a trivial issue that's not our problem -- even though we need it and
> nobody knows exactly how to do it -- buckle down and solve it, in detail,
> with careful attention to the real environment in which it will operate. 
> It shouldn't be impossible, but it requires effort, not just hand-waving.

First and third party cancels have already been solved, and should be in
the standard. The format for fourth party cancels can also be included,
even though the specific key distribution system has not been designed. 

"We need to design a bulletproof key distribution system for news." "Why?
There is no standard that defines how those keys will be used."

"We need to design the format for cancels and headers that will be
required to allow authentication in regular messages." "Why, There is no
method to distribute the keys required to implement one kind of
authenticated cancel, and until we can do all of them, we can't do any of
them."

We can do an important part of the cancel system now. If we wait until
EVERY kind of cancel can be accomplished, we risk waiting for eternity.
What if nobody ever comes up with a bulletproof system for distributing
keys?