]> BubbleFish Technologies, Inc.

naalp-editor@bubblefish.sh

ART agents agentic application layer post-quantum CBOR COSE The Native Agentic Application Layer Protocol (N-AALP) is an application-layer object protocol for autonomous software agents. Every N-AALP object is a deterministically encoded CBOR structure signed with COSE, carrying under one signature its content identity, its originating signer, a closed effect label that is an authorization input rather than a hint, optional approval and audit bindings, and its causal derivation. Objects are transport- independent: the identical signed object is carried, with identical object-level guarantees, over the N-PAMP substrate, QUIC, WebSocket, or HTTP. N-AALP defines a frozen envelope, a post-quantum signature profile (ML-DSA with an optional Ed25519 hybrid), a self-certifying identity with key rotation, a single-use approval ledger, a hash-chained audit and causal- ordering model with a federated higher tier, native streaming with a single per-stream commitment, foreign-protocol carriage by class, and twenty tiered channel surfaces. This document is an Independent Submission and does not represent IETF consensus.

Introduction Autonomous agents increasingly exchange consequential messages -- tool invocations, memory writes, capability delegations, settlements -- across trust and organizational boundaries. Existing agent protocols secure the transport connection but leave the individual message un-signed, its effect on the world undeclared, and its authorization implicit. N-AALP makes the object, not the connection, the unit of security and governance. N-AALP is the application layer above the N-PAMP substrate : N-PAMP provides the post-quantum secure channel, channel identifiers, and foreign-protocol Bridge; N-AALP provides the signed, effect-labeled, audited object that rides any transport. The two compose but N-AALP does not require N-PAMP: the same object is valid over QUIC, WebSocket, or HTTP.

