Discrepancy between spec and test suite re JMSMessageID during pub/sub

While the specification appears to require that the JMSMessageID should be preserved from the time it is generated during a publish until the time it is consumed from a subscribe, the test suite does not check for this condition.

I am intentionally avoiding a claim that the spec is ambiguous on this matter after discussion it with Nigel on Twitter and [Stack Overflow](http://stackoverflow.com/questions/29001655/should-the-jmsmessageid-change-between-publish-and-subscribe). However, the IBM MQ JMS implementation (and perhaps others I'm unfamiliar with) changes the JMSMessageID between the publish and the subscribe and this is contrary to the intent of the specification, I am told.

The issue I am trying to resolve here is not IBM's implementation but rather the combination of the wording in the spec and test suite implementation that allows seasoned practitioners in the field to arrive at completely opposed interpretations of the spec on something so foundational as the JMSMessageID and both believe strongly that theirinterp[retation is correct.

Some specific issues that give rise to this include:

The word 'provider' is used both to mean the transport and the thing sending messages. The spec switches between these contexts without qualifying which is intended. This impacts the scope to which statements about atomicity of the message may apply.

The spec does not clearly distinguish between identical but separate physical copies of the same logical message versus distinct and unique logical messages. For example, the spec says that...

> Each copy of the message is treated as a completely separate message. Work done on one copy has no effect on any other; acknowledging one does not acknowledge any other; one message may be delivered immediately, while another waits for its consumer to process messages ahead of it.

IBM has advanced the theory that "the copies of the message created when sending to a Topic can be considered as completely separate messages." Based on this and the absence of a test in the reference suite to check whether the JMSMessageID has been preserved across a publish and subscribe, they conclude that "Because separate JMS messages are uniquely identified by their JMSMessageID field, each separate subscription message should have a different JMSMessageID."

Nigel advances a slightly different theory:

> Each message sent to a topic is delivered to every subscriber on that topic. These subscribers will receive a separate copy of the same message, with the same body, properties and headers, including JMSMessageID value.

My argument is that if the specification was sufficiently clear, then the interpretations arrived at by an authoritative member of the spec team and a representative member of the JMS Experts group would be at least somewhat compatible. In this case, two advanced practitioners are not only diametrically opposed in their interpretation, but both adamant about the correctness of their positions. I would think either a clarification of the spec or a cage match is called for. I'd pay to see either but would prefer the clarification.

Finally, Nigel notes that after so much time and with large bodies of deployed code, it might not be worth amending the spec. If that is true, then at least a non-binding clarification would point implementers consistently in the right direction so that discrepancies in implementations can be addressed through attrition, if no other way.
#### Environment
All.
#### Affected Versions
[1.0, 1.0.1, 1.0.2, 1.0.2b, 1.1, 2.0ED, 2.0PD, 2.0FD, 2.0]

Start by comparing the JMS specification wording about JMSMessageID, provider terminology, and topic message copies with the existing pub/sub tests, which currently do not check preservation across publish and subscribe. Done means the interpretation is agreed and recorded through a specification clarification or non-binding clarification, with the relevant test coverage updated if appropriate.

Written by the indexing model from the issue text.