Peter, thank you for your review. I have entered a No Objection ballot for this document. Lars > On 2021-9-7, at 10:00, Peter Yee via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Peter Yee > Review result: Ready with Issues > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-jmap-smime-07 > Reviewer: Peter Yee > Review Date: 2021-09-06 > IETF LC End Date: 2021-09-06 > IESG Telechat date: Not scheduled for a telechat > > Summary: This document provides a JMAP extension that allows the JMAP server to > provide its thoughts on the verification of a messages S/MIME signature. While > the details of the extension seem fine, I'm not convinced that the rationale > for it and the consequences of trusting the server to perform the verification > are well described. [Ready with issues] > > Major issues: None > > Minor issues: > > Page 2, section 1: There really ought to be a description of why a client would > want to do this and why it would trust the results. This is taking a decision > on something that is normally an end-to-end property of a message and > delegating its verification to a server. Is signature verification so onerous? > > Page 4, smimeErrors, 3rd sentence: the error may also be in the certificate > chain. > > Page 5 and 6 examples: Put an introduction before each example so the reader > knows that it is an example and what it intends to show. > > Page 7, section 6: I think a stronger description of the implications of doing > server-side verification is merited. The document is written as though it is a > forgone conclusion that a client would want to do this without much explanation. > > Nits/editorial comments: > > General: > > The use of asterisks and underscores for emphasis or for offsetting various > items is not explained. The usage is also inconsistent. I note that RFC 8621 > does some of this as well, but I think it would be preferable to abstain from > extravagant use of these characters unless their significance is explained. > Sometimes items are marked with asterisks, other times with quotation marks. I > find it all rather off-putting and could not find anything in the RFC Editor's > Style Guide indicating a standardized meaning for the characters. > > Do not put a colon after the title of each example (e.g., "Example 1:") > > Specific: > > Page 2, section 1, 2nd paragraph: insert "the" before "multipart/signed media" > and "application/pkcs7-mime". > > Page 2, section 3, 1st sentence: change "the JMAP spec" to "[RFC8621]". This > obviates the need to use underscores around the following "this". > > Page 3, section 4, 1st paragraph, 1st sentence: insert "the" before "Email/get". > > Page 3, *smimeStatus*: insert "the" before the final '"smimeStatus"'. > > Page 3, *smimeErrors*: insert "the" before the final '"smimeErrors"'. > > Page 3, *smimeVerifiedAt*: insert "the" before the final '"smimeVerifiedAt"'. > > Page 3, *smimeStatusAtDelivery*, 1st sentence: insert "the" before the final > '"smimeStatusAtDelivery"'. > > Page 3, *smimeStatusAtDelivery*, 2nd sentence: insert "is" before "effectively > ". Insert "the" before '"smimeStatus"'. Change "deliver" to "delivery". > > Page 3, smimeStatus, 2nd real sentence: change "This" to "Otherwise, this". > > Page 3, smimeStatus, 4th real sentence: change "Client" to "Clients". > > Page 3, smimeStatus, unknown, 1st sentence: delete the comma after "signed". > > Page 3, smimeStatus, unknown, 2nd sentence: insert "an" before "unknown". > > Page 3, smimeStatus, signed, 2nd sentence: insert "a" before "signature". > > Page 3, smimeStatus, signed/verified: insert "the" before "sender matches". > Append a comma after "field". > > Page 4, 1st non-status paragraph, 1st sentence: delete the comma after > '"smimeStatus"'. Insert "is" before "calculated". > > Page 4, 1st non-status paragraph, 2nd sentence: insert "the" before "S/MIME". > Change "it helps to" to "to help". > > Page 4, smimeErrors, 1st sentence: insert "the" before "S/MIME". > > Page 4, smimeErrors, 2nd sentence: append a comma after "I.e.". > > Page 4, smimeErrors, 3rd sentence: insert "the" before "Content-Language ". > > Page 4, smimeErrors, 6th sentence: insert "a" before "CRL". > > Page 4, smimeVerifiedAt, 2nd sentence: insert "the" before "S/MIME". > > Page 4, smimeVerifiedAt, 3rd sentence: insert "an" before "S/MIME". > > Page 4, last paragraph, 1st sentence: change "it's" to "its". > > Page 5, 1st paragraph: append a comma after "server". > > Page 6, 1st paragraph after Example 2, 1st sentence: insert "the" before > "Email/query". > > Page 7, section 6, 1st paragraph, 1st sentence: change "Server side" to > "Server-side". Insert "the" before "server". > > Page 7, section 6, 2nd paragraph, 1st sentence: insert "a" before "Denial". > > Page 7, section 6, 2nd paragraph, 2nd sentence: append a comma after "reason". > > > -- > last-call mailing list > last-call@xxxxxxxx > https://www.ietf.org/mailman/listinfo/last-call
Attachment:
signature.asc
Description: Message signed with OpenPGP
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
