Re: [Technical Errata Reported] RFC7030 (5904)

Michael Richardson <[email protected]> Mon, 30 Mar 2020 13:27:58 -0400

Newsgroups	gmane.ietf.x509
Message-ID	<9922.1585589278@localhost>

Eliot Lear <[email protected]> wrote:
    >> Option #1: Change all references from Content-Transfer-Encoding to
    >> Transfer-Encoding. A caveat is that "base64" has a different meaning in
    >> HTTP (no CRLFs) vs MIME (includes CRLFs).

    > For interoperability purposes in the erratum, we might advise that both
    > should be tolerated, but one needs to be preferred.  Adding Max,
    > Michael, Stefan, and Panos who have implemented, for discussion.

Unless someone with a deployed product comes forward claiming that they
accept non-base64 encoded content when there is no CTE header *AND* they have
interoperated with some other product, then the feedback from implementers
that I was able to reach last spring is that they:
  1) didn't insert CTE, (and ignored it), because it was junk.
  2) base64 encoded all content.

Changing it to Transfer-Encoding does not make sense.

{This is in the archives somewhere}

    >> Option #2: Remove all references to Content-Transfer-Encoding and
    >> base64. Responses would be transmitted as binary. This allows the
    >> response to be transported more efficiently without base64 size bloat,
    >> and it allows optional use of Content-Length header so the response can
    >> be parsed more efficiently knowing the length ahead of time.
    >>

    > If this is the direction, then I would hold for update because more
    > work would need to be done, and it would not be interoperable with
    > existing implementations.

This would be an incompatible change on the wire.

--
Michael Richardson <[email protected]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix

signature.asc (application/pgp-signature, 487 B)