Re: [Extra] Eric Rescorla's No Objection on draft-ietf-extra-sieve-fcc-08: (with COMMENT)

[Ken Murchison <[e-mail]>]

Hi Ned,


On 1/9/19 10:21 AM, Ned Freed wrote:
>> Eric Rescorla has entered the following ballot position for
>> draft-ietf-extra-sieve-fcc-08: No Objection
>> IMPORTANT
>> S 3.
>>>       copy of the generated message into the mailbox provided in the
>>>       subsequent argument.  The syntax and semantics of the mailbox
>>>       argument MUST match those of the mailbox argument to the "fileinto"
>>>       action specified in Section 4.1 of [RFC5228].  If the specified
>>>       mailbox doesn't exist, the implementation MUST file the message into
>>>       the user's main mailbox (e.g.  IMAP "INBOX").
>> This seems to sort of conflict with S 3.1.1.
> I think you meant 3.1.2 (mailbox extension), not 3.1.1 (imap4flags).
>
>> I assume that the logic
>> is: if (!exists && :create) { try_to_create() }; if (!exists) {
>> file_in_inbox()} else { file_in_fcc_mailbox()}, but this text isn't
>> celar.
> Actually, there's a more serious conflict here. RFC 5228 section 4.1 has this
> to say in regards to the semantics of the mailbox argument to fileinto:
>
>     If the specified mailbox doesn't exist, the
>     implementation MAY treat it as an error, create the mailbox, or
>     deliver the message to an implementation-defined mailbox.  If the
>     implementation uses a different encoding scheme than UTF-8 for
>     mailbox names, it SHOULD reencode the mailbox name from UTF-8 to its
>     encoding scheme.  For example, the Internet Message Access Protocol
>     [IMAP] uses modified UTF-7, such that a mailbox argument of "odds &
>     ends" would appear in IMAP as "odds &- ends".
>
> If the semantics MUST match this, as the document currently says, then you
> can't then require fallback to INBOX if the specified mailbox doesn't already
> exist, since only one of several possible behaviors.
>
> Nor does :create in RFC 5490 actually change this. All the mailbox
> extension does is provide a means to say "create the mailbox". It doesn't
> change the behavior when :create isn't specified, meaning implementations
> are allowed to treat :create as a no-op. (The reason for this, incidentally,
> is that requiring :create for a create operation would potentially invalidate
> existing sieves.)
>
> Or, to put this another way, RFC 5228 says this is also valid:
>
>    if (!exists) { try_to_create() };
>    if (!exists) { file_in_inbox()} else { file_in_fcc_mailbox()}
>
> as well as several other possibilities.
>
> I think the correct way to resolve this is to make the text match RFC 5228
> semantics. The alternative is to note that the semantics here aren't
> those of fileinto, which I see as a least astonishment principle violation.

I agree, and I had originally used the RFC 5228 text.  The current text 
was a result of a comment during AD review, which I have asked him to 
review/reconsider.  My intent is to revert to the 5228 text unless there 
is pushback, in which case I will have to note the semantic difference 
as you suggest.


>> COMMENTS
>> S 1.
>>>       The capability string associated with this extension is "fcc".
>>>
>>>       Each action that generates additional messages will need to specify
>>>       how it interfacts with :fcc.  This document specifies the interaction
>>>       of :fcc with the Vacation [RFC5230] and Notify [RFC5435] extensions.
>> Are these the only such actions?
> They are the only standardized ones. There are probably implementations
> of the old notify draft out there:
>
>    https://datatracker.ietf.org/doc/html/draft-martin-sieve-notify
>
> and there may be other stuff as well.


Well, there is [e]reject, but we decided to remove the section stating 
that :fcc is incompatible.  We can certainly add it back in.


-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC