From: Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu>
Date: Fri, 01 Feb 2002 21:42:56 -0500
[...]
We had a similar discussion regarding SMTP extension names, and I
like the compromise we came up with - SMTP extension names can be
reserved with either a standards-track document, or an experimental
document with IESG approval. That allows extension names to be
reserved for proposals that are publicly documented and have had
a basic sanity check even if they're not deemed ready for prime time -
but if the extension proves worthy of standardization without
incompatible change, the same extension name can be used.
Ok, so Cyrus IMAP uses LMTP extensively, which uses SMTP extensions.
Our LMTP server advertises "IGNOREQUOTA". There's even an
internet-draft about it (which hasn't expired, but it will in March).
Did we do the right thing? We don't have a "standards-track document"
nor IESG approval.
My concern is for interoperability and reliability of Internet mail.
I'm not as concerned with labelling something "right" or
"wrong" as with encouraging behavior that makes email work better.
If we're arguing about what the rules for extensions should be, I'll
recommend a set of rules that I think will help promote interoperability
and reliability.
If you ask me whether you should document a protocol extension and/or
get review before deploying it, I'll recommend that you do so because
I think that will promote interoperability and reliability (unless
I'm firmly of the opinion that your extension is a Bad Idea, in which
case I'll recommend that you don't deploy it at all and/or try to suggest
something that I think will work better.)
If you ask me what to do when you've already deployed a protocol extension,
I'll recommend whatever actions I think will help promote interoperability
and reliability.
(Note that interoperability and reliability includes having email work
unsurprisingly and predictably across a wide range of user agents -
and there is a general tendency for new extensions to any protocol
to introduce surprising behavior.)
What's the danger that someone else will use the same keyword (in either
SMTP or LMTP) to mean something different? What's the danger that someone
else will try to implement your extension but do so in a way that harms
interoperability or reliability of ail delivery? What can you do to
minimize such danger?
Even if the LMTP spec says it uses SMTP extensions, that doesn't mean
that using a non-SMTP extension in LMTP is violating the SMTP standard,
nor does it mean that the rules for extending SMTP should inherently apply
to LMTP.
Still, it would be good to publish the spec for the extension as
an Informational or Experimental RFC, so that if others want to
implement something like this they'll have your spec to go by.
Keith