I'm going to have some comments on the specifics of Nicks text but it
has triggered a concern I've had for 
a while.
 
The RFC 2119 keywords - MUST, MAY, MUST NOT etc. were originally used
for, and are very
appropriate for describing the requirements of an implementation of a
protocol. They are not
always quite so useful when describing the requirements of a more
declarative language, such as 
CDL (and various other cases). 
 
 
It's quite straightforward to say "the sender MAY include a
reply-address. If a message with
a reply-address is received any response from the responder MUST be sent
to that address" Those are permissions
and constraints on the behaviour of real systems and programs.
Implementations that disobey the 
MUST or do not allow for the peer's MAY will not generally interoperate
and are not conformant.
 
But for CDL, the target isn't an implementation with active behaviour,
but a document that defines
the required and acceptable behaviour of systems. So MUST means "a
document without this
is not valid" and MAY means "a document with or without this is valid".
(And there are then implications
for an implementation that consumes CDL documents for some purpose).
But the MUST, MAY
terminology can be a bit misleading for CDL.
 
It's clear in some cases with CDL - from Nick's text "Two or more
Interactions MAY be marked as Choreography 
initiators, indicating alternatives ..." - A <choreography /> that
contained more than one interaction marked
as initiator would be valid. (actually 
 
But "Initially, the collaboration MUST be established between parties, 
then work MAY be performed within it and finally it MAY complete. " is
much less clear. Especially, that
sounds like a dynamic constraint on the behaviour, but I think it's just
descriptive, and could be expressed as
simple definition
 
A collaboration
    - is initially established
    - then may perform work
    - finally may complete
 
That uses MAY, but not really in the sense of 2119.  RFC 2119 text on
MAY is all about one implementation 
choosing to do it, another not. But here we are talking about the
characteristics of a collaboration, which if it doesn't
meet the the definition is not invalid, but is just not the kind of
collaboration we are talking about.
 
Although this has been triggered by the lifeline text, it's more a
general matter. I'd suggest that the
editors use the rfc 2119 words with caution especially when dealing with
the description of what something
is, rather than what it must do.
 
 
Peter