AMQP 1.0 Message Encoding - using AMQP typed data vs. Mime content-type / content-encoding (Was (unintentionally I assume): P)

I think it's inconsistent to use a mechanism (content type) intended for
opaque data on data which is not opaque... only in a couple of special
cases (an amqp-value section containing a string or binary value) does it
make sense. In general the question is who is the field aimed at - the
AMQP library or the client application? I think the content-type should
actually be interpreted by the AMQP library - in the same way that I would
expect the AMQP types to be.

I think it "appears" to be more convenient to set the content-type on the
properties field for a string value because we perceive that the client
library would be able to understand AmqpValue(String("{ }")) but not
AmqpValue(Described(Symbol("org.json"),String("{ }"))) and that the
content-type would be made available to the end user of the API for them to
then be able to understand that this is Json, and not intercepted by the
client library. However that's not necessarily the case (the current JMS
client doesn't expose the content type IIRC, and may use it for switching
behaviours on opaque data - e.g. for object messages).

More generally I think we collectively (in Qpid and in the wider AMQP
world) need to decide when/if we use the AMQP type system to encode data,
versus using MIME types.

If I want to start compressing data as I generally send large messages,
should I send my data with the content-encoding as gzip, or should I define
a new described type for compressed data. If the former - what if the
large message I want to send is a map?

My general advice is to choose one mechanism or the other and not to
confuse the two.

Of course you have an inconsistency to resolve if somebody sets an AMQP

The spec is the spec, and now ratified at ISO, so the wording there is not
going to change. We could interpret the spec more loosely, but - as above
- i think that ultimately that will lead to more confusion.

-- Rob