--- 1/draft-ietf-lamps-rfc7030est-clarify-06.txt	2020-06-16 11:13:09.753999618 -0700
+++ 2/draft-ietf-lamps-rfc7030est-clarify-07.txt	2020-06-16 11:13:09.782000330 -0700
@@ -1,22 +1,22 @@
 
 LAMPS Working Group                                        M. Richardson
 Internet-Draft                                  Sandelman Software Works
 Updates: 7030 (if approved)                                    T. Werner
 Intended status: Standards Track                                 Siemens
-Expires: December 16, 2020                                        W. Pan
+Expires: December 18, 2020                                        W. Pan
                                                      Huawei Technologies
-                                                           June 14, 2020
+                                                           June 16, 2020
 
    Clarification of Enrollment over Secure Transport (EST): transfer
                           encodings and ASN.1
-                 draft-ietf-lamps-rfc7030est-clarify-06
+                 draft-ietf-lamps-rfc7030est-clarify-07
 
 Abstract
 
    This document updates RFC7030: Enrollment over Secure Transport (EST)
    to resolve some errata that was reported, and which has proven to
    cause interoperability issues when RFC7030 was extended.
 
    This document deprecates the specification of "Content-Transfer-
    Encoding" headers for EST endpoints.  This document fixes some
    syntactical errors in ASN.1 that was presented.
@@ -29,21 +29,21 @@
    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF).  Note that other groups may also distribute
    working documents as Internet-Drafts.  The list of current Internet-
    Drafts is at https://datatracker.ietf.org/drafts/current/.
 
    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
-   This Internet-Draft will expire on December 16, 2020.
+   This Internet-Draft will expire on December 18, 2020.
 
 Copyright Notice
 
    Copyright (c) 2020 IETF Trust and the persons identified as the
    document authors.  All rights reserved.
 
    This document is subject to BCP 78 and the IETF Trust's Legal
    Provisions Relating to IETF Documents
    (https://trustee.ietf.org/license-info) in effect on the date of
    publication of this document.  Please review these documents
@@ -149,54 +149,57 @@
    CRLF, while the "base64" used in MIME [RFC2045] does.  This
    specification clarifies that despite [RFC2616], that white space
    including CR, LF, spaces (ASCII 32) and, tabs (ASCII 9) SHOULD be
    tolerated by receivers.  Senders are not required to insert any kind
    of white space.
 
 3.2.  Changes sections 4 of RFC7030
 
 3.2.1.  Section 4.1.3
 
-   Replace:
+   In the paragraph reading:
 
    A successful response MUST be a certs-only CMC Simple PKI Response,
    as defined in [RFC5272], containing the certificates described in the
    following paragraph.  The HTTP content-type of
    "application/pkcs7-mime" is used.  The Simple PKI Response is sent
    with a Content-Transfer-Encoding of "base64" [RFC2045].
 
+   Replace:
+
+      The Simple PKI Response is sent
+      with a Content-Transfer-Encoding of "base64" [RFC2045].
+
    with:
 
-   A successful response MUST be a certs-only CMC Simple PKI Response,
-   as defined in [RFC5272], containing the certificates described in the
-   following paragraph.  The HTTP content-type of
-   "application/pkcs7-mime" is used.  The CMC Simple PKI Response is
-   encoded in base64 [RFC4648].
+      The CMC Simple PKI Response is encoded in base64 [RFC4648].
 
 3.2.2.  Section 4.3.1
 
-   Replace:
+   In the paragraph reading:
 
     If the HTTP POST to /fullcmc is not a valid Full PKI Request, the
     server MUST reject the message.  The HTTP content-type used is
     "application/pkcs7-mime" with an smime-type parameter "CMC-request",
     as specified in [RFC5273].  The body of the message is the binary
     value of the encoding of the PKI Request with a
     Content-Transfer-Encoding of "base64" [RFC2045].
 
+   Replace:
+
+      The body of the message is the binary
+      value of the encoding of the PKI Request with a
+      Content-Transfer-Encoding of "base64" [RFC2045].
+
    with:
 
-    If the HTTP POST to /fullcmc is not a valid Full PKI Request, the
-    server MUST reject the message.  The HTTP content-type used is
-    "application/pkcs7-mime" with an smime-type parameter "CMC-request",
-    as specified in [RFC5273].  The body of the message is encoded
-    in base64 [RFC4648].
+      The body of the message is encoded in base64 [RFC4648].
 
 3.2.3.  Section 4.3.2
 
    Replace:
 
     The body of the message is the binary value of the encoding of the
     PKI Response with a Content-Transfer-Encoding of "base64" [RFC2045].
 
    with: