data/datacontenttype clarifications (alternative) #471
Conversation
Signed-off-by: Clemens Vasters <clemensv@microsoft.com>
clemensv
force-pushed
the
data-clarification
branch
from
fc6cd17 to
6bf2b28
Compare
|
@jroper what are your thoughts on this? |
| accurate media-type. If no IANA registered media-type is available, a vendor | ||
| extension or application/octet-stream MAY be used. | ||
|
|
||
| The attribute SHOULD be set for String content in the data field. If set, the |
There was a problem hiding this comment.
The CloudEvents-String is defined as "Sequence of printable Unicode characters". That (probably) makes sense for a regular attribute, but for data?
If a publisher wants to send text-data that (potentially) contains line breaks, they can use Binary, but will still declare text/plain. How can a consumer decide if it's a String or a Binary?
There was a problem hiding this comment.
Correcting myself: The publisher doesn't want to use Binary, because then they have to base64 encode.
I guess it is out of scope for this PR, but I suggest we split String into two parts: The String we need as an identifier for the Map, and the String we want to use for attributes. The latter should not be constraint to printable characters IMO. We could also further constrain the Map-String type (e.g. SHOULD follow the same pattern for attribute names).
|
Closing in support of #484 |
I had typed a bunch of normative-style text into the comments of #470 and now chose to break that out into a separate and alternative PR here, and I also amend the primer to explain the 3 event model scenarios (as Tim Bray pointed out on Thursday's call) for further clarification of why we have these options.
@jroper @duglin