[Extra] AD review of draft-ietf-extra-sieve-mailboxid-03

[Barry Leiba <[e-mail]>]

Here's my AD review of the subject document.  I have some issues to
discuss about the specification, so please read my comments and let's
have the discussion.  I'll set the substrate to "AD Followup".

— Section 1 —

   By extending "fileinto" to reference the immutable mailboxid
   specified by [RFC8474] , sieve rules can continue to target the same
   mailbox, even if it gets renamed.

The sieve rules are not extending fileinto; this document is.

NEW
   By telling "fileinto" to reference the immutable mailboxid
   specified by [RFC8474], using the extension specified herein,
   sieve rules can continue to target the same mailbox even if
   it gets renamed.
END

— Section 3 —

   The server advertises the capability "mailboxid"

How are sieve capabilities advertised?

— Section 4 —

Two things here:

1. I think this is underspecified.  It’s not clear what the behaviour
is when the specified mailboxid does exist, but matches a mailbox with
a different name that what’s specified.  If I say:

   fileinto :mailboxid “12” “xyzzy”

…and there’s a mailbox named “xyzzy” with mailboxid 4, and a mailbox
named “plugh” with mailboxid 12, what happens?  It needs to be
explicitly clear.

2. Did the working group consider not requiring the mailbox name at
all, if the mailboxid is specified?  So I could say:

   fileinto :mailboxid “12”

…and in the example above it would behave as though I’d said:

   fileinto :mailboxid “12” “plugh”

I’m not sure that it ever makes sense to specify both the mailbox name
and the mailboxid.

— Section 4.1 —

This doesn’t make any sense to me, and ties into my item 2 in Secton
4.  If I care about the mailboxid, why would I want that to be
ignored?  The point of mailboxid is to override the name (such as in
the case of renames), and I would think that in the example in Section
4.1, if mailboxid Fnosuch isn’t what I think I’m looking for, I’d want
that to be an error condition, rather than creating a new mailbox, no?

— Section 4.2 —

What’s the use case for prioritising the mailboxid over the special
use?  That also seems an odd choice, given the context of special use
mailboxes.  The combination just seems strange — I would normally
specify *either* the special use of the mailbox *or* the name, but not
both.  Adding mailboxid to that just adds more weirdness.

— Section 14 —
According to the IESG Statement on Normative and Informative
References <https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/>:

   Note 1: Even references that are relevant only for optional
   features must be classified as normative if they meet the
   above conditions for normative references.

I think that makes 5490 and 8579 normative, not informative, as
Sections 4.1 and 4.2 are not understandable without those references.

-- 
Barry