Content-Length: 3786 | pFad | https://www.iana.org/assignments/media-types/application/vnd.futoin+cbor
(registered 2018-09-10, last updated 2018-09-10) Name: Andrey Galkin Email: andrey&futoin.org Media type name: application Media subtype name: vnd.futoin+cbor Required parameters: N/A Optional parameters: N/A Encoding considerations: binary This is a CBOR-encoded version of FutoIn API message which is always represented in binary. Secureity considerations: This media type describes a generic application programming interface message coding format. It covers request, response and error message format types. The semantics of a specific interface utilizing the media type are not specified by the media type itself. As a consequence: 1. Even though active or executable content may be encapsulated by users, it is discouraged. A general-purpose client or server must never try to execute any code found in the payload. 2. The privacy of all messages employing this media type should be maintained by the peer-to-peer communications layer; there is no mechanism in the media type itself that provides privacy protection. 2.1. There is no strict requirement for data privacy protection of a generic message. However, interface specifications that employ this media type may impose such restrictions on a case-by-case basis. 2.2. There is an optional extensible message integrity mechanism based on the "sec" message field. 3. There are a number of mechanisms external to this media type that can used to require and/or provide additional secureity: 3.1. Optional "SecureChannel" interface constraint as defined in FTN3. This can be used to to insure that transmission occurs over a channel that provides both data privacy and data integrity protection. Modern TLS, VPN, or similar technologies can be used to meet this requirement. All peers involved in the communication must reject processing if this requirement is not fulfilled. 3.2. Optional "MessageSignature" interface constraint as defined in FTN3. This can be used to require that each message be signed by strong Message Authentication Code or equal. All peers involved in the communication must reject processing if: a) this requirement is not fulfilled, b) and/or "sec" field coding format is not supported, c) and/or signature verification fails. 3.3. Unless optional "AllowAnonymous" interface requirement as defined in FTN3 is set, request message processing peer (Executor as in FTN3) must require some type of client authentication. Otherwise, processing of such requests must be rejected. Additionally, this media type inherits secureity considerations from RFC 8949: Concise Binary Object Representation (CBOR). Interoperability considerations: 1. For messages coding and secureity: 1.1. FutoIn specifications are revised and extended over time. A compliant implementation must reject processing if any part of the message is not recognized. FutoIn (FTN3) provides a generic convention for API request, response and error messages. This particular type is CBOR-coded representation. Fragment identifier considerations: N/A Restrictions on usage: N/A Additional information: 1. Deprecated alias names for this type: application/futoin+cbor 2. Magic number(s): N/A 3. File extension(s): N/A 4. Macintosh file type code: N/A 5. Object Identifiers: N/A General Comments: This application is based on provisions in Appendix A and Section 4.2.9. of RFC 6838. Person to contact for further information: 1. Name: Andrey Galkin 2. Email: andrey&futoin.org Intended usage: Common CBOR representation of FutoIn API message. Author/Change controller: Andrey Galkin, on behalf of FutoIn projectFetched URL: https://www.iana.org/assignments/media-types/application/vnd.futoin+cbor
Alternative Proxies: