Skip to main content

Shepherd writeup
rfc9219-12

Document Shepherd Write-Up for draft-ietf-jmap-smime

1. This document is being requested as an Proposed Standard because it
extends an existing Proposed Standard (RFC8621).

The request type is indicated in the title page header as "Standards Track".

2.

Technical Summary

  This spec extends the JMAP Mail Protocol (RFC8621) with a way to
  obtain information about S/MIME signature verification status.

Working Group Summary

  This document originally included both the verification and the
  creation of S/MIME signatures, but was split into two documents
  and this one is just the verification part.

  The main discussion was around cached validation status and being
  able to know if the server successfully validated the message in
  the past once a key has expired.

  There was also discussion about whether there was any point in
  describing what specifically caused validation to fail, or just
  a simple yes/no on validity.

  This document was discussed in multiple IETF sessions, as well as
  on the mailing list, and everybody was happy with the end result.

Document Quality

  This spec is easy to implement for a server which already validates
  S/MIME.  It can either store information or always calculate in
  real-time.  It uses the standard JMAP extension mechanism to add
  new data items to the existing Email object, so will be familiar
  to anybody who has implemented JMAP.

Personnel

  Document Shepherd - Bron Gondwana (EXTRA co-chair)
  Responsible Area Director - Murray Kucherawy


3. The Document Shepherd has read the document through in detail.

4. There are no concerns about reviews, this document has been well reviewed.

5. There is no review required for the document by other areas.

6. There are no concerns with this document that IESG should be aware of.

7. Yes, the author has been contacted and confirmed and confirmed that
they have no disclosures.

8. There have been no IPR disclosures filed.

9. The WG consensus is solid.

10. There has been no discontent.

11. The ID nits tool complains of one line which is overly long, which
can be easily fixed in editing.  It's inside an JSON example.

12. This document doesn't define anything which needs formal review
outside the working group.

13. All references have been identified as normative.

14. All normative references are published standards.

15. There are no downreferences.

16. This RFC does not change the status of any other RFC.

17. The IANA considerations ask for a single entry in the JMAP capability
registry, and the registration completely specifies the fields for that
registry.

18. There are no new registries created.

19. There are no ABNF sections.  The JSON examples were validated with
the `jq` tool.
Back