Added datacontentencoding #387
Conversation
Signed-off-by: Clemens Vasters <clemensv@microsoft.com>
|
ping @alanconway @n3wscott |
|
The datacontentencoding changes are all good by me. On a side note: I'm surprised that critical attribute names are still changing, e.g. "contenttype -> datacontenttype". Also since the spec has adopted the cantdecideonwordseparatorssoletshavenone convention, it seems like a not-so-great idea to be adding more words to multi-word names. However, that's another story. |
|
Would an example help clarify the need for this to a newbie? Could be done in a follow-on PR if so. |
| attribute for when the `data` field MUST be encoded as a string, | ||
| like with structured transport binding modes using the JSON event | ||
| format, but the `datacontenttype` indicates a non-string media | ||
| type. When the `data` field's effective data type is not `String`, |
There was a problem hiding this comment.
When the
datafield's effective data type is notString,
this attribute MUST NOT be set and MUST be ignored when set.
why not? I want to zip my http binary data payload...
There was a problem hiding this comment.
Or I want to base64 encode my binary http payload because I am a weirdo...
There was a problem hiding this comment.
Perhaps not, looking at RFC 2045 I do not see anything I would want to use besides base64. And normal http transports can give me gzip...
/lgtm
|
On Wed, Feb 20, 2019 at 8:38 PM Scott Nichols ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In spec.md
<#387 (comment)>:
> @@ -276,6 +274,23 @@ help intermediate gateways determine how to route the events.
[RFC 2046](https://tools.ietf.org/html/rfc2046)
* For Media Type examples see [IANA Media Types](http://www.iana.org/assignments/media-types/media-types.xhtml)
+### datacontentencoding
+* Type: `String` per [RFC 2045 Section 6.1](https://tools.ietf.org/html/rfc2045#section-6.1)
+* Description: Describes the content encoding for the `data`
+ attribute for when the `data` field MUST be encoded as a string,
+ like with structured transport binding modes using the JSON event
+ format, but the `datacontenttype` indicates a non-string media
+ type. When the `data` field's effective data type is not `String`,
Perhaps not, looking at RFC 2045 I do not see anything I would want to use
besides base64. And normal http transports can give me gzip...
Compression is a separate "transfer-encoding" header in HTTP.
Content-encoding is just for transorts that can't store simple binary data,
like 1960s 7-bit-ascii email, or (sigh) JSON in 2019.
|
| the `data` attribute towards the application is the base64-decoded | ||
| binary array. | ||
|
|
||
| All other RFC2045 schemes are undefined for CloudEvents. |
There was a problem hiding this comment.
Add a "Constraints" section, like the other attributes?
I think at the moment, "Constraints" is "Must be the string 'Base64'". If so, would it make more sense to standardize on assuming 'Base64' encoding and excluding the other options?
|
perhaps "contentencoding" rather than "datacontentencoding"? Given the
(unfortunate IMO) choice of noseparatorswhatsoever for attribute names, I
think it's important to try hard for names that are only one word, and
absolutely ban names that are more than two words.
…On Wed, Mar 6, 2019 at 8:40 PM Doug Davis ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In spec.md
<#387 (comment)>:
> +### datacontentencoding
+* Type: `String` per [RFC 2045 Section 6.1](https://tools.ietf.org/html/rfc2045#section-6.1)
+* Description: Describes the content encoding for the `data`
+ attribute for when the `data` field MUST be encoded as a string,
+ like with structured transport binding modes using the JSON event
+ format, but the `datacontenttype` indicates a non-string media
+ type. When the `data` field's effective data type is not `String`,
+ this attribute MUST NOT be set and MUST be ignored when set.
+
+ The "Base64" value for the Base64 encoding as defined in [RFC 2045 Section 6.8](https://tools.ietf.org/html/rfc2045#section-6.8)
+ MUST be supported. When set, the event-format-encoded value of the `data`
+ attribute is a base64 string, but the effective data type of
+ the `data` attribute towards the application is the base64-decoded
+ binary array.
+
+ All other RFC2045 schemes are undefined for CloudEvents.
@clemensv <https://github.com/clemensv> ^^^
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#387 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AHa6XoY-4aHsm7jvcUIyMzsFVuyVilSaks5vUG4QgaJpZM4a9679>
.
|
Signed-off-by: Clemens Vasters <clemensv@microsoft.com>
|
@alanconway we chose to rename contenttype to datacontenttype because people were confused about what that relates to, and now this also needs to have data in front of it, because it relates to the same attribute. |
|
All - This one has been updated - please review and comment |
|
Might be good to add an example |
|
+1 for some examples - but maybe there should be a separate PR to add a few examples based on recent changes. Generally LGTM but deferring final comment until merge conflicts are resolved. |
|
Approved on the 4/4 call |
Implements content encoding as raised in issue #371