Date: 18 Jan 1997 06:18:39 -0000
Message-ID: <19970118061839.16455.qmail@koobera.math.uic.edu>
From: "D. J. Bernstein" <djb@koobera.math.uic.edu>
To: drums@cs.utk.edu
Subject: Re: I-D ACTION:draft-ietf-drums-MHRegistry-00.txt

> There is an obvious risk that the
> same header name is used in different ways by different software
> products.

Yes, this risk is obvious, but you'd do a better job of addressing it if
you identified the causes:

(1) An implementor may accidentally reuse an existing field name. The
direct solution is to maintain a central list of names in use.

(2) An implementor may accidentally misuse another implementor's field.
The direct solution is to maintain a central list of pointers to field
definitions.

(3) Two implementors may supply conflicting definitions for a field. The
direct solution is to delegate spec authority to one implementor.

Your system does a poor job for #1, does only a marginally better job
than RFCs for #2, and does nothing for #3.

> The following words are used in this memo with the meaning
> specified below:

The standard terminology is ``field name,'' ``field,'' and ``header,''
not ``header name,'' ``header,'' and ``heading'' respectively.

> Anyone can propose the registry of additional headers, but such
> headers should be approved by the IETF application area managers
> before accepted in the registry.

This restriction will exacerbate the risk that your document is supposed
to address.

> maximum interoperability is attained by restricting the
> number of headers used to those "common" headers expected to be
> widely implemented.

I don't believe you.

In two minutes of searching recent mail I found 342 different field
names. An MUA that barfs on unrecognized names simply can't survive.

> The registration process requires the identification of any
> known security problems with the header name.

This restriction will exacerbate the risk that your document is supposed
to address.

---Dan
Put an end to unauthorized mail relaying. http://pobox.com/~djb/qmail.html