Subject: Re: [EAI] Re: UTF8SMTP mailbox on SMTP reply (Re: POLL: HDR= extension on MAIL FROM)

From: Chris Newman <[email-masked]>
Date: Fri, 13 Apr 2007 20:09:26 -0700

John C Klensin wrote on 4/10/07 9:40 -0400:
> I was not.  I was referring to the much older idea that we
> should establish single "line" format and forms and let systems
> at the end points convert to and from them rather than creating
> the N**2 problem of everyone being expected to understand
> everyone else's forms (or, in this case, languages and character
> sets).

Quality user interfaces are a non-deterministic problem because they raise all 
the issues about human communication and culture.  This makes engineers who 
want precise answers unhappy for obvious reasons.  Attempting standardize every 
possible error condition that might merit a slightly different user interface 
is a fool's errand and results in a cumbersome infrastructure that can't adapt 
easily.  The problem with enumerating conditions for localization is it 
requires full standards quality interoperability at both ends.  Adding a new 
diagnostic condition requires updates to software on both ends.  Furthermore, 
good user diagnostics generally include references to names, identifiers, who 
to contact for further help, etc.  Trying to create a machine readable syntax 
for a diagnostic code and useful ancillary arguments makes the problem 
sufficiently complex that I don't think it's worth solving.

At the other extreme, we've learned from POP that simple success/fail 
diagnostics are not adequate -- we need machine readable diagnostics for cases 
which merit different software behavior (RFC 3206).

The correct answer is a solid middle ground.  We enumerate diagnostic codes for 
common cases (indeed as many cases as the industry has energy to enumerate in 
standards and/or a registry), but we also transport human readable text to 
handle the less common cases, provide a simple way to embed 
OS/platform/software specific diagnostic codes and identifiers and provide a 
more agile and user friendly experience (because diagnostics can be improved by 
just a server update).  This requires language negotiation which is messy 
(particularly in the SMTP case), but has been implemented and used in deployed 
SMTP software at least for localization of the first part of a DSN/MDN.

> If you are correct, then enhanced status codes are a failure and
> should be pulled of the standards track and junked:  providing
> the adequate foundation to which you refer was a large part of
> the justification for doing those codes in the first place.

The problem we had with the base SMTP codes was that they were too aggressively 
overloaded and too much deployed software didn't treat them in an extensible 
fashion -- basically they fell on the base POP3 side of the necessary middle 
ground. When software has to start keying off the human readable content of the 
status code to determine what to do, then the protocol is broken and needs a 
patch. Enhanced status codes provided that patch and the fact new enhanced 
codes are being defined and deployed is a sign they are useful and successful.

While I've never seen an MUA with a catalog to convert SMTP status codes to 
localized human text, it would be a nice feature for an MUA to have.  But the 
fact that feature hasn't deployed doesn't make the mechanism a failure as the 
mechanism has other purposes (log categorization, automated DSN handling, etc).

> IMO, 2640 is badly broken for other reasons.  Trying to write
> that up and fix it generated a collection of prerequisite work.
> And I have almost the same objections to the POP and IMAP
> proposals that I do to the SMTP one.   However, SMTP is more
> difficult for the usual other reason: FTP, POP, and IMAP all
> require a direct client-server connection (in FTP's case, for
> the command channel) to operate.  Consequently, any negotiations
> about replies are between the client and the server that will
> produce them.  Because of the relay issues, an SMTP negotiation
> about the language and form of responses is much more tentative
> and tenuous.  Certainly it will work sometimes, but the other
> cases a problematic.

Yes, SMTP LANG is a much trickier case than simple client-server protocols.

                - Chris

_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima