fixup! Introduce links to CDEvents

Signed-off-by: benjamin-j-powell <benjamin_j_powell@apple.com>

links.md

@@ -49,17 +49,24 @@ introduce a new field called `parent` in each event.
 The new `parent` field will be an array of the immediate preview parent(s)
 events.
 
-`global_id` will also be added to the context of events which will allow for
-querying all links from a given global id.
+Further to propogate context, we will introduce two new headers,
+* `X-CDEVENTS-GLOBAL-ID`
+* `X-CDEVENTS-PARENT-ID`
 
-The new parent field will be an added optional field, but the `global_id` will be
-a required field in **all** cdEvent types looking something like:
+The reasoning for using headers here is in the event that payloads cannot be
+changed due to some service not adhering to CDEvents, but can instead forward
+headers to allow any CDEvents compatible service to properly continue
+propogating.
 
 ```json
+# Headers
+# X-CDEVENTS-GLOBAL-ID: "00000000-0000-0000-0000-000000000001"
+# X-CDEVENTS-PARENT-ID: "271069a8-fc18-44f1-b38f-9d70a1695819"
+
+# Payload
 {
   "context": {
     "version": "0.3.0-draft",
-    "global_id": "00000000-0000-0000-0000-000000000001", // new field
     "id": "505b31c2-8bc8-47b3-a1a0-269d7a8530ac",
     "source": "dev/jenkins",
     "type": "dev.cdevents.testsuite.finished.0.1.1",
@@ -71,10 +78,9 @@ a required field in **all** cdEvent types looking something like:
     "type": "testSuite",
     "content": {}
   },
-  "parent": [ // new proposed field here
+  "parent": [ # new field
     {
       "context": {
-        "global_id": "00000000-0000-0000-0000-000000000001",
         "version": "0.4.0-draft",
         "id": "271069a8-fc18-44f1-b38f-9d70a1695819",
         "source": "/event/source/123",
@@ -165,10 +171,9 @@ simply turning on linking payload aggregation, will send all links in the
 payload. Mind you, this can make the payload very large, but may be good for
 debugging.
 
-The `global_id` field will use whatever is in the context, unless the user
-explicitly starts a new global event. If there is no `global_id` set, the
-client will generate one and that will be used for the lifetime of the whole
-events span
+The global ID header will continue to propogate, unless the user explicitly
+starts a new CDEvent span. If there is no global ID header, the client will
+generate one and that will be used for the lifetime of the whole events span
 
 ![link flow](images/links_flow.jpeg)
 
@@ -264,16 +269,16 @@ Scalability is one of the bigger goals in this proposal and we wanted to ensure
 fast lookups. This section is going to describe how the proposed links format
 will be scalable and also provide tactics on how DB read/writes can be done.
 
-The purpose of the `global_id` was to ensure very fast lookups no matter the
+The purpose of the global ID is to ensure very fast lookups no matter the
 database. We could say that only graph DBs could be used to do a full span
-lookup without a `global_id` but that poses two problems:
+lookup without a global ID but that poses two problems:
 
 * Slower lookups as the graph DB needs to backtrack to find the full span
 * Requires either graph DBs or using SQL like graph DBs.
 
 Instead a link service that processes and agnostically stores to some DB is
 much prefer as it gives companies and developers options to choose from.  When
-using an SQL database, the `global_id` could be the secondary key to easily
+using an SQL database, the global ID could be the secondary key to easily
 retrieve indexed entities. Links could be easily sorted by timestamp which
 should roughly coordinate to their linked neighbors, parent and child.