Tidy up TBD in docs

docs/src/main/asciidoc/getting-started.adoc

@@ -42,16 +42,19 @@ JMS.
 The `@Beans` can be `Function`, `Consumer` or `Supplier` (all from
 `java.util`), and their parametric types can be String or POJO. A
 `Function` is exposed as a Spring Cloud Stream `Processor` if
-`spring-cloud-function-stream` is on the classpath.
-A `Consumer` is also exposed as a Stream
-`Sink` and a `Supplier` translates to a Stream `Source`. 
-HTTP endpoints are exposed if the Stream binder is `spring-cloud-stream-binder-servlet`.
+`spring-cloud-function-stream` is on the classpath.  A `Consumer` is
+also exposed as a Stream `Sink`, and a `Supplier` translates to a
+Stream `Source`.
 
-Functions can be of `Flux<String>` or `Flux<Pojo>` and Spring Cloud
-Function takes care of converting the data to and from the desired
-types, as long as it comes in as plain text or (in the case of the
-POJO) JSON. TBD: support for `Flux<Message<Pojo>>` and maybe plain
-`Pojo` types (Fluxes implied and implemented by the framework).
+Functions can also be of `Flux<String>` or `Flux<Pojo>` and Spring
+Cloud Function takes care of converting the data to and from the
+desired types, as long as it comes in as plain text or (in the case of
+the POJO) JSON. There is also support for `Message<Pojo>` where the
+message headers are copied from the incoming event, depending on the
+adapter. The web adapter also supports conversion from form-encoded
+data to a `Map`, and if you are using the function with Spring Cloud
+Stream then all the conversion and coercion features for message
+payloads will be applicable as well.
 
 Functions can be grouped together in a single application, or deployed
 one-per-jar. It's up to the developer to choose. An app with multiple