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

From: Matthew Elvey <[email-masked]>
Date: Fri, 16 Dec 2005 10:59:20 -0800

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
>

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 30 Dec 2005 20:34:01 +0300

Matthew Elvey wrote:

> '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.
>