Consider removing the web-hook spec

[duglin]

See: #414 (comment)

As @cneijenhuis points out, this doc (while useful) isn't really related to CloudEvents and as such might be better off living some place else. Additionally, for the most part CloudEvents is trying to stay away from defining the processing model for consumers (or even processing model for transports), and this spec gets into those topics.

/cc @clemensv

[cneijenhuis]

To clarify, I hope this is both better for the CloudEvents spec, because the goal of "no processing model" is much clearer if we don't deal with this anywhere; and better for the webhook spec because it can dive into this topic and can be opinionated when it needs to be.

[clemensv]

The spec really is a required profile for achieving ad-hoc event delivery interop over a protocol with a million knobs like HTTP, IMO. It defines the HTTP method, it narrows down the auth options, and provides a simple DoS abuse defense model.

I think it'd be great for the spec to be moved into a more appropriate forum, but I do think we need it and CloudEvents implementations ought to implement it. Until we have a better home (IETF?), it should best stay here.

The alternative were to pull the spec back into the HTTP binding.

[clemensv]

I've started a discussion with some of our (Microsoft) standards folks about a better venue for this spec. In that email thread I wrote this:

This is here is a standard HTTP usage profile for sending a notification to an existing web service; it’s a WebHook POST. WebHooks are a common way for sites (like GitHub) to notify services (like AppVeyor) that something happened (a Pull Request). Everyone uses some sort of POST with some sort of payload with some sort of auth, but amazingly there’s no common way to do it.

CloudEvents is a common way to express the event and bind it to an HTTP message. This spec is a common way to push that message to a service endpoint.

I actually think it'd be a huge loss if we cut that last hop spec out and moved it elsewhere.

[duglin]

I'm going to close this since I can't think of a better place for it right now and we can always choose to move it later.