Group start issue

[Jacques Durand <JDurand@us.fujitsu.com>]

Title: Group start issue

Proposal from Sunil & Jacques on an issue assigned to us at last call:

---------------------------------------------------------------------------------------------

Issue:

Group "start" status is redundant with sequence number = 0 used for the
first message of a group. Having two starting group markers is redundant and
may lead to inconsistencies.

Proposal summary:

(a)- we keep seq num = 0 as a MUST for the first message of a group. @status="start"
is no longer used, or relied upon.
(b)- we state more explicitly that the absolute max value for sequence number (in 4.2.1.1)
is 18446744073709551615 (XMLschema unsignedlong)
(c)- we state more explicitly that a group must NOT wrap-around seq numbers,
i.e. when the max integer limit is reached, the group automatically closes.
We add this closing case in 5.1 (T6).
(d)- we remove the @status attribute from the schema, and use instead an attribute named "last",
with values = "false" or "true". Value "false" is the default. When @last="true",
it is the same as previous @status="end". But it is now OK to have the first message
of a group be also the last one, even when using seq numbers.

NOTE 1: removing @status and using @last instead, is less ambiguous now that
there is no reason to use "start" and "continue". In addition, we keep using "status"
with a different meaning: the spec says frequently that a PollRequest is used to get
the "status" of messages, which is a different thing. This is confusing.

NOTE 2: a conservative alternative to (d) is to keep @status, but allow only two values: "end", "continue" ("continue" meaning "not end").

NOTE 3: Places affected by teh change from @status to @last:
simpe edits (in many cases, just remove status="start")
except for subsection (4) in 4.2.1.1 (replace 10 lines). Spec areas affected are:
-Example 1
-Example 5
-sec 4.2.1.1: Line 617, Example 6, Table 3, Subsection (4) on Status attribute (line752-762)
-Table 16 (InvalidMessageParameter entry)
-sec 5.1.1, line 1118.
-sec 5.1.2, line 1127.
-Sec 5.1.3, Termination T3, T4.
-Example 10

NOTE 4: (suggested by Jacques) We also state that it is recommended that the
sender application only uses a "group handle" - and not directly the GroupId - when
submitting a message for a particular group.
*In case* group handles are supported, then in case a Sender submits a message that exhausts
the last sequence number in a group, then the Sender must be able to keep submitting
messages for the same group handle, without having to worry about the group it used being closed:
The RMP MUST automatically start a new group with same RM profile as the exhausted one,
and transparently associate the group handle with the new group.