| Internet-Draft | RTP-Payload-avatar | July 2025 |
| HS Yang, et al. | Expires 3 January 2026 | [Page] |
This memo outlines RTP payload formats for the MPEG-I Avatar data. A Avatar Stream format (ASF) is composed of Avatar animation unit (AAU) including a AAU header and zero or more AAU packets. The RTP Payload header format allows for packetization of a AAU unit in an RTP packet payload as well as fragmentation of a AAU into multiple RTP packets.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
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 3 January 2026.¶
Copyright (c) 2025 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Avatars are digital representations of users in the metaverse, a set of virtual worlds where people can interact with each other in real-time. Users can customize different aspects of their avatars, such as clothing, accessories, and even physical attributes. Avatars allow users to express themselves and create a unique digital identity within the metaverse. The integration, animation, and representation of avatars in real-time communication services is essential to enable immersive experiences.¶
[ISO.IEC.23090-39] specifies the Avatar Representation Format (ARF) to offer an interoperable exchange format for the storage, carriage and animation of 3D avatars. It defines the "Avatar animation Unit" as a unit of packetization suitable for Avatar animation streaming, and similar in essence to the NAL unit defined in some video specifications. This document describes how Avatar data (Avatar animation Unit) can be transmitted using the RTP protocol. This document followed recommendations in [RFC8088] and [RFC2736] for RTP payload format writers.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document uses the definitions of the Avatar Representation Format [ISO.IEC.23090-39]. Some of these terms are provided here for convenience.¶
Animation Streams: timed data used to animate the base avatar.¶
The Avatar Representation Format (ARF) defines two key components of an avatar animation system: the Base Avatar Format and the Animation Stream Format.¶
The Base Avatar Format defines a standardized structure for avatar models, allowing them to be stored in digital asset repositories. This ensures that core avatar assets can be reliably accessed and animated by receiving systems. In contrast, the Animation Stream Format specifies how animation data is organized and transmitted between sender and receiver. It defines the encoding of facial and body animation, enabling data captured from input devices such as head-mounted displays (HMDs) and sensors to be consistently interpreted across different systems for animating associated avatars. Figure 1 describe an Avatar reference architecture.¶
+---------+
|Reference|
| Model |
+----+----+
| +-------------+
+--------------->|Digital Asset|Base Avatar Format(BAF)
| | Repo +--------------------+
| +-------------+ |
| |
+----+---+ |
|Tracking| +------+ Animation Stream Format(ASF) +----v---+
| System |--->|Sender|----------------------------->|receiver|
+--------+ +------+ +--------+
Animation streams are timed data used to animate an avatar. This data includes skeletal, blend shape set, and other animation-related information. Animation stream format defines how animation data is structured and carried between senders and receivers. This format defines how facial and body animation information is encoded, allowing data captured from input devices like Head-Mounted Displays (HMDs) and sensors to be consistently interpreted across different systems for the animation of associated avatars.¶
Avatar animation data may be stored as samples in an avatar container, such as the MPEG Avatar Representation Format container [ISO.IEC.23090-39], along with the avatar model representation. This data may also be generated on-the-fly as cameras and sensor capture a person's motion and generate corresponding commands to mimic this movement for an avatar that represent the user. Avatar animation samples may be structured into a bitstream comprising a sequence of Avatar Animation Units (AAUs), whose general structure is provided in Figure 2.¶
Each AAU includes an Avatar ID that indicates the target avatar to which the animation data applies. In addition, it may also include parameters such as a Level of Detail (LoD), which indicates the quality of the avatar animation, and an Avatar Part ID, which indicates which specific part of the avatar is animated.¶
Avatar animation content can be transmitted over one or more streams, depending on applications. For example, an application may transmit animations for a single avatar in different streams or may transmit animations for multiple avatars in a single stream. In some cases, an application may choose to stream a single level of detail for all avatar animations, while in some other cases, an application could associate different avatars or avatar parts with different levels of details, depending on the position of the avatar, and possibly changing the level of detail over time. An application could even stream different avatar parts in different streams. In all cases, the receiver should be aware of the avatar IDs, levels of detail and/or avatar part IDs that are transmitted in a stream, to make sure it has the necessary assets to render the avatar animation. The receiver can use the avatar ID or level of detail associated with an AAU to transmit the AAU to an animation player instance that has the proper assets.¶
+---------+-----------+ +----------+-----------------+ |Unit_type|Unit_length| |time stamp|data of unit_type| +---------+-----------+ +----------+-----------------+ (a) AAU Header (b) AAU Payload
This section describes details related to the RTP payload format definitions for the Avatar codec defined in [ISO.IEC.23090-39]. Aspects related to RTP header, RTP payload header and general payload structure are considered.¶
The RTP header is defined in [RFC3550] and represented in Figure 3. Some of the header field values are interpreted as follows.¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Marker bit (M): 1 bit.¶
The marker bit SHOULD be set to one in the first RTP packet after an any idle period. This can for example be used for jitter buffer adaptation. The marker bit in all other packets MUST be set to zero.¶
Payload type (PT): 7 bits¶
The assignment of a payload type MUST be performed either through the profile used or in a dynamic way.¶
Sequence Number (SN): 16 bits¶
Set and used in accordance with [RFC3550]¶
Timestamp: 32 bits¶
A timestamp representing the sampling time. The AAU (Avatar Animation Unit) defines aau_timestamp in its payload. The timestamp in seconds can be calculated as: timestamp / timescale.¶
Synchronization source (SSRC): 32 bits¶
Used to identify the source of the RTP packets. By definition a single SSRC is used for all parts of a single bitstream. The remaining RTP header fields are used as specified in [RFC3550].¶
The RTP Payload Header follows the RTP header. Figure 4 describes RTP Payload Header.¶
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-------+-----+---------------+ |D| UT | L | Av ID | +-+-------+-----+---------------+
D (Sync Type, 1 bit): this field indicates whether an AAU included in the avatar animation packet payload is a sync AAU (D=0) or not (D=1). If D=1, the AAU is dependent on other AAUs for decoding. If D=0, the AAU can be decoded independently.¶
UT (Unit Type, 4 bits): this field indicates the type of the payload, which can be the type of the AAU for single unit payload, or the type of the payload otherwise, as shown in Figure 5.¶
L (Layer or Level of Detail, 3 bits): this field indicates the layer or level of detail of the avatar to which the AAU applies.¶
AvID (Avatar ID, 8 bits): this field identifies the avatar to which the animation data in the payload of the packet applies. The avatar corresponds to the digital assets to be animated.¶
Three different types of RTP packet payload structures are specified. A single unit packet contains a single AAU in the payload. A fragmentation unit contains a subset of a AAU. An aggregation packet contains multiple Avatar animation units in the payload. The unit type (UT) field of the RTP payload header, as shown in Figure 5, identifies both the payload structure and, in the case of a single-unit structure, also identifies the type of Avatar animation unit present in the payload.¶
Unit Payload Name Type Structure ---------------------------------------- 0 N/A Reserved 1 Single Configuration AAU 2 Single Animation AAU 3 Single Joint AAU 4 Single Landmark AAU 13 Aggr Aggregation Packet (STAP) 14 Aggr Aggregation Packet (MTAP) 15 Frag Fragmentation Unit
The payload structures are represented in Figure 6. The single unit payload structure is specified in Section 5.4.2. The fragmented unit payload structure is specified in Section 5.4.3. The aggregation unit payload structure is specified in Section 5.4.4.¶
+-------------------+
| RTP Header |
+-------------------+
| RTP Payload Header|
+-------------------+ | (Aggregation) |
| RTP Header | +-------------------+
+-------------------+ +-------------------+ | AAU 1 Size |
| RTP Header | | RTP Payload Header| +-------------------+
+-------------------+ | (Fragmentation) | | AAU 1 |
| RTP Payload Header| +-------------------+ +-------------------+
+-------------------+ | FU Header | | AAU 2 Size |
| RTP Payload | +-------------------+ +-------------------+
| (Single AAU)| | | RTP Payload | | ... |
+-------------------+ +-------------------+ +-------------------+
(a) single unit (b)fragmentation unit (c) aggregation packet
In a single unit payload structure, as described in Figure 7, the RTP packet contains the RTP header, followed by the Payload Header and one single AAU. The Payload Header follows the structure described in Section 5.3. The payload contains an AAU as defined in [ISO.IEC.23090-39].¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Payload Header | | +---------------+ | | AAU Data | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | :...OPTIONAL RTP padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In a fragmented unit payload structure, as described in Figure 8, the RTP packet contains the RTP header, followed by the Payload Header, a Fragmented Unit (FU) header, and an AAU fragment. The Payload Header follows the structure described in Section 5.3. The value of the UT field of the Payload Header is 15. The FU header follows the structure described in Figure 9.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Payload Header | FU Header | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | AAU Fragment | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | :...OPTIONAL RTP padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FU headers are used to enable fragmenting a single AAU into multiple RTP packets. Fragments of the same AAU MUST be sent in consecutive order with ascending RTP sequence numbers (with no other RTP packets within the same RTP stream being sent between the first and last fragment). FUs MUST NOT be nested, i.e., an FU MUST NOT contain a subset of another FU.¶
Figure 9 describes a FU header, including the following fields:¶
+-------------------------------+ | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | +---+---+---+---+---+---+---+---+ |FUS|FUE| RSV | UT | +---+---+-------+---------------+
FUS (Fragmented Unit Start, 1 bit): this field MUST be set to 1 for the first fragment, and 0 for the other fragments.¶
FUE (Fragmented Unit End, 1 bit): this field MUST be set to 1 for the last fragment, and 0 for the other fragments.¶
RSV (Reserved, 3 bits): these bits MUST be set to 0 by the sender and ignored by the receiver.¶
UT (Unit Type, 4 bits): this field indicates the type of the AAU this fragment belongs to, using values defined in Figure 5.¶
In an aggregation packet, as described in Figure 10, the RTP packet contains an RTP header, followed by a Payload Header, and, for each aggregated AAU, an AAU size followed by the AAU. The Payload Header follows the structure described in Section 5.3.¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Payload Header | AAU 1 Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AAU 1 |
| |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AAU 2 Size | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| AAU 2 |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10 shows a Single-Time Aggregation Packet (STAP), which can be used to transmit multiple avatar animation units that correspond to the same timestamp. For example, if two different AAUs are used for different animations for different parts of the avatar, they can be transmitted together in a single STAP. The default sizes of the avatar animation unit length field is 16 bits. The value of the UT field of the Payload Header is 13.¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Payload Header | AAU 1 Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS offset | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| AAU 1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AAU 2 Size | TS offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS offset | |
|-+-+-+-+-+-+-+-+ |
| AAU 2 |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11 shows a multi-time aggregation packet. It is used to transmit multiple Avatar animation units with different timestamps, in one RTP packet. Multi-time aggregation can help reduce the number of packets, in environments where some delay is acceptable. The default sizes of the TS offset and the AAU length fields are 16 bits each. The value of the UT field of the Payload Header is 14. In case of MTAP, the timestamp offset field MUST be set to the value of (AAU-time of the animation unit - RTP timestamp of the packet). The timestamp offset of the earliest aggregation unit MUST always be zero. Therefore, the RTP timestamp of the MTAP is identical to the earliest AAU-time.¶
The following considerations apply for the streaming of avatar animation units over RTP:¶
In some multimedia conference scenarios using an RTP video mixer (e.g., when adding or selecting a new source), it is recommended to use Full Intra Request (FIR) feedback [RFC5104] messages with avatar animation. The purpose of the FIR message is to cause an encoder to send a decoder refresh point at the earliest opportunity. In the context of avatar animation, an appropriate decoder refresh point is a configuration AAU. The configuration AAU point enables a decoder to be reset to a known state and be able decode all AAUs following it.¶
This section describes payload formant optional parameters. A mapping of the parameters into the Session Description Protocol (SDP) [RFC8866] is also provided for applications that use SDP. Equivalent parameters could be defined elsewhere for use with control protocols that do not use SDP.¶
The receiver MUST ignore any parameter unspecified in this memo.¶
Type name: application¶
Subtype name: ampg¶
Required parameters: N/A¶
Optional parameters are defined in the following section.¶
version provides the year of the edition and amendment of the specifications followed by this RTP payload type.¶
profile name of the profile used to generate the encoded stream.¶
avatar-id identifies the avatars which are the target of the avatar animation stream. This parameter is a comma-separated list of integers.¶
avatar-lod indicates which levels of detail are used in the avatar animation stream. This parameter is a comma-separated list of integers.¶
avatar-part-id identifies which specific parts of the avatar are associated with the avatar animation stream. This parameter is a comma-separated list of integers.¶
General congestion control considerations for RTP transmission, as described in [RFC3550], also apply to avatar streaming over RTP. By adjusting the SDP 'avatar-lod' parameter, it is possible to reduce processing load and optimize bandwidth usage, thereby partially mitigating congestion issues. The ability to adapt the level of detail dynamically allows senders or receivers to manage computational complexity and network resource consumption based on system constraints or user context. Moreover, in use cases such as video conferencing, different levels of detail may be applied to different parts of the avatar and transmitted via separate streams.¶
The mapping of above defined payload format media type to the corresponding fields in the Session Description Protocol (SDP) is done according to [RFC8866].¶
The media name in the "m=" line of SDP MUST be application.¶
The encoding name in the "a=rtpmap" line of SDP MUST be ampg¶
The clock rate in the "a=rtpmap" line may be any sampling rate.¶
The OPTIONAL parameters (defined in Section 7.2), when present, MUST be included in the "a=fmtp" line of SDP. This is expressed as a media type string, in the form of a semicolon-separated list of parameter=value pairs.¶
An example of media representation corresponding to the avatar animation RTP payload in SDP is as follows:¶
m=application 43291 UDP/TLS/RTP/SAVPF 120 a=rtpmap:120 ampg/8000 a=fmtp:120 profile=1;version=2025¶
When using the offer/answer procedure described in [RFC3264] to negotiate the use of avatar animations, the following considerations apply:¶
When used for a unidirectional stream, the SDP parameters represent the properties of the sender (on the sending side) and of the receiver (on the receiving side). When used for a sendrecv stream, the SDP parameters represent the properties of the receiver.¶
The avatar animation signal can be sampled at different rates. The Avatar Animation standard does not mandate a specific frequency.¶
The receiver properties expressed using the SDP parameters 'version', 'profile' have a mandatory character, since they represent implementation capabilities. The version and profile parameters MUST be used symmetrically in SDP offer and answer. That is, their values in the answer MUST match those in the offer, either explicitly signaled or implicitly inferred. In the same session, version and profile MUST NOT be changed in subsequent offers or answers.¶
The parameter 'version' indicates the version of the avatar animation standard specification. If it is not specified, the initial version of the avatar animation specification SHOULD be assumed, although the sender and receiver MAY use a specific value based on an out-of-band agreement. The parameter 'profile' is used to restrict the number of tools used. If it is not specified, the most general profile "main" SHOULD be assumed, although the sender and receiver MAY use a specific value based on an out-of-band agreement.¶
Any receiver compliant with [ISO.IEC.23090-39] must accept any stream with a compatible version and profile. A receiver supporting a more general profile will accept a stream corresponding to a same or less general profile (e.g., "main" is more general than other profiles).¶
The properties expressed using SDP parameters other than 'version' and 'profile' are provided as recommendations for efficient data transmission and are not binding, meaning that a sender is encouraged but not required to conform to the parameters specified by the receiver. These properties may be set to different values in offers and answers. These properties may be updated in subsequent offers or answers.¶
The parameters 'avatar-id', 'avatar-lod', and 'avatar-part-id' can be sent by a sender to reflect the characteristics of bitstreams and can be set by a receiver to reflect the capabilities and configurations of the local player device, or a preferred set of bitstream properties.¶
The parameter avatar-id indicates that the AAUs of the stream correspond to the one or more avatar IDs signalled with this parameter. The receiver, to be able to render the animations, needs to have loaded the corresponding animation models.¶
The parameter avatar-part-id indicates that the AAUs of the stream corresponds to the one or more avatar part IDs signalled with this parameter. The receiver, to be able to render the animations, needs to have loaded parts of the animation models corresponding to the part IDs.¶
The parameter avatar-lod indicates that the AAUs of the stream correspond to the one or more level of details signalled by this parameter. The receiver, to be able to render the animations, needs to have loaded parts of the animation models including the assets corresponding to the signalled level of details.¶
A receiver may ignore any part of a received stream, e.g., that it does not have support for rendering.¶
When avatar animation over RTP is offered with SDP in a declarative style, the parameters capable of indicating both bitstream properties as well as receiver capabilities are used to indicate only bitstream properties. For example, in this case, the parameters avatar-id, avatar-lod, and avatar-part-id declare the values used by the bitstream, not the capabilities and configurations for receiving bitstreams. A receiver of the SDP is required to support all parameters and values of the parameters provided; otherwise, the receiver MUST reject or not participate in the session. It falls on the creator of the session to use values that are expected to be supported by the receiving application.¶
New media types will be registered with IANA; see Section 7.1.¶
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550], and in any applicable RTP profile such as RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711], or RTP/SAVPF [RFC5124].¶
For example, an avatar may contain sensitive information derived from a user's personal data, and thus requires protection against leakage or tampering during transmission. When avatar data is delivered over a network or downloaded from a server, it is critical to ensure its integrity and confidentiality to prevent unauthorized access, modification, or confidentiality.¶
However, as "Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202] discusses, it is not an RTP payload format's responsibility to discuss or mandate what solutions are used to meet the basic security goals like confidentiality, integrity, and source authenticity for RTP in general. This responsibility lays on anyone using RTP in an application. They can find guidance on available security mechanisms and important considerations in "Options for Securing RTP Sessions" [RFC7201]. Applications SHOULD use one or more appropriate strong security mechanisms. The rest of this Security Considerations section discusses the security impacting properties of the payload format itself.¶