Subject: [Jmap] Adam Roach's Discuss on draft-ietf-jmap-mail-14: (with DISCUSS and COMMENT)

From: Adam Roach <[email-masked]>
Date: Thu, 21 Feb 2019 00:33:10 -0800

Adam Roach has entered the following ballot position for
draft-ietf-jmap-mail-14: Discuss

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-jmap-mail/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks to everyone who worked on this document. I found it well-organized and
easy to read.

---------------------------------------------------------------------------

See my DISCUSS on draft-ietf-jmap-mail regarding the issues that can arise
from normatively referencing the WHATWG HTML document. Consider citing
https://www.w3.org/TR/html52/ instead.

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

ID Nits Reports:

  -- The draft header indicates that this document updates RFC5788, but the
     abstract doesn't seem to mention this, which it should.

---------------------------------------------------------------------------

§1.1:

>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  document are to be interpreted as described in [RFC2119].

Please use the boilerplate from RFC 8174.

---------------------------------------------------------------------------

§2:

>     However, unlike in IMAP, a mailbox may only have a single role,
>     and no two mailboxes in the same account may have the same role.

I get the impression that JMAP for mail is intended to be implementable as a
façade on top of a normal IMAP server. It is very unclear how such an
implementation is able to fulfill this requirement when the IMAP server has
multiple mailboxes marked as, say, "Sent". Please add guidance.

---------------------------------------------------------------------------

§2.3:

>  A Mailbox object matches the filter if and only if all of the given
>  conditions match.

I believe this means to say that it matches the *FilterCondition* if and only
if the conditions match (rather than saying it matches the *filter*). Looking
at draft-ietf-jmap-core section 5.5, the *filter* consists of
*FilterOperators* and *FilterConditions*; and one presumes that JMAP for mail
is not intending to override the meaning of "*FilterOperators*" by making them
all behave identical to "AND".

This issue also arises in §7.3

---------------------------------------------------------------------------

§4.1.1:

>  o  *keywords*: "String[Boolean]" (default: ) A set of keywords that

The intended default is unclear to me. Is this meant to indicate "{}"?

---------------------------------------------------------------------------

§4.1.2.1:

>  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).

This seems to preclude a client-side implementation of DKIM. That seems
problematic.

---------------------------------------------------------------------------

§4.1.2.3:

>  o  *name*: "String|null" The _display-name_ of the [RFC5322]
>     _mailbox_, or "null" if none.

Although its use is not technically correct, the use of comments in From
header fields to include display names was, at one time, painfully common --
and one still comes across such usage in the field from time to time.

For example, I received a message as recently as ten days ago with a From
header field of the form:

  From: [email-masked] (Mail Delivery System)

(Yes. That was generated by an IETF-affiliated mail server. ¯\_(ツ)_/¯ )

It would probably be good for this specification to at least *allow* (and
probably encourage) JMAP-for-mail servers to populate the name field with such
comments when no properly-formatted name is available; this would allow
JMAP-for-mail clients to easily operate on par with existing IMAP clients.

---------------------------------------------------------------------------

§4.1.4:

>        the charset was unknown, or the content-trasfer-encoding was

Nit: "...-transfer-..."

---------------------------------------------------------------------------

§7.5.1:

>     "description": "Verzeihung, wegen verdaechtiger Aktivitaeten Ihres
Benutzerkontos haben wir den Versand von Nachrichten gesperrt. Bitte wenden Sie
sich fuer Hilfe an unser Support Team."

This line is approximately 120 characters too long. Consider wrapping.

---

From: "Alexey Melnikov" <[email-masked]>
Date: Thu, 21 Feb 2019 08:38:27 -0500

Hi Adam,
Thank you for your comments.
Just replying to a couple of them:

> draft-ietf-jmap-mail-14: Discuss

 [...]

I agree that the W3C reference is a better choice.

 (snip)

Allowing multiple choices of "Sent" mailbox is a misfeature of the original IMAP extension which JMAP is trying to correct. When I implemented similar functionality in IMAP, I restricted it to allowing only 1 mailbox per each special-use attribute.

I suppose it would be useful to add some guidance about what to do if one implements JMAP as a frontend to IMAP which allows multiple mailboxes with the same special-use attribute.

 (snip)

Yes, I think so.

I am not entirely sure this is the right choice here, as JMAP (like IMAP) tries to preserve message fidelity. I think JMAP clients can do this automatically based on what they get from JMAP servers.

---

From: Adam Roach <[email-masked]>
Date: Thu, 21 Feb 2019 09:05:34 -0600

