Review feedback from hudlow

This streamlines the text/event-stream discussion and makes a few
other tweaks based on feedback from @hudlow.

Author: handrews

src/oas.md

@@ -91,7 +91,7 @@ Each mapping is addressed where the relevant media type is discussed in this sec
 
 #### Sequential Media Types
 
-Within this specification, a _sequential media type_ is defined as any media type that consists of a repeating structure, separated by some delimiter, without any sort of header, footer, envelope, or other metadata in addition to the sequence.
+Within this specification, a _sequential media type_ is defined as any media type that consists of a repeating structure, without any sort of header, footer, envelope, or other metadata in addition to the sequence.
 
 Some examples of sequential media types (including some that are not IANA-registered but are in common use) are:
 
@@ -1660,8 +1660,8 @@ See also the [Media Type Registry](#media-type-registry).
 ##### Complete vs Streaming Content
 
 The `schema` field MUST be applied to the complete content, as defined by the media type and the context ([Request Body Object](#request-body-object), [Response Object](#response-object), [Parameter Object](#parameter-object), or [Header Object](#header-object).
-Unless some sort of streaming JSON Schema processor is available, this requires loading the entire content into memory.
-This poses a challenge for streamed content, particularly streams where the client is intended to choose when to stop reading as there is no well-defined end to the stream.
+Because this requires loading the content into memory in its entirety, it poses a challenge for streamed content.
+Use cases where client is intended to choose when to stop reading are particularly challenging as there is no well-defined end to the stream.
 
 ###### Binary Streams
 
@@ -1680,13 +1680,7 @@ For example, if partial content is read from a stream and then passed with the `
 
 ##### Special Considerations for `text/event-stream` Content
 
-For `text/event-stream`, each item in the array MUST be treated as if it were a JSON object with property names taken from the left side of the `:` (or the enter non-empty line if no ":" is present), property values from the right side, and consecutive lines with the same name treated as a single property, with the value combined in accordance with the [`text/event-stream` specification](https://html.spec.whatwg.org/multipage/server-sent-events.html#parsing-an-event-stream).
-
-Field names can be repeated within an item to allow splitting the value across multiple lines; such split values MUST be treated the same as if they were a single field, with newlines added as required by the [`text/event-stream` specification](https://html.spec.whatwg.org/multipage/server-sent-events.html#parsing-an-event-stream).
-Similarly, when a field name appears without a value, the value MUST be treated as an empty string.
-
-The `text/event-stream` specification requires that fields with Unknown names, as well as `id` fields where the value contains `U+0000 NULL` and `retry` fields with characters other than ASCII digits be ignored.
-These fields SHOULD NOT be present in the data used with the Schema Object.
+For `text/event-stream`, implementations MUST work with event data after it has been parsed according to the [`text/event-stream` specification](https://html.spec.whatwg.org/multipage/server-sent-events.html#parsing-an-event-stream), including all guidance on ignoring certain fields (including comments) and/or values, and on combining values split across multiple lines.
 
 Field value types MUST be handled as specified by the `text/event-stream` specification (e.g. the `retry` field value is modeled as a JSON number that is expected to be of JSON Schema `type: integer`), and fields not given an explicit value type MUST be handled as strings.