[Top] [All Lists]

Re: List of open issues with Sieve reject draft

2006-10-28 23:06:17
On 7/18/06 1:36 PM, and at other times, Kristin Hubner wrote extensively about 1l8n, and pushed for :exacttext or something like it.

Kristin, will you be at IETF 67? Alexey and Randall Gellens (and I, if I attend), will be getting together to discuss :exacttext. (See attached email (which I trust they don't mind me sharing) for discussion points.) I'm thinking it would be good if you could attend.

My own view was last expressed: "The /i18n/ solution is complex, but it does seem to be the simplest solution given the constraints." As much as I hate permitting MDNs and DSNs, I have a hard time imagining telling a Chinese, say, that he can't communicate in his own language, and not feeling ridiculous.

I do wonder if punycode couldn't be an alternative. I am really loathe to allow any unnecessary blowback. (Incidentally, I personally have been receiving huge amounts of blowback over the past month or so.)

--- Begin Message ---
At 11:04 AM +0100 8/2/06, Alexey Melnikov wrote:

 Randall Gellens wrote:

 My comments on -02 apply to -03, with one extra:

Is the exacttext option worth it? It seems to be adding a lot of complexity for fairly small gain. I understand users wanting to put reject reasons in their native language. However, the intent of this draft is that reject will operate at the SMTP level wherever possible. Hence, the reject reason should be very short and must be usable in an SMTP response. Use of ASCII is best for interoperability. Use of UTF-8 will only work when EAI extensions are also being used, or when MDNs are being generated instead of SMTP protocol responses. Since EAI is new, I don't think we want to rely on it.

This was discussed a lot on the mailing list. I thought we almost came to an agreement of not having this option. But then Kristine Hubner sent the following message:


 and I think the message has a point.

To me, the message argues that some mechanism is needed to reject non-spam messages. Such a mechanism needs UTF-8 and therefore shouldn't be at the SMTP level. This argues for a command that generates an MDN. I'd be fine with that.

But this draft is targeted at rejections where doing it at the SMTP level is far more important than delivering a nice reject reason. That argues that only short ASCII strings be permitted.

  So I added the option.
But note, it is controlled by another capability. If EAI (or whatever) enables UTF-8 response text in SMTP, this extension would just go away.

That is asking for interoperability problems at least until EAI is widely deployed.

And the intent is to get away from MDNs. Hence, we should encourage brevity and mandate ASCII.

 Once EAI extensions are deployed we can extend reject to permit UTF-8.

EAI is not required by the draft, the text is inentionally vague to allow anything :-).

Unfortunately we can't just require reject reason string to be in ASCII, people want to use UTF-8.

Of course people want UTF-8, but the question is why and when. In other words, which is more important: delivering nice rejection reasons, or doing SMTP-level rejections? If the nice reasons are more important, drop this draft and stick to MDNs. If SMTP-level is more important, require short ASCII strings. If both are needed then introduce a new command that always does MDNs, or change this draft to use a new command that always does SMTP with a fall-back to DSN.
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
As soon as we started programming, we found to our surprise that it
wasn't as easy to get programs right as we had thought.  Debugging had
to be discovered.  I can remember the exact instant when I realized
that a large part of my life from then on was going to be spent in
finding mistakes in my own programs.
--Maurice Wilkes discovers debugging, 1949 (courtesy of Paul Robinson)

--- End Message ---
<Prev in Thread] Current Thread [Next in Thread>