Scope This document specifies: the object envelope and its deterministic CBOR encoding (# Object Model); the COSE signing constructions and crypto-agile profiles (# Cryptographic Constructions); self-certifying identity and key lifecycle (# Identity); the closed effect vocabulary and effect-to-authorization rule (# Effects and Authorization); the approval object and single-use consume ledger (# Approval); the audit receipt chain, causal graph, and tiered ordering (# Audit, Causal Graph, and Ordering); delivery stages (# Delivery); native streaming (# Streaming); the four transport bindings and the confidentiality boundary (# Transport Bindings); foreign carriage by class (# Foreign Carriage by Class); and the twenty tiered channel surfaces (# Channel Surfaces).

Non-Goals N-AALP does not define a transport handshake, key exchange, or record layer; those are the substrate's (N-PAMP's, or the underlying TLS/QUIC's). It does not define agent reasoning, planning, or model behavior. It does not replace the foreign protocols it carries; it wraps them.

Conventions and Terminology 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 when, and only when, they appear in all capitals, as shown here. The following terms are used:

Object:

a deterministically encoded CBOR map, signed with COSE, that is the unit of N-AALP security and governance.

Content id:

the multihash of the SHA-384 of an object's canonical body excluding its own id field; it binds the object's bytes.

Signer id:

a self-certifying identifier derived from a public signing key (# Identity); no certificate authority is involved.

Effect:

one closed value stating what an object does to the world, aligned with the N-PAMP Bridge SafetyLabel and used as an authorization input (# Effects and Authorization).

Channel:

one of twenty application surfaces, identified by an N-PAMP channel id (# Channel Surfaces).

Carriage:

wrapping a foreign protocol's message octet-for-octet inside a signed N-AALP object (# Foreign Carriage by Class).

Architecture N-AALP separates three layers that MUST NOT be conflated:

1. The object (this document): self-secured, transport-independent.
2. The transport: provides confidentiality, connection authentication, and framing; N-PAMP is the reference confidential transport, but QUIC, WebSocket, and HTTP are equally valid carriers of the identical object.
3. The application: the twenty channel surfaces, each a thin body over the one object model.

Object-level guarantees (integrity, identity, non-repudiation, effect, audit) are always present regardless of transport. Confidentiality, forward secrecy, and connection authentication are transport-provided and conditional (# Transport Bindings).

Object Model

Deterministic encoding All N-AALP structures are encoded as deterministic CBOR per Section 4.2.1: shortest-form integer and length encoding, major-type map keys sorted in bytewise-lexicographic order of their encoded form, no indefinite-length items, and no duplicate keys. A non-canonical encoding of any structure defined here MUST be rejected.

The object body The signed payload is the object body, a CBOR map, expressed here in CDDL :

any }, ; ext: non-critical; unknown ignored ? 12 : { * uint => any }, ; cext: critical; unknown => reject } effect = &( read_only:0, idempotent_write:1, non_idempotent_write:2, destructive:3 ) profile = &( public:1, enterprise:2, sovereign:3 ) ]]>

Content identity The id (field 1) is multihash(0x20, SHA-384(C)) where C is the deterministic CBOR encoding of the body with field 1 removed, and 0x20 is the multiformats code for SHA-384. A verifier recomputes the content id and MUST reject a mismatch (ContentIdMismatch). Because the id binds the exact bytes, altering any field changes the id.

Extensions and versioning Field 11 (ext) carries non-critical extensions a verifier that does not recognize them MUST ignore. Field 12 (cext) carries critical extensions a verifier that cannot honor them MUST reject the whole object (fail-closed). Higher channel tiers add capability solely through these fields and the tier field; the envelope does not change across versions or tiers.

Cryptographic Constructions

Signing An object is signed with COSE_Sign1 over the deterministic-CBOR object body as the payload. The protected header carries the COSE algorithm and a pre-parse routing copy of the signer, profile, and protocol version under a text-string label. A verifier MUST reject an object whose header signer/profile copies disagree with body fields 5 and 9 (HeaderBodyMismatch). On the wire the object is a tagged COSE_Sign1 (CBOR tag 18); the optional hybrid uses tagged COSE_Sign (tag 98) and is accepted only if all its signatures verify.

Algorithms and profiles The mandatory-to-implement signature algorithm is ML-DSA using the deterministic variant (rnd = 0) so two implementations produce byte-identical signatures. The classical hybrid leg is Ed25519 . Within the COSE algorithm framework , the algorithm identifiers are those registered for ML-DSA and Ed25519 ; N-AALP does not define new COSE algorithm code points and reuses the existing IANA COSE Algorithms registry. Three profiles select a signature floor:

profile	value	signature floor
public	1	ML-DSA-65 (NIST level 3)
enterprise	2	ML-DSA-65 (NIST level 3)
sovereign	3	ML-DSA-87 (NIST level 5)

A verifier for a profile MUST reject a signature below the profile's floor (ProfileDowngrade) and an unknown algorithm (UnknownAlg). The optional Ed25519+ML-DSA hybrid (COSE_Sign) is accepted only when both legs verify (HybridIncomplete otherwise). Digests use SHA-384 .

Identity The signer id (object field 5) is self-certifying: multibase(base32, multihash(0x12, SHA-256(multicodec(mc, pubkey)))), identical in form to the N-PAMP PeerHandle, where mc is the multiformats key-type code (0xed ed25519-pub, 0x1211 mldsa-65-pub, 0x1212 mldsa-87-pub). A verifier recomputes the id from the key and MUST reject a mismatch (SignerMismatch). No certificate authority is involved. Key lifecycle records are signed with the same COSE crypto: a Rotation is co-signed by both the old and new key; a Revocation is signed by the revoked key or a recovery key; a foreign-identity link is cross-signed by the foreign identity's key. Identity strings that carry human text MUST be Unicode NFC (NonNFC otherwise). A receipt signed under a superseded key remains attributable to the durable identity thread across rotations.

Effects and Authorization Every object carries, under signature, one value from a closed four-value effect vocabulary aligned 1:1 with the N-PAMP Bridge SafetyLabel: read_only (0), idempotent_write (1), non_idempotent_write (2), destructive (3). The values form a lattice with destructive at the top. An unrecognized effect value MUST be treated as destructive and MUST NOT fail open. Unlike a SafetyLabel that "describes intent and does not replace authorization", the N-AALP effect IS an authorization input: an endpoint grants a maximum effect (a capability) to an authenticated signer id, and an object is authorized only if its effect does not exceed the grant (EffectNotAuthorized otherwise). No layer MUST treat transport metadata, a foreign header, or a client-supplied name as an authorization identity; the authorizing principal is the object's signature-verified signer id. An object MAY carry an optional signed safety label (a non-critical ext) { risk, scope }; it is an accountable claim attributable to the signer, not a guarantee that the content is safe.

Approval An Approval object binds, under signature, the content id of the exact canonical argument object it approves, so approving one action cannot authorize another (ApprovalMismatch if the args are mutated). It carries the approver signer id, the granted effect, an anti-replay nonce, and an expiry. The consume ledger is a durable, hash-chained set keyed by approval content id. Consume is an atomic compare-and-set: the first consumer appends a ledger entry and wins; a second consume for the same approval id is rejected (AlreadyConsumed). Atomicity is provided by a write-ahead log written before the acknowledgment and a single-writer-per-approval-id discipline; under concurrency exactly one consumer succeeds. An approval past its expiry is rejected (ApprovalExpired). An approval-required-but-not-granted outcome is a distinct signed non-success result, never a silent success or denial.

Audit, Causal Graph, and Ordering An ordering authority records each accepted object by appending a signed Receipt { prev, obj, seq, at } where prev is the SHA-384 of the previous receipt body (genesis is zero) and obj is the object content id. The chain is tamper-evident: reordering, omission, or substitution breaks a prev link or a seq (ChainBroken). The authority MUST NOT mutate the origin object to order it; ordering is an outer signed layer. Every object MAY name its causes by content id (field 8). This is a signed partial order: an edge "A causes B" is proven by B's signature over A's content id, checkable offline with no ordering authority present. An object MUST NOT name a cause it could not have seen (a cause whose ordering position exceeds the effect's, or a cycle), which is rejected (CausalViolation). A total order is a policy layered over this partial order. An independent auditor detects equivocation -- two receipts by one authority at one seq naming different objects -- from the signed receipts alone (Equivocation). A receipt whose signature does not verify is rejected (ReceiptUnsigned). Ordering is tiered. The baseline tier is a single authority's monotonic receipt chain. The higher tier is federated: multiple independent authorities each order their own scope and reconcile deterministically over the shared causal graph (a topological linearization tie-broken by content id). Because the merge depends only on the causal graph, both tiers order the identical signed objects and moving to federated ordering requires no envelope change.

Delivery Delivery is four distinct, monotonic, separately-observable stages, each a signed delivery update naming the object content id and the stage reached: persisted_origin (0), accepted_relay (1), persisted_target (2), presented (3). There is no single "sent" flag. An endpoint MUST durably persist an object before emitting the acknowledgment that advances its stage (persist-before-acknowledge), so a crash immediately after an acknowledgment loses nothing. A stage earlier than the one already reached is rejected (StageOutOfOrder). A relay that holds an object only in transit MAY write an audit trail over content ids while retaining no payload.

Streaming A native stream is three signed objects plus unsigned chunks. StreamOpen binds the stream identity, effect, and (where it causes an effect) approval; a stream whose effect is not authorized is refused before any chunk. Chunks are raw data frames the transport authenticates; they are not individually signed. StreamCommit carries a single rolling SHA-384 over the chunks in absolute-offset order, making the whole stream non-repudiable with one signature; altering any delivered byte invalidates it (StreamDigestMismatch). Optional signed StreamCheckpoints let a verifier confirm a prefix without the end. The same three objects map onto QUIC streams, WebSocket messages, and HTTP chunked/event streams; the commitment verifies identically across transports.

Transport Bindings A binding carries exactly one signed object as one message unit, with identical object semantics over N-PAMP, QUIC, WebSocket, and HTTP. The object is self-secured; the binding adds only framing and, from the transport, confidentiality and connection authentication. The media type is application/naalp+cbor (one object per representation). The confidentiality boundary is normative: an object marked sensitive MUST NOT be emitted in cleartext over a non-confidential transport; the binding refuses it (ConfidentialTransportRequired) and directs the deployment to a confidential transport. A transport lacking peer authentication where policy requires it is refused (PeerUnauthenticated).

Foreign Carriage by Class N-AALP carries a foreign agent protocol by wrapping its message, octet-for-octet, in a signed carriage object interpreted by a carriage class:

The foreign field is carried verbatim and MUST NOT be re-serialized, canonicalized, summarized, or rewritten. The carriage object's signer remains the authority: a foreign protocol's identity, header, or metadata MUST NOT become an N-AALP authorization identity. The OPAQUE class carries any protocol, including an undefined one, on an experimental protocol id with no registration. A below-foreign failure uses a defined structured error and MUST NOT report an undelivered message as delivered; an N-AALP semantic a foreign protocol cannot represent surfaces a typed mapping error, never a silent drop.

Channel Surfaces N-AALP defines twenty channel surfaces (channel ids 0x0000..0x0013): Control, Memory, Capability, Identity, Governance, Immune, Federation, Settlement, Compliance, Sensory, Telemetry, Audit, Stream, Bridge, Commerce, Interaction, Discovery, Workflow, Knowledge, and Spatial. Each surface adds only object kind codes and their declared effects over the one object model; it introduces no channel-local encoding, signature, or identity. Every channel has a complete frozen baseline surface. Higher tiers add capability under the frozen envelope through the tier field and critical/non-critical extensions. The complete kind/effect table is the N-AALP Channel and Object Kind registries (# IANA Considerations).

Security Considerations Mandatory-to-implement algorithms and post-quantum rationale: N-AALP signs with ML-DSA , a post-quantum signature, because N-AALP objects (receipts, approvals, audit chains) are long-lived non-repudiable records subject to store-now-verify-later forgery risk from a future cryptographically relevant quantum computer; a classical-only signature on such records would be a latent forgery exposure. An optional Ed25519 hybrid provides defense-in-depth during the transition and is accepted only when both legs verify. Downgrade and negotiation: algorithm agility is expressed by the COSE algorithm identifier bound under the signature and checked against the profile floor; a signature below the floor is rejected, so agility cannot become a downgrade. Replay and reordering: approvals bind a nonce and expiry and are single-use through the consume ledger; the audit receipt chain binds each object into a hash chain so reordering, omission, and substitution are detectable; delivery stages are monotonic. Identity and trust: the signer id is a pure function of the public key, so a forged id cannot recompute; there is no certificate authority to compromise. Compromise of a signing key is bounded by rotation and revocation, and attribution survives rotation. A non-injective or forgeable identity function would collapse this property; the SHA-256 multihash over the multicodec-tagged key provides collision and second-preimage resistance. Effect and authorization: the effect is an authorization input, not a hint; an unrecognized effect fails closed to destructive; authorization is never derived from transport metadata or a foreign principal. This closes the gap a pure intent label leaves open. Denial of service: an object requires one signature verification and one deterministic decode; verification is fail-closed and performed before any state change or effect. Streaming amortizes one signature over many chunks. Implementations SHOULD bound object and stream sizes by policy. Confidentiality: object-level guarantees do not include confidentiality; a sensitive object MUST use a confidential transport (# Transport Bindings), enforced by refusal. What N-AALP does NOT defend against: it does not provide confidentiality by itself (that is the transport's); it cannot force an ordering authority to deliver events it chooses to withhold (a chain reveals equivocation and omission-of-known-events but cannot compel delivery); it does not police the semantic correctness of a carried foreign message beyond octet-exact carriage; and it does not defend against a signer that is itself authorized and malicious (it makes that signer's actions attributable and auditable, not impossible).

IANA Considerations This document is an Independent Submission. All registries requested below use registration policies that do not require IETF Review or Standards Action, consistent with the Independent stream: media-type registration under , and per-registry Specification Required with a Designated Expert per . Numeric values shown are the values this specification defines; where IANA assignment is requested the placeholder TBD is used.

Media type application/naalp+cbor IANA is requested to register the following media type in the standards tree per , using the +cbor structured syntax suffix defined in and registered in the IANA Structured Syntax Suffixes registry (whose mechanism is established by and populated by ):

• Type name: application
• Subtype name: naalp+cbor
• Required parameters: none
• Optional parameters: none
• Encoding considerations: binary (CBOR per )
• Security considerations: see (# Security Considerations) of this document
• Interoperability considerations: objects are deterministic CBOR; see (# Object Model)
• Published specification: this document
• Applications that use this media type: autonomous-agent application-layer messaging
• Fragment identifier considerations: as specified for application/cbor
• Additional information: Magic number(s): none; File extension(s): .naalp; Macintosh file type code(s): none
• Person & email address to contact for further information: the author (front matter)
• Intended usage: COMMON
• Restrictions on usage: none
• Author: S. Sammartano
• Change controller: the author (BubbleFish Technologies, Inc.)

N-AALP Channel registry IANA is requested to create the "N-AALP Channels" registry. Registration policy: Specification Required (a Designated Expert confirms a stable public specification and non-collision). Columns: Channel Id (uint 0..19), Name, Reference. Initial contents: the twenty channels of (# Channel Surfaces), ids 0x0000..0x0013, this document.

N-AALP Object Kind registries IANA is requested to create, per channel, an "N-AALP Object Kinds (channel N)" registry. Registration policy: Specification Required. Columns: Kind Code (uint), Name, Effect (one of the four closed effect names, or "variable"), Reference. Initial contents: the sixty-five baseline kinds of this document.

N-AALP Effect registry IANA is requested to create the "N-AALP Effects" registry. Registration policy: Specification Required (this closed set is not expected to grow; additions require a stable specification and MUST preserve the fail-closed lattice). Columns: Value (0..3), Name, Reference. Initial contents: read_only 0, idempotent_write 1, non_idempotent_write 2, destructive 3, this document.

N-AALP Carriage Protocol Id registry IANA is requested to create the "N-AALP Carriage Protocol Ids" registry, a one-octet space partitioned: standards 0x01-0x0F (Specification Required), experimental 0x10-0x7F (no registration), private 0x80-0xFF (no registration). Columns: Protocol Id, Name, Carriage Class, Reference. Initial standards-range contents: 0x01 MCP (JSONRPC), 0x02 A2A (JSONRPC), 0x03 HTTP (HTTP), 0x04 WebSocket (STREAM), this document.

N-AALP Error Code registry IANA is requested to create the "N-AALP Error Codes" registry. Registration policy: Specification Required. Columns: Name, Retryable, Reference. Initial contents: the named errors of this document (ContentIdMismatch, HeaderBodyMismatch, UnknownCriticalExt, UnknownKind, RangeError, NonCanonical, NonNFC, ProfileDowngrade, UnknownAlg, HybridIncomplete, BadSignature, SignerMismatch, RotationUnauthorized, KeyRevoked, EffectNotAuthorized, UnauthenticatedPrincipal, ApprovalMismatch, ApprovalExpired, AlreadyConsumed, ApprovalRequired, ChainBroken, Equivocation, CausalViolation, ReceiptUnsigned, StageOutOfOrder, StreamDigestMismatch, ConfidentialTransportRequired, PeerUnauthenticated, NotDelivered, MappingError, ScopeOverlapConflict, CapExceedsParent, TransformCycle, InputGateBypass).

COSE algorithms N-AALP reuses the existing IANA COSE Algorithms registry for ML-DSA and Ed25519 and requests no new COSE code points.

Designated Expert guidance For each Specification-Required registry the Designated Expert confirms: (1) a stable, publicly available specification documents the value; (2) the value does not collide with an existing entry; (3) the name is protocol-neutral and carries no vendor product name; and (4) for object kinds, the declared effect is one of the closed set and preserves the fail-closed model.

Implementation Status RFC-Editor: please remove this section and the reference to before publication. This section records the status of known implementations at the time of posting, per . Listing here does not imply endorsement. Two independent reference implementations exist, in Go and in Rust, from a single codebase but separate language runtimes. For every construction carrying a security or interoperability claim (deterministic CBOR and content id; COSE_Sign1 and the ML-DSA/Ed25519 profiles; the object envelope; signer id; effect authorization; approval and the consume ledger; audit chain, causal graph, and federated reconcile; delivery; streaming; transport bindings; foreign carriage; and the twenty channel surfaces), the two implementations produce byte-identical output and are cross-validated against an independent oracle whose expected values come from the relevant RFC, FIPS, or NIST vector or a from-scratch constructor, never from the implementation under test. A runnable conformance harness grades every construction and validates the CDDL module against the committed vectors. Coverage and known gaps are tracked in the project's parity ledger.

Conformance A conforming implementation MUST implement the object model, the signing constructions, identity, effects and authorization, and the baseline surfaces of every channel, and MUST reject a non-conforming object whole with its named error and no state change (fail-closed). Conformance is demonstrated against the machine-gradable vector corpus and the CDDL module (Appendix A). This specification recommends, but does not require for Independent-stream publication, two independent interoperating implementations; two exist (# Implementation Status).

Specification License This specification may be implemented by anyone, royalty-free. This right to implement is granted independently of the license of any reference implementation (the reference code is licensed separately). Contributions to this document are subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents.

Normative References The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052). This document, along with RFC 9052, obsoletes RFC 8152. This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. This document specifies JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for the Module-Lattice-Based Digital Signature Standard (ML-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in US NIST FIPS 204. This specification refers to cryptographic algorithm identifiers that fully specify the cryptographic operations to be performed, including any curve, key derivation function (KDF), and hash functions, as being "fully specified". It refers to cryptographic algorithm identifiers that require additional information beyond the algorithm identifier to determine the cryptographic operations to be performed as being "polymorphic". This specification creates fully-specified algorithm identifiers for registered JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) polymorphic algorithm identifiers, enabling applications to use only fully-specified algorithm identifiers. It deprecates those polymorphic algorithm identifiers. This specification updates RFCs 7518, 8037, and 9053. It deprecates polymorphic algorithms defined by RFCs 8037 and 9053 and provides fully-specified replacements for them. It adds to the instructions to designated experts in RFCs 7518 and 9053. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. National Institute of Standards and Technology National Institute of Standards and Technology In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. A content media type name sometimes includes partitioned meta- information distinguished by a structured syntax to permit noting an attribute of the media as a suffix to the name. This document defines several structured syntax suffixes for use with media type registrations. In particular, it defines and registers the "+json", "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" structured syntax suffixes, and provides a media type structured syntax suffix registration form for the "+xml" structured syntax suffix. This document is not an Internet Standards Track specification; it is published for informational purposes. BubbleFish Technologies, Inc.

Collected CDDL The complete, machine-validated CDDL module is maintained with the reference implementation as spec/naalp-draft-00.cddl and is normative for the byte-level wire format. It is validated for well-formedness and against the conformance vectors by the project's conformance harness. The object body, effect, and profile productions of (# Object Model) and the carriage body of (# Foreign Carriage by Class) are reproduced there in full, together with the COSE wrapper, protected header, identity records, safety label, approval and consume records, receipt, delivery update, stream objects, and the federated reconcile record.

Acknowledgments N-AALP builds on the N-PAMP substrate.