SM wrote:
That's a pretty strong argument in favour of creating something new
rather than overloading something old. But that too runs headlong
into likely interoperability concerns. There's a bit of induced
paralysis there that needs to be overcome.
Yes.
I would say that it is more about adoption than interoperability. There
is also "domain of applicability" to consider. It can help in
addressing interoperability concerns or even protocol "violations".
Someone else suggested nothing parses SMTP replies beyond the three
digits. That's not true in ESMTP; the enhanced status codes (if used)
and the reply to EHLO itself are structured. It's not true in pure
SMTP either, where I think some of the replies are specified beyond
the three digits (the 220 greeting, the reply to HELO, and the 221
message, as I recall).
The keyword is "structured text".
It seems to me that once this door is open (wider) to begin developed
new SMTP methods, that it may be a good idea to create a base protocol
that will define a particular text based data structure all new
methods can use consistently. This will allow a SMTP client to single
source its parsing code for all applications.
Just winging it, but the I-D
May start with the ABNF
*(tag "=" value [ ";" / SP ])
Even a consideration to use JSON syntax where solid parsers already
exist in all major languages.
With rules such as where it can places in the text string:
- end of the line only?
- Anywhere, but after any Extended Codes?
- Last line for multiple line responses?
This can really help in other areas too:
- offer a "url=" tag for references,
- Some already mention the idea of exposing server info/limits
and a MX= hint
and without a doubt open the door for new great SMTP client/server
negotiation ideas using a structured text response syntax.
Don't wish to suggest more work for Murray, but it sounds like to
something Murray can quickly create with his experience creating other
base format RFC protocols.
--
Sincerely
Hector Santos
http://www.santronics.com
jabber: hector(_at_)jabber(_dot_)isdg(_dot_)net