Matthew Elvey wrote:
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.
I think you and I have given enough warnings about the change.
2)How 'bout the default action becomes protocol-level refusal,
I think you mean "whatever make sense depending on where Sieve is
executed". For where==MDA/MTA, this is a 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?
An option for language is overkill, action priority should be sufficient
and mandatory, IMHO.
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.
I agree, but I want to let future SMTP extensions to be able to remove
this restriction. If I remember correctly the draft already says "error,
unless there is a mutually negotiated extension that allows for 8bit
human readable text".
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.
It is readable, but it is a hack worth being published as an April 1st
RFC :-).
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