PR fixes

Author: Tigran Najaryan

specification/library-guidelines.md

@@ -16,15 +16,17 @@ _Note to Language Library Authors:_ OpenTelemetry specification, API and SDK imp
 
 3. The developers of the final application normally decide how to configure OpenTelemetry SDK and what extensions to use. They should be also free to choose to not use any OpenTelemetry implementation at all, even though the application and/or its libraries are already instrumented.  The rationale is that third-party libraries and frameworks which are instrumented with OpenTelemetry must still be fully usable in the applications which do not want to use OpenTelemetry (so this removes the need for framework developers to have "instrumented" and "non-instrumented" versions of their framework).
 
-4. Language library implementation must be clearly separated into wire protocol-independent parts that implement common logic (e.g. batching, tag enrichment by process information, etc.) and protocol-dependent telemetry exporters. Telemetry exporters must contain minimal functionality, thus enabling vendors to easily add support for their specific protocol.
+4. The SDK must be clearly separated into wire protocol-independent parts that implement common logic (e.g. batching, tag enrichment by process information, etc.) and protocol-dependent telemetry exporters. Telemetry exporters must contain minimal functionality, thus enabling vendors to easily add support for their specific protocol.
 
-5. Language library implementation should include the following exporters:
+5. The SDK implementation should include the following exporters:
     - Jaeger.
     - Zipkin.
     - OpenCensus.
     - Prometheus.
     - OpenTelemetry Protocol (when the protocol is specified and approved).
-    - Standard output to use for debugging and testing.
+    - Standard output (or logging) to use for debugging and testing as well as an input for the various log proxy tools.
+
+    Note: some of these support multiple protocols (e.g. gRPC, Thrift, etc). The exact list of protocols to implement in the exporters is TBD.
 
     Other vendor-specific exporters (exporters that implement vendor protocols) should not be included in language libraries and should be placed elsewhere (the exact approach for storing and maintaining vendor-specific exporters will be defined in the future).