Resending with correct LAMPS ML name of "SPASMS". I have posted the draft https://datatracker.ietf.org/doc/draft-richardson-lamps-rfc7030est-clarify/
this morning. It attempts to address the errata posted by Sean Turner in 2017 on RFC7030. Specifically the use of Content-Type-Encoding (CTE) and base64. You can see my other query to httpbis at: https://mailarchive.ietf.org/arch/msg/httpbisa/m4l4G_lHKfQVfSeAn7IxReUioD0 In doing BRSKI (draft-ietf-anima-bootstrapping-keyinfra) interop testing we had a number of confusions about whether or things are base64 encoded, and if they are always base64 encoded, why send the CTE header, and if BRSKI is binary or base64 encoded! Given that RFC7030 is somewhat well deployed, acting on the errata that Sean Turner noted is a bit difficult! (As a process thing, it's a problem that his 2017 errata seems to have gone into /dev/null). I am posting the core of the proposal at the bottom of this email. It tries to leverage the Postel doctrine in a way. Some questions/issues: 1) does this belong in secdispatch? 2) is this appropriate for LAMPS? 3) independant submission seems wrong. 4) ANIMA BRSKI needs to clarify things itself, and I will add a section on this, but I'm hesistant to add a normative reference here. I have an idea of appropriate text that I will post on Tuesday. Getting clarity here is really the most important thing for me. 5) I don't have a simple answer for the /csrattrs API. Maybe it needs to be solved by creating a new end point. or it could be done with Accept: header. ps: it's ironic to me, this is perhaps something that could also be solved by versioning the API in the URL. For the other three methods, when the client is aware that this is an amended server then it SHOULD send the POST request in binary form (DER-encoded), and omit the Content-Transfer-Encoding header. How the client knows what kind of server it is dealing with is communicating with is detailed in the next section. An amended server, when it receives a request that has no Content- Transfer-Encoding header, or has a Content-Transfer-Encoding header with the "binary" attribute, MUST respond in the same binary format. When an amended server receives a request in CTE-base64 form, then it MAY respond in kind. It is reasonable for a server to be configured to ignore or fail requests of this form, either via run-time configuration, or via a compile-time option. A main reason to do this is to avoid a permutation that requires testing in the future when no legacy EST clients are expected to connect. -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =- -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
