More clarifications to bundling

content/client-lib-development-guide/features.textile

@@ -500,10 +500,13 @@ h3(#realtime-channel). Channel
 *** @(RTL6c2)@ If the connection is @INITIALIZED@, @CONNECTING@ or @DISCONNECTED@, and @ClientOptions#queueMessages@ has not been explicitly set to false, then the message will be queued and delivered as soon as the connection is @CONNECTED@ and the channel is in a state in which publishing is permitted per @RTL6c1@
 *** @(RTL6c4)@ If the connection is @SUSPENDED@, @CLOSING@, @CLOSED@, or @FAILED@, or the channel is @SUSPENDED@ or @FAILED@, the operation will result in an error
 *** @(RTL6c5)@ A publish should not trigger an implicit attach (in contrast to earlier version of this spec)
-** @(RTL6d)@ Messages for a single channel that have been queued may be sent in a single @ProtocolMessage@ by bundling them into the @ProtocolMessage#messages@ array, subject to the following constraints:
+** @(RTL6d)@ Messages that have been queued may be sent in a single @ProtocolMessage@ by bundling them into the @ProtocolMessage#messages@ or @ProtocolMessage#presence@ array, subject to the following constraints:
 *** @(RTL6d1)@ The resulting @ProtocolMesssage@ must not exceed the @maxMessageSize@
-*** @(RTL6d2)@ Messages with differing @clientId@ values must not be bundled together. (Note that this constraint only applies to what the client library can autonomously do as part of queuing messages, not to what the user can do by publishing an array of @Messages@. It exists because if any @Message@ in a @ProtocolMessage@ has an invalid @clientId@, the entire @ProtocolMessage@ is rejected. This is fine if the user has deliberately published the @Messages@ together – they requested atomicity – but not if the client library has bundled them without the user's knowledge)
-*** @(RTL6d3)@ Within messages for a given channel, only contiguous messages can be bundled together. For example, if the user publishes three messages, A, B, and C for channel X, and A and C have the same @clientId@ but B has a different one, the client library should not do any bundling, else message ordering preservation would be violated
+*** @(RTL6d2)@ Messages can only be bundled together if they have the same @clientId@ value (or both have no @clientId@ set). (Note that this constraint only applies to what the client library can autonomously do as part of queuing messages, not to what the user can do by publishing an array of @Messages@. It exists because if any @Message@ in a @ProtocolMessage@ has an invalid @clientId@, the entire @ProtocolMessage@ is rejected. This is fine if the user has deliberately published the @Messages@ together – they requested atomicity – but not if the client library has bundled them without the user's knowledge)
+*** @(RTL6d3)@ Messages can only be bundled together if they are for the same @channel@
+*** @(RTL6d4)@ Messages can only be bundled together if they are of the same type (that is, @Message@ versus @PresenceMessage@)
+*** @(RTL6d5)@ Only contiguous messages in the queue can be bundled together. For example, if the user publishes three messages, A, B, and C, of which A and C could be bundled together under @RTL6d1-4@ but B could not, then no bundling should occur
+*** @(RTL6d6)@ The order of messages in the resulting @ProtocolMessage@ Messages must match the publish order. For example, if the user publishes @Message@ D, then the @Message@ array [E, F], then @Message@ G, the final @messages@ array should be [D, E, F, G]
 ** @(RTL6e)@ Unidentified clients using "Basic Auth":https://en.wikipedia.org/wiki/Basic_access_authentication (i.e. any @clientId@ is permitted as no @clientId@ specified):
 *** @(RTL6e1)@ When a @Message@ with a @clientId@ value is published, Ably will accept and publish that message with the provided @clientId@. A test should assert that the @clientId@ of the published @Message@ is populated
 ** @(RTL6g)@ Identified clients with a @clientId@ (as a result of either an explicitly configured @clientId@ in @ClientOptions@, or implicitly through Token Auth):