Skip to content

Size Constraints #405

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

Merged
duglin merged 3 commits into from
Jun 6, 2019
Merged

Size Constraints #405

Changes from 1 commit
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
34 changes: 34 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,39 @@ encapsulated within the `data` attribute.
- Constraints:
- OPTIONAL

# Size Limits

Copy link
Member

@erikerikson erikerikson Mar 22, 2019

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 it's wire-size, and includes every bit that is
Copy link
Member

@erikerikson erikerikson Jun 5, 2019

Choose a reason for hiding this comment

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

NIT: I believe size is the term here. I think only that should be quoted.

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 at least 64 KByte.
Copy link
Member

@erikerikson erikerikson Jun 5, 2019

Choose a reason for hiding this comment

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

Although I believe I understand your intent, this technically only creates a requirement for events of "at least 64 KByte" or in other words, events with a size that is 64KB or more. As such, as written it doesn't discuss events of the smaller size but worse, it specifies that all events 64KB or larger MUST be forwarded by intermediaries.

Copy link
Collaborator

@duglin duglin Jun 6, 2019

Choose a reason for hiding this comment

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

@erikerikson can you suggest some alternate wording?

Copy link
Member

@erikerikson erikerikson Jun 6, 2019

Choose a reason for hiding this comment

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

My original recommendation was offered in a previous [comment] (#405 (comment)) but new framing has been developed which is good. I'll attempt to make a suggestion in the next few days.

Copy link
Collaborator

@duglin duglin Jun 6, 2019

Choose a reason for hiding this comment

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

.... of a size of 64 KBytes or less.

- Consumers SHOULD accept events of a size of at least 64 KByte.

In effect, these rules will allow events of up to 64 KByte to be published
Copy link
Member

@erikerikson erikerikson Jun 5, 2019

Choose a reason for hiding this comment

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

Consider 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.

and routed safely, with it being 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