(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.

Security 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 security:

   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 security considerations 
   from RFC 8949: Concise Binary Object Representation (CBOR).

Interoperability considerations:
   1. For messages coding and security:

   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 project