Establish a set of canonical "hard" event encodings for testing.

[evankanderson]

Related to #367, there are also a number of cases where the expected parsing is not spelled out today. I volunteer the following HTTP binary mode object for consideration:

POST / HTTP/1.1
Content-Type: text/xml
CE-Extension: foo
CE-Extension-Key1: bar
CE-Extension-Key2: baz
CE-SpecVersion: 0.2
CE-Cloudeventsversion: v0.1
CE-Source: https://jackboxgames.com/project/you-dont-know-jack-party/
CE-Type: u(dont-know-jack)
CE-ID: ""😊
Content-Length: 19

<much wow=\"xml\"/>

I believe this should correspond to a JSON object like the following:

{
  "specversion": "0.2",
  "source": "https://jackboxgames.com/project/you-dont-know-jack-party/",
  "type": "u(dont-know-jack)",
  "id": "\"\"😊",
  "extension": "foo",
  "cloudeventsversion": "v0.1",
  "contenttype": "text/xml",
  "data": "<much wow=\\\"xml\\\"/>"
}

Note that the extension map keys were silently dropped; a different definition would be to discard the value "foo". Additionally, the actual "data" content is actually invalid XML, if I recall my XML correctly.

[cneijenhuis]

I believe your example is simply not a valid CloudEvent. What is the type of the attribute Extension? Apparently, both String and Map at the same time. That is not allowed in the CloudEvent typesystem.

Since this is not a CloudEvent, there is also no corresponding JSON.

Similarly, your JSON is also not a CloudEvent, because the id is not a URI-reference. 😉

there are also a number of cases where the expected parsing is not spelled out today.

You are right insofar that we haven't spelled out how to handle documents that could be parsed by ignoring some fields, e.g. in the HTTP case some headers, or e.g. in JSON invalid attribute names (like "UPP123").
One could argue to follow the Robustness Principle - or one could argue that this causes more problems than it solves, and such documents must be rejected.

IMO it is fine to leave it as "undefined" at the spec level, and let implementations decide how they handle these cases.

[evankanderson]

By my read of the spec, id is valid (except that I forgot to %-encode it in the header -- bad on me). The conflicting Extension type is a problem, and I'd prefer to have an encoding which made such a conflict impossible (e.g. by serializing the JSON map as a single header rather than a set of headers).

id

• Type: String
• Description: ID of the event. The semantics of this string are explicitly undefined to ease the implementation of producers. Enables deduplication.
• Examples:
  • A database commit ID
• Constraints:
  • REQUIRED
  • MUST be a non-empty string
  • MUST be unique within the scope of the producer

[duglin]

I actually would prefer to serialize a Map as a single header too. I'm not sure why we treat that one type differently than the others.

[cneijenhuis]

@evankanderson Sorry, you're of course right, I mixed up id and source.

My overall point is that in any encoding format, creating an invalid document is (often trivially) possible. It is easy to create a valid JSON or a valid HTTP request that is not a valid CloudEvent.

That said, I'm fine with serializing the Map as a single header, but it won't make the general problem (handing invalid documents) go away.

[n3wscott]

On this topic, I am looking for a canonical way to represent a cloudevent. This might be hard for the data section, but it would be very handy to have a way to describe the message body without representing it as one of the encodings? Otherwise, how do you validate that the message can be translated to the encoded message?

[evankanderson]

I can come up with some cases in a PR for some sample strange values for each field.

[duglin]

@evankanderson sorry, but I'm having trouble remembering where we are on this one. Do you think the spec needs to change in some normative way or do we just need to add some "things to watch out" in the primer? Or do we need to do anything at all?

[duglin]

I pinged @evankanderson and he said he'd work on this one soon... so I assigned it to him

[evankanderson]

I'll take look at this soon -- I'm guessing that it will need to be partially transport-specific, and builds on Clemens' #432, which clarifies some of the above points.

[evankanderson]

Working on this now, PR this afternoon, I expect.

Plan is:

testcases subdir with pairs of encoded / JSON-canonical CloudEvents by suffix, with comments in the JSON about what is tricky. Will try to cover at least a few different encodings, but probably focused on HTTP for now.

[evankanderson]

Found a couple interesting quirks; I haven't looked at AMQP, NATS, or Protobuf yet.