[Top] [All Lists]

Re: Confirming WG consensus: combine reject and refuse into a single action

2005-12-30 10:58:16
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. 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.


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.



<Prev in Thread] Current Thread [Next in Thread>