From 7c5d7e5dd6e85c2402d9f69996382639a88f81b1 Mon Sep 17 00:00:00 2001 From: Christoph Neijenhuis Date: Wed, 9 Jan 2019 17:55:26 +0100 Subject: [PATCH 1/6] Size limits or guarantees Signed-off-by: Christoph Neijenhuis --- spec.md | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/spec.md b/spec.md index b17709129..96ed28a83 100644 --- a/spec.md +++ b/spec.md @@ -15,6 +15,7 @@ This document is a working draft. - [Type System](#type-system) - [Context Attributes](#context-attributes) - [Data Attribute](#data-attribute) +- [Size Limits](#size-limits) - [Example](#example) ## Overview @@ -289,6 +290,32 @@ encapsulated within the `data` attribute. * Constraints: * OPTIONAL +# Size Limits + +In order to increase interoperability, the following size limits apply to any +CloudEvent: + +* The CloudEvent serialized as JSON (minified, i.e. without white-space) MUST + NOT exceed a size of 128KB. +* The CloudEvent MUST NOT have more than 100 top-level attributes. + +CloudEvent producers SHOULD only create CloudEvents within these limits. +CloudEvent consumers MUST accept all CloudEvents within these limits and SHOULD +reject messages that violate these limits. + +# Size Guarantees // Another option + +In order to increase interoperability, all CloudEvent consumers MUST accept +messages up to the following sizes: + +* The CloudEvent serialized as JSON (minified, i.e. without white-space) does + not exceed a size of 128KB. +* The CloudEvent does not have more than 100 top-level attributes. + +CloudEvent consumers MAY reject messages that violate these limits. +It is RECOMMENDED for CloudEvent producers to only create CloudEvents within +these limits, unless they can be sure all consumers support larger sizes. + # Example The following example shows a CloudEvent serialized as JSON: From f40f128414b36b992a29a3ec3d0c931cdce24a97 Mon Sep 17 00:00:00 2001 From: Christoph Neijenhuis Date: Wed, 23 Jan 2019 22:51:31 +0100 Subject: [PATCH 2/6] Settle on size guarantee; remove attribute limit Signed-off-by: Christoph Neijenhuis --- spec.md | 28 ++++++---------------------- 1 file changed, 6 insertions(+), 22 deletions(-) diff --git a/spec.md b/spec.md index 96ed28a83..d9e52bc6d 100644 --- a/spec.md +++ b/spec.md @@ -15,7 +15,7 @@ This document is a working draft. - [Type System](#type-system) - [Context Attributes](#context-attributes) - [Data Attribute](#data-attribute) -- [Size Limits](#size-limits) +- [Event Size Guarantees](#event-size-guarantees) - [Example](#example) ## Overview @@ -290,31 +290,15 @@ encapsulated within the `data` attribute. * Constraints: * OPTIONAL -# Size Limits - -In order to increase interoperability, the following size limits apply to any -CloudEvent: - -* The CloudEvent serialized as JSON (minified, i.e. without white-space) MUST - NOT exceed a size of 128KB. -* The CloudEvent MUST NOT have more than 100 top-level attributes. - -CloudEvent producers SHOULD only create CloudEvents within these limits. -CloudEvent consumers MUST accept all CloudEvents within these limits and SHOULD -reject messages that violate these limits. - -# Size Guarantees // Another option +# Event Size Guarantees In order to increase interoperability, all CloudEvent consumers MUST accept -messages up to the following sizes: - -* The CloudEvent serialized as JSON (minified, i.e. without white-space) does - not exceed a size of 128KB. -* The CloudEvent does not have more than 100 top-level attributes. +messages up to a size of 256KB, measured by serializing the CloudEvent as +[JSON](./json-format.md) (minified, i.e. without white-space). -CloudEvent consumers MAY reject messages that violate these limits. +CloudEvent consumers MAY reject CloudEvents above this size. It is RECOMMENDED for CloudEvent producers to only create CloudEvents within -these limits, unless they can be sure all consumers support larger sizes. +this size, unless they can be sure all consumers support larger sizes. # Example From a877004ace6ae542bde36641143c94f9aaf25e01 Mon Sep 17 00:00:00 2001 From: Christoph Neijenhuis Date: Thu, 24 Jan 2019 09:21:02 +0100 Subject: [PATCH 3/6] Better headline Signed-off-by: Christoph Neijenhuis --- spec.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/spec.md b/spec.md index d9e52bc6d..81e614425 100644 --- a/spec.md +++ b/spec.md @@ -15,7 +15,7 @@ This document is a working draft. - [Type System](#type-system) - [Context Attributes](#context-attributes) - [Data Attribute](#data-attribute) -- [Event Size Guarantees](#event-size-guarantees) +- [Minimum Supported Event Size](#minimum-supported-event-size) - [Example](#example) ## Overview @@ -290,7 +290,7 @@ encapsulated within the `data` attribute. * Constraints: * OPTIONAL -# Event Size Guarantees +# Minimum Supported Event Size In order to increase interoperability, all CloudEvent consumers MUST accept messages up to a size of 256KB, measured by serializing the CloudEvent as From 3ae6f2750bcc31a9a89369c1950f55fb73edda7c Mon Sep 17 00:00:00 2001 From: Christoph Neijenhuis Date: Thu, 24 Jan 2019 19:02:01 +0100 Subject: [PATCH 4/6] Remove message, replace with event Signed-off-by: Christoph Neijenhuis --- spec.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/spec.md b/spec.md index 81e614425..ff064da8d 100644 --- a/spec.md +++ b/spec.md @@ -293,12 +293,12 @@ encapsulated within the `data` attribute. # Minimum Supported Event Size In order to increase interoperability, all CloudEvent consumers MUST accept -messages up to a size of 256KB, measured by serializing the CloudEvent as +events up to a size of 256KB, measured by serializing the CloudEvent as [JSON](./json-format.md) (minified, i.e. without white-space). -CloudEvent consumers MAY reject CloudEvents above this size. -It is RECOMMENDED for CloudEvent producers to only create CloudEvents within -this size, unless they can be sure all consumers support larger sizes. +CloudEvent consumers MAY reject events above this size. +It is RECOMMENDED for CloudEvent producers to only create events within this +size, unless they can be sure all consumers support larger sizes. # Example From a58c45d34488337834fa0ec144faa4190c2a2fa7 Mon Sep 17 00:00:00 2001 From: Christoph Neijenhuis Date: Mon, 28 Jan 2019 10:48:47 +0100 Subject: [PATCH 5/6] Clarify relationship of event and message with an extra paragraph and some examples Signed-off-by: Christoph Neijenhuis --- spec.md | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/spec.md b/spec.md index ff064da8d..7046de4d5 100644 --- a/spec.md +++ b/spec.md @@ -296,10 +296,24 @@ In order to increase interoperability, all CloudEvent consumers MUST accept events up to a size of 256KB, measured by serializing the CloudEvent as [JSON](./json-format.md) (minified, i.e. without white-space). -CloudEvent consumers MAY reject events above this size. +CloudEvent consumers MAY reject events above this size and MAY reject messages +that are not minified (e.g. contain unnecessary white-space). It is RECOMMENDED for CloudEvent producers to only create events within this size, unless they can be sure all consumers support larger sizes. +The same event serialized with a different format will likely result in a +different size. However, to aid interoperability, only the minified +[JSON](./json-format.md) is used to measure the size. As an example, an +[AMQP](./amqp-format.md) message of 270KB MUST be accepted if the contained +event serialized as JSON is below 256KB. However, an [AMQP](./amqp-format.md) +message of 250KB MAY be rejected if the contained event serialized as JSON +exceeds 256KB. Practically, an [AMQP](./amqp-format.md) consumer that wants to +protect theirself from large messages MAY simply choose to reject messagess +after a higher limit (e.g. 512KB) that comfortably fits any valid event size. +However, a middleware that wants to guarantee that the event can be forwarded +in any format SHOULD measure the size of the event independently of the format +it was received in. + # Example The following example shows a CloudEvent serialized as JSON: From 59133448b57b7ca15ca1786d634309819fb94633 Mon Sep 17 00:00:00 2001 From: Christoph Neijenhuis Date: Thu, 7 Feb 2019 20:23:45 +0100 Subject: [PATCH 6/6] Lower size to 64KB, replace MUST with SHOULD Signed-off-by: Christoph Neijenhuis --- spec.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/spec.md b/spec.md index 7046de4d5..e12f389f3 100644 --- a/spec.md +++ b/spec.md @@ -292,8 +292,8 @@ encapsulated within the `data` attribute. # Minimum Supported Event Size -In order to increase interoperability, all CloudEvent consumers MUST accept -events up to a size of 256KB, measured by serializing the CloudEvent as +In order to increase interoperability, all CloudEvent consumers SHOULD accept +events up to a size of 64KB, measured by serializing the CloudEvent as [JSON](./json-format.md) (minified, i.e. without white-space). CloudEvent consumers MAY reject events above this size and MAY reject messages @@ -304,12 +304,12 @@ size, unless they can be sure all consumers support larger sizes. The same event serialized with a different format will likely result in a different size. However, to aid interoperability, only the minified [JSON](./json-format.md) is used to measure the size. As an example, an -[AMQP](./amqp-format.md) message of 270KB MUST be accepted if the contained -event serialized as JSON is below 256KB. However, an [AMQP](./amqp-format.md) -message of 250KB MAY be rejected if the contained event serialized as JSON -exceeds 256KB. Practically, an [AMQP](./amqp-format.md) consumer that wants to +[AMQP](./amqp-format.md) message of 70KB MUST be accepted if the contained +event serialized as JSON is below 64KB. However, an [AMQP](./amqp-format.md) +message of 60KB MAY be rejected if the contained event serialized as JSON +exceeds 64KB. Practically, an [AMQP](./amqp-format.md) consumer that wants to protect theirself from large messages MAY simply choose to reject messagess -after a higher limit (e.g. 512KB) that comfortably fits any valid event size. +after a higher limit (e.g. 256KB) that comfortably fits any valid event size. However, a middleware that wants to guarantee that the event can be forwarded in any format SHOULD measure the size of the event independently of the format it was received in.