New SMTP response codes

"Paul E. Hoffman" <phoffman@imc.org> Wed, 14 May 1997 01:14 UTC

Received: from cnri by ietf.org id aa07154; 13 May 97 21:14 EDT
Received: from mail.proper.com by CNRI.Reston.VA.US id aa20681; 13 May 97 21:14 EDT
Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA21814 for ietf-smtp-bks; Tue, 13 May 1997 17:58:57 -0700 (PDT)
Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id RAA21806 for <ietf-smtp@imc.org>; Tue, 13 May 1997 17:58:54 -0700 (PDT)
Message-Id: <v0310282eaf9ebd82fe9d@[165.227.249.100]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 13 May 1997 17:59:40 -0700
To: ietf-smtp@imc.org
From: "Paul E. Hoffman" <phoffman@imc.org>
Subject: New SMTP response codes
Sender: owner-ietf-smtp@imc.org
Precedence: bulk

And now for something completely different. I needed a new SMTP response
code for an SMTP extension I'm writing. However, I could not find any
central registry of them. This seems to be a bit of a problem, because I
don't want to choose the same one that some other extension writer has
chosen.

(I'm pretty sure I didn't. I grepped all the mail-related drafts and RFCs
on the IMC site for "560", the number I chose, and got nothing relevant.)

This isn't a pressing need, but it could be embarassing if we end up with
two standards-track SMTP extensions that use the same new error code for
very different things. Sounds like a job for IANA, but we need to define
what IANA should do.

My straw-man proposal is:

- Start with a list of all response codes from 821 and all standards-track
RFCs (I can compile this)

- Generally treat this like the TCP port number reservation scheme (first
come, first served)

- Require that a registrant provide:
Name
Email address
Name of Internet Draft the code is used in
Date of first use

Because the response code space is limited, it might eventually fill up and
someone will have to go through and cull out the response codes that were
reserved but for which there is no valid Internet Draft or RFC.  However,
that will hopefully not happen for a decade or two, given that SMTP
extensions should not be promulgated willy-nilly.

Thoughts?

--Paul E. Hoffman, Director
--Internet Mail Consortium