Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Size Constraints #405

Merged
merged 3 commits into from
Jun 6, 2019
Merged

Size Constraints #405

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
fc7b84e
added size limits
Jun 4, 2019
af81b44
addressing @erikerikson feedback
Jun 6, 2019
b723e49
project call feedback
Jun 6, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 36 additions & 0 deletions spec.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -18,6 +18,7 @@ This document is a working draft.
- [Type System](#type-system)
- [Context Attributes](#context-attributes)
- [Data Attribute](#data-attribute)
- [Size Limits](#size-limits)
- [Privacy & Security](#privacy-and-security)
- [Example](#example)

Expand Down Expand Up @@ -425,6 +426,41 @@ encapsulated within the `data` attribute.
- Constraints:
- OPTIONAL

# Size Limits

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be nice to start with the requirements in a compact/clear declaration followed by the explainer text. Seek time is high as written.

Perhaps

The size of an event is its wire-size.  Wire-size includes every bit that is transmitted on the wire: transport frame-metadata, event metadata, and event data.

* Consumers MUST accept events up to 64KM in size.
* Consumers MAY reject any event over 64KB in size.

Perhaps MUST should be SHOULD to allow for compliant low memory footprint consumers but my expectation is that such circumstances would be fairly narrow and would reduce the value of this section.

In many scenarios, CloudEvents will be forwarded through one or more
generic intermediaries, each of which might impose limits on the size of
forwarded events. CloudEvents might also be routed to consumers, like
embedded devices, that are storage or memory-constrained and therefore
would struggle with large singular events.

The "size" of an event is its wire-size, and includes every bit that is
transmitted on the wire for the event: transport frame-metadata, event
metadata, and event data, based on the chosen event format and the chosen
protocol binding.

If an application configuration requires for events to be routed across
different transports or for events to be re-encoded, the least efficient
transport and encoding used by the application SHOULD be considered for
compliance with these size constraints:

- Intermediaries MUST forward events of a size of 64 KByte or less.
- Consumers SHOULD accept events of a size of at least 64 KByte.

In effect, these rules will allow producers to publish events up to 64KB in
size safely. Safely here means that it is generally reasonable to expect the
event to be accepted and retransmitted by all intermediaries. It is in any
particular consumer's control, whether it wants to accept or reject events
of that size due to local considerations.

Generally, CloudEvents publishers SHOULD keep events compact by avoiding to
embed large data items into event payloads and rather use the event payload
to link to such data items. From an access control perspective, this approach
also allows for a broader distribution of events, because accessing
event-related details through resolving links allows for differentiated access
control and selective disclosure, rather than having sensitive details embedded
in the event directly.

# Privacy and Security

Interoperability is the primary driver behind this specification, enabling such
Expand Down