Subject: Re: [Jmap] Review of draft-ietf-jmap-mail-06

From: Stephan Bosch <[email-masked]>
Date: Mon, 3 Sep 2018 02:42:12 +0200

Hi Neil,

Op 29/08/2018 om 08:02 schreef Neil Jenkins:
> Hi
>
>> I am mainly concerned about strings that the user will get to see: 
>> the IDs are not in that realm. I am just saying that a 
>> specification-enforced limit will hit the multi-byte character 
>> languages (think e.g. Japanese) more than english. So, while 255 
>> octets ought to be enough for everyone, it might not be. I agree 1024 
>> is less likely to be too limited, but still: is a capability property 
>> really such a burden?
>
> For the reasons explained before I think the limit should be specified 
> in octets (if clients want to give the user a guaranteed UTF-8 
> character limit they can always just divide this by 4…). However, I 
> guess we can make the actual value of the limit a capability. We 
> probably want to add:
>
>   * *maxMailboxDepth*: |PositiveInt|null|
>     The maximum depth of the mailbox hierarchy (i.e. one less than the
>     maximum number of ancestors a mailbox may have), or |null| for no
>     limit.
>   * *maxSizeMailboxName*: |PositiveInt|
>     The maximum length, in (UTF-8) octets, allowed for the name of a
>     mailbox. This MUST be >= 255.
>

Looks good to me.

>>> I'm happy with that.  Cyrus' current limitation is purely the length 
>>> of the internal version of the mailbox name, but you could create 
>>> A.A.A.A out to MAX_MAILBOX_NAME.  Annoyingly, some buggy clients did 
>>> that with INBOX.INBOX.INBOX... such that we special-case reject that 
>>> now.
>
> Explaining that kind of limit to users is … hard. Renaming folder X 
> may fail even though the new name is a reasonable length, because the 
> combined length with some of its descendants could now be too long — 
> ouch. The server is free to reject the change with an 
> |invalidProperties| error response though of course, which is fine. I 
> don't think this should be a capability though.

I have no real preference here. Others might.. feel free to pitch in.

>>>>> -> How are IMAP namespaces mapped to JMAP? More specifically: how are
>>>>> personal and shared mailboxes identified in JMAP?
>>>>
>>>> They would be presented as different JMAP accounts 
>>>> <https://jmap.io/spec-core.html#terminology> the user has access 
>>>> to. The primary account would (normally) be the one belonging to 
>>>> the user.
>>
>> Ok. Then do we need to add a flag that signifies an account as being 
>> shared/public, so that the client can present mailboxes and other 
>> objects therein as such? There could e.g. also be an Archive account 
>> that is still personal, but not primary.
>
> Hmm, yes that's probably reasonable. I think a simple boolean on each 
> account object would suffice; something like |"isYours": 
> true|false| (or |isUser| or |isPersonal|… naming things is hard). 
> Thoughts on the name?

I like isPersonal.

Regards,

Stephan.