Sorry I missed Vancouver.
While there's a desire to combine reject and refuse into a single
action, there isn't an expressed consensus (AFAIK) about how to handle
the details. The current draft works, so let's not jump ship 'till we
know where we're headed.
Some open issues if we're to combine the two.
1)Is there a consensus to continue to use (i.e. redefine) the verb
"reject" in this non-backwards-compatible way and have it claim to
support require "reject" ?
If anyone objects, SPEAK NOW, or face my wrath if you don't speak up
'till much later. :) And yes, I fear that that the issue may come up in
the final (non-WG) last call. IMHO, there needs to be consensus support
for this EXPRESSED BY SEVERAL FOLKS NOW, or we should not continue on
this path. Please reply, folks! If there's broad support for this
expressed now, it will help with the final approval stages.
2)How 'bout the default action becomes protocol-level refusal, as the
current draft specifies, but there would also be optional options to
specify language or action priority, per Kristin's needs. Should
support for these be mandatory or optional? Please let us know you
object if it's optional (indicated by support for <require
"rejectoptions">), Kristin. As Cyrus has mentioned, some sysadmins will
want to support the new spec, but NOT want to allow DSNs to be sent, so
making support for language priority mandatory won't fly.
3)How do we deal with non-US-ASCII in the default case? Consider it an
error as the current draft does? I think so. If the error is in a
romance language such as French or Italian, it will be understandable
even if mapped to US-ASCII. Perhaps US-ASCIIfied Russian is
intelligible too. But I know of no easy way (e.g an Open Source
library) to do such mappings.
http://en.wikipedia.org/wiki/Roman_alphabet is informative. I'm
confident that most Chinese would NOT understand Pinyin Chinese.
Let's try to keep it simple! I very much do NOT want to write a spec
that's more complex than absolutely necessary.
On 11/21/05 3:53 PM, Kristin Hubner sent forth electrons to convey:
On Nov 18, 2005, at 7:49 AM, Alexey Melnikov wrote:
Hi folks,
During the Vancouver IETF people in the room have agreed that Sieve
writers don't care about difference between MDNs, DSNs and protocol
level refusals. So refuse and reject actions will be combined into a
single action, which will generate protocol level refusals, MDNs or
DSNs, depending on what is appropriate. If anybody objects to this
decision, please speak up now.
Alexey
As long as the "combined" action would have the ability to deal with
the charset issues, I don't object.
That is, I'd like to see not only an ability to specify non-US-ASCII
rejection text, but also a way to choose whether the use of
the non-US-ASCII reject text is mandatory (hence disabling SMTP
level rejection -- user prefers to use their own text rather than
get SMTP level rejection), or optional (used only when an inability
to do an SMTP level rejection for other reasons has already caused
"fall back" to the DSN or MDN approach). That way, we could
satisfy the users who really, really want their own rejection text
used, and the users who want SMTP level rejection when possible but
when not possible want then to go ahead and use some non-US-ASCII
rejection text.
Regards,
Kristin