Re: [Extra] Call for adoption, draft-gondwana-sieve-mailboxid

[Bron Gondwana <[e-mail]>]

On Sun, Aug 12, 2018, at 08:56, Ned Freed wrote:
> 
> 
>> On 08/11/2018 02:55 PM, Ned Freed wrote:
>>>> This extension can probably interact with :fcc.
>>> 
>>> Definitely.
>>> 
>>>>   Should the interop be
>>>> described in this draft of the :fcc draft?
>>> 
>>> Why not have it build on the :fcc draft instead of creating a
>>> dependency>>> in the other direction?
> 
>> Agreed.
> 
> 
> 
>>>> Additionally, the :mailboxid argument probably doesn't play
>>>> well with>>>> :create, or at least I don't see how it could without a mailbox
>>>> name.>>> 
>>> Not sure I see the conflict. Of course you can't create a mailbox
>>> with the specified objectid, but in the fallback case :create would>>> still be valid.
>>> 
>>> It just needs to be spelled out in the document.
> 
>> :create wouldn't have a mailbox name to use if :mailboxid is
>> specified.>> :mailboxid changes the positional parameter in fileinto from a
>> name to>> an id (unless I'm reading it incorrectly).
> 
> Missed that, sorry.
> 
> I'm not sure I agree with this approach. Why not use the :specialuse
> approach instead, where :specialuse takes an argument specifying the
> specialuse mailbox and if it doesn't exist then the regular fileinto
> argument is used instead.
> 
> Wouldn't a similar semantic make sense for objectid in the event
> that the folder with the specified objectid is gone?

Hrmm... yeah, I guess you could do that with a fallback of INBOX if you
didn't have a different name to specify.
I wasn't sure if that would be too confusing to somebody reading:

fileinto :mailboxid "F213478" "INBOX.Foo";

And then having both INBOX.Foo and a different renamed folder exist.

I do agree that it's more consistent to match the specialuse draft
though - especially by not repurposing the positional parameter.  I'm
happy to update the draft and my implementation.
Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [e-mail]