OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [ebxml-cppa] My update contributions to the 1.07 draft


Attached please find a zip file containing the following:
  • the updated Word document
  • an example CPA
  • two corresponding example CPPs
  • a corresponding BPSS example
  • the XML schema for the CPA
  • the XML schema for the BPSS example (based on the BPSS team's bpss1.02.xsd but slightly modified to fix a couple of problems detected by the schema editor)
The schema changes addressed in the Word document, example instances, and in the schema include:
  • Factor out PersistDuration as a sibling of ReliableMessaging
  • Rename the WillInitiate element as CanSend; rename the WillRespond element as CanReceive
  • Rename the BusinessProcessCharacteristics element as BusinessTransactionCharacteristics 
  • Add isTamperProof, isIntelligibleCheckRequired, timeToAcknowledgeReceipt, timeToAcknowledgeAcceptance, timeToPerform attributes to the BusinessTransactionCharacteristics element
  • Remove defaultSignalChannelId attribute from the ServiceBinding element 
  • Replace confidentiality.type with tns:confidentiality.type in schema
  • Add optional schemaLocation attribute to the PartyRef element
  • Allow the PartyRef element under PartyInfo to be repeating
  • 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 IMPLIED uuid attribute to ProcessSpecification
  • Make the name attribute in ProcessSpecification IMPLIED 
  • Make the cpaid attribute within the CollaborationProtocolAgreement element REQUIRED 
  • Add AccessAuthentication element to TransportSender and TransportReceiver
  • Add REQUIRED cppid attribute to CollaborationProtocolProfile
  • Require CollaborationProtocolAgreement to have exactly two PartyInfo
  • Make all version attributes REQUIRED except in protocol.type
  • Make id attribute in SimplePart REQUIRED 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, by adding excludeFromSignature attribute to Constituent element
  • Make TrustAnchors and SecurityPolicy elements under SecurityDetails non repeating
  • Make the idref attribute in Constituent REQUIRED
  • Make the CompositeList element in Packaging REQUIRED
  • Add uniqueness constraints related to the action attribute under ThisPartyActionBinding
  • Add ID attribute to complex type ActionBinding.type
  • Make OtherPartyActionBinding to be of type IDREF rather than ActionBinding.type.
Additional changes to the Word document include:
  • 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.
  • 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 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
  • Change type attribute in PartyId to be of type "anyURI", not "string"
  • Clarify that CollaborationProtocolAgreement must have 0 to 3 signatures, not one or more signatures
  • Remove the following statement: "The error endpoint may be use as the address for error messages issued by the messaging service."
  • Add ReliableMessaging element under ebXMLReceiverBinding
  • Mention that Packaging can be used to describe compression of individual or composite MIME parts
  • Remove section 7.7.2 SimplePart under Packaging; there already is a section 7.6 SimplePart
  • Add copyright information to the examples
  • Update References section
  • Remove Appendix E
  • Update glossary
The following issues (from the issues database) for which I have been assigned responsibility are candidates for having their status changed to resolved: 7, 10, 40, 45, 49, 60, 61, 62, 63, 65, 69, 73, 75, 77, 83, 84, 88, 89, 90, 91, 98, 103, 105, 107, 108, 109, 110, 112, 113, 114, 116, 120, 125, 131, 143, 151, 153, 154, 156, 158, 161, 163, 165, 166, 167, 168, 170, 171, 174, 177, 179, 181, 186, 188, 192, 200, 215.
 
-Arvola

 

20020207.zip



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC