<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:
-
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?
-
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?
-
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.
-
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.
-
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.
-
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?
<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.
-
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
|