On 2/21/19 7:38 AM, Alexey Melnikov wrote:
>> §4.1.2.3:
>>
>>>   o*name*: "String|null" The_display-name_  of the [RFC5322]
>>    From:[email-masked]  (Mail Delivery System)
>>
>> It would probably be good for this specification to at least*allow*  (and
> I am not entirely sure this is the right choice here, as JMAP (like IMAP) tries to preserve message fidelity.

It appears that this is true for the raw headers, but the processed 
headers notably exclude things like comments, and have already performed 
transformations (e.g. the conversion of "=?UTF-8?Q?John_Sm=C3=AEth?=" to 
"John Smith"). I read these already-parsed forms of header fields as 
being *semantic* rather than *syntactic*, and the semantic in the 
more-common-than-it-should-be case that I cite is that "Mail Delivery 
System" is intended as the name to be displayed.

>   I think JMAP clients can do this automatically based on what they get from JMAP servers.

Only if they access the raw header fields, but that really defeats the 
purpose of having the parsed forms.

/a

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 21 Feb 2019 16:26:07 +0000

Hi Adam,

On 21/02/2019 15:05, Adam Roach wrote:

> headers notably exclude things like comments, and have already 
> performed transformations (e.g. the conversion of 
> "=?UTF-8?Q?John_Sm=C3=AEth?=" to "John Smith"). I read these 
> already-parsed forms of header fields as being *semantic* rather than 
> *syntactic*, and the semantic in the more-common-than-it-should-be 
> case that I cite is that "Mail Delivery System" is intended as the 
> name to be displayed.
>
I think I misread your comment. If you  mean the the thing in () to be 
used instead of the missing display name, than it would be Ok. I think 
several IMAP servers already do this.

---

From: Adam Roach <[email-masked]>
Date: Thu, 21 Feb 2019 14:57:27 -0600

On 2/21/19 10:26 AM, Alexey Melnikov wrote:
> used instead of the missing display name, than it would be Ok.

That is exactly what I mean, yes. Thanks.

/a

---

From: "Neil Jenkins" <[email-masked]>
Date: Mon, 25 Feb 2019 01:50:27 -0500

Thanks for the detailed feedback Adam.

> https://www.w3.org/TR/html52/ instead.

I have changed the citation to this.

>  abstract doesn't seem to mention this, which it should.

What is normally expected here? Looking at RFC7230 <https://tools.ietf.org/html/rfc7230> (HTTP/1.1) as an example, it updates 2817 and 2616, but neither are mentioned in the abstract.

> Please use the boilerplate from RFC 8174.

I have done this.

> multiple mailboxes marked as, say, "Sent". Please add guidance.

As Alexey said, these were misfeatures and many servers already enforce the restrictions JMAP adds. I think it can really be left up to the implementation how to translate multiple IMAP roles, or multiple folders with the same role, to enforce the JMAP restrictions, since this is not a compatibility issue within JMAP itself and the implementation may have domain-specific knowledge to help it make an informed choice. I have updated the text to clarify this:

*This value is shared with IMAP (exposed in IMAP via the [@!RFC6154] SPECIAL-USE extension). However, unlike in IMAP, a mailbox MUST only have a single role, and there MUST NOT be two mailboxes in the same account with the same role. Servers providing IMAP access to the same data are encouraged to enforce these extra restrictions in IMAP as well. Otherwise, it is implementation dependent how to modify the IMAP attributes to ensure compliance when exposing the data over JMAP.*

> if the conditions match

Thanks, I've fixed this.

> The intended default is unclear to me. Is this meant to indicate "{}"?

Yes, it's meant to be `{}` – it got lost in the translation from markdown to RFC XML format. I've now fixed this.

> This seems to preclude a client-side implementation of DKIM. That seems

You can always fetch the raw bytes for the whole message (by using the standard download mechanism with the blobId of the message). When returning data within the structured JSON however, it MUST be UTF-8 encoded or we'd be returning invalid JSON. I think the currently defined behaviour is reasonable.

> comments when no properly-formatted name is available

Agreed. I have changed it to:

*name*: `String|null`

The *display-name* of the [@!RFC5322] *mailbox*. If this is a *quoted-string*:
 1. The surrounding DQUOTE characters are removed.
 2. Any *quoted-pair* is decoded.
 3. White-space is unfolded, and then any leading and trailing white-space is removed.
If there is no *display-name* but there is a *comment* immediately following the *addr-spec,* the value of this SHOULD be used instead. Otherwise, this property is `null`.

> > the charset was unknown, or the content-trasfer-encoding was

Fixed, thanks.

> This line is approximately 120 characters too long. Consider wrapping.

Fixed, thanks.

Cheers,
Neil.

---

From: Barry Leiba <[email-masked]>
Date: Mon, 25 Feb 2019 01:12:31 -0800

> What is normally expected here? Looking at RFC7230 (HTTP/1.1) as an example, it updates 2817
> and 2616, but neither are mentioned in the abstract.

We, the IETF community in general and the IESG in particular, don't
always agree on everything; this is one of those things we don't agree
on.  I think it's not necessary to put it in the abstract unless it's
abstract-worthy material.  Keep in mind when you decide that, that the
abstract is meant to be read separately from the document and its
metadata, and someone doing that might not otherwise know about the
"updates" situation until she reads the document itself.  If you think
that's OK, then we shouldn't have to say it in the abstract.

The point of having it called out by id-nits is that if it's left out,
that should be done thoughtfully, not negligently.

Barry

---

From: Adam Roach <[email-masked]>
Date: Mon, 25 Feb 2019 12:51:33 -0600

> Thanks for the detailed feedback Adam.

Thanks! Your answers look good. One quick response below.

> What is normally expected here? Looking at RFC7230 
> <https://tools.ietf.org/html/rfc7230> (HTTP/1.1) as an example, it 
> updates 2817 and 2616, but neither are mentioned in the abstract.
>

  RFC 8067 provides a good example. If you want something more minimal, 
I'd look at RFC 6122.

/a

---

From: "Neil Jenkins" <[email-masked]>
Date: Mon, 25 Feb 2019 20:01:44 -0500

On Mon, 25 Feb 2019, at 20:12, Barry Leiba wrote:
> I think it's not necessary to put it in the abstract unless it's abstract-worthy material.

Yes. Having considered this and looked at the example Adam gave, it seems clear to me it seems clear to me that in the case of this document it is not necessary to mention the updated RFC in the abstract as it is not core to what the document is about, but rather a minor update to a registry to make it encompass JMAP as well as IMAP.

Cheers,
Neil.