Allow use of text encoded properties

[SergeyKanzhelev]

It will be useful to allow text encoded properties as addition to binary. It may be easier to implement and use in certain scenarios that are less critical to the property size.

[ryeats]

I would like to point to JMS in-particular which doesn't support byte[] message properties. So a binary format would preclude that messaging API abstraction from being able to include the application layer without some support from the underlying client to do the conversion.

[sgryphon]

I definitely agree that, despite the longer length, the traceparent field should remain in text format for interoperability.

For example, Azure Service Bus can use either AMQP or HTTPS as the transport mechanism, with a message have a collection of user properties. The API does support objects (so presumably a byte array could be used, although I'm not sure how it is serialised).

However, from the documentation "user properties map directly to and from HTTP headers; in AMQP they map to and from the application-properties map." https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-messages-payloads

When adding the property you won't necessarily know which transport will be used, so won't know whether to add string (for HTTPS) or binary (for AMQP). The framework may take care of this if adding the property automatically (e.g. from Activity.Current), but if you are adding manually (e.g. aren't using Activity), then you would not know the format to use.

Various other wrappers around AMQP may have similar limitations, such as JMS mentioned above.

It would also be more consistent to use string for both traceparent and tracestate, and make pass through operations easy, e.g. converting from HTTP to AMQP. If you can't pass through the string you would need to parse and serialise.

String is far better (despite the longer length).