Skip to content
Closed
34 changes: 26 additions & 8 deletions spec.md
Original file line number Diff line number Diff line change
Expand Up @@ -217,26 +217,40 @@ Incompatible changes to the schema SHOULD be reflected by a different URL.
or application protocol's content-type metadata property. Normative rules
for the binary mode and the content-type metadata mapping can be found
in the respective transport mapping specifications.

* Constraints:
* OPTIONAL
* If present, MUST adhere to the format specified in
[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)

### extensions

### identityLabels
* Type: `Map`
* Description: This is for additional metadata and this does not have a
mandated structure. This enables a place for custom fields a producer or
middleware might want to include and provides a place to test metadata before
adding them to the CloudEvents specification.
See the [Extensions](extensions.md) document for a list of possible
attributes.
* Description: This is a place for custom key-value pairs a producer or
middleware wants to include to provide additional identity information
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

A producer would include, the middleware would inject.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

I would argue the action for both is inject.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

identity is just one usecase

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

identity is an attribute (identity labels belong to this attribute category). The identify labels inside this bag can be used for many different use cases. For example, a serverless app for burglary detection can use it, a serverless app for travel request/approval can use it, etc..

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Yes, I understand the examples, and I am saying they are not enough to justify addition to the top level of the spec.

about the event. The syntax and semantics of each specific label
inside this map are open for each event type producer to define,
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

for each event type producer to define

seems like in saying this, you have lost the value of the identity aspect if that is what this is for.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

We have to leave what goes inside this identity bag open since different types of events could have different labels and we can not predict all the labels. What we know is that an event could have an identity bag of labels, which serverless platforms (we can view the platform as an event consumer) need to support many serverless applications.

but the key is a string and the value is a string.
For example, a travel request messaging event producer could put
"TravelRequestID: 123456" as an identity label for a travel
request event, a home IoT device event producer could put
"home address: 20 Spruce Street, San Jose, CA" as an identity label
for that IoT device event. Identity labels could be used by a
serverless platform to correlate this event with other types of
events associated with the same serverless application instance.
* Constraints:
* OPTIONAL
* If present, MUST contain at least one entry
* Examples:
* authorization data
``` JSON
properties
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

properties being a map is still a bad idea. See my previous comments.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

OK. Existing spec defines a list of types that can be used by the attributes. Map is the closest one for the need of this attribute, that is why there is further clarification inside the description on the type of the value.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

if these labels are a map of LabelKey: LabelValue then adding metadata on the label is impossible without complex logic to point back to the key.

{
"employee-ID": "H0098002",
"travel-request-ID": "123456"
}
```

## Data Attribute

Expand Down Expand Up @@ -266,6 +280,10 @@ The following example shows a CloudEvent serialized as JSON:
"extensions" : {
"comExampleExtension" : "value"
},
"identityLabels" : {
"employee-ID": "H0098002",
"travel-request-ID": "123456"
},
"contentType" : "text/xml",
"data" : "<much wow=\"xml\"/>"
}
Expand Down