Re: [ebxml-cppa] Some issues I like to see discussed in tomorrow's CC

["Himagiri(Hima) Mukkamala" <himagiri@sybase.com>]

<hima> inline

Arvola Chan wrote:

 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:

1. 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.

<hima> What did we decide on this?

1. 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.

<hima> My vote is for implied. Are you suggesting that consistency
constraints would have to based on values retrieved from both CPA
and BPSS?

1. 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.

<hima> Not clear on why absence of xlink:href would make Signature impossible.
It would only make ds:Reference over ProcessSpecification impossible.

1. 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.

<Hima> agree. Can we add <any> so that if user wants to have
 a transform to be applied over the constituent, it can be done.

1. The NamespaceSupported element description refers to S2ML. Is this superseded by SAML (developed under the auspices of OASIS)? Should we reference SAML instead?

<hima> Yes.

1. 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"?
2. 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?

<hima> Didn't we decide that version does not have to be reflected
in the cpaid cause the assumption/description in document would
say that it's assumed that only one version of CPA is deployed at both
the sites at any instance, and the version attribute would convey that
version number. So in that sense, we don't really have support
for simulataneous deployment of different versions of same CPA.

1. For extensibility, which elements should accept #wildcards?

Thanks,-Arvola

-----Original Message-----
From: Arvola Chan <arvola@tibco.com>
To: Dale Moberg <dmoberg@cyclonecommerce.com>; Himagiri(Hima) Mukkamala <himagiri@sybase.com>; Tony Weida <rweida@hotmail.com>; Peter Ogden <pogden@cyclonecommerce.com>
Cc: ebxml-cppa@lists.oasis-open.org <ebxml-cppa@lists.oasis-open.org>
Date: Thursday, January 31, 2002 2:41 PM
Subject: My planned changes to be incorporated into the 1.07 draft
 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