Subject: [Extra] Francesca Palombini's No Objection on draft-ietf-extra-sieve-mailboxid-07: (with COMMENT)

From: Francesca Palombini via Datatracker <[email-masked]>
Date: Fri, 12 Mar 2021 03:41:28 -0800

Francesca Palombini has entered the following ballot position for
draft-ietf-extra-sieve-mailboxid-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-mailboxid/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for this document, which I found clear and easy to read.

I would only like to bring up again Magnus unanswered comment about formal
syntax, and hope that the working group can address that before the document
moves forward. Thread starting here:
https://mailarchive.ietf.org/arch/msg/extra/zuH2VTx-NoXQXFzQ1PeJJkts0Bo/

Francesca

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 12 Mar 2021 04:04:45 -0800

> https://mailarchive.ietf.org/arch/msg/extra/zuH2VTx-NoXQXFzQ1PeJJkts0Bo/

As it happens, EXTRA is meeting at IETF 110 in a couple of hours, and I
think the plan is to discuss this there.

-MSK

---

From: "Bron Gondwana" <[email-masked]>
Date: Fri, 12 Mar 2021 23:19:30 +1100

On Fri, Mar 12, 2021, at 23:04, Murray S. Kucherawy wrote:
> On Fri, Mar 12, 2021 at 3:41 AM Francesca Palombini via Datatracker <[email-masked]> wrote:
> As it happens, EXTRA is meeting at IETF 110 in a couple of hours, and I think the plan is to discuss this there.
> 

Sure is!  I'm putting together slides right now, because there's nothing like the last minute.

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [email-masked]

---

From: "Bron Gondwana" <[email-masked]>
Date: Tue, 16 Mar 2021 15:29:29 +1100

> Sure is!  I'm putting together slides right now, because there's nothing like the last minute.

Conclusion from the meeting was:

1) let's just put in the ABNF for FCC-OPTS since that has consistent syntax that it makes sense to complete.  For everything else, less than 1/4 of existing sieve extensions have ABNF, so it's not really sensible to try to extend that - it's all been done with prose.

2) we need to make the :fcc behaviour match the fileinto behaviour for the relationship between specialuse and mailboxid tests.

I made both those changes and uploaded -08 right now.

Cheers,

Bron.

---

From: "Bron Gondwana" <[email-masked]>
Date: Tue, 16 Mar 2021 23:50:23 +1100

Murray pointed out that I STILL had it wrong.  Uploaded again with a much better version :)

   MAILBOXID-OPT = ":mailboxid" objectid

   FCC-OPTS =/ MAILBOXID-OPT

objectid is defined in RFC8474 as:

      objectid = 1*255(ALPHA / DIGIT / "_" / "-")
              ; characters in object identifiers are case
              ; significant

Of course now that I've posted this, I do wonder if I actually need to make it:

MAILBOXID-OPT = ":mailboxid" SPACE DQUOTE objectid DQUOTE

*sigh*.

I mean, RFC8580 already doesn't seem to be very specific about the whitespace between tokens - but I expect we probably do want the mailboxid to be a string rather than an objectid for parser simplicity.  I welcome input on that!  (I'm pretty sure the parser we have in Cyrus right now needs it to be a string for example)

Cheers,

Bron.

On Tue, Mar 16, 2021, at 15:29, Bron Gondwana wrote:
> _______________________________________________
> Extra mailing list
> [email-masked] <mailto:Extra%40ietf.org>
> https://www.ietf.org/mailman/listinfo/extra
>

---

From: Ken Murchison <[email-masked]>
Date: Tue, 16 Mar 2021 09:14:43 -0400

On 3/16/21 8:50 AM, Bron Gondwana wrote:
> I mean, RFC8580 already doesn't seem to be very specific about the 
> whitespace between tokens - but I expect we probably do want the 
> mailboxid to be a string rather than an objectid for parser 
> simplicity.  I welcome input on that!  (I'm pretty sure the parser we 
> have in Cyrus right now needs it to be a string for example)

I don't think adding SPACE is necessary, and no other extension does this.

We definitely want :mailboxid to take a string as argument, since 
RFC5228 doesn't specify anything other than numbers, strings, and 
stringlists.

You can probably do something like what the imap4flags and special-use 
extensions do and simply define:

MAILBOXID-OPT = ":mailboxid" <mailboxid: string>

and state in the text that the mailboxid string is limited to the 
characters allowed in objectid.  Of course, even if you don't state 
this, and the string contains invalid objectid chars, the script will 
still parse as valid, but just not match any mailbox.

>>>> On Fri, Mar 12, 2021 at 3:41 AM Francesca Palombini via Datatracker 
>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>
>>>>     <https://mailarchive.ietf.org/arch/msg/extra/zuH2VTx-NoXQXFzQ1PeJJkts0Bo/>
>>>>
>>>>
>>>> As it happens, EXTRA is meeting at IETF 110 in a couple of hours, 
>>>> and I think the plan is to discuss this there.
>>>>
>>>
>> 1) let's just put in the ABNF for FCC-OPTS since that has consistent 
>> syntax that it makes sense to complete.  For everything else, less 
>> than 1/4 of existing sieve extensions have ABNF, so it's not really 
>> sensible to try to extend that - it's all been done with prose.
>>
>> 2) we need to make the :fcc behaviour match the fileinto behaviour 
>> for the relationship between specialuse and mailboxid tests.
>>
>> <https://www.ietf.org/mailman/listinfo/extra>
>>
>
> --
> [email-masked]

-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 16 Mar 2021 13:32:03 +0000

> I don't think adding SPACE is necessary, and no other extension does this.
Right, Sieve ABNF is applied to tokenized input, so whitespaces don't 
appear.
> characters allowed in objectid.
>
Makes sense.
>
>   Of course, even if you don't state this, and the string contains 
> invalid objectid chars, the script will still parse as valid, but just 
> not match any mailbox.
>

---

From: "Bron Gondwana" <[email-masked]>
Date: Thu, 18 Mar 2021 11:33:02 +1100

On Wed, Mar 17, 2021, at 00:14, Ken Murchison wrote:

> We definitely want :mailboxid to take a string as argument, since RFC5228 doesn't specify anything other than numbers, strings, and stringlists.

> You can probably do something like what the imap4flags and special-use extensions do and simply define:

> and state in the text that the mailboxid string is limited to the characters allowed in objectid.  Of course, even if you don't state this, and the string contains invalid objectid chars, the script will still parse as valid, but just not match any mailbox.

Yeah right, this is pretty much reverting to what I had in the previous revision!  OK, I'll go revert :)

Bron.