The following are the changes I plan to contribute to the 1.07 draft. I
will start working on the schema and example changes and wait for the 1.06 draft
from Tony on Monday before updating the specification.
-Arvola
Schema (and corresponding spec) changes:
- Factor out PersistDuration as an element as sibling of the
ReliableMessaging element
- Rename the WillInitiate element as CanSend; rename the
WillRespond element as CanReceive
- Add isTamperProof, isIntelligibleCheckRequired, timeToAcknowledgeReceipt,
timeToAcknowledgeAcceptance, timeToPerform attributes to the
BusinessProcessCharacteristics element
- Remove defaultSignalChannelId attribute from the
ServiceBinding element and require explicit action bindings for signals if
they are to be used
- Replace confidentiality.type with tns:confidentiality.type in
schema
- Add optional schemaLocation attribute to PartyRef
element
- Allow an action binding to specify multiple delivery channels
to provide for the use of different transport protocols; the same Packaging
would be used regardless of DeliveryChannels
- Add uuid attribute to ProcessSpecification
- Make the cpaid attribute within the
CollaborationProtocolAgreement element required rather than
optional
- Add AccessAuthentication element to TransportSender and
TransportReceiver
- Add cppid attribute to
CollaborationProtocolProfile
- Require CollaborationProtocolAgreement to have exactly two
PartyInfo
- Make all version attributes required
- Make id attribute in SimplePart required rather than optional
because it is no longer nested under Packaging and can be referenced from
multiple Packaging elements
- Propose schema change to allow identification of SimpleParts
that are to be excluded from signature
Spec only changes:
- Clarify relationships between BusinessProcessCharacteristics
and MessagingCharacteristics attributes and sub-elements of Transport and
DocExchange; state consistency requirements among attribute values
- Clarify that NRR can be supported either through MSH level signed
Acknowledgment or business level Receipt Acknowlegment signals. In the latter
case, the ServiceBinding must have action binding specified for the Receipt
Acknowledgment signal.
- Clarify that the short-form action names used by the two
collaborating parties may not be identical; recommend that the
RequestingBusinessActivity and RespondingBusinessActivity names be used in the
absence of reuse of the same BusinessTransaction in multiple
BusinessTransactionActivities
- Clarify that the short-form action name needs to be unique across
CollaborationRoles (if a Party has multiple CollaborationRoles)
- Clarify that the Service element for non piggybacked Signal messages
should be equal to the Service element used in the original business message
being acknowledged
- Clarify that the sync reply mode "responseOnly" means that no
signals are to be used at all; and that the sync reply mode
"signalsAndResponse" means that the requester must also return the Receipt
Acknowledgment signal for the response over the same HTTP
connection
- Change BPSS example to use different values for the name and
nameID attributes for InitiatingRole and RespondingRole
- Require the use of multiple ServiceBindings if both sync and
async reply modes are to be supported because different Packaging would have
to be used for synchronous versus asynchronous response
- Clarify that in a SimplePart element, the first NamespaceSupported
sub-element identifies the schema for the SimplePart
- Incorporate S/MIME encryption example into Packaging
section
- Clarify that timeToPerform is to be used for HTTP connection
timeout
- Clarify in normative appendix that RefToMessageId can be used
for correlating response with request
- Update CPP/CPA examples with valid ds:KeyInfo elements
- Line 814: type attribute in PartyId is of type "anyURI", not "string"
- Line 2616: CollaborationProtocolAgreement must have 0 to 3
signatures, not one or more signatures
-Arvola
|