simplified design goals based on community discussions

  Signed-off-by: Sarah Allen <sarahallen@google.com>

README.md

@@ -32,7 +32,7 @@ In order to achieve these goals, the Serverless WG must describe:
 - One or more common architectures that are in active use today or planned to be
 built by WG members
 - How events are transported from source to action via at least one protocol
-- Authorization model(s) that control access and execution permissions
+- Identify and resolve whatever else is needed for interoperability
 
 ### Non-Goals of this specification
 The following non-goals will not be part of the specification:

spec.md

@@ -30,57 +30,25 @@ platforms and beyond.
 # Design Goals
 
 CloudEvents are typically used in a distributed system to allow for services to
-be loosely coupled during development, then may be configured with
-tight-coupling for specific applications or dynamically configured at runtime.
+be loosely coupled during development, deployed independently, and later
+can be connected to create new applications.
 
 The goal of the CloudEvents specification is to define interoperability of event
-systems that allow cloud providers, third-party tools and services to provide:
-- new event sources
-- new event consumers
-- observability, such as monitoring, debugging and visualization,
-- developer tools and libraries
-
-## Key properties of the system:
-- Source & action may be developed and deployed independently
-- Trigger configuration allows for actions to be invoked based on a condition
-(e.g. for a specific event type generated by a source, optionally filtered by
-specific attribute values, such as a Function which is invoked when an image is
-uploaded to a specific bucket in an object store).
-- Events are uniquely identified to facilitate developer velocity and tooling:
-  - a unique identifier allows for idempotency for reliable implementation
-  - structured event definitions allow the consumer to rely on a specific format
-- Common metadata attributes allow for observability via tools without
-knowledge of the specific implementation of an event system and also can provide
-value without detailed handling of the specifics of the unique event data
-- CloudEvents may be transported from source to action with different protocols.
-
-In order to achieve the above goals and desired system properties, the
-Serverless WG must agree on a common vocabulary with precise definitions
-describing the key elements of the system including:
-- [Source](../spec.md#source)
-- Action: An action consumes an event, producing a behavior or effect which was
-triggered by a specific *occurrence* from a specific *source*.  While the
-details of how events are delivered to an action is outside of the scope of the
-specification, the purpose of generating an *event* is typically to allow other
-systems to easily react to changes in a source that they do not control. The
-*source* and action are often built by different developers.
-
-Examples:
-- the *source* is a managed service and the *action* is custom code in a
-serverless Function.
-- the *source* is an IoT device and the *event* is transmitted through an API
-Gateway to the *action*, a service provided by a different developer.
-
-The events system provides a way for the developer to specify which *event*
-should be delivered to which *action*. The specific mechanism is outside the
-scope of the specification, yet the following definitions facilitate an
-understanding of how CloudEvents are typically used in context:
-- Trigger: the condition that causes an event to be transmitted from source to
-action
-- Rule: the association of trigger + action
-
-Systems which generate events can have independent mechanisms for how triggers
-are specified and how rules are stored and evaluated.
+systems that allow services to produce or consume events, where the producer and
+consumer can be developed and deployed independently.  A producer must be able
+to generate events before a consumer is listening, and a consumer must be able
+to express an interest in an event or class of events that is not yet being
+produced.
+
+To this end, the specification will include common metadata attributes of an
+event that facilitate interoperability, where the event does not contain any
+details about the consumer or transport that might be use to send the event.
+
+## Non-Goals
+The following will not be part of the specification:
+Function build and invocation process
+Language-specific runtime APIs
+Selecting a single identity/access control system
 
 ## Status
 At this time the specification is focused on the following scope: