[Last-Call] Opsdir last call review of draft-ietf-jmap-smime-07

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Reviewer: Menachem Dodge
Review result: Has Nits

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

The document explains the need to add an extension to JMAP for returning S/MIME
signature verification status. The document is written clearly.

Please consider whether the document header should indicate "Updates: 8621".

Nits:

1. Section 4:  Paragraph 5 - *smimeStatusAtDelivery*:
The brackets:

OLD==> (It effectively the same as "smimeStatus" value
 calculated at the date/time of deliver, as specified by
 "receivedAt".)
Suggested==> (It is effectively the same as the "smimeStatus" value
 calculated at the date/time of delivery, as specified by "receivedAt".)

2. Section 4: Paragraph 7 beginning with ' smimeStatus: "String|null". '
OLD==> ' Client MUST treat unrecognized values as "unknown" or "signed/failed".
' SUGGESTED==> ' Clients MUST treat unrecognized values as "unknown" or
"signed/failed". '

3. Section 4: Paragraphs 8,9,10 and 11. Missing colon following the first word
of the paragraph, this word being the possible string values of the property.
 Suggest that it be:        "unknown:" , "signed:" , signed/verified:", 
 "signed/failed:"

4. It would be useful to add additional actual examples of  messages - and to
refer to them in the text. So for the paragraph on "smimeErrors" it would be
useful to refer to the Example 2 below. It would be good to have an additional
example  showing the case where: "For example, the signing certificate might be
 expired and the message From email address might not correspond to
 any of the email addresses in the signing certificate."

5. In section 6 "Security Considerations" - it would be nice to have some
additional explanation of the recommendation to cache the results for 10
minutes. Is this to be done on the server side or at the client? Should there
be a reference here to other documents on signature verification?

Thank you kindly.

Menachem Dodge


-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux