Update prometheus proposals based on discussions.

text/entities/0264-resource-and-entities.md

@@ -322,18 +322,29 @@ Today, [Prometheus compatibility](https://github.com/open-telemetry/opentelemetr
 Here's a list of requirements for the solution:
 
 - Existing prometheus/OpenTelemetry users should be able to migrate from where they are today.
-- Prometheus should have a set of identifying attributes for their up and coming `info()` function and info metric features.
-- (desired) OpenTelemetry should be able to create unique `job`/`instance` labels between all metrics sent to prometheus for any "info" metric join.
-
-A quick proposal of what this might look like:
-
-- `target_info` metric generation is updated to exclude any keys which are contained in `descriptive_attributes_keys` of an entity.
-- For each entity which has non-empty descriptive_attributes_keys, generate an info metric: `<entity_type>_entity_info` (naming TBD), which has all identifying and descriptive keys. This should play nicely with the planned improvements to [info-typed metrics](https://github.com/prometheus/proposals/blob/main/proposals/2024-04-10-native-support-for-info-metrics-metadata.md#goals).
-
-Another option (that would break compatibility):
-
-- `job`/`instance` are synthesized using a consistent hashing algorithm and identifying attributes of entity on resource.
-- Each entity type is written as an info metric called `<entity_type>_entity-info`.
+- Any solution MUST work with the [info-typed metrics](https://github.com/prometheus/proposals/blob/main/proposals/2024-04-10-native-support-for-info-metrics-metadata.md#goals) being added in prometheus.
+  - Resource descriptive attributes should leverage `info()`
+  - Resource identifying attributes need more thought/design.
+  - Note: Current `info()` design will only work with `target_info` metric, and `job/instance` labels for joins.  This labels MUST be generated by the OTLP endpoint in prometheus.
+- (desired) Users should be able to correlate metric timeseries to other signals via Resource attributes showing up as labels in prometheus.
+- (desired) Conversion from `OTLP -> prometheus` can be reversed such that `OTLP -> Prometheus -> OTLP` is non-lossy.
+
+Here's a few (non-exhaustive) options for what this could look like:
+
+- Option #1 - Stay as close to today as possible
+  - `target_info` continues to exist as it is, with all resource attributes.
+  - OpenTelemetry syntehsizes unique `job`/`instance` labels from identifying attributes in Resource in lieu of `service` entity.
+  - Prometheus OTLP ingestion continues to support promoting resource attributes to metric labels.
+- Option #2 - Promote all identifying attributes
+  - By default all identifying labels on Resource are promoted to resource attributes.
+  - All descriptive labels are placed on `target_info`.
+  - (likely) `job`/`instance` will need to be synthesized for resources lacking a `service` entity.
+- Option #3 - Enocde entities into prometheus as info metrics
+  - Create `{entity_type}_entity_info` metrics.
+  - Synthesize `job`/`instance` labels for joins between all `*_info` metrics.
+  - Expand the scope of info-typed metrics work in Prometheus to work with this encoding.
+
+These designs will be explored and evaluated in light of the requirements.
 
 ### Should entities have a domain?