Re: [Extra] I-D Action: draft-ietf-extra-sieve-special-use-01.txt

[Stephan Bosch <[e-mail]>]

Hi Ned,


Op 13/06/2018 om 17:40 schreef Ned Freed:
>> > This, incidentially, is one of those places where providing the 
>> actual IMAP
>> > commands will be especially valuable: Pointing out that you should 
>> use the
>> > NAMESPACE extension and if it isn't present, fallback to LIST "" 
>> would be very
>> > helpful.
>
>> Here's my initial attempt at addressing this point (separate branch in
>> Github):
>
>> https://github.com/ietfextra/draft-ietf-extra-sieve-special-use/commit/035a1af6137a383089c8d54cd733238dc2dfebda 
>>
>
>> This adds an IMAP example for specialuse_exists.
>
>> What do you think?
>
> The first step seems fine:
>
>   C: A01 NAMESPACE
>   S: * NAMESPACE (("INBOX/" "/")("Archive/" "/")) NIL (("Public/" "/"))
>   S: A01 OK NAMESPACE command completed
>
> In the next step:
>
>    Subsequently, when no particular mailbox is of interest (i.e., the
>    "specialuse_exists" test has no mailbox argument), the client lists
>    all mailboxes with special-use flags in the two returned personal
>    namespaces:
>
>    C: A02 LIST (SPECIAL-USE) "" ("INBOX/*" "Archive/*") RETURN 
> (SPECIAL-USE)
>    S: * LIST (\Drafts) "/" INBOX/Drafts
>    S: * LIST (\Trash) "/" INBOX/Trash
>    S: * LIST (\Sent) "/" INBOX/Sent
>    S: * LIST (\Archive) "/" Archive/Default
>
> It should be noted that this depends on extended list being available.

True. I thought LIST-EXTENDED is pretty much required for SPECIAL-USE, 
but the specification doesn't actually mention anything like that. Is 
there another way to obtain information on which mailboxes have a 
particular special-use flag assigned?

> The final step is:
>
>    C: A03 SELECT Archive/Default
>    S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
>    S: * OK [PERMANENTFLAGS (\Answered \Deleted \Seen \Draft \*)] Flags 
> permitted.
>    S: * 11211 EXISTS
>    S: * 3 RECENT
>    S: * OK [UIDVALIDITY 1526903163] UIDs valid
>    S: * OK [UIDNEXT 11278] Predicted next UID
>    S: A03 OK [READ-WRITE] SELECT command completed
>
> There are several issues here.
>
> First, if you're going to use SELECT it's probably worth noting that 
> since
> inclusion of [READ-WRITE] for writable mailboxes is a SHOULD in RFC 
> 3501 while
> inclusion of [READ-ONLY] for non-writable is a MUST, a writability 
> check really
> needs to based on the absence of [READ-ONLY]. (RFC 5490 3.1.a appears 
> incorrect
> to me in this regard - should I file an errata?)

Agreed.

> However, I think use of SELECT for this purpose is problematic: It's
> potentially expensive and worse, may cause undesireable state changes. 
> Why
> not use the MYRIGHTS command to obtain the access rights (and check 
> for "p" or
> "i") without having to select the mailbox?

Sure, if the ACL capability is available. I can mention that. If it is 
not available, there is really no alternative to using SELECT, right?

> And as a bonus, if it's available you could use the just-standardized
> LIST-MYRIGHTS extension to piggyback getting the rights while getting 
> the list
> of special-use mailboxes.

Sure.

> More generally, this is why documenting the things necessary to 
> implement the
> necessary semantics of an extension is helpful - there may be 
> optimizations and
> concerns that should be called out lest implementors miss them.
>
> It also helps clarify overall implementation difficulty. And while this
> extension may be easy to implement in the Sieve-in-IMAP case, from the
> perspective of an MTA/MDA implementation, even if all of the steps can 
> be done
> efficiently, there's still the question of IMAP server availability 
> and the
> handling of temporary errors.
>

Yeah.

> All of which is roundabout way of saying I now think that we may want a
> capability for specialuse_exists that's separate from
> "special-use"/:specialuse. Or better still, since we already have the 
> "mailbox"
> capability for "mailbox access stuff", I think we should require the 
> presence
> of both "mailbox" and "special-use" capabilities in order to use
> specialuse_exists.

Can you clarify this point? I don't see how this leads to requiring the 
mailbox extension.

> I also reviewed the rest of the revised draft, and it's looking good. 
> My one
> remaining concern is with the handling of multiple mailboxes having the
> same special-use flag assigned. The draft currently says:
>
>   More than one mailbox in the user's personal namespace can have a
>   particular special-use flag assigned.  In case of such ambiguity, the
>   mailbox that is chosen for delivery is implementation-defined.
>   However, while the set of mailboxes to which the involved special-use
>   flags are assigned remains unchanged, implementations MUST ensure
>   that the mailbox choice is made consistently, so that the same
>   mailbox is used every time.  Conversely, the chosen mailbox MAY
>   change once the special-use flag assignments that are relevant for
>   the mailbox choice are changed (usually by user interaction).
>
> I don't see a way I can reasonably implement this MUST via IMAP unless 
> the IMAP server always returns the list of special-use mailboxes in 
> the same order.
> Sure, I can cache the user/special-use-attribute/actual-mailbox-list 
> tuple
> somewhere, but caches can always be lost. And mailbox metadata is (a)
> Potentially much too expensive and (b) Subject to the vagarities of user
> actions.
>
> I'm not happy about it, but I think this needs to become a SHOULD.

Ok. I am not too attached to the MUST anyway.

> Another possibility is to use the default mailbox name as a means of
> disambiguating multiple mailboxes with the same special-use attribute:
> If the default mailbox is one of these deliver to it preferentially,
> otherwise the behavior is implementation-defined. Not perfect, but it
> provides a bit more consistent behavior that's easily achievable.
>

Sounds like a good idea. I'll give this a closer look for the next revision.

> Aside from these issues, this draft looks good to go to me.

I still need to make an IMAP example for "fileinto :specialuse".

I should be able to work on this next week.

Regards,

STepham.