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

[Dale Moberg <dmoberg@cyclonecommerce.com>]

Note: we ran out of time when discussing these points.
We need a resolution soon. Some issues below marked
for discussion next week. Others, such as exceptions
for some IMPLIED attributes, should be reviewed
and any dissent noted today, Friday because Arvola
will submit the schema this afternoon!



Dale> comments interspersed with
<hima> inline and
Arvola> 

Arvola>  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? 

Thursday, we decided to note this as an exception and make it IMPLIED.

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? 

Dale> I think the consensus at the Face to Face was to make attributes
REQUIRED. 
We have discovered a few exceptions. Do we still need more exceptions? 
For BP Characteristics, I think we should always announce the values
that are agreed upon, whether they override or just repeat.
That makes for a standard way to check status of overriding and alert
humans to the situation when they are overriding.


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


Dale> I thought we were looking for a way to support a registry query by
UUID?
Even in the Registry, you eventually get a URL (site specific probably).
I don't
know if BPSS instances will have standardized locations within Oasis or
UN/CEFACT.
I doubt it because different industries can role their own. So, it seems
safe to
assume a resolvable URL in the use case we had for UUID.


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

Dale> I agree with Arvola that UUID should not be REQUIRED, for the
reason given.
Do we need a poll on this?

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

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

Dale> Sounds like a way to handle the xmldsig problem. IMPLIED seems
appropriate
here also. Hima's #any is OK addition here. This transform is then a per
constituent
transform, right?

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. 
Dale> Yes, we need a check on the Bibliography. I am trying to find out
how
we arrange to have the spec updated to final references. I don't know if
SAML will be approved before us or not...So how do we refer to in
progress stuff
without introducing undesirable staleness?

Arvola> 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"? 

Dale> This namespace is registered and under an authority so as I
indicated, it seems OK to use 
this URN tree as a base of operations. URN resolution is mainly a
futures matter.

Arvola> 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? 

Dale> We never reached consensus on this. The tension was some favored
not having to
change the CPAId when the CPA version changed. At the minimum, a warning
must be provided
that use of the same CPAId and changing versions creates a
synchronization problem that
software must resolve-- perhaps by setting the effective dates
appropriately? (Still can
be overlapping validity periods though.) I think we need to discuss this
one at the next
meeting. 


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

Dale> I agree with Hima that we were leaning toward saying that only one
CPA deployed
at both sites. But we left it implementation dependent how to
synchronize. Version 3?
 
For extensibility, which elements should accept #wildcards? 

Dale> Need to take this up at next meeting too.

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