From 691eea6036b4c5d83d4ffcbde2c27b88ba6e6236 Mon Sep 17 00:00:00 2001 From: Klaus Deissner Date: Wed, 9 Oct 2019 17:58:25 +0200 Subject: [PATCH 1/6] Changed name from transport to protocol binding. Adjusted the protocol binding to the definition of event format that is introduced in #521. Signed-off-by: Klaus Deissner --- ...ort-binding.md => amqp-protocol-binding.md | 85 +++++++++++-------- 1 file changed, 49 insertions(+), 36 deletions(-) rename amqp-transport-binding.md => amqp-protocol-binding.md (81%) diff --git a/amqp-transport-binding.md b/amqp-protocol-binding.md similarity index 81% rename from amqp-transport-binding.md rename to amqp-protocol-binding.md index 670d3116d..3de7ed757 100644 --- a/amqp-transport-binding.md +++ b/amqp-protocol-binding.md @@ -21,9 +21,6 @@ This document is a working draft. 2. [Use of CloudEvents Attributes](#2-use-of-cloudevents-attributes) -- 2.1. [datacontenttype Attribute](#21-datacontenttype-attribute) -- 2.2. [data](#22-data) - 3. [AMQP Message Mapping](#3-amqp-message-mapping) - 3.2. [Binary Content Mode](#31-binary-content-mode) @@ -68,7 +65,7 @@ modes. In the _structured_ content mode, event metadata attributes and event data are placed into the AMQP message's [application data][data] section using an -[event format](#14-event-formats). +[event format](event-format). In the _binary_ content mode, the value of the event `data` is placed into the AMQP message's [application data][data] section as-is, with the @@ -80,9 +77,7 @@ section. Event formats, used with the _stuctured_ content mode, define how an event is expressed in a particular data format. All implementations of this specification -MUST support the [JSON event format][json-format] as well as the [AMQP event -format][amqp-format] for the [application-properties][app-properties] section, -but MAY support any additional, including proprietary, formats. +MUST support the [JSON event format][json-format]. ### 1.5. Security @@ -94,33 +89,14 @@ mandate specific existing features to be used. This specification does not further define any of the [CloudEvents][ce] event attributes. -Two of the event attributes, `datacontenttype` and `data` are handled specially -and mapped onto AMQP constructs, all other attributes are transferred as +One event attribute, `datacontenttype` is handled specially in *binary* content +mode and mapped onto AMQP constructs. All other attributes are transferred as metadata without further interpretation. This mapping is intentionally robust against changes, including the addition and removal of event attributes, and also accommodates vendor extensions to the -event metadata. Any mention of event attributes other than `datacontenttype` and -`data` is exemplary. - -### 2.1. datacontenttype Attribute - -The `datacontenttype` attribute is assumed to contain a [RFC2046][rfc2046] -compliant media-type expression. - -### 2.2. data - -`data` is assumed to contain opaque application data that is -encoded as declared by the `datacontenttype` attribute. - -An application is free to hold the information in any in-memory representation -of its choosing, but as the value is transposed into AMQP as defined in this -specification, the assumption is that the `data` value is made -available as a sequence of bytes. - -For instance, if the declared `datacontenttype` is -`application/json;charset=utf-8`, the expectation is that the `data` -value is made available as [UTF-8][rfc3629] encoded JSON text for use in AMQP. +event metadata. Any mention of event attributes other than `datacontenttype` +is exemplary. ## 3. AMQP Message Mapping @@ -151,13 +127,25 @@ directly to the CloudEvents `datacontenttype` attribute. #### 3.1.2. Event Data Encoding -The [`data`](#22-data) byte-sequence is used as the AMQP +Event data is assumed to contain opaque application data that is +encoded as declared by the `datacontenttype` attribute. + +An application is free to hold the information in any in-memory representation +of its choosing, but as it is transposed into AMQP as defined in this +specification, the assumption is that the event data is made available as a +sequence of bytes. The byte sequence is used as the AMQP [application-data][data] section. +Example: + +If the declared `datacontenttype` is `application/json;charset=utf-8`, the +expectation is that the event data is made available as [UTF-8][rfc3629] encoded +JSON text for use in AMQP. + #### 3.1.3. Metadata Headers -All [CloudEvents][ce] attributes with exception of `datacontenttype` and `data` -MUST be individually mapped to and from the AMQP +All [CloudEvents][ce] attributes with exception of `datacontenttype` MUST be +individually mapped to and from the AMQP [application-properties][app-properties] section, with exceptions noted below. CloudEvents extensions that define their own attributes MAY define a secondary @@ -169,7 +157,7 @@ mapping. An extension specification that defines a secondary mapping rule for AMQP, and any revision of such a specification, MUST also define explicit mapping rules -for all other transport bindings that are part of the CloudEvents core at the +for all other protocol bindings that are part of the CloudEvents core at the time of the submission or revision. ##### 3.1.3.1 AMQP Application Property Names @@ -186,8 +174,32 @@ Examples: ##### 3.1.3.2 AMQP Application Property Values The value for each AMQP application property is constructed from the respective -attribute's AMQP type representation, compliant with the [AMQP event -format][amqp-format] specification. +attribute's AMQP type representation. + +The CloudEvents type system MUST be mapped to AMQP types as follows, with +exceptions noted below. + +| CloudEvents | AMQP | +| ------------- | --------------------------- | +| Boolean | [boolean][amqp-boolean] | +| Integer | [long][amqp-long] | +| String | [string][amqp-string] | +| Binary | [binary][amqp-binary] | +| URI | [string][amqp-string] | +| URI-reference | [string][amqp-string] | +| Timestamp | [timestamp][amqp-timestamp] | + +A CloudEvents AMQP *binary* mode implementation MUST allow for attribute values +to be convertible from/to their canonical CloudEvents string representation. For +instance, the `time` attribute MUST be convertible from and to a conformant +RFC3339 string value. + +If an non-string attribute is received as string from a communicating party, an +AMQP intermediary MAY convert it to the native AMQP representation before +forwarding the event; an AMQP consumer SHOULD convert it to the native AMQP +representation before surfacing the value to the API. An AMQP implementation +SHOULD convert from/to the native runtime or language type system to the AMQP +type system directly without translating through strings whenever possible. #### 3.1.4 Examples @@ -291,6 +303,7 @@ content-type: application/cloudevents+json; charset=utf-8 (AMQP) Version 1.0 [ce]: ./spec.md +[event-format]: ./spec.md#event-format [json-format]: ./json-format.md [amqp-format]: ./amqp-format.md [data-section]: 3.2.6 From 415993a73f6fb724948872f5650b805aaced0f10 Mon Sep 17 00:00:00 2001 From: Klaus Deissner Date: Wed, 9 Oct 2019 18:10:08 +0200 Subject: [PATCH 2/6] Fixed a link Removed the separate AMQP format definition Signed-off-by: Klaus Deissner --- amqp-format.md | 143 --------------------------------------- amqp-protocol-binding.md | 9 +-- 2 files changed, 3 insertions(+), 149 deletions(-) delete mode 100644 amqp-format.md diff --git a/amqp-format.md b/amqp-format.md deleted file mode 100644 index 8eb6b439d..000000000 --- a/amqp-format.md +++ /dev/null @@ -1,143 +0,0 @@ -# AMQP Event Format for CloudEvents - Version 1.0-rc1 - -## Abstract - -The AMQP Format for CloudEvents defines how event attributes and payload data -are expressed in the [AMQP 1.0 Type System][type-system]. - -## Status of this document - -This document is a working draft. - -## Table of Contents - -1. [Introduction](#1-introduction) -2. [Attributes](#2-attributes) -3. [Data](#3-data) -4. [References](#4-references) - -## 1. Introduction - -[CloudEvents][ce] is a standardized and transport-neutral definition of the -structure and metadata description of events. This specification defines how the -elements defined in the CloudEvents specification are to be represented in the -[AMQP 1.0 Type System][amqp-types]. - -The [Attributes](#2-attributes) section describes the naming conventions and -data type mappings for CloudEvents attributes for use as AMQP message -properties. - -This specification does not define an envelope format. The AMQP type system's -intent is primarily to provide a consistent type system for AMQP itself and not -for message payloads. - -### 1.1. Conformance - -The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", -"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be -interpreted as described in [RFC2119][rfc2119]. - -## 2. Attributes - -This section defines how CloudEvents attributes are mapped to the AMQP -type-system. This specification does not explicitly map each attribute, but -provides a generic mapping model that applies to all current and future -CloudEvents attributes, including extensions. - -### 2.1. Base Type System - -The core [CloudEvents specification][ce] defines a minimal abstract type system, -which this mapping leans on. - -### 2.2. Type System Mapping - -The CloudEvents type system MUST be mapped to AMQP types as follows, with -exceptions noted below. - -| CloudEvents | AMQP | -| ------------- | --------------------------- | -| Boolean | [boolean][amqp-boolean] | -| Integer | [long][amqp-long] | -| String | [string][amqp-string] | -| Binary | [binary][amqp-binary] | -| URI | [string][amqp-string] | -| URI-reference | [string][amqp-string] | -| Timestamp | [timestamp][amqp-timestamp] | - -A CloudEvents AMQP format implementation MUST allow for attribute values to be -convertible from/to their canonical CloudEvents string representation. For -instance, the `time` attribute MUST be convertible from and to a conformant -RFC3339 string value. - -If an non-string attribute is received as string from a communicating party, an -AMQP intermediary MAY convert it to the native AMQP representation before -forwarding the event; an AMQP consumer SHOULD convert it to the native AMQP -representation before surfacing the value to the API. An AMQP implementation -SHOULD convert from/to the native runtime or language type system to the AMQP -type system directly without translating through strings whenever possible. - -Extension specifications MAY define a -[secondary mapping rule](./amqp-transport-binding.md#313-metadata-headers) -for the values of attributes they define, but MUST also include the previously -defined primary mapping. - -For instance, the attribute value may be a data structure defined in a standard -outside of CloudEvents, with a formal AMQP mapping, and there might be risk of -translation errors or information loss when the original format is not -preserved. - -An extension specification that defines a secondary mapping rule for AMQP, and -any revision of such a specification, MUST also define explicit mapping rules -for all other event formats that are part of the CloudEvents core at the time of -the submission or revision. - -## 3. Data - -Before encoding, the AMQP serializer MUST first determine the runtime data type -of the data content. This may be determined by examining the data for characters -outside the UTF-8 range or by consulting the `datacontenttype` attribute. - -If the implementation determines that the type of the data is binary, the value -MUST be stored in the payload as a single [AMQP data][amqp-data] section. - -For other types (non-binary data without a `datacontenttype` attribute), the -implementation MUST translate the data value into an [AMQP type -system][type-system] value and the value MUST be stored in an [AMQP -value][amqp-value] section. - -## 4. References - -- [RFC2046][rfc2046] Multipurpose Internet Mail Extensions (MIME) Part Two: - Media Types -- [RFC2119][rfc2119] Key words for use in RFCs to Indicate Requirement Levels -- [OASIS-AMQP-1.0][oasis-amqp-1.0] OASIS Advanced Message Queuing Protocol - (AMQP) Version 1.0 - -[ce]: ./spec.md -[content-type]: https://tools.ietf.org/html/rfc7231#section-3.1.1.5 -[type-system]: - https://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-types-v1.0-os.html -[type-system-encoding]: - http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-types-v1.0-os.html#section-encodings -[amqp-boolean]: - http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-types-v1.0-os.html#type-boolean -[amqp-long]: - http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-types-v1.0-os.html#type-long -[amqp-string]: - http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-types-v1.0-os.html#type-string -[amqp-binary]: - http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-types-v1.0-os.html#type-binary -[amqp-timestamp]: - http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-types-v1.0-os.html#type-timestamp -[amqp-data]: - http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-data -[amqp-value]: - http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-value -[rfc2046]: https://tools.ietf.org/html/rfc2046 -[rfc2119]: https://tools.ietf.org/html/rfc2119 -[rfc4627]: https://tools.ietf.org/html/rfc4627 -[rfc4648]: https://tools.ietf.org/html/rfc4648 -[rfc6839]: https://tools.ietf.org/html/rfc6839#section-3.1 -[rfc8259]: https://tools.ietf.org/html/rfc8259 -[oasis-amqp-1.0]: - http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-overview-v1.0-os.html diff --git a/amqp-protocol-binding.md b/amqp-protocol-binding.md index 3de7ed757..58e9abbcd 100644 --- a/amqp-protocol-binding.md +++ b/amqp-protocol-binding.md @@ -1,8 +1,8 @@ -# AMQP Transport Binding for CloudEvents - Version 1.0-rc1 +# AMQP Protocol Binding for CloudEvents - Version 1.0-rc1 ## Abstract -The AMQP Transport Binding for CloudEvents defines how events are mapped to +The AMQP Protocol Binding for CloudEvents defines how events are mapped to OASIS AMQP 1.0 ([OASIS][oasis-amqp-1.0]; ISO/IEC 19464:2014) messages. ## Status of this document @@ -65,7 +65,7 @@ modes. In the _structured_ content mode, event metadata attributes and event data are placed into the AMQP message's [application data][data] section using an -[event format](event-format). +event format as defined in the CloudEvents [spec][ce]. In the _binary_ content mode, the value of the event `data` is placed into the AMQP message's [application data][data] section as-is, with the @@ -303,10 +303,7 @@ content-type: application/cloudevents+json; charset=utf-8 (AMQP) Version 1.0 [ce]: ./spec.md -[event-format]: ./spec.md#event-format [json-format]: ./json-format.md -[amqp-format]: ./amqp-format.md -[data-section]: 3.2.6 [content-type]: https://tools.ietf.org/html/rfc7231#section-3.1.1.5 [json-value]: https://tools.ietf.org/html/rfc7159#section-3 [rfc2046]: https://tools.ietf.org/html/rfc2046 From 164b15a581f5be5a32b4b7e266124ce3ada89368 Mon Sep 17 00:00:00 2001 From: Klaus Deissner Date: Thu, 10 Oct 2019 14:55:41 +0200 Subject: [PATCH 3/6] Fixed links Worked on comments from the PR Signed-off-by: Klaus Deissner --- README.md | 2 +- amqp-protocol-binding.md | 35 ++++++++++++++++------------------- documented-extensions.md | 2 +- 3 files changed, 18 insertions(+), 21 deletions(-) diff --git a/README.md b/README.md index 7143f0e65..082c7f90f 100644 --- a/README.md +++ b/README.md @@ -31,7 +31,7 @@ The following documents are available: | | | **Optional Specifications:** | | AMQP Event Format | [v1.0-rc1](https://github.com/cloudevents/spec/blob/v1.0-rc1/amqp-format.md) | [master](https://github.com/cloudevents/spec/blob/master/amqp-format.md) | -| AMQP Transport Binding | [v1.0-rc1](https://github.com/cloudevents/spec/blob/v1.0-rc1/amqp-transport-binding.md) | [master](https://github.com/cloudevents/spec/blob/master/amqp-transport-binding.md) | +| AMQP Transport Binding | [v1.0-rc1](https://github.com/cloudevents/spec/blob/v1.0-rc1/amqp-protocol-binding.md) | [master](https://github.com/cloudevents/spec/blob/master/amqp-protocol-binding.md) | | AVRO Event Format | - | [master](./avro-format.md) | | HTTP Transport Binding | [v1.0-rc1](https://github.com/cloudevents/spec/blob/v1.0-rc1/http-transport-binding.md) | [master](https://github.com/cloudevents/spec/blob/master/http-transport-binding.md) | | JSON Event Format | [v1.0-rc1](https://github.com/cloudevents/spec/blob/v1.0-rc1/json-format.md) | [master](https://github.com/cloudevents/spec/blob/master/json-format.md) | diff --git a/amqp-protocol-binding.md b/amqp-protocol-binding.md index 58e9abbcd..28e55816b 100644 --- a/amqp-protocol-binding.md +++ b/amqp-protocol-binding.md @@ -67,11 +67,11 @@ In the _structured_ content mode, event metadata attributes and event data are placed into the AMQP message's [application data][data] section using an event format as defined in the CloudEvents [spec][ce]. -In the _binary_ content mode, the value of the event `data` is placed -into the AMQP message's [application data][data] section as-is, with the -`datacontenttype` attribute value declaring its media type; all other event -attributes are mapped to the AMQP [application-properties][app-properties] -section. +In the _binary_ content mode, the value of the event `data` is placed into the +AMQP message's [application data][data] section as-is, with the +`datacontenttype` attribute value declaring its media type mapped to the AMQP +`content-type` message property; all other event attributes are mapped to the +AMQP [application-properties][app-properties] section. ### 1.4. Event Formats @@ -90,8 +90,8 @@ This specification does not further define any of the [CloudEvents][ce] event attributes. One event attribute, `datacontenttype` is handled specially in *binary* content -mode and mapped onto AMQP constructs. All other attributes are transferred as -metadata without further interpretation. +mode and mapped onto the AMQP content-type message property. All other +attributes are transferred as metadata without further interpretation. This mapping is intentionally robust against changes, including the addition and removal of event attributes, and also accommodates vendor extensions to the @@ -146,7 +146,7 @@ JSON text for use in AMQP. All [CloudEvents][ce] attributes with exception of `datacontenttype` MUST be individually mapped to and from the AMQP -[application-properties][app-properties] section, with exceptions noted below. +[application-properties][app-properties] section. CloudEvents extensions that define their own attributes MAY define a secondary mapping to AMQP properties for those attributes, also in different message @@ -189,17 +189,14 @@ exceptions noted below. | URI-reference | [string][amqp-string] | | Timestamp | [timestamp][amqp-timestamp] | -A CloudEvents AMQP *binary* mode implementation MUST allow for attribute values -to be convertible from/to their canonical CloudEvents string representation. For -instance, the `time` attribute MUST be convertible from and to a conformant -RFC3339 string value. - -If an non-string attribute is received as string from a communicating party, an -AMQP intermediary MAY convert it to the native AMQP representation before -forwarding the event; an AMQP consumer SHOULD convert it to the native AMQP -representation before surfacing the value to the API. An AMQP implementation -SHOULD convert from/to the native runtime or language type system to the AMQP -type system directly without translating through strings whenever possible. +All attribute values in an AMQP binary message MAY be represented using the +native AMQP types above, or MAY be in canonical string form. An implementation +MUST be able to interpret both forms on an incoming AMQP message. An +implementation SHOULD use the native AMQP form on outgoing AMQP messages when it +is efficient to do so, but MAY forward values as canonical strings. A robust +implementation MAY further relax the requirements for incoming messages (for +example accepting numeric types other than AMQP long) but MUST use only the +prescribed AMQP types or canonical strings on outgoing messages. #### 3.1.4 Examples diff --git a/documented-extensions.md b/documented-extensions.md index 9096e548b..65d1f400d 100644 --- a/documented-extensions.md +++ b/documented-extensions.md @@ -33,7 +33,7 @@ MAY), this usage only applies to events that use the extension. Extensions always follow a common placement strategy for in-memory formats (e.g. [JSON](json-format.md), XML) that are decided by those representations. Transport bindings (e.g. [HTTP](http-transport-binding.md), -[MQTT](mqtt-transport-binding.md), [AMPQ](amqp-transport-binding.md), +[MQTT](mqtt-transport-binding.md), [AMPQ](amqp-protocol-binding.md), [NATS](nats-transport-binding.md)) provide default placement for extensions, but an extension MAY require special secondary representation when transported (e.g. tracing standards that require specific headers). Extension authors SHOULD only require From e111f9abf503d87ea277e519ee6edfb478e72fd2 Mon Sep 17 00:00:00 2001 From: Klaus Deissner Date: Thu, 10 Oct 2019 16:28:54 +0200 Subject: [PATCH 4/6] Fixed link to already released amqp-transport-binding.md Signed-off-by: Klaus Deissner --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 082c7f90f..5199f0292 100644 --- a/README.md +++ b/README.md @@ -31,7 +31,7 @@ The following documents are available: | | | **Optional Specifications:** | | AMQP Event Format | [v1.0-rc1](https://github.com/cloudevents/spec/blob/v1.0-rc1/amqp-format.md) | [master](https://github.com/cloudevents/spec/blob/master/amqp-format.md) | -| AMQP Transport Binding | [v1.0-rc1](https://github.com/cloudevents/spec/blob/v1.0-rc1/amqp-protocol-binding.md) | [master](https://github.com/cloudevents/spec/blob/master/amqp-protocol-binding.md) | +| AMQP Transport Binding | [v1.0-rc1](https://github.com/cloudevents/spec/blob/v1.0-rc1/amqp-transport-binding.md) | [master](https://github.com/cloudevents/spec/blob/master/amqp-protocol-binding.md) | | AVRO Event Format | - | [master](./avro-format.md) | | HTTP Transport Binding | [v1.0-rc1](https://github.com/cloudevents/spec/blob/v1.0-rc1/http-transport-binding.md) | [master](https://github.com/cloudevents/spec/blob/master/http-transport-binding.md) | | JSON Event Format | [v1.0-rc1](https://github.com/cloudevents/spec/blob/v1.0-rc1/json-format.md) | [master](https://github.com/cloudevents/spec/blob/master/json-format.md) | From 5187cf296459c05ac2c8ca385eddaca5f2eec387 Mon Sep 17 00:00:00 2001 From: Klaus Deissner Date: Thu, 10 Oct 2019 19:55:23 +0200 Subject: [PATCH 5/6] Rephrased a sentence in type mapping section of binary mode according to what was discussed on the WG call. Signed-off-by: Klaus Deissner --- amqp-protocol-binding.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/amqp-protocol-binding.md b/amqp-protocol-binding.md index 28e55816b..365222d22 100644 --- a/amqp-protocol-binding.md +++ b/amqp-protocol-binding.md @@ -189,14 +189,14 @@ exceptions noted below. | URI-reference | [string][amqp-string] | | Timestamp | [timestamp][amqp-timestamp] | -All attribute values in an AMQP binary message MAY be represented using the -native AMQP types above, or MAY be in canonical string form. An implementation -MUST be able to interpret both forms on an incoming AMQP message. An -implementation SHOULD use the native AMQP form on outgoing AMQP messages when it -is efficient to do so, but MAY forward values as canonical strings. A robust -implementation MAY further relax the requirements for incoming messages (for -example accepting numeric types other than AMQP long) but MUST use only the -prescribed AMQP types or canonical strings on outgoing messages. +All attribute values in an AMQP binary message MUST either be represented using +the native AMQP types above or the canonical string form. An implementation MUST +be able to interpret both forms on an incoming AMQP message. An implementation +SHOULD use the native AMQP form on outgoing AMQP messages when it is efficient +to do so, but MAY forward values as canonical strings. A robust implementation +MAY further relax the requirements for incoming messages (for example accepting +numeric types other than AMQP long) but MUST be strict for outgoing messages as +defined above. #### 3.1.4 Examples From 024265797d70ce39a2e42df8583eb5ce9495d473 Mon Sep 17 00:00:00 2001 From: Klaus Deissner Date: Thu, 10 Oct 2019 21:04:57 +0200 Subject: [PATCH 6/6] Further refinements Signed-off-by: Klaus Deissner --- amqp-protocol-binding.md | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/amqp-protocol-binding.md b/amqp-protocol-binding.md index 365222d22..60da2b593 100644 --- a/amqp-protocol-binding.md +++ b/amqp-protocol-binding.md @@ -177,7 +177,7 @@ The value for each AMQP application property is constructed from the respective attribute's AMQP type representation. The CloudEvents type system MUST be mapped to AMQP types as follows, with -exceptions noted below. +additional notes below. | CloudEvents | AMQP | | ------------- | --------------------------- | @@ -190,13 +190,16 @@ exceptions noted below. | Timestamp | [timestamp][amqp-timestamp] | All attribute values in an AMQP binary message MUST either be represented using -the native AMQP types above or the canonical string form. An implementation MUST -be able to interpret both forms on an incoming AMQP message. An implementation -SHOULD use the native AMQP form on outgoing AMQP messages when it is efficient -to do so, but MAY forward values as canonical strings. A robust implementation -MAY further relax the requirements for incoming messages (for example accepting -numeric types other than AMQP long) but MUST be strict for outgoing messages as -defined above. +the native AMQP types above or the canonical string form. + +An implementation + +- MUST be able to interpret both forms on an incoming AMQP message +- MAY further relax the requirements for incoming messages (for example +accepting numeric types other than AMQP long), but MUST be strict for outgoing +messages. +- SHOULD use the native AMQP form on outgoing AMQP messages when it is efficient +to do so, but MAY forward values as canonical strings #### 3.1.4 Examples