John Levine wrote:
Again, I'm not proposing a change. I'm merely a little worried that
the syntax is insufficiently unique and I'm wondering if others are
It would make sense to create a registry of local part prefixes,
probably limited to prefixes of the form xxx= where the xxx is a
string of letters and digits.
Here's suggested text for an IANA Considerations section.
7. IANA Considerations
IANA is directed to create the registry "Bounce Address Tag
validation (BATV) Tag Schemes". The BATV Tag Scheme table has
the following entries in it:
Tag Scheme Code: A short tag for the tag scheme, following the
ABNF given in RFC XXXX.
Tag Scheme Name: The full name for the tag scheme.
Description: A short description of the code.
Reference: A reference to the document in which the tag
scheme is defined. This reference should note
whether the relevant specification is
standards-rack or not, using "(Standards track)"
or "(Not standards track)".
Submitter: The identity of the submitter, usually the
Change Controller: The identity of the change controller
for the specification. This will be "IESG" in
the case of IETF-produced documents.
7.1. The initial entry for the prvs tag scheme defined in this RFC is
Tag Scheme Code: prvs
Tag Scheme Name: Simple Private Signature
Description: The Simple Private Signature (PRVS) scheme signs
the original MailFrom by using a simple
shared-key to add a hash of the address and some
time-based randomizing information.
Reference: RFC XXXX
Submitter: J. Levine, D. Crocker, S. Silberman, T. Finch
Reference: RFC XXXX. (Standards track)
Change controller: IESG.
7.2. Review Process for New Values
Entries in this registry are expected to follow the "Specification
Required" model ([RFC2434]) although, in practice, most entries are
expected to derive from standards-track documents. Non-standards-
track documents that specify codes to be registered should be readily
available. The principal purpose of this registry is to avoid
confusion and conflicts among different definitions or uses for the