[Top] [All Lists]

Re: BATV pseudo-Last Call

2008-05-19 20:49:18

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
also concerned.

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
                        document author.

    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 shown here:

    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
   same code.

<Prev in Thread] Current Thread [Next in Thread>