Re: List of open issues with Sieve reject draft

On 7/18/06 1:36 PM, and at other times, Kristin Hubner wrote extensivelyabout 1l8n, and pushed for :exacttext or something like it.

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

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

I do wonder if punycode couldn't be an alternative. I am really loatheto allow any unnecessary blowback. (Incidentally, I personally havebeen 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 ofcomplexity for fairly small gain. I understand users wanting toput reject reasons in their native language. However, the intentof this draft is that reject will operate at the SMTP levelwherever possible. Hence, the reject reason should be very shortand must be usable in an SMTP response. Use of ASCII is best forinteroperability. Use of UTF-8 will only work when EAI extensionsare also being used, or when MDNs are being generated instead ofSMTP protocol responses. Since EAI is new, I don't think we wantto rely on it.
This was discussed a lot on the mailing list. I thought we almostcame to an agreement of not having this option. But then KristineHubner sent the following message:
 &lt;http://www.imc.org/ietf-mta-filters/mail-archive/msg03079.html&gt;

 and I think the message has a point.
To me, the message argues that some mechanism is needed to rejectnon-spam messages. Such a mechanism needs UTF-8 and thereforeshouldn't be at the SMTP level. This argues for a command thatgenerates an MDN. I'd be fine with that.
But this draft is targeted at rejections where doing it at the SMTPlevel 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 (orwhatever) enables UTF-8 response text in SMTP, this extension wouldjust go away.
That is asking for interoperability problems at least until EAI iswidely deployed.
And the intent is to get away from MDNs. Hence, we shouldencourage 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 toallow anything :-).
Unfortunately we can't just require reject reason string to be inASCII, people want to use UTF-8.
Of course people want UTF-8, but the question is why and when. Inother words, which is more important: delivering nice rejectionreasons, or doing SMTP-level rejections? If the nice reasons aremore important, drop this draft and stick to MDNs. If SMTP-level ismore important, require short ASCII strings. If both are needed thenintroduce a new command that always does MDNs, or change this draftto 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 ---