[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: List of open issues with Sieve reject draft
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
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.
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 ---