While working on my contributions to the 1.07 draft, I come
across the following issues that I like to see discussed in tomorrow's CC if
possible:
- We agreed at the F2F that all version attributes should be
REQUIRED. However, In the NonRepudiationProtocol element example, I have a
hard time figuring out what would be an appropriate version attribute value.
The example is currently using "http://www.w3.org/2000/09/xmldsig#"
as the string value for NonRepudiationProtocol.
- It is not clear to me if the attributes under
BusinessProcessCharacteristics should be REQUIRED or IMPLIED. We say that
these attributes can be used to override parameters specified in the business
process. In that sense, I would think that if an attribute is omitted, the
default value should be obtained from the business process. However, we try to
describe consistency contraints between various attributes. It would be much
simpler for a CPA composition tool to check for consistency if all attributes
are directly available from the CPA, rather than having to retrieve default
values from the BPSS instance.
- In the ProcessSpecification element, we have an existing
REQUIRED xlink:href attribute and we are trying to add a uuid attribute. One
reason for adding a uuid attribute is that it may not be always possible to
provide a resolvable xlink:href for the business process document. If so, then
we should not have made xlink:href REQUIRED in the first place. It also seems
inappropriate to make uuid REQUIRED. What if the BPSS spec is not being used?
There may not be a usable uuid. One argument in favor of making xlink:href
REQUIRED is that its absence would make it impossible to attach one or more
signatures on CPPs and CPAs.
- In order to describe which parts of business message is to be
signed by the ebXML MSH, I suggest adding an IMPLIED boolean
excludedFromSignature attribute to the Constituent element. This attribute is
only applicable to those Constitutents that comprise the top-level multipart
ebXML message. By default, this attribute is "false", meaning that the
Constituent will be included in the ds:Signature. Those Constituents that have
this attribute explicitly set to "false" would be excluded from the
signature.
- The NamespaceSupported element description refers to S2ML. Is
this superseded by SAML (developed under the auspices of OASIS)? Should we
reference SAML instead?
- Is it acceptable to allow PartyRef to occur multiple times,
in order to accommodate the reference to context information? What are
appropriate values for the type attribute? Would it be appropriate to use URNs
like "urn:oasis:names:tc:ebxml-cppa:contact-information" and
"urn:oasis:names:tc:ebxml-cppa:context"?
- We need to decide on how CPAs should be versioned. Should the
Appendix on ebMS/CPPA element mapping state that the cpaid and version
attibutes in the CollaborationProtocolAgreement element should be concatenated
to populate the CPAId element in ebMS message header?
- For extensibility, which elements should accept
#wildcards?
Thanks,
-Arvola
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
|