[
https://issues.apache.org/jira/browse/QPID-7434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-7434:
-----------------------------
Description:
There are a number of gaps in our message converters that mean some message are
not converted with complete fidelity (particularly in the treatment of
application headers), and where complete fidelity cannot be acheived we need
sensible rules, uniformly implemented to decide how aspects degrade.
For instance, for AMQP 0-8..0-10 allow application headers whose values were
complex types (e.g. map). AMQP 1.0 disallows this. What should the behaviour
be? Should the header be dropped?
Another instance is the length and constituency of the keys of application
headers. AMQP 0-8..0-10 have a protocol restriction of 255 UTF8 bytes. AMQP
has supports longer strings. Also AMQP 0-9 says further restricts the key to
be formed like a Java identifier.
was:
There are a number of gaps in our message converters that mean some message are
not converters with complete fidelity (particularly in the treatment of
application headers), and where complete fidelity cannot be acheived we need
sensible rules, uniformly implemented to decide how aspects degrade.
For instance, for AMQP 0-8..0-10 allow application headers whose values were
complex types (e.g. map). AMQP 1.0 disallows this. What should the behaviour
be? Should the header be dropped?
Another instance is the length and constituency of the keys of application
headers. AMQP 0-8..0-10 have a protocol restriction of 255 UTF8 bytes. AMQP
has supports longer strings. Also AMQP 0-9 says further restricts the key to
be formed like a Java identifier.
> Mature the AMQP message conversion layer (headers and content)
> --------------------------------------------------------------
>
> Key: QPID-7434
> URL: https://issues.apache.org/jira/browse/QPID-7434
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
> Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> There are a number of gaps in our message converters that mean some message
> are not converted with complete fidelity (particularly in the treatment of
> application headers), and where complete fidelity cannot be acheived we need
> sensible rules, uniformly implemented to decide how aspects degrade.
> For instance, for AMQP 0-8..0-10 allow application headers whose values were
> complex types (e.g. map). AMQP 1.0 disallows this. What should the
> behaviour be? Should the header be dropped?
> Another instance is the length and constituency of the keys of application
> headers. AMQP 0-8..0-10 have a protocol restriction of 255 UTF8 bytes. AMQP
> has supports longer strings. Also AMQP 0-9 says further restricts the key to
> be formed like a Java identifier.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
