Define URIs to follow the URI-reference rule.

[inlined]

URI-reference is a URI or relative-ref. This
now makes our existing examples meet the spec
as defined. Notably, this allows schemaless URIs.

Per 4/19 meeting, this will be merged as 0.1 if
it has sufficient approvals by then.

Signed-off-by: Thomas Bouldin inlined@google.com

[duglin]

LGTM

[duglin]

thanks for the quick PR

[clemensv]

LGTM

[deissnerk]

LGTM, as it is for 0.1

But:
If I understand RFC 3986 correctly, there is no such thing as a schemaless URI. Section 5.1 of the rfc lists four ways to derive a base URI from the context. One of them is to have a default base URI. This may be the reason why the relative references are so common inside the big cloud infrastructures, because you can assume that there is always the same base URI behind all relative references.
As CloudEvents are supposed to be interoperable, I think this assumption does not hold anymore. So for the sake of interoperability we will have to revisit this topic after CloudNativeCon again.

[duglin]

@deissnerk I guess from a strict technical perspective we could define what the default base URI is but in practice I don't think it really matters since no matter what value we choose all relative URIs will use that same base URI and therefore appending the relative URI provided to the end of a constant will be just about as good as appending it to "". :-)

[clemensv]

@deissnerk The base URI can quite well be external to the document. It turns out that all of our specs in this repo use relative URIs inside the documents for cross-references, because the base URI is external and the base URI actually changes in forks, but all the cross-references stay stable.

For Azure events, the conceptual "base URI" might be something like azure://westeurope.azure.com or azure://westus2.azure.com, but since the following resource path is unambiguous and equally applicable to all public cloud regions, the base URI doesn't matter. We achieve disambiguation for interpretation of the URI because we now namespaced the eventType. With Microsoft.Storage.BlobCreated, the interpretation of a relative URI is unambiguously related to the public Azure cloud. For private deployments of Azure Stack, we might indeed end up using fully qualified URIs that designate the respective deployment.

[deissnerk]

all relative URIs will use that same base URI and therefore appending the relative URI provided to the end of a constant will be just about as good as appending it to "".

@duglin If we interpret it this way, we should not use the term URI at all and just require some kind of unique string or something similar to Java package names. Without any authority or scheme and the requirement to create globally unique path segments, I don't see the point of calling it a URI.

@clemensv Your examples are actually what I had in mind when talking about relative references being common for the big cloud providers. My understanding of CloudEvents is, that the context attributes should even be unambiguous, if they leave one cloud environment and are interpreted somewhere else. What happens, if an event from Azure is forwarded to a Google Cloud Function? How could you then determine the right conceptual base URI? I don't think that relying on the namespaced event type can be a general solution, as @inlined already brought up the idea of common event types being used by several parties.

This is not just about formal compliance to RFC 3986 but about interoperability. If we can come up with rules how to determine the base URI, I am fine with relative references.

[duglin]

TBH I actually do view it more like some "unique string" because I think in the end that's all it really is. Now, that's not to say that having some structure to it isn't useful. For example, being able to easily route all github.com/* URIs to one component vs some other is a lot easier when we don't have to worry that some providers sending it as github.com/foo while others send it as foo:github.com. And for that reason I do think calling it a URI helps because it provides some level of consistent (interop?) to help us. But, whether our use of it 100% aligns with the RFC to the point where we need to define some fictitious "base URI" so that conceptually we have something to concatenate to isn't a big worry to me. But, I'm not against defining it if people want to be 100% spec aligned.

[duglin]

Been open for 21 hours and we got some LGTMs + we agreed to this on the call yesterday. Merging and cutting the release.

[ultrasaurus]

thank you! I reviewed and hadn't commented yet. I think this is a nice improvement.

[yaronha]

@duglin this LGTM and a good way to achieve interop

[clemensv]

@deissnerk the URI is unambiguous in the context of the namespaced eventType. If there is a common event type, that event type would also define the URI shape. I think of event types as actual types that lay down the law for the shape of the event, not mere labels.

I don't grasp how interoperability is improved when I choose:

azure:/subscriptions/2626262/resourceGroup/sample/provider/Microsoft.ServiceBus/..

over

/subscriptions/2626262/resourceGroup/sample/provider/Microsoft.ServiceBus/..

within the scope of an event that is typed Microsoft.ServiceBus.MessageAvailable

[deissnerk]

@clemensv Is it just azure: or or something like azure://westus2.azure.com as you said before?

@inlined How does this idea of the event type providing the scope work with reuse of event types, or the same event types being used on premise and in the cloud? As soon as I am trying to route events from multiple cloud providers and applications, this gets quite complex. There will be conventions per event type.
Otherwise I could just take scheme and authority of the source and do a simple source-based routing.

We could provide a rule how to dereference the relative URI reference that would point to the namespace of the event type. If the source is a relative URI reference, the base URI is derived from the event type. To me it would just be important that the source URI could be retrieved by a simple algorithm described in the spec without applying some heuristics or lengthy switch/case statements.