Re: [Jmap] AD review of draft-ietf-jmap-mail-12

[Alexey Melnikov <[e-mail]>]

Hi Neil,

Below I removed comments from my reply where we are in agreement:

On 10/01/2019 03:42, Neil Jenkins wrote:
> On Thu, 10 Jan 2019, at 4:34 AM, Alexey Melnikov wrote:
>>     By default, the JMAP server should hide EHLO
>>       capabilities that are to do with the transport mechanism and thus
>>       are only relevant to the JMAP server
>>
>> Is it worth having a registry for these a la Section 6.2 of RFC 8494?
>
> I don't feel a need for one strongly, but we can add one if you think 
> it's necessary?
This is a possible interop issue and I would rather have a registry. I 
am Ok with Bron's proposal to define it in another document.

>>    In addition, servers MUST support a psuedo-type called
>>    "EmailDelivery" in the push mechanisms.
>>
>> I think an example or pointer to an example would be useful here.
>
> I've added the following example to the document; does this clarify it 
> for you?
>
> /The client has registered for push notifications just for the 
> `EmailDelivery` type (see [@!I-D.ietf-jmap-core] for details of the 
> push system)./
This mostly works, but EmailDelivery is not defined in CORE, it is only 
shown there in examples. /
/
> /The user marks an email as read on another device, causing the state 
> string for the `Email` type to change, however as nothing new was 
> added to the store the `EmailDelivery` state does not change and 
> nothing is pushed to the client. A new message arrives in the user's 
> inbox, again causing the `Email` state to change. This time the 
> `EmailDelivery` state also changes, and a StateChange object is pushed 
> to the client with the new state string. The client may then resync to 
> fetch the new message immediately./
The rest looks fine.
>
>> In Section 2:
>>
>> > Servers MUST forbid sibling Mailboxes with the same name.
>> What exactly is this trying to say?
>
> I have rewritten this to say:
>
> /There MUST NOT be two mailboxes with both the same parent and the 
> same name./
////
>
> Is that clear? (IMAP is path based so naturally you cannot have two 
> sibling mailboxes with the same name; but JMAP is id based so in 
> theory you could. For IMAP compatibility, and to avoid user confusion, 
> this is forbidden by fiat.)
If you change "two mailboxes" to "two sibling mailboxes", that would be 
clear.
>
> >   determine a charset and decode the octets, or MAY replace any octet
>> >   or octet run with the high bit set that violates UTF-8 syntax with
>> >   the unicode replacement character (U+FFFD).
>>
>> Do we really want to encourage the "MAY use heuristics" part? Such email
>> messages are non compliant and thus not in scope for this document!
>
> Well, they appear in the real world so servers do need to deal with 
> them. Using heuristics to determine what the sender intended often 
> provides the best user experience (customers tend not to care that it 
> was the sender that sent something broken…).
MAY is compliance language, but "MAY use heuristics" is impossible to 
test for interoperability.
> However, I'm not strongly attached. Would you prefer me to replace 
> this with the following?
>
> /A server SHOULD replace any octet or octet run with the high bit set 
> that violates UTF-8 syntax with the unicode replacement character 
> (U+FFFD).//
> /
Yes, please.
  [snip]
>> Is it worth explicitly mentioning Content-Description header field here
>> as well?
>
> The spec currently only has restrictions on RFC5322 and RFC2369 
> headers. Other headers such as this one are not explicitly forbidden 
> so may be used with the form already. So I don't think it's necessary 
> to mention explicitly.

It just took me some time to realize that it is allowed. I don't have a 
strong preference.


>> In Section 4.1.2.3:
>> Is RFC 2231 encoding allowed in this and the following section?
>
> I don't think so, as To, Cc etc. don't have parameter values. Or have 
> I got that wrong?

You are right. I think I want a new type for parsing ;-separated 
attribute=value pairs with RFC 2231 parameters, as this is a pain to do 
in clients.

>>
>> In 4.1.3:
>>
>> asText and asAddresses is not defined in the document. Did you mean:
>
> This is defined at the top of page 26 in 4.1.3:
>
> o  *:as{header-form}* This means the value is in a parsed form, where
>        "{header-form}" is one of the parsed-form names specified above.
>        If not given, the value is in _Raw_ form.
Never mind than.
>> In Section 4.1.4:
>>
>> You need to define handling for unrecognised Content-Transfer-Encoding
>> values here.
>
> I have added
>
> /If the transfer encoding is unknown, it is treated as though it had 
> no transfer-encoding./

Ok. I think you should also mention that this would result in 
isEncodingProblem being true as well.

  [snip]

>> In Section 4.2 (and similar text in 4.9):
>>
>> maxBodyValueBytes:
>>
>>  "The server MUST ensure the truncation results in valid UTF-8 and does
>> not occur mid-codepoint." --
>>
>> The document needs to make sure that this is only true for body parts
>> which are known to be textual (e.g. text/plain, text/html, XML, JSON).
>> If a body part is a JPEG image, this requirement doesn't make sense.
>
> As Bron pointed out, bodyValue is only returned like this for text/* 
> types.

Ok. Maybe explain this in a comment, if you feel like it.

>
>> In Sections 4.8/4.9:
>>
>> The document needs to explicitly allow EAI messages, not just RFC 5322
>> format.
>
> I'm not entirely sure how to specify this. I have added this sentence 
> to the introduction to each of these methods:
>
> /The server SHOULD support messages with [@!RFC6532] EAI headers./
In IMAP4rev2 we made it a MUST. I wouldn't mind if you add a capability 
for this.
> Is that sufficient? (And should it be a MUST?)
>
> In Section 7:
>>
>> Are "MDN" and "DSN" blobIds referencing only the machine parseable part
>> or the whole multipart/report coming back? I think the document should
>> clarify this and (ideally) give some examples.
>
> This is intended to be the whole MIME message a with a top-level 
> content-type of multipart/report; I have added the following line to 
> the two properties to clarify:
>
> /The blob is the whole MIME message (with a top-level content-type of 
> multipart/report), as received./
Ok. I suggest you add Normative references to RFCs that define MDN and 
DSN report types.
>> End of Section 7.5:
>>
>>  "The server MAY choose to localise this string into the user's
>> preferred language, if known."
>>
>> How can this be done?
>
> This is just acknowledging the server may have some kind of 
> out-of-band knowledge about the authenticated user and if so should 
> use it to increase the likelihood of presenting an understandable 
> error to the user. I think anything more is out of scope of the 
> current specification.

Use of MAY is compliance language, but you don't provide a way to do 
this interoperably (or at all). At minimum clients should be able to 
deduce the language tag used, so you must have a field for conveying it 
(even if it is omitted in most cases.) I think I agree with Bron that 
the mechanism for specifying user's preferred language(s) should be 
specified in CORE.

Best Regards,

Alexey