[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Issues list
Attached is a revised issues list for use at the F2F. It was exported from Access in text format this time, which unlike RTF export format, has the advantage of preserving the complete descriptions :-) Cheers, Tony _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
CPPA Issues Category BPSS Submitter Issue ID 39 Issue Link from action attribute to matching business transaction Description - Currently, the link from the action attribute (Override element) to the matching business transaction in the Process-Specification document is the equality of the value of the action attribute to the value of the name attribute in the desired BusinessTransaction element. Use of an xlink may be better for the installation tools. - At the July 24-25 meeting it was suggested that Xpointer be considered to define the links. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 1 of 171 Category BPSS Submitter Issue ID 18 Issue BPSS timeToPerform for BusinessTransactionActivity and related CPPA parameters Description The BPSS Process Specification document has a timeToPerform attribute of the BusinessTransactionActivity element. This is the maximum allowed service time for a request, defined separately for each business transaction. However the BPSS does not define the number of retries or retry interval. One could add number of retries and retry interval to the CPP-CPA but it isn't clear that it makes sense without including retries in the BPSS choreography. It isn't clear whether the BPSS would have to be extended to cover retries or at least to include attributes that express number of retries and retry interval. If these were defined in the BPSS, then the corresponding items in the CPP-CPA would define override values. Overrides of timeToPerform and retry interval might make sense since these quantities are probably system-dependent. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 2 of 171 Category BPSS Submitter Issue ID 19 Issue BPSS timeToPerform for Binary Collaboration and related CPPA parameters Description The BPSS defines timeToPerform for a binary collaboration. Should this be in the CPA (with number of retries and retry interval)? timeToPerform in a binary collaboration is the time to execute the full set of business transactions. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 3 of 171 Category BPSS Submitter Issue ID 20 Issue BPSS timeToAcknowledgeReceipt and timeToAcknowledgeAcceptance Description The BPSS also defines timeToAcknowledgeReceipt and timeToAcknowledgeAcceptance. These deal with business signals rather than with application-level responses. Are override attributes for these needed in the CPP-CPA? Do these require number of retries and retry interval? Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 4 of 171 Category BPSS Submitter Issue ID 21 Issue Consistency of timeouts and installation tools Description The CPP-CPA-BPSS installation tools will have to check the consistency of the relative values of the timeouts at the three levels (business signals, business transaction, and binary collaboration. Some rules are already present in the BPSS spec. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 5 of 171 Category BPSS Submitter Issue ID 38 Issue Better way of specifying combinations of characteristics Description Currently, there is one Characteristics element per delivery channel. Yet each business transaction may have a different combination of characteristics. We need a better way of specifying characteristics than by multiplying the number of delivery channels. See "alternatives and choices" below. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 6 of 171 Category BPSS Submitter Issue ID 42 Issue Guaranteed Delivery Description In the BPSS, guaranteed delivery is stated as requiring third-party guarantees of delivery and nothing is said about reliable messaging. - Should the BPSS have some definitions related to use of reliable messaging between each role and the third party? - Do we need something in the CPP-CPA to cover third-party-based guarantees? - The BPSS has no definitions about reliable messaging between two parties. Is any thing needed or is this a matter only for CPP-CPA and messaging service? Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 7 of 171 Category BPSS Submitter Issue ID 43 Issue Binary Collaboration with more than one business transaction Description The BPSS says that a binary collaboration should not be used when business transaction rollback is required. Presumably, issue is what to do about earlier business transactions in the binary collaboration when one has to be rolled back. - Is there another way to specify a unit of work containing multiple business transactions? - The usual solution to rollback of a business transaction within a larger unit of work is to roll back the failed business transaction and perform compensating transactions on the earlier ones. The compensating transactions are application-dependent and would have to be included in the choreography. Should the BPSS cover compensating transactions? - Is there a CPP-CPA issue here? Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 8 of 171 Category BPSS Submitter Issue ID 45 Issue "Optional" attributes Description If any BPSS attributes may or may not appear, we may need rules in the CPPA spec about how to deal with an attribute in the CPP-CPA that does not appear in the referenced Process Specification document. Should such an attribute be treated as if it is present in the Process Specification document? Should the installation tools indicate an error? Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 9 of 171 Category BPSS Submitter Issue ID 37 Issue Direct selection of binary collaborations Description - Have the CPA directly select the binary collaboration(s) that are applicable. Add to the ProcessSpecification element a child element (cardinality one or more) that contains an xlink pointing directly to a binary collaboration Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 10 of 171 Category BPSS Submitter Issue ID 41 Issue Nonrepudiation of business signals Description Does the CPP-CPA need definitions in the delivery channel, in addition to listing the attributes in the Characteristics element, that support nonrepudiation of origin and receipt? Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 11 of 171 Category BPSS Submitter Issue ID 40 Issue BPSS isNonrepudiationRequired attribute and CPPA Nonrepudiation element Description The BPSS defines this attribute as requiring the message sender to save an audit trail. It has no signing semantics. The isTamperProof attribute controls signing of the business document. isTamperProof may be needed in the CPP-CPA Characteristics element. The CPP-CPA Nonrepudiation element is defined as covering signing and "prevents later nonrepudiation". Perhaps the definition should be expanded to explicitly cover the rule about audit trail that is stated in the BPSS Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 12 of 171 Category BPSS Submitter Chan Issue ID 44 Issue Other BPSS attributes to be reflected in CPPA? Description Are there other attributes that need to be reflected in the CPP-CPA? See, for example, Arvola Chan's comments posted to the CPPA list 7/22/01. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 13 of 171 Category BPSS Submitter Chan Issue ID 78 Issue Relationship between Acknowledgement, DeliveryReceipt,and BPSS Business Signals Description According to the Messaging Service spec, the Acknowledgement element is an optional element that is used by one MHS to indicate to another MHS that it has received a message (to support the implementation of reliable messaging). The DeliveryReceipt element is defined as an optional element that is used by the To Party who received a message to let the From Party who sent the original message know that the message was received. Origin email Date of Origin 7/22/2001 Reference Subject: Relationship between Acknowledgement, DeliveryReceipt,and BPSS Business Signals _______________________________________________________________ Page 14 of 171 Category BPSS Submitter Chan Issue ID 111 Issue Overriding Timing Parameters Specified in a Business Process Description . BPSS parameters that can be overridden are essentially boolean attributes. (In fact, it would be rather cumbersome for a party to indicate that it can accept both True and False values for these attributes. Essentially, all acceptable combinations would have to be enumerated!) There is no established convention to specify the range of acceptable values for non boolean attributes as well their preferred values. Therefore, it is not clear to me whether such enhancements can be introduced easily. Origin email Date of Origin 8/20/2001 Reference Subject: Overriding Timing Parameters Specified in a Business Process _______________________________________________________________ Page 15 of 171 Category BPSS Submitter Chan Issue ID 90 Issue T2 Non repudiation and MSG, CPP/A, BPSS spec alignment Description The BPSS spec says that nonRepudiationOfReceipt (NRR) is tied to the ReceiptAcknowledgement signal. NRR and reliable messaging are orthogonal. A business process may specify the non repudiation of receipt for the requesting business activity business message and/or the repudiation of receipt for the responding business activity business message, without requiring that reliable messaging be used. I think the Messaging Service should not tie NRR to the DeliveryReceipt element if the latter is used exclusively in reliable messaging. The MSH is not responsible for validating the syntax of payloads. NRR at the MSH level does not really implement NRR as called for by the business process specification. NRR at the BPSS level includes syntax validation on the payloads. Receipt Acknowledgement business signals have to be persisted in order to satisfy legal requirements implied by NRR. I just don't see the utility of persisting the DeliveryReceipt generated at the MSH level in addition to the ReceiptAcknowledgement signal. This may just be unnecessary overhead. Currently, NRR parameters are tied to the DeliveryChannel element in the CPP/A. According to Marty, these parameters may have to be relocated / added to the ProcessSpecification and/or the Role element in order to properly model the non repudiation requirements associated with the business process. Page 16 of 171 email Originemail I strongly feel that non repudation is one area that the MSG, CPP/A, heir 1.1 specifications. Date of Origin 8/30/2001 Reference Subject: T2 Non repudiation and MSG, CPP/A, BPSS spec alignment _______________________________________________________________ Category BPSS Submitter Sachs Issue ID 135 Issue Technical report on interoperability across Messaging, BPSS and CPPA specs Description We might want to consider a technical report on interoperability across the Messaging, BPSS and CPPA specifications. Dale agreed with the idea and felt that someone needs to draft it, but wasn't sure who. Origin call Date of Origin 8/6/2001 Reference _______________________________________________________________ Page 17 of 171 Category BPSS Submitter Sachs Issue ID 134 Issue isIntelligibleCheckRequired property from BPSS Description The BPSS specification has a Boolean isIntelligibleCheckRequired property associated with receipt acknowledgement to indicate if a syntax check is entailed. Marty wasn't sure if not sure if we have that in our version 1.0 [we don't] and opined that it's starting to look like it ought to be included. Origin call Date of Origin 8/6/2001 Reference _______________________________________________________________ Page 18 of 171 Category BPSS Submitter Moberg Issue ID 91 Issue Delivery Receipt, NRR and MSG/CPPA/BPSS (mis-)alignment and thelayering mishmash Description Details to be distilled. See the thread starting with the cited Origin email Date of Origin 8/31/2001 Reference Subject: Delivery Receipt, NRR and MSG/CPPA/BPSS (mis-)alignment and thelayering mishmash (was jumbled into: reliable messaging - hop by hop) _______________________________________________________________ Page 19 of 171 Category Business Collaboration Specs Submitter Issue ID 25 Issue Specializations of generic business processes for specific partners Description Specialization of the Process-Specification document for specific pairs of partners can be done using the 'substitution' capability that was added to BPSS at Vienna. In general this concerns how to have generic business processes, and yet be able to process specializations of those for the specific partners. This would be joint work with the CPPA and BP teams. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 20 of 171 Category Business Collaboration Specs Submitter Issue ID 46 Issue Overrides of details in BPSS Instance Document (Process Specification Document) Description Details to override include attribute values, business document types, etc. An override capability permits tailoring a BPSS instance document without having to replicate it, modify it, and treat it as a new business collaboration. Two proposals have been put forward, which may be useful together. They were presented at the July 24-25 meeting/ ú Karsten Riemer's substitution proposal. ú Tony Weida's proposal to use ds:Transforms to produce the effect of modifying the Process Specification document. One example of a transform is XSLT, but other may also be applicable. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 21 of 171 Category Business Collaboration Specs Submitter Issue ID 26 Issue Composition of Services Description David Burdett asked whether it is possible to use the same service in different business processes. An example is a payment authority that offers a payment authorization service that accepts a payment request and returns a payment response that conforms to some part of the IFX specification. This could be used in many different processes to make a payment, e.g. to pay an invoice, to get foreign exchange, etc. It would be really good if a payment authority could just define the service once and then everyone could use it in whatever business process it is needed in. This can be done with the existing CPA definition since a CPA can reference multiple Process Specification documents, one of which could be the payment process. However, there is no way to choreograph the interaction between the payment process and the accompanying business process. This is probably a BPSS issue. The IBM WSFL web-services proposal includes composition of services from simpler services. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 22 of 171 Category Business Collaboration Specs Submitter Issue ID 17 Issue Timeouts, number of retries, and retry interval Description Should the CPA provide for specifying timeout, number of retries, and retry interval for business-level responses? If the Specification Schema provides these parameters, then they probably have to be given values in the CPA. As with the security attributes, what is in the Process Specification document can be viewed as a default or recommendation with the agreed values specified in the CPP/CPA. For example, the timeout might depend on a Party's specific implementation of the process. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 23 of 171 Category Business Collaboration Specs Submitter Issue ID 15 Issue Business collaboration specifications besides BPSS Description We should provide for use of "foreign" business-collaboration specifications as alternatives to the Specification Schema model. Examples might be: úHand-crafted collaboration protocols based on a tpaML-like language úCollaboration protocols based on WSDL úCollaboration protocols based on alternative models such as WSFL, BPML, or whatever these evolve into. Some of these may involve joint work with the BP team or collaboration with the appropriate W3C team. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 24 of 171 Category Business Collaboration Specs Submitter Moberg Issue ID 128 Issue Two-phase commit and long-running transactions Description Dale mentioned the OASIS BTP team and the possibility of addressing two-phase commits and long running transactions - is it feasible to accommodate them? Marty answered that we have very little about conversations in version 1.0; he suspects that we need much more for two-phase commit. In terms of scope, we must decide if it's likely to become important in the next 18 months. . We consider our relation with BTP. Might we use BPSS, XLANG, WSFL or similar specs together with BTP? Tim cited a difficulty with BTP: it dictates the message sequence, e.g., certain timeouts. Origin Scottsdale F2F Date of Origin Reference _______________________________________________________________ Page 25 of 171 Category Business Collaboration Specs Submitter Weida Issue ID 121 Issue Business rules and constraints Description Capture business constraints and rules that specify context-dependent validation of a B2BI system's runtime behavior (for both profiles and agreements). See cited reference for more details. Origin Scottsdale F2F Date of Origin Reference http://www.oasis-open.org/committees/ebxml-cppa/meetings/business_rul es_and_constraints.ppt _______________________________________________________________ Page 26 of 171 Category Business Collaboration Specs Submitter Hayes Issue ID 148 Issue ProcessSpecification xlink:href attribute. Description The ebXML Business Process Analysis Worksheets & Guidelines [bpWS] recommends the use of a Business Process Identification Naming Scheme (BPINS) which is a URN. Recommend discussing its usage here. [Also from Duane Nickull Re: Why all this obsession over UIDs? As forwarded by Marty Sachs on Sept 28 2001: THe CPP and CPA documents should refer to BP schemas via the UIDmechnism too. This means I can recognize the UID value in the CPP andCPA which prevents me from having to get the sodding thing out of theregistry each time and read it manually.] Origin email Date of Origin 9/27/2001 Reference Subject: CPPA Version 1.0 Comments And Issues _______________________________________________________________ Page 27 of 171 Category Business Collaboration Specs Submitter Hayes Issue ID 141 Issue State that a modified Process Spec should be registered in a Business Library. Description Modifying Process Specs: Recommend stating that the new Process Specification is either registered in a Business Library. The Business Library can be public to the parties involved or could be a local private Business Library. In the case of local private Business Libraries, the new Process Specification should be registered and stored at each of the parties Business Libraries. Origin email Date of Origin 9/27/2001 Reference Subject: CPPA Version 1.0 Comments And Issues _______________________________________________________________ Page 28 of 171 Category Business Collaboration Specs Submitter Hayes Issue ID 142 Issue Remove or elaborate on description of process specification modification Description If the process specification is digitally signed, there should be no issue with this. I think the sentence should be struck from the document or the use case needs to be elaborated further (e.g. state that the CPA information along with the new process specification is exchanged between the two parties until agreement is reached). Origin email Date of Origin 9/27/2001 Reference Subject: CPPA Version 1.0 Comments And Issues _______________________________________________________________ Page 29 of 171 Category Collateral Submitter Issue ID 27 Issue CPA Use Cases Description It has been suggested that a technical report be prepared that discusses various use cases for the CPA. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Category Collateral Submitter Issue ID 73 Issue Publication of text forms of the DTD and XSD files Description We need to decide where to publish the text forms of future versions of the specification. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 30 of 171 Category Collateral Submitter Collier Issue ID 85 Issue Primer on message construction Description A primer on how the message is constructed gets my vote. Especially, if it addresses how the security features are incorporated. It might be quite a job though, as it should include the BP, CPP/A, and MSH teams. Origin email Date of Origin 8/7/2001 Reference Subject: RE: T2: ackRequested attribute in Via element _______________________________________________________________ Page 31 of 171 Category Intermediaries Submitter Issue ID 11 Issue Third-party security services Description Use of third-party security services (this is a special case of an intermediary). Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 32 of 171 Category Intermediaries Submitter Issue ID 42 Issue Guaranteed Delivery Description In the BPSS, guaranteed delivery is stated as requiring third-party guarantees of delivery and nothing is said about reliable messaging. - Should the BPSS have some definitions related to use of reliable messaging between each role and the third party? - Do we need something in the CPP-CPA to cover third-party-based guarantees? - The BPSS has no definitions about reliable messaging between two parties. Is any thing needed or is this a matter only for CPP-CPA and messaging service? Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 33 of 171 Category Intermediaries Submitter Issue ID 23 Issue Intermediaries and Multihop Scenarios Description Use of intermediaries may need to be accounted for in the CPA. Intermediaries include trading services of various kinds. The use of a proxy outside a Party's firewall is a specific case of an intermediary. Are there cases where an intermediary has to understand the value of the CPAId element in the message header? Reliable messaging through an intermediary might be a CPA matter. The following discussion is from the Sept. 6 2001 teleconference minutes: Marty told us that the multiparty case involves major issues about which party is privy to what information; what state has to be tracked by who, etc. He said that while BPSS has some provision for multiparty collaboration, it really just amounts to a set of binary collaborations. In his opinion, we should steer clear of multipart collaborations until we have more immediate issues under control - meanwhile we can get away with sets of binary collaborations. Dale pointed out that the ebXML POC showed multiparty collaboration, but all CPPA properties pertained to end-to-end interaction, which Marty characterized as a case of passive store and forward intermediaries. Dale suggested that if an intermediary's role is important to a business process, that should be captured via BPSS. Arvola mentioned the CPAId in the Messaging header. One can also specify a CPA between the sender and (the first) intermediary, probably using the Messaging specification's via element, which Arvola thinks has its own Service and Action elements [it does]. Dale suspects a gap between BPSS and intermediary provisions in MSH. Brian will work with David Burdett on that. One point of view was expressed that if Party A says to send to a 3rd party and Party B does send it there, that's sufficient - Party B has fulfilled its obligation under a CPPA. Another case occurs when Party A can only send to an intermediary such as Commerce One, but has an obligation (under a CPA) to send it to the ultimate recipient. Dale expressed the view that the whole area of "interconnects" is out of scope for version 1.1 - we don't even provide for VANs as transports. Although VANs showed up in tpaML, Marty advised that it was merely as a placeholder. Page 34 of 171 Origin 'Possible New Work' Document [Also see email re Draft of Requirements for Intermediary Support for Date of Origin discussion - Aug 1, 2001 ff, and minutes of Sept. 6 teleconference] Reference _______________________________________________________________ Page 35 of 171 Category Intermediaries Submitter Sachs Issue ID 86 Issue Designation of mutually trusted third party Description One of the scenarios I was wondering about was an intermediary that functions as a mutually-trusted party that adds signed timestamps to messages. So if A sends a message to B through this IM, B receives a message that contains the original message from A, plus a time value, signed by the IM, so that B can later prove (provide evidence) that the message was generated before time T and that B received it after time T. This scenario has IM signing something that might have already been signed by A, i.e. nested signing, which is not at all uncommon in cryptologic protocols, but which doesn't seem to be something contemplated by the existing Message Service spec. So I suppose this is a scenario that we do not propose to deal with. But one of the interesting things about it is that the fact that the messages need to be timestamped by a mutually-trusted third party, and the question of who we mutually trust, are really parts of a business agreement and would therefore logically belong in the actual CPA. But just because someone can invent a scenario does not mean that supporting it is a requirement! The real question is what use cases are actually required. Origin email Date of Origin 8/14/2001 Reference Subject: Re: T2 - Assertions and Questions _______________________________________________________________ Page 36 of 171 Category Messaging Submitter Issue ID 42 Issue Guaranteed Delivery Description In the BPSS, guaranteed delivery is stated as requiring third-party guarantees of delivery and nothing is said about reliable messaging. - Should the BPSS have some definitions related to use of reliable messaging between each role and the third party? - Do we need something in the CPP-CPA to cover third-party-based guarantees? - The BPSS has no definitions about reliable messaging between two parties. Is any thing needed or is this a matter only for CPP-CPA and messaging service? Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 37 of 171 Category Messaging Submitter Issue ID 22 Issue Alternative message services Description The specification tries to make it clear that a user of a CPP or CPA may use an alternative message service such as SOAP or XML Protocol. However, the specification does not prescribe a formal way to add the alternative messaging service. The user must revise the schema or DTD to eliminate the ebXMLBinding element and add whatever new element is needed. For this approach, we need to change the cardinality of ebXMLBinding to (0 or 1). Other possibilities: - Add an extensibility element to be used when introducing an alternative messaging service. - Provide xxxBinding elements for commonly used messaging services. SOAP 1.1 and XML Protocol (when available). All these "supported" elements would be defined as part of an enumeration (1 out of the list would be required). Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 38 of 171 Category Messaging Submitter Issue ID 69 Issue Payload Compression: Description Should the CPP and CPA support payload compression? This element would indicate whether the sending party is sending compressed payload and what the compression algorithm is. It could be: ú Once for each party's set of business transactions ú Once per message definition. ú Interaction between compression and encryption (at a minimum, compression must precede encryption since encryption reduces compressibility. ú Compression of part vs. the whole message. See also email from Arvola Chan on 21 Aug 2001 re Transport level compression and followups. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 39 of 171 Category Messaging Submitter Issue ID 47 Issue Normative Appendix on Use of the CPA with the ebXML Message Service Description This appendix is an outstanding item from Ver. 1.0. There are ambiguities in the Message Service Specification that result from treating the CPA as optional. Therefore, the CPP-CPA specification has to define exactly how various elements in the message header are to be used with a CPA. This item should be joint work with the MSG team. Some examples: ú Possible clarification of the role of the Service and Action elements in the header. ú How the RefToMessageId element is to be used in application-level request and response messages (see "Routing of Response Messages" below). ú Clarification of some of the Reliable Messaging issues pointed out by Arvola Chan (see "Reliable Messaging Consistency" below). ú List and discussion of all elements in the message header that relate to the CPA. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 40 of 171 Category Messaging Submitter Issue ID 132 Issue Is MSH the endpoint for Nonrepudiation of receipt? Description Marty feels there is confusion about whether or not the MSH is the endpoint for NRR functionality. That impacts where NRR information belongs in a CPP/A. Origin call Date of Origin 8/6/2001 Reference _______________________________________________________________ Category Messaging Submitter Issue ID 49 Issue PersistDuration Description There is some ambiguity in the Message Service specification as to whether this is internal to each party or something that has to be agreed upon. Discussions with the MSG team are needed Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 41 of 171 Category Messaging Submitter Issue ID 50 Issue Delivery failure negotiation Description Delivery failure notification is internal to each party. However, if the MSG team retains the optionality of delivery failure notification, this team should consider whether to include an element or attribute in the CPA that states whether the parties agree to require guaranteed delivery failure notification. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 42 of 171 Category Messaging Submitter Issue ID 51 Issue Timeout for delivery failure notification Description A party needs to know how long to wait for successful delivery or a delivery failure notification. The maximum waiting time is a bit longer than the maximum time for retries. Because RetryInterval may be shorter or longer than the internal timeout that the Message Service Handler uses for deciding whether to retry, some discussion with the MSG team is needed on how to determine the maximum time and whether anything is needed in the CPP or CPA. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 43 of 171 Category Messaging Submitter Issue ID 54 Issue RefToMessageId element in Message Header Description The following requires some definition work with the MSG team. There is no explicit statement in the Message Service spec about the use of the RefToMessageId element in messages other than message service to message service control messages. Use in application-level messages is valuable and will not interfere with the currently defined use and the necessary words should be added. ú In an application-level response message, the RefToMessageId element should contain the ID of the message that the message is responding to. This is necessary to disambiguate the case described in "Routing of Response Messages" above. ú At the same time, words should be added which allow the RefToMessageId to be used in an application-level request message. This would, for example, allowing a message requesting a compensation action to point to the message being compensated. ú It may be necessary to add an indicator somewhere in the message header that the message is a response to a prior application-level message. This indicator would be supplied by the sending application and would enable the receiving system to recognize that the message is a response and the RefToMessageId element should be used as part of the information that routes the message to the appropriate software entry point. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 44 of 171 Category Messaging Submitter Ferris Issue ID 80 Issue Advertise use of of NTP, XNTP etc. in CPP Description >> mshTimeAccuracy >> >>>This is the accuracy to which a recipient of a message claims to keep their internal >> system clocks. This should probably be part of a CPP and not vary from message to message >> therefore it does not need to be in the MessageHeader >> [David Fischer] Agreed, but what if there is no CPP? I'm not sure why this is necessary. Chris Ferris>It isn't represented in the CPP, nor should it be. I have repeatedly expressed my >belief that this is unnecessary at best, and more likely unimplementable in any event [1]. >If anything, I could see parties agreeing to a requirement that their respective >system's system clock be synchronized using something like NTP or some similar >service and having this reflected in some manner within the CPP/A, but not mshTimeAccuracy! >I for one would like to see this removed from the 1.1 specification. I agree with Chris that the use of NTP to synchronize clocks at a distance is something that is suitable for a CPA and that the use of NTP or XNTP or whatever could be advertized in a CPP. I also agree that putting the mshTimeAccuracy in the MessageHeader is definitely excess baggage! Should be removed. Page 45 of 171 Origin email Date of Origin 8/1/2001 Reference (via Dale M) Subject: msh TimeAccuracy RE: T2 Reliable Messaging w/o CPA or VIA... _______________________________________________________________ Category Messaging Submitter Chan Issue ID 78 Issue Relationship between Acknowledgement, DeliveryReceipt,and BPSS Business Signals Description According to the Messaging Service spec, the Acknowledgement element is an optional element that is used by one MHS to indicate to another MHS that it has received a message (to support the implementation of reliable messaging). The DeliveryReceipt element is defined as an optional element that is used by the To Party who received a message to let the From Party who sent the original message know that the message was received. Origin email Date of Origin 7/22/2001 Reference Subject: Relationship between Acknowledgement, DeliveryReceipt,and BPSS Business Signals _______________________________________________________________ Page 46 of 171 Category Messaging Submitter Chan Issue ID 87 Issue RosettaNet Retry Parameter not Expressible in BPSS or CPP/A Description Existing RosettaNet PIPs do not require exactly once delivery semantics. Asynchronous PIPs have a Retry parameter that governs how many additional retries a sender will send a message, if it has not received a Receipt Acknowledgement signal from the other party. Currently, BPSS does not allow for the specification of a retry count. At the CPP/A level, the only available retry parameter is associated with reliable messaging. It is not clear if RosettaNet should always use reliable messaging for all PIPs. Ideally, the DocExchange element should carry an alternate Retry element that is not tied to reliable messaging. Otherwise, it will be great fi extension mechanisms whereby namespace qualified extension elements/attributes can be added. This is an approach that is used both in SOAP and in the Message Service to provide extensibility. Origin email Date of Origin 8/23/2001 Reference Subject: RosettaNet Retry Parameter not Expressible in BPSS or CPP/A _______________________________________________________________ Page 47 of 171 Category Messaging Submitter Chan Issue ID 88 Issue Piggybacking of signals on application level messages via packaging Description From response by Dale Moberg: We intended to handle the specification of the agreement on how piggybacking was to be done via packaging. This has not yet occurred. Here are some issues needing resolution on the way to getting this done: 1. When we have signalsAndResponse true, and syncResponse true, then the packaging should describe how the signal and Response (payload) are arranged in a SOAP with attachments package. 2. When we have signalsOnly, we need to be able to indicate that there are in effect two communication channels used in responding. The signal will be returned on the requesting connection as a HTTP reply. The payload (business response) needs a URL to specify the endpoint that it is returned to. At the moment, we do not have enough apparatus available to express these facts. In addition, two different packaging formats need to be available to reflect the message containing the signal and the one containing the business response. Origin Page 48 of 171 Reference Subject: One issue pertaining to Arvola response to Marty to Hima on v1question4 _______________________________________________________________ Category Messaging Submitter Chan Issue ID 89 Issue Linkage of SimplePart element to BusinessDocument at the BPSS level Description One or more business signals, along with a business response can be carried in the same ebXML message in the synchronous reply mode. I suspect that each of the above has to be treated as one attachment to the SOAP message with attachments. The CPP/CPA has a Packaging element that is supposed to describe the constituents of a payload and its security packaging. However, the SimplePart element in the CPP/A currently does not seem to have any linkage to a BusinessDocument at the BPSS level I think this is an alignment issue among the MSG, CPP/A, and eBTWG workgroups. Origin email Date of Origin 8/29/2001 Reference Subject: Re: "Primary Business Document" _______________________________________________________________ Page 49 of 171 Category Messaging Submitter Chan Issue ID 90 Issue T2 Non repudiation and MSG, CPP/A, BPSS spec alignment Description The BPSS spec says that nonRepudiationOfReceipt (NRR) is tied to the ReceiptAcknowledgement signal. NRR and reliable messaging are orthogonal. A business process may specify the non repudiation of receipt for the requesting business activity business message and/or the repudiation of receipt for the responding business activity business message, without requiring that reliable messaging be used. I think the Messaging Service should not tie NRR to the DeliveryReceipt element if the latter is used exclusively in reliable messaging. The MSH is not responsible for validating the syntax of payloads. NRR at the MSH level does not really implement NRR as called for by the business process specification. NRR at the BPSS level includes syntax validation on the payloads. Receipt Acknowledgement business signals have to be persisted in order to satisfy legal requirements implied by NRR. I just don't see the utility of persisting the DeliveryReceipt generated at the MSH level in addition to the ReceiptAcknowledgement signal. This may just be unnecessary overhead. Currently, NRR parameters are tied to the DeliveryChannel element in the CPP/A. According to Marty, these parameters may have to be relocated / added to the ProcessSpecification and/or the Role element in order to properly model the non repudiation requirements associated with the business process. Page 50 of 171 email Originemail I strongly feel that non repudation is one area that the MSG, CPP/A, heir 1.1 specifications. Date of Origin 8/30/2001 Reference Subject: T2 Non repudiation and MSG, CPP/A, BPSS spec alignment _______________________________________________________________ Page 51 of 171 Category Messaging Submitter Chan Issue ID 126 Issue SMTP Delivery Status Notification and Message Disposition Notification Description The following is an excerpt from section 2.4.3.3 in the RNIF 2.0 Core Specification: Email-based message transfer is a store-forward-based message delivery mechanism and the SMTP messages need not be sent directly between the source and the eventual recipient's SMTP nodes (due to SMTP routing involved). Hence, trading partners cannot rely on any synchronous transport level errors (analogous to HTTP response/error codes) being returned. Therefore, trading partners MUST have a mechanism in place to handle undeliverable email messages sent to each other. Delivered messages with content problems SHOULD, however, result in the recipient sending separate RosettaNet Exception business signals. If desired, trading partners could use the SMTP Delivery Status Notification (DSN) mechanism (see RFC 1891) to request that the recipient notify the sender of SMTP message delivery status. Partners could also use the SMTP Message Disposition Notification (MDN) mechanism as needed. These are part of the standard SMTP message delivery mechanism / standard and can be used by trading partners as needed and feasible, based on their SMTP set-ups. RosettaNet does not provide any explicit specification in this respect. Should the use of DSN and MDN be specifiable as part of the SMTP protocol? Origin email Date of Origin 8/23/2001 Reference Subject: SMTP Delivery Status Notification and Message Disposition Notification(RFC 1891 and RFC 2298) _______________________________________________________________ Page 52 of 171 Page 53 of 171 Category Messaging Submitter Chan Issue ID 75 Issue Clarification of syncReplyMode Attribute Description Line 1171 in the 1.0 CPPA spec talks about four possible values for the syncReplyMode attribute: signalsOnly, responseOnly, signalsAndResponse, and none. Line 1178 is confusing. I think it should say "the sending application expects in a response" rather than "the receiving application expects in a response". The explanation of signalsOnly is not clear. Depending on the definition of the business transaction (i.e., whether there is a responding activity), the sending application may still expect a business response message separately. This response message in turn will trigger a business level acknowledgement that may or may not be returned synchronously. The meaning of responseOnly is also unclear. Does it mean that no business signals should be sent at all or are they only to be sent separately and asynchronously? What if non-repudiation of receipt is required? In the case of signalsAndResponse, I suppose the multiple business level messages have to be packaged into a single message at the MHS level as multiple MIME body parts. I don't think this point is clearly stated. Also, if the responder returns the business signals and business response synchronously, how is the initiator expected to send its business level receipt acknowledgement? Will that have to be sent asynchronously? The RosettaNet Implementation Framework 2.0 supports synchronous response but makes a number of simplifying assumptions. For a one-action PIP, the responder can return a signal or not at all. For a two-action PIP, the responder can return a business response but no business signal. Thus, there is no non-repudiation of receipt for the request action from the responder. It is also assumed that the initiator is not required to return a receipt acknowledgement for the response action. Therefore, there is no non-repudiation of receipt of the response action from the initiator either. In other words, synchronous response mode can only be used for certain PIPs that Page 54 of 171 don't require response or non-repudiation of receipt. The ebXML message is more flexible to allow signal(s) and response to be packaged into the same message, so it may be unnecessary to impose any of the above simplifying assumptions. Still, it is useful Origin email tion of receipt Date of Origin 7/26/2001 Reference Subject: Clarification of syncReplyMode Attribute See also Subject: <1.0 bug> syncReplyMode attribute values are not clearly explainedA - Aug 21 2001 _______________________________________________________________ Page 55 of 171 Category Messaging Submitter Chan Issue ID 83 Issue Are signals meaningful in case syncReplyMode is not set to none? Description Whether response for a business process is to be returned synchronously is specified in the CPA rather than in the business process specification itself. This may lead to inconsistent specifications that can be rather meaningless. Consider the case of a business process that calls for the use of both receipt acknowledgement and acceptance acknowledgement for the request activity. Let's say their corresponding timeouts are 5 minutes and 10 minutes, and the time to perform is 30 minutes. Now suppose the CPA specifies syncReplyMode = signalsAndResponse, does it mean that both the signals and the response have to be returned within 5 minutes? If not, isn't the requesting party supposed to consider the transaction null and void due to not getting the receipt acknowledgement in time? If the purpose of the receipt acknowledgement is to indicate that the request message has passed the intelligible check, and the purpose of the acceptance acknowledgement is to indicate that the request message has passed additional business rules validation, there isn't much of a point to return these signals along with the response synchronously (being packaged into the same ebXML message). The fact that the response is returned implies that both forms of validation have passed. Batching these signals with the response essentially make them redundant and worthless. Among RosettaNet PIPs, 2A9 (Query Electronic Components Technical Information) is the only one that allows both synchronous and asynchronous response. In the case of synchronous response, time to perform is 5 minutes. For asynchronous response, time to perform is 24 hours. It does not seem possible to model PIP 2A9 using BPSS and CPP/A as a single business process specification. Only a single time to perform can be specified at the BPSS level. There is no mechanism at the CPP/A level to override the time to perform parameter. In fact, I think it will be useful if time to acknowledge receipt, time to acknowledge acceptance, and time to perform for a business process specification can all be overridden at the CPP/A level to suit the performance requirements between the two trading partners. Page 56 of 171 Origin email Date of Origin 8/2/2001 Reference Subject: Are signals meaningful in case syncReplyMode is not set to none? _______________________________________________________________ Category Messaging Submitter Chan Issue ID 84 Issue ackRequested attribute in Via element (of MSH) and QOS Description To be distilled from the cited email thread. Origin email Date of Origin 8/7/2001 Reference (reply to David Burdett forwarded by Marty Sachs) Subject: Re: T2: ackRequested attribute in Via element _______________________________________________________________ Page 57 of 171 Category Messaging Submitter Chan Issue ID 48 Issue Possible need for TimeAccuracy and TimeToLive Description Arvola Chan (posting of 7/15/01) reported a number of problems with the Reliable Messaging definition in the Message Service Specification. Fixing some of these may require coordination between the CPPA and MSG teams. For example, he questioned whether TimeAccuracy and TimeToLive should be added to the CPA. Items discussed at the July 24-25 meeting: ú TimeToLive is intended to be on an individual message basis; hence it is not an agreement matter. If it is necessary to specify it per message type or business transaction, it may have to be specified in the Process Specification document with an override in the CPA Characteristics element. ú MSHTimerAccuracy. This appears to be an internal matter at each party. We need to discuss this with the MSG team. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 58 of 171 Category Messaging Submitter Chan Issue ID 118 Issue Problem with Non Repudiation over a Synchronous Delivery Channel Description The CertificateRef under NonRepudiation is presumably the certificate used by the sender for signing. What happens if syncReplyMode is set to something other than None? In that case, the receiver (responder) has to deliver the response document over the same channel. Where is the CertificateRef for signing by the responder? Origin email Date of Origin 8/21/2001 Reference Subject: Does CPA support SSL mutual authentication? _______________________________________________________________ Page 59 of 171 Category Messaging Submitter Chan Issue ID 77 Issue Idempotency attribute Description This concept is not mentioned any where in the Messaging Service spec. In order to implement the OnceAndOnlyOnce delivery semantics, the MSH already performs duplicate detection and filtering. It is not clear how the idempotency test applied at the document exchange layer (described on line 1575) differs from the duplicate detection and handling described in Section 10.3 in the Messaging Service spec. Is the document exchange layer part of the MSH? What is the meaning of deliverySemantics=OnceAndOnlyOnce and idempotency=false? Origin email Date of Origin 7/26/2001 Reference Subject: Idempotency attribute (Section 7.6.4.2, line 1569) _______________________________________________________________ Page 60 of 171 Category Messaging Submitter Sachs Issue ID 133 Issue Clarify MSH, Middleware, and their relationship Description Marty wants to make sure that we distinguish between the formal definition of MSH [editorial: which is not entirely clear] and related middleware. Dale believes a crucial issue is how much work the MSH does when generating NRR. For example, invoking an XML parser extends its scope from an architectural point of view. In the case of NRR for RosettaNet, MSH alone is not sufficient; cooperation of another middleware component is needed -- maybe we should undertake to specify division of labor in this area. Arvola observed that our specification is currently tied to BPSS. Marty elaborated that we have links for BPSS instance documents and roles, along with a set of security attributes to override information in a BPSS instance, but we say little about those attributes in terms of what functionality must be where. . Returning to syntax checking as part of receipt acknowledgement, it was mentioned that the MSH could provide a plug in. This again raises questions about the scope of MSH and division of labor among middleware components. Someone (Engkee?) asked if the Interoperability committee might address such matters. Origin call Date of Origin 8/6/2001 Reference _______________________________________________________________ Page 61 of 171 Category Messaging Submitter Sachs Issue ID 93 Issue Clarity of text re NRR / Delivery Channel and/or separate send delivery channel Description NRR is expressed in the CPA by the NonRepudiation element under ebXMLBinding in the delivery channel. The delivery channel describes a Party's receive properties. Nonrepudiation requires action by both parties. However signing is done by the From Party. So having it NRR in the delivery channel (receive properties) is a bit peculiar. The points that I don't think I made previously are these: Although NonRepudiation is in the delivery channel (receive properties), the certificate which must be referenced is for signing the message. This certificate belongs to the From party, not the To party. If we leave NonRepudiation where it is, the text must make it clear that the certificate is one belonging to the other party, not the party that owns this delivery channel. Because the certificate belongs to the other party, the certificate reference is meaningless in the CPP. The text should state that the certificate referenced in the CPP must be replaced by a reference to the other party's certificate when the CPA is composed. A better solution is to provide "send" delivery channels along with the Origin email Date of Origin 9/6/2001 Reference Subject: Nonrepudiation of receipt in CPA Page 62 of 171 ________ Category Messaging Submitter Sachs Issue ID 131 hannels though this is probably out of scope for V1.1. Issue MSH timeout Description . We do not define the actual timeout that the MSH uses to determine when to retry. That timeout could be longer or shorter than RetryInterval. We also do not say whether RetryInterval is measured from the sending of the message or the expiration of the MSH timeout. I recommend defining the MSH timeout and adding it to the CPA. . Origin email Date of Origin 8/12/2001 Reference Subject: RE: T2 Clarify TimeToLive _______________________________________________________________ Page 63 of 171 Category Messaging Submitter Sachs Issue ID 130 Issue Routing ambiguity when two different BPSS instance documents are used at once Description Details to be distilled from cited email thread. Origin email Date of Origin 8/12/2001 Reference Subject: RE: T2 The answer isn't always "you need a CPA" _______________________________________________________________ Page 64 of 171 Category Messaging Submitter Sachs Issue ID 135 Issue Technical report on interoperability across Messaging, BPSS and CPPA specs Description We might want to consider a technical report on interoperability across the Messaging, BPSS and CPPA specifications. Dale agreed with the idea and felt that someone needs to draft it, but wasn't sure who. Origin call Date of Origin 8/6/2001 Reference _______________________________________________________________ Page 65 of 171 Category Messaging Submitter Moberg Issue ID 91 Issue Delivery Receipt, NRR and MSG/CPPA/BPSS (mis-)alignment and thelayering mishmash Description Details to be distilled. See the thread starting with the cited Origin email Date of Origin 8/31/2001 Reference Subject: Delivery Receipt, NRR and MSG/CPPA/BPSS (mis-)alignment and thelayering mishmash (was jumbled into: reliable messaging - hop by hop) _______________________________________________________________ Page 66 of 171 Category Messaging Submitter Collier Issue ID 95 Issue Lack of processing rules Description The TRP document addresses wire format only. Given the complex nature of composing a message that adequately reflects both security and reliability in addition to the correct business process data, there is a good deal of the processing of a business message through the MSH to the SOAP process that is left as an exercise for the reader. While the TRP specification makes a recommendation on how signatures should be applied to a Message Envelope, there are still areas of overlap between the SOAP envelope and the ebXML envelope that probably need further definition. As is mentioned in Section 12.1 item 7, there is no defined line of communication to the MSH from the SOAP layer. There are several areas in which the specification of the sequence of processing of a message would be helpful. Origin ebXML Technical Architecture Risk Assessment v1.0 Date of Origin Reference _______________________________________________________________ Page 67 of 171 Category Middleware Submitter Issue ID 74 Issue Business Service Interface Description Business Service Interface (BSI) design may be outside our scope, but statement of BSI requirements may be in. see also email re "Suggestions from Karsten Riemenr" - June 25 ff Origin Scottsdale F2F Date of Origin Reference _______________________________________________________________ Page 68 of 171 Category Middleware Submitter Issue ID 66 Issue Interaction between configuration inside a Party and the CPA Description In general, configuration matters are internal to each party and should not appear in the CPA. However there may be CPA implications, especially if internal configuration information overrides fields in the CPA. If that can happen, it needs to be documented in the CPA specification. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 69 of 171 Category Middleware Submitter Issue ID 16 Issue Middleware interoperability Description úUpper interface of Message Service úInterface between middleware and bridge to legacy applications úAnything else to support interoperability aspects of CPA and middleware? úReliable messaging delivery failure notification may be an issue that involves the interfaces within the middleware/ Probably this should be joint work among CPPA, MSG, and BP teams. Perhaps some new OASIS team should be created to lead this work. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 70 of 171 Category Middleware Submitter Issue ID 132 Issue Is MSH the endpoint for Nonrepudiation of receipt? Description Marty feels there is confusion about whether or not the MSH is the endpoint for NRR functionality. That impacts where NRR information belongs in a CPP/A. Origin call Date of Origin 8/6/2001 Reference _______________________________________________________________ Page 71 of 171 Category Middleware Submitter Sachs Issue ID 133 Issue Clarify MSH, Middleware, and their relationship Description Marty wants to make sure that we distinguish between the formal definition of MSH [editorial: which is not entirely clear] and related middleware. Dale believes a crucial issue is how much work the MSH does when generating NRR. For example, invoking an XML parser extends its scope from an architectural point of view. In the case of NRR for RosettaNet, MSH alone is not sufficient; cooperation of another middleware component is needed -- maybe we should undertake to specify division of labor in this area. Arvola observed that our specification is currently tied to BPSS. Marty elaborated that we have links for BPSS instance documents and roles, along with a set of security attributes to override information in a BPSS instance, but we say little about those attributes in terms of what functionality must be where. . Returning to syntax checking as part of receipt acknowledgement, it was mentioned that the MSH could provide a plug in. This again raises questions about the scope of MSH and division of labor among middleware components. Someone (Engkee?) asked if the Interoperability committee might address such matters. Origin call Date of Origin 8/6/2001 Reference _______________________________________________________________ Page 72 of 171 Category Miscellaneous Submitter Issue ID 24 Issue TPA reference element Description It has been proposed to add an optional element to the CPA that provides a reference to an associated "traditional" contract or TPA. This should be able to be either a text string or the URI of an electronic (e.g. XML) representation of the contract or TPA. It should be stated this element is for information only; its presence or absence is independent of whether a contract does or does not exist. It will be necessary to consider the relation of this element to the isLegallyBinding attribute in the Process Specification document. (See listserver discussion June 26-27, 2001). Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 73 of 171 Category Miscellaneous Submitter Issue ID 70 Issue Include higher-level abstractions in the CPA Description There has been a suggestion to extend the CPA to include higher level abstractions like service information and contractual obligations. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 74 of 171 Category Miscellaneous Submitter Issue ID 59 Issue Publishing Party capabilities with a CPA template instead of a CPP Description There was discussion on the list server Feb. 6-8 about use of CPA Templates in place of CPPs. This would simplify things for a small business so that it doesn't have to go through the whole CPP and composition process when all he needs to do is fill in a few items in a CPA prepared large business. The words in the spec are sufficiently permissive to allow the possibility of the use of CPA Templates but one could make it more explicit Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 75 of 171 Category Miscellaneous Submitter Issue ID 67 Issue Multiparty CPAs Description Extension of the CPA to more than two parties could be considered. Some (but not all) issues are: ú Enforceability across more than two parties. ú Namespace scope ú Business signals ú Conversation state tracking across more than two parties: does each party need to know about interactions between the others? How can this be accomplished? Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 76 of 171 Category Miscellaneous Submitter Issue ID 53 Issue Ambiguity re Routing of Response Messages to the Correct Software Entry Point Description ú There appears to be an ambiguity for the following case. The ambiguity should be confirmed or refuted and, if it is ambiguous, either fix the ambiguity or put in a statement that this is not a valid case. The case boils down to the same party playing both roles in the same business transaction. " Each Party to the CPA includes two CollaborationRole elements that point to the same Process-specification document. In one CollaborationRole element, Party A has the role "seller" (for example) and Party B has the role "buyer". In the other CollaborationRole element, Party B has the role "seller" and party A has the role "buyer". " The same combination of binary collaboration and business transaction is performed in both of the above cases (i.e. the two Parties can switch roles). " Both CollaborationRole elements specify delivery channels with the same transport address (e.g. URL). " The message service cannot tell whether an arriving message is a request or a response message. It can only route based on transport address, service, action, and role. If the same delivery channel (same transport address) is used with both CollaborationRole elements, the messaging service cannot tell whether to route the message to Party A as "seller" (the first CollaborationRole element) or to Party B as "seller" (the second CollaborationRole element). " Use of ConversationId and CPAId in routing may resolve the ambiguity. In addition, we could make use of the RefToMessageId element in the message header as part of the routing information. See the "RefToMessageId" below. Origin 'Possible New Work' Document Date of Origin Reference Page 77 of 171________ Category Miscellaneous Submitter Chan Issue ID 127 Issue Specializations of generic business messages for specific partners Description The schema of a business document may contain certain optional fields. However, two trading partners may specifically require some of these optional fields be always present in their exhanged messages. Should this be specifiable through the CPP/A? Origin email Date of Origin 8/23/2001 Reference Subject: Potential 2.0 requirement _______________________________________________________________ Page 78 of 171 Category Miscellaneous Submitter Weida Issue ID 121 Issue Business rules and constraints Description Capture business constraints and rules that specify context-dependent validation of a B2BI system's runtime behavior (for both profiles and agreements). See cited reference for more details. Origin Scottsdale F2F Date of Origin Reference http://www.oasis-open.org/committees/ebxml-cppa/meetings/business_rul es_and_constraints.ppt _______________________________________________________________ Page 79 of 171 Category Miscellaneous Submitter Hayes Issue ID 140 Issue invocationLimit attribute appears to be a CPA Lifetime attribute Description CPA Lifetime and Conversation Constraints: The invocationLimit attribute appears to be a CPA Lifetime attribute and not a conversation constraint. Origin email Date of Origin 9/27/2001 Reference Subject: CPPA Version 1.0 Comments And Issues _______________________________________________________________ Page 80 of 171 Category Miscellaneous Submitter Hayes Issue ID 143 Issue Adding a ccpid element to the CollaborationProtocolProfile. Description CPP Structure: Recommend adding a ccpid element to the CollaborationProtocolProfile. This would be used to uniquely identify the CPP and will be useful when a business has more than one CPP. I also recommend that we provide a recommendation (even a non-normative one ) on the format of the identifier. See the BPINS scheme in [bpWS]. Origin email Date of Origin 9/27/2001 Reference Subject: CPPA Version 1.0 Comments And Issues _______________________________________________________________ Page 81 of 171 Category Miscellaneous Submitter Hayes Issue ID 144 Issue CPP Categories Description Recommend that there be an optional way of categorizing CPPs. Perhaps this implemented by registries; however, I much prefer there could be a category element as part of the CollaborationProtocolProfile. It should be possible to specify one or more categories. The category should be a URI and a recommend categorization scheme would be TBD (the values might have semantics of MRO goods, direct goods, aerospace, etc. Interesting enough, the categories could possibly be used as part of the Core Components Context).Putting the category information into the CPP is preferred over the registry approach since the registry (or a sophisticated registry) is not required for use of CPPs. Origin email Date of Origin 9/27/2001 Reference Subject: CPPA Version 1.0 Comments And Issues _______________________________________________________________ Page 82 of 171 Category Miscellaneous Submitter Hayes Issue ID 145 Issue CPA Categories Description Recommend CPA Categories. See comment regarding CPP Categories (ISSUE 144). Origin email Date of Origin 9/27/2001 Reference Subject: CPPA Version 1.0 Comments And Issues _______________________________________________________________ Category Negotiation Submitter Issue ID 12 Issue Negotiation of CPA contents Description The negotiation team is currently elaborating on this general issue. Marty Sachs suggested that we defer inclusion of specific negotiation issues in this database for now. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 83 of 171 Category Negotiation Submitter Issue ID 57 Issue PartyId type Description It has been suggested that a negotiation of PartyId type may be desirable since a given Party may not be capable of interpreting all possible PartyId types. One possibility is to add an element by which a Party can indicate which PartyId types it understands. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Category Negotiation Submitter Issue ID 13 Issue Negotiation of Business-level parameters Description This issue is a general placeholder to be elaborated on some time in the future. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 84 of 171 Category Packaging Submitter Issue ID 5 Issue Packaging Description Improvements to packaging definition including security capabilities. Specific problems related to XMLDSIG have been noted (Dale Moberg 5/3/01) See also email re: S/MIME, Dale Moberg, August 16, 2001 ff Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 85 of 171 Category Packaging Submitter Issue ID 36 Issue Virtual Packaging Description Enhance notation to capture the "virtual packaging" used by XMLDsig external references. Origin 'CPA-CPP Changes to Consider' document Date of Origin Reference _______________________________________________________________ Page 86 of 171 Category Packaging Submitter Chan Issue ID 89 Issue Linkage of SimplePart element to BusinessDocument at the BPSS level Description One or more business signals, along with a business response can be carried in the same ebXML message in the synchronous reply mode. I suspect that each of the above has to be treated as one attachment to the SOAP message with attachments. The CPP/CPA has a Packaging element that is supposed to describe the constituents of a payload and its security packaging. However, the SimplePart element in the CPP/A currently does not seem to have any linkage to a BusinessDocument at the BPSS level I think this is an alignment issue among the MSG, CPP/A, and eBTWG workgroups. Origin email Date of Origin 8/29/2001 Reference Subject: Re: "Primary Business Document" _______________________________________________________________ Page 87 of 171 Category Packaging Submitter Moberg Issue ID 35 Issue Grammars for packaging Description Investigate using "grammars" to provide more compact means of expressing packaging parsing and generative capabilities. Origin 'CPA-CPP Changes to Consider' document Date of Origin Reference _______________________________________________________________ Category Packaging Submitter Hayes Issue ID 152 Issue Need for packageId attribute if there is only one Package per CPP/CPA Description xxx Origin email Date of Origin 9/27/2001 Reference Subject: CPPA Version 1.0 Comments And Issues _______________________________________________________________ Page 88 of 171 Category Security Submitter Issue ID 10 Issue Security attributes under Characteristics element Description Define security attributes under the Characteristics element in enough detail to understand what has to be specified in doc exchange and transport to support them and enable a tool to check for consistency between Characteristics and the details in DocExchange and Transport. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 89 of 171 Category Security Submitter Issue ID 9 Issue Certificates Description Replace ds:keyinfo element by a definition that does not embed the actual ceritficate in the CPP or CPA. From Security Issues 01-08-26.doc (via Tim Collier): Depending on how it is used, the ds:keyinfo element can contain an actual base-64-encoded certificate. Except for signing of the CPP or CPA, there is no need for actual certificates to be embedded in the CPP or CPA. The Certificate element should be changed to point to information at a key-management service instead. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 90 of 171 Category Security Submitter Issue ID 8 Issue Signing of payload and header Description Signing of payload and header vs. signing only of payload and response. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Category Security Submitter Issue ID 7 Issue Nonrepudiation of receipt Description Specification of nonrepudiation of receipt. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 91 of 171 Category Security Submitter Issue ID 6 Issue NonRepudiation element improvements Description Nonrepudiation improvements including possible addition of other elements that reflect choices that can be made (Transform?). A possibility is that this element could take the form of a Signature "template" which effectively provides the entire requisite binding information including reference URI(s) with only the Digest and actual signature omitted. This would be similar to the way we now define the signature. See listserver discussion 6/13-01 - 6/14/01. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 92 of 171 Category Security Submitter Issue ID 5 Issue Packaging Description Improvements to packaging definition including security capabilities. Specific problems related to XMLDSIG have been noted (Dale Moberg 5/3/01) See also email re: S/MIME, Dale Moberg, August 16, 2001 ff Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 93 of 171 Category Security Submitter Issue ID 58 Issue Digests of Other External Documents Description If other external documents, such as security profiles, are introduced, the possibility of creating digests of those document, similar to what is specified for the Process Specification document should be considered in order to detect alterations. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Category Security Submitter Issue ID 4 Issue Public-Key Infrastructure Description Public-Key Infrastructure issues. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 94 of 171 Category Security Submitter Issue ID 3 Issue Security policy element Description We should consider a Security policy element. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Category Security Submitter Issue ID 11 Issue Third-party security services Description Use of third-party security services (this is a special case of an intermediary). Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 95 of 171 Category Security Submitter Issue ID 2 Issue Security profile Description Security profile developed by the ebXML security team. From the Technical Architecture Risk Assessment technical report: This element would advertise the set of security mechanisms a party understands, the profiles for those mechanisms, and the trust anchors that will be issuing the credentials used within that policy. The policies can be asymmetric, allowing separate identification of what it can accept from what it will, itself, generate. For example, a party might accept SSL-protected messages, but will itself, only generate [XMLDSIG] signed acknowledgements. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 96 of 171 Category Security Submitter Issue ID 1 Issue Technical Architecture Risk Assessment Description Technical Architecture Risk Assessment technical report recommendations related to CPP/CPA. (Note: some items below may duplicate material in that report.) Origin 'Possible New Work' Document Date of Origin Reference http://www.ebxml.org/specs/ebTA.pdf _______________________________________________________________ Page 97 of 171 Category Security Submitter Issue ID 40 Issue BPSS isNonrepudiationRequired attribute and CPPA Nonrepudiation element Description The BPSS defines this attribute as requiring the message sender to save an audit trail. It has no signing semantics. The isTamperProof attribute controls signing of the business document. isTamperProof may be needed in the CPP-CPA Characteristics element. The CPP-CPA Nonrepudiation element is defined as covering signing and "prevents later nonrepudiation". Perhaps the definition should be expanded to explicitly cover the rule about audit trail that is stated in the BPSS Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 98 of 171 Category Security Submitter Issue ID 41 Issue Nonrepudiation of business signals Description Does the CPP-CPA need definitions in the delivery channel, in addition to listing the attributes in the Characteristics element, that support nonrepudiation of origin and receipt? Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 99 of 171 Category Security Submitter Chan Issue ID 117 Issue Clarify and detail support of SSL mutual authentication Description took a look at the Communication Protocol Bindings section (Appendix B) in the Message Service Spec. Lines 2843 to 2845 state: "Both [RFC2246] and [SSL3] require the use of server side digital certificates. In addition client side certificate based authentication is also permitted. ebXML Message Service handlers MUST support hierarchical and peer-to-peer trust models." Therefore, I think the CPP/A 1.1 spec needs to be fixed to support mutual authentication. In addition, lines 2823 to 2828 in the Message Service spec state: "Implementers MAY protect their ebXML Message Service Handlers from unauthorized access through the use of an access control mechanism. The HTTP access authentication process described in "HTTP Authentication: Basic and Digest Access Authentication" [RFC2617] defines the access control mechanisms allowed to protect an ebXM L Message Service Handler from unauthorized access. Implementers MAY support all of the access control schemes defined in [RFC2617] however they MUST support the Basic Authentication mechanism, as described in section 2, when Access Control is used." More changes to the CPP/A spec will be necessary to support Basic Authentication. However, I seriously doubt if basic authentication which sends user name and password in cleartext is suitable for conducting E business transactions. Perhaps we should lobby the MSG TC to remove the Page 100 of 171 Origin email .1 spec. Date of Origin 8/21/2001 Reference See separate email threads started by Arvola Chan on 21 Aug 2001 regarding "Does CPA support SSL mutual authentication?" and on 23 Aug 2001 "Re: SSL Mutual Authentication and the Message Service Spec". Also thread by Dale Moberg re "Transport related authentication in CPA (was SSL Mutual Authenticationand the Message Service Spec)" on 29 Aug 2001. _______________________________________________________________ Page 101 of 171 Category Security Submitter Chan Issue ID 124 Issue Possible addition of CipherSuites element under TransportSecurity Description Section B.2.7 in the Message Service spec states: ebXML Message Service Handlers MAY use any of the allowable encryption algorithms and key sizes specified within [RFC2246]. At a minimum ebXML Message Service Handlers MUST support the key sizes and algorithms necessary for backward compatibility with [SSL3].The following cipher suites are defined in [RFC2246]: [ . see cited email for complete list . ] Do we have to add a CipherSuites element to the TransportSecurity element to indicate the cipher suites that are supported by the destination party? [See cited email for detailed list of suites] Origin email Date of Origin 8/23/2001 Reference Subject: Encryption Algorithms and Key Sizes for Transport Level Security _______________________________________________________________ Page 102 of 171 Category Security Submitter Chan Issue ID 90 Issue T2 Non repudiation and MSG, CPP/A, BPSS spec alignment Description The BPSS spec says that nonRepudiationOfReceipt (NRR) is tied to the ReceiptAcknowledgement signal. NRR and reliable messaging are orthogonal. A business process may specify the non repudiation of receipt for the requesting business activity business message and/or the repudiation of receipt for the responding business activity business message, without requiring that reliable messaging be used. I think the Messaging Service should not tie NRR to the DeliveryReceipt element if the latter is used exclusively in reliable messaging. The MSH is not responsible for validating the syntax of payloads. NRR at the MSH level does not really implement NRR as called for by the business process specification. NRR at the BPSS level includes syntax validation on the payloads. Receipt Acknowledgement business signals have to be persisted in order to satisfy legal requirements implied by NRR. I just don't see the utility of persisting the DeliveryReceipt generated at the MSH level in addition to the ReceiptAcknowledgement signal. This may just be unnecessary overhead. Currently, NRR parameters are tied to the DeliveryChannel element in the CPP/A. According to Marty, these parameters may have to be relocated / added to the ProcessSpecification and/or the Role element in order to properly model the non repudiation requirements associated with the business process. Page 103 of 171 email Originemail I strongly feel that non repudation is one area that the MSG, CPP/A, heir 1.1 specifications. Date of Origin 8/30/2001 Reference Subject: T2 Non repudiation and MSG, CPP/A, BPSS spec alignment _______________________________________________________________ Page 104 of 171 Category Security Submitter Chan Issue ID 104 Issue Nonrepudiation archival Description Don't non repudiation of origin and non repudiation of receipt imply that the recipient has to keep a persistent copy of the message for some rather long period of time (typically of the order of years)? Is this duration implicit (i.e., has the same value for all cases) or should it be represented explicitly in the CPA? Another related question is whether the logging functionality to support non repudiation belongs above or below the Message Service Interface. Origin email Date of Origin 8/16/2001 Reference Subject: Non Repudiation _______________________________________________________________ Page 105 of 171 Category Security Submitter Chan Issue ID 113 Issue Clarification of NamespaceSupported element advertising in CPP Description From response by Dale M. on 20 Aug 2001: . .. because adding namespaces is one way that XML infosets are extended, interoperability can be expected to involve support for namespaces that are used, either in the header or in the payload. Is this obscure? We can certainly add some more text to clarify that the point of a CPP is to advertise capabilities with the view of promoting interoperability. . From Tim C.'s Security Issues 01-08-26.doc: Yes. Perhaps an example omitting XMLDsig and using SMIME encryption would have been more useful. In addition, when a namespace URI for XML encryption emerges, we can add that to the list if it is to be used even though it is not a part of MS G spec now. Finally, the constituent specs are to be modular and possibly independent. What is required by MSG is not necessarily required by CPPA. So what can be a default because it is part of MSG would be OK if we agree to make all features of MSG the default for CPPA. That has not been proposed as yet, and it may tend to conflict with the intent to have each spec remain modular and independent. Origin email Date of Origin Reference Subject: What is the purpose of the NamespaceSupported element? _______________________________________________________________ Page 106 of 171 Category Security Submitter Chan Issue ID 123 Issue Indicate use of basic authentication Description Request from Arvola Chan, with the following response from Dale Moberg: OK, I could see that we could add a detail under TransportSecurity element, even if MSG decides to drop discussion of any HTTP auth. mechanism. Is there a standardized way of referring to different HTTP auth mechanisms that we could reuse (like a URI, OID or whatever...)? Origin email Date of Origin 8/28/2001 Reference Subject: Re: SSL Mutual Authentication and the Message Service Spec _______________________________________________________________ Page 107 of 171 Category Security Submitter Chan Issue ID 118 Issue Problem with Non Repudiation over a Synchronous Delivery Channel Description The CertificateRef under NonRepudiation is presumably the certificate used by the sender for signing. What happens if syncReplyMode is set to something other than None? In that case, the receiver (responder) has to deliver the response document over the same channel. Where is the CertificateRef for signing by the responder? Origin email Date of Origin 8/21/2001 Reference Subject: Does CPA support SSL mutual authentication? _______________________________________________________________ Page 108 of 171 Category Security Submitter Mukkamala Issue ID 29 Issue Signed delivery receipt Description Hima, I have added a comments to the first question below. We can follow up tomorrow if time permits. Dale Hima wrote: "1) How could you request a Delivery Receipt signed/unsigned using CPA as the governing document for messaging" DWM>> I assume we are talking about Delivery Receipts within the ebxml Oasis MSG specification, and not any other flavor. The MSG spec now has both Acknowledg(e)ments (primarily used for support of RM) and Delivery Receipts, which are apparently classified as business level messages.(!) Moreover, the Delivery Receipts appear to be quite similar to Acknowledgements, and Acknowledgements can include a Reference and hash of the original message. I hope that usage and distinctions pertaining to all these "signals" or messages can be one item we get clear on at the joint meeting. I believe that in v1.0, some information about Delivery Receipts is found under the ../DocExchange/ebXMLBinding/nonRepudiation path, when the CollaborationRole is for the Response side of a conversation. Other information is under ../DeliveryChannel/Characteristics/[@='nonRepudiationOfReceipt'], a boolean that tells us that the conversation is making use of nonRepudiationOfReceipt and with ebXML bindings, which means to do it "the" MSG way, we know we need to return a Delivery Receipt, I think. Now, since there is an Ack. with some receipt like characteristics and a DeliveryReceipt with receipt like characteristics, which is to Page 109 of 171 be used. I think this is one thing we have to straighten out. We might disambiguate by means of something in Packaging that indicates whether the SOAP Header is an Ack or DR. Anyway, I think we need to nail this down by 1.1. There was a lot of seemingly minor adjustments in MSG at the 1.0 level and I am not certain that we tracked them all. We also need to investigate whether to remove the scope barriers to capturing interop info about signals. And how to indicate MSH to MSH layer traffic and how to indicate APP to APP traffic... 3 SOAP-SEC extensions and signatures in ebXML messages Given that an ebXML message is carried within a SOAP message, there are currently two ways of signing messages. This may cause some confusion or runtime failures due to misinterpretation. There has been a note posted to the W3C, which identifies one possible set of processing instructions for signing SOAP messages. Below are some "similarities and differences" that may help people wade through the notations. In addition, there is a good reminder in the concluding section of the XMLDSIG note about digital signature not itself preventing replay attacks. The "no-dupes" of reliable messaging can be used to address this type of attack. 1. SOAP-SEC[SOAP-SEC] uses its own namespace and has a schema that wraps around the XMLDSIG namespace, unlike the ebXML example. 2. SOAP-SEC and ebXML Digital Signatures both have the signature under the SOAP-ENV:Header. 3. The SOAP-SEC schema allows just one signature 4. SOAP-SEC uses the SOAP-ENV:actor and SOAP-ENV:mustUnderstand elements, whereas the ebXML example does not. 5. The actual W3C XMLDSIG machinery is shared. Of course, the ebXML example illustrates using an XPATH transform to cut out the TraceHeaderList (though the S1 value for the id attribute doesn't point to anything in the ebxml example) 6. The ebXML-Sig Reference [ebMS] mechanism uses cid: style URIs, but these are also acceptable in SOAP-SEC (section 3.2). 7. SOAP-SEC uses the soap protocol conventions of the mustUnderstand and actor constructs. It is not certain whether this is an advantage Page 110 of 171 Date of Origin 8/22/2001 Reference Subject: 1.0 Questions _______________________________________________________________ or just overhead. It might be a disadvantage if SOAP processing and ebXML MSH processing are "walled-off". In that case, no defined lines of communication to the MSH from the SOAP layer exist so that MSH won't have access to the outcomes of checking. In general, it is difficult to assess the impact on implementations, but using SOAP-SEC within ebXML would tend to promote writing a SOAP processing layer Page 111 of 171 Category Security Submitter Sachs Issue ID 93 Issue Clarity of text re NRR / Delivery Channel and/or separate send delivery channel Description NRR is expressed in the CPA by the NonRepudiation element under ebXMLBinding in the delivery channel. The delivery channel describes a Party's receive properties. Nonrepudiation requires action by both parties. However signing is done by the From Party. So having it NRR in the delivery channel (receive properties) is a bit peculiar. The points that I don't think I made previously are these: Although NonRepudiation is in the delivery channel (receive properties), the certificate which must be referenced is for signing the message. This certificate belongs to the From party, not the To party. If we leave NonRepudiation where it is, the text must make it clear that the certificate is one belonging to the other party, not the party that owns this delivery channel. Because the certificate belongs to the other party, the certificate reference is meaningless in the CPP. The text should state that the certificate referenced in the CPP must be replaced by a reference to the other party's certificate when the CPA is composed. A better solution is to provide "send" delivery channels along with the Origin email Date of Origin 9/6/2001 Reference Subject: Nonrepudiation of receipt in CPA Page 112 of 171 ________ Category Security Submitter Moberg Issue ID 91 hannels though this is probably out of scope for V1.1. Issue Delivery Receipt, NRR and MSG/CPPA/BPSS (mis-)alignment and thelayering mishmash Description Details to be distilled. See the thread starting with the cited Origin email Date of Origin 8/31/2001 Reference Subject: Delivery Receipt, NRR and MSG/CPPA/BPSS (mis-)alignment and thelayering mishmash (was jumbled into: reliable messaging - hop by hop) _______________________________________________________________ Page 113 of 171 Category Security Submitter Moberg Issue ID 122 Issue Generalized credential container Description Possibly we could use an xlink/xpointer/URI to within the CPA to reference a generalized credential container if there is a need to establish links between CPAs and credentials. (This credential container would be something like the pkcs12 container used for keypairs; I haven't yet encountered an XML credential store container format that has been proposed, though.) Origin email Date of Origin 8/28/2001 Reference Subject: RE: SSL Mutual Authentication and the Message Service Spec _______________________________________________________________ Page 114 of 171 Category Security Submitter Collier Issue ID 94 Issue Signature Method Element Description In the 1.0 CPPA spec (lines 3116 to 3118), we have the following declarations: <element name="HashFunction" type="string"/> <element name="EncryptionAlgorithm" type="string"/> <element name="SignatureAlgorithm" type="string"/> On the other hand, the April 19, 2001 W3C Candidate Recommendation of XML-Signature shows: <element name="SignatureMethod" type="ds:SignatureMethodType"/> <complexType name="SignatureMethodType" mixed="true"> <sequence> <element name="HMACOutputLength" minOccurs="0" type="ds:HMACOutputLengthType"/> <any namespace="##other" minOccurs="0" maxOccurs="unbounded"/> <!-- (0,unbounded) elements from (1,1) external namespace --> </sequence> <attribute name="Algorithm" type="anyURI" use="required"/> </complexType> This means that the SignatureMethod element in XML-Signature may have an optional HMACOutputLength sub-element plus 0 or more wildcard elements from other namespaces. Shouldn't SignatureAlgorithm be defined in the CPPA spec accordingly? Likewise, I think it may be useful to allow wildcard attributes/sub-elements in the declaration of HashFunction and EncryptionAlgorithm to provide for the specification of properties like encryption strength. In addition, the following sentence on lines 874-876 does not seem to make sense: "As an alternative to the string value of the ds:DigestMethod, shown in the above example, the child element, ds:HMACOutputLength, with a string value, MAY be used." Page 115 of 171 It does not correspond to the example on lines 811-814 (which in itself seems erroneous, the HMACOutputLength should be a number, not a string) or to the schema definition of ds:DigestMethod in XML-Signature: <element name="DigestMethod" type="ds:DigestMethodType"/> <complexType name="DigestMethodType" mixed="true"> <sequence> <any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </sequence> <attribute name="Algorithm" type="anyURI" use="required"/> </complexType> According to the above definition, any sub-element under DigestMethod would have to come from some other namespace! Origin Security Issues 01-08-26.doc Date of Origin Reference _______________________________________________________________ Page 116 of 171 Category Security Submitter Collier Issue ID 96 Issue Key Management Description Key management is a major issue that needs to be addressed with respect to the capabilities of the TR& P Message Service Handler. In particular, if the MSH will be called upon to apply digital signatures, the appropriate private keys must be available to the MSH. Private keys must be managed very carefully and deliberately. Thus, some configuration will be necessary to establish the key management mechanisms to be used by the MSH. Origin ebXML Technical Architecture Risk Assessment v1.0 Date of Origin Reference _______________________________________________________________ Page 117 of 171 Category Security Submitter Collier Issue ID 99 Issue Signing Message Parts Description To address the secure packaging part of the Transport Routing & Packaging configuration in the CPP, the CPP should also document the packaging of the message header, payload and attachments so that S/MIME or XMLDSIG can be used to protect the appropriate elements of the message. If the packaging is well defined, it will allow the security tags within the CPP to specify the appropriate certificate data (X.509, PGP, etc.) to be applied to securely sign/encrypt the elements of the Message. Origin ebXML Technical Architecture Risk Assessment v1.0 Date of Origin Reference _______________________________________________________________ Page 118 of 171 Category Security Submitter Collier Issue ID 100 Issue Use of Schema: Application to individual elements Description In the current version of the CPP/CPA, the specification of security elements is limited. It is recommended that XML schema be considered to more effectively express security attributes. For example, the security characteristic is a single element that contains attributes with Boolean values indicating whether or not a security attribute has been addressed. It would be useful to have the security characteristics have a type and be able to have a reference id to include on lower elements (like the transport element), which contain the details like the protocol. Origin ebXML Technical Architecture Risk Assessment v1.0 Date of Origin Reference _______________________________________________________________ Page 119 of 171 Category Security Submitter Collier Issue ID 102 Issue Nonrepudiation in the delivery channel vs. the certificate in the role tag. Description Discussion is needed on the function of nonrepudiation in the delivery channel vs. the certificate in the role tag. Chris Ferris' comment on this: I for one believe that it is only useful when signing both header and payload together. Of course, there has also been discussion that the only meaningful NR signature is that where the "application" signs the payload (or header and payload) and the ack. This needs more scrutiny [TW: Tim included this from Marty's "CPPA Changes to Consider" document. Should possibly combine this with "NonRepudation Tags" issue] Origin Security Issues 01-08-26.doc Date of Origin Reference _______________________________________________________________ Page 120 of 171 Category Security Submitter Collier Issue ID 103 Issue non-repudiation of receipt (NRR) at the message level Description [TW: I'm keeping this discussion intact for now to aid clarity; when the constituent issues are actively addressed, they should be split out as suggested below] Note This discussion focuses on message level NRR. Application level responses are out of the scope of this discussion. From a top level (business level) perspective, the most important issue is to determine exactly what parts of the message are subject to NRR. For example, should NRR be applied to the payload items and/or the header? One suggested solution would be to apply NRR to only those parts of the message that were signed by the originator. Another issue concerns how the NRR response should be sent back to the message originator. Should the message be sent back as part of another ebXML message, or should a separate mechanism be used (such as AS1 and/or AS2)? The third and final issue is determining what format the NRR response should take. If it is chosen to use an externally defined transport and format such as AS1 or AS2, then this decision is already made. If, however, ebXML is the chosen transport, it needs to be decided where the NRR response should reside (in the SOAP header, or body, etc.). Additionally, the content of the NRR needs to be decided. It has been proposed within the TRP group that a NRR response should simply be the acknowledgements element which has been signed, but that neglects to include a hash of the parts of the original document for which the NRR is being generated. At a minimum, the hash of the original message parts and a reference to those parts (such as the acknowledgements element) must be signed to supply NRR. As part of the format used, there much be a decision made about what algorithms and transformations will be used to sign the NRR response. Once all of those issues have been decided, there must be some mechanism within the CPP for any optional information (such as the scope of the desired NRR) to be supplied. Origin ebXML Technical Architecture Risk Assessment v1.0 Page 121 of 171 Reference _______________________________________________________________ Category Security Submitter Collier Issue ID 97 Issue Encouragement of selected protocols Description In order to encourage maximum interoperability, the following standard mechanisms are identified and vendors are encouraged to implement them: ú When exchanging identity information, use X.509v3 Certificates that follow the IETF profile (RFC2459 and its successors). [PKIX] ú When symmetric-key encryption is needed, use 3DES or the AES. ú When asymmetric encryption is needed, use RSA encryption with the OAEP encryption scheme and a key size of 1024 or 2048 bits. ú When hashing (or digesting) is needed, use SHA-1. When transport-level security is required, use SSLv3 or TLS with RSA keys and the RC4 (or ARC4) stream cipher. Origin ebXML Technical Architecture Risk Assessment v1.0 Date of Origin Reference _______________________________________________________________ Page 122 of 171 Category Security Submitter Collier Issue ID 34 Issue Policy conditionals for security Description Can we provide a way to determine the appropriate policy to use based on some expressible condition. Like, if the value of the purchase order is over $15,000 then use a digital signature of type "manager". Origin Security Issues 01-08-26.doc Date of Origin Reference _______________________________________________________________ Page 123 of 171 Category Security Submitter Collier Issue ID 33 Issue Minimum requirement for security Description It is currently assumed that the collaboration agreement (CPA) reached between two Trading Partners adequately reflects the ordering and priority of security policies stated in the CPP, but there is no mechanism for establishing minimum security requirements. The current CPP DTD does not allow the tagging of security configuration at a level that indicates what is required, what is optional, or what is preferred. Origin ebXML Technical Architecture Risk Assessment v1.0 Date of Origin Reference _______________________________________________________________ Page 124 of 171 Category Security Submitter Collier Issue ID 31 Issue Trust anchor Description This document proposes that a trust anchor element be created within the CPP and that it be represented as an XML Digital Signature [XMLDSIG] KeyInfo element. It is an endpoint for a set of credentials used by the party. It is important to recognize that a single policy will probably have multiple anchors. For example, a small enterprise might have an SSL certificate from a DNS registrar, yet use PGP [PGP] keys signed by a particular staff member for all purchasing agents. <SecurityPolicy> <TrustAnchors> <!-a set of <ds:KeyInfo> elements. --> <ds:KeyInfo ID='foo'>...</ds:KeyInfo> <ds:KeyInfo ID='bar'>...</ds:KeyInfo> <ds:KeyInfo ID='chumley'>...</ds:KeyInfo> </TrustAnchors> <Profiles> <!-- A set of "Profile" elements. Each profile identifies a profile, and then the anchors used in that profile. --> <Profile ID="pf1" URN="urn" ANCHORS="foo bar"/> </Profiles> <WillUse> <-- A set of profiles the party will use. --> <ProfileRef>pf1</ProfileRef> </WillUse> <WillAccept> <-- A set of profiles the party will accept. --> <ProfileRef>pf1</ProfileRef> </WillAccept> </SecurityPolicy> Origin ebXML Technical Architecture Risk Assessment v1.0 Date of Origin Page 125 of 171 _______________________________________________________________ Page 126 of 171 Category Security Submitter Collier Issue ID 30 Issue SOAP-SEC extensions and signatures in ebXML messages Description Given that an ebXML message is carried within a SOAP message, there are currently two ways of signing messages. This may cause some confusion or runtime failures due to misinterpretation. There has been a note posted to the W3C, which identifies one possible set of processing instructions for signing SOAP messages. Below are some "similarities and differences" that may help people wade through the notations. In addition, there is a good reminder in the concluding section of the XMLDSIG note about digital signature not itself preventing replay attacks. The "no-dupes" of reliable messaging can be used to address this type of attack. 1. SOAP-SEC[SOAP-SEC] uses its own namespace and has a schema that wraps around the XMLDSIG namespace, unlike the ebXML example. 2. SOAP-SEC and ebXML Digital Signatures both have the signature under the SOAP-ENV:Header. 3. The SOAP-SEC schema allows just one signature 4. SOAP-SEC uses the SOAP-ENV:actor and SOAP-ENV:mustUnderstand elements, whereas the ebXML example does not. 5. The actual W3C XMLDSIG machinery is shared. Of course, the ebXML example illustrates using an XPATH transform to cut out the TraceHeaderList (though the S1 value for the id attribute doesn't point to anything in the ebxml example) 6. The ebXML-Sig Reference [ebMS] mechanism uses cid: style URIs, but these are also acceptable in SOAP-SEC (section 3.2). SOAP-SEC uses the soap protocol conventions of the mustUnderstand and actor constructs. It is not certain whether this is an advantage or just overhead. It might be a disadvantage if SOAP processing and ebXML MSH processing are "walled-off". In that case, no defined lines of communication to the MSH from the SOAP layer exist so that MSH won't have access to the outcomes of checking. In general, it is difficult to assess the impact on implementations, but using SOAP-SEC within ebXML would tend to promote writing a SOAP processing layer as part of the MSH to facilitate communication. Page 127 of 171 essment v1.0 Date of Origin Reference _______________________________________________________________ Category Security Submitter Collier Issue ID 28 Issue Nonrepudiation of message parts Description The move to using an underlying SOAP message envelope may require the restructuring of the current CPP definition of the "nonrepudiation" element and its sub elements. The current tag specifies a protocol and hash algorithm but does not adequately express how this can be applied to an ebXML message (either parts or the complete message) to provide evidence that the receiver has adequately verified the receipt of a signed message and replied with a receipt acknowledging the same hash value over the signed message. Origin ebXML Technical Architecture Risk Assessment v1.0 Date of Origin Reference _______________________________________________________________ Page 128 of 171 Category Security Submitter Collier Issue ID 79 Issue NonRepudiation tags Description If two parties agree on complimentary roles within a process specification, and agree on the document properties (in particular signing) don't the nonrepudiation elements in the delivery channel characteristics become superfluous? After all, the parties have agreed on a process specification that includes acknowledgement of receipt, and they have agreed on which documents have signatures attached (in the document exchange). To me NRR sounds like a requirement on the BP, and NRO is a document requirement for digital signature. I have heard that the delivery channel is an implementation convenience, which is ok, but it seems even for that the authenticated tag covers the digital signature requirement. And the implementation already is monitoring the runtime process according to the BPSS. Do you think the nonrepudiation tags in the delivery channel express unique requirements that are not already covered? Origin email Date of Origin 7/31/2001 Reference Subject: Security - question about nonrepudiation _______________________________________________________________ Page 129 of 171 Category Security Submitter Collier Issue ID 32 Issue Public key policies Description See example from Appendix C: Sample Certificate Policy Element Origin ebXML Technical Architecture Risk Assessment v1.0 Date of Origin Reference _______________________________________________________________ Page 130 of 171 Category Security Submitter Clark Issue ID 129 Issue Non-PKI security Description Jamie pointed out that the PKI and Certificate Authority (CA) approach is not the only way; that peer-to-peer and PGP are also good; we may not want to marry ourselves to PKI. Marty mentioned that version 1.0 stops at the point of identifying the certificate and doesn't get into other PKI issues. It was observed that the spec doesn't talk about CA at all. Origin Scottsdale F2F Date of Origin Reference _______________________________________________________________ Page 131 of 171 Category Specification document Submitter Issue ID 64 Issue Title of XSD Appendix Description The title of Appendix D should be "W3C XML Schema Document" or "XSD Schema Document instead of "XML Schema Document". Note that the title of the schema specification is "XML Schema". (Sun submitted these quality-review comments after the version-1 specification was published.) Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 132 of 171 Category Specification document Submitter Issue ID 71 Issue Figures in version 1.0 specification Description The figures should be redrawn with Word's own drawing tool. This may allow better control over the positioning of the figures than is true with the current figures imported from PowerPoint. The positions of the current figures are notoriously unstable with respect to nearby text changes. During the July 24-25 meeting, it was suggested that unchecking "move object with text" would freeze the position of the figure and eliminate the instability. Redrawing the figures with the Word drawing tool should also allow automatically numbered captions to be used instead of the captions currently drawn within the figures. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 133 of 171 Category Specification document Submitter Issue ID 72 Issue Definitions of terms (post Vienna) Description If the post-Vienna disposition of the ebXML specifications renders global documents, such as the ebXML glossary, inoperative, the definitions of terms should be restored to the CPA-CPP specification. The definitions in the TP Requirements document are a starting point but this list will have to be updated. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 134 of 171 Category Specification document Submitter Chan Issue ID 106 Issue Incorrect cross-reference to BPSS element Description Line 952 contains an incorrect reference to the business-partner-role element. ú name attribute of the business-partner-role element. 952 It should be BusinessPartnerRole. Origin email Date of Origin 8/17/2001 Reference Subject: <1.0 bug> Incorrect cross-reference to BPSS element _______________________________________________________________ Page 135 of 171 Category Specification document Submitter Chan Issue ID 76 Issue Minor inconsistency in Section 8 of the CPPA spec Description Section 8.1 shows an example CPA while Section 8.2 describes the element structure. The Packaging and Comment elements shown in Section 8.1 are missing from Section 8.2. To be consistent, Section 8.2 should mention the Packaging and Comment elements and there should be a sub-section on Packaging added to Section 8. There already is a Comment sub-section (8.8). Origin email Date of Origin 7/26/2001 Reference Subject: Minor inconsistency in Section 8 of the CPPA spec _______________________________________________________________ Page 136 of 171 Category Specification document Submitter Chan Issue ID 105 Issue Non Meaningful Example of a Packaging element Description Lines 1712 to 1733 in section 7.7 contains an example of the Packaging element. The example is not meaningful because the attributes are not given meaningful values. In particular, the mimetype attribute in the Composite element has the value "type". This is not consistent with the statement on line 1792 that "this will be some MIME composite type, such as "multipart/related" or "multipart/signed". The mimetype "type" is also not a meaningful illustration of the Encapsulation element. I recommend substituting this example with the example on lines 1058-1074 from http://www.ebxml.org/specs/secRISK.pdf Origin email Date of Origin 8/16/2001 Reference Subject: Non Meaningful Example of a Packaging element _______________________________________________________________ Page 137 of 171 Category Specification document Submitter Chan Issue ID 112 Issue All examples that refer to tp:version="0.98b" should be updated. Description Issue says it all. Origin email Date of Origin 8/20/2001 Reference Subject: <1.0 bug> References to tp:version 0.98b _______________________________________________________________ Page 138 of 171 Category Specification document Submitter Chan Issue ID 125 Issue Spelling of NonRepudiation element Description The spelling for the NonRepudiation element is not consistent with the spellings for the nonrepudiationOfOrigin and nonrepudiationOfReceipt attributes. I recommend that the latter be changed to nonRepudiationOfOrigin and nonRepudiationOfReceipt. Origin email Date of Origin 8/23/2001 Reference Subject: Minor spelling inconsistency _______________________________________________________________ Page 139 of 171 Category Specification document Submitter Chan Issue ID 109 Issue Appendix D is out of date Description Appendix D needs to be replaced with the contents of cpp-cpa-v1_0.xsd and including the bug fixes I have reported in an earlier post. The default namespace has to be set to http://www.w3c.org/2000/10/XMLSchema. Otherwise, the element names like Element and Attribute would have to be qualified with the above namespace. The clause xmlns = "http://www.w3.org/2000/10/XMLSchema" is present in cpp-cpa-v1_0.xsd but is missing from Appendix D. Origin email Date of Origin 8/17/2001 Reference Subject: <1.0 bug> Appendix D is out of date _______________________________________________________________ Page 140 of 171 Category Specification document Submitter Chan Issue ID 110 Issue Appendix D: Retries, RetryInterval, and PersistDuration Description In order to conform to the W3C Recommended version of XMLSchema, the following changes should be made to Appendix D: - Retries should be of type integer, not string. - RetryInterval should be of type Duration, not string. - PersistDuration should be of type Duration, not timeDuration. In addition, the example in section 7.6.4 should be changed accordingly: - The RetryInterval example should not assume the unit is second. - The PersistDuration example should look like PT30S. (The P designator must always be present; the T designator must be present if any time item is present.) Origin email Date of Origin 8/20/2001 Reference Subject: <1.0 bug> Retries, RetryInterval, and PersistDuration _______________________________________________________________ Page 141 of 171 Category Specification document Submitter Chan Issue ID 107 Issue Inconsistent spelling of uriReference Description It is "anyURI" now in any event;-) Cheers, Chris > Arvola Chan wrote: > > The example on lines 650 and 651 (section 7.5.1) uses uriReference. This is consistent with all > other examples with the exception of the one on line 694 (section 7.5.2.3) which uses > uri-reference. > > -Arvola > Origin email Date of Origin 8/17/2001 Reference (reply by Chris Ferris) Subject: Re: <1.0 bug> Inconsistent spelling of uriReference _______________________________________________________________ Page 142 of 171 Category Specification document Submitter Sachs Issue ID 92 Issue Dependency on ebXML Requirements spec. Description I suggest not referring to the ebXML Requirements Specification. It is not clear to me that ebRS will continue to be updated by a global requirements team or that the individual new teams will keep it updated in another way. Important requirements-type matters should be spelled out in the MSG specification. Origin email Date of Origin 9/2/2001 Reference Subject: ebXML Requirements spec. _______________________________________________________________ Page 143 of 171 Category Specification document Submitter Wang Issue ID 82 Issue SimplePart and NamespaceSupported elements Description Section 7.7.3 SimplePart element should probabaly be numbered as 7.7.2.1 and its title should be "NamespaceSupported element". (Section 7.7.2 already discusses SimplePart element.) NamespaceSupported should in this context be a child of SimplePart, and this should be straightened out for the v 1.1 specification. Origin email Date of Origin 8/2/2001 Reference (forwarded by Arvola Chan) Subject: Fw: renumber and retitle of section 7.7.3 _______________________________________________________________ Page 144 of 171 Category Specification document Submitter Hayes Issue ID 149 Issue Explicitly identify/discuss ds:URI and ds:Digest elements (of ds:Reference) Description The ds:URI and ds:Digest elements (of ds:Reference) should be explicitly identified and discussed. Origin email Date of Origin 9/27/2001 Reference Subject: CPPA Version 1.0 Comments And Issues _______________________________________________________________ Page 145 of 171 Category Specification document Submitter Hayes Issue ID 142 Issue Remove or elaborate on description of process specification modification Description If the process specification is digitally signed, there should be no issue with this. I think the sentence should be struck from the document or the use case needs to be elaborated further (e.g. state that the CPA information along with the new process specification is exchanged between the two parties until agreement is reached). Origin email Date of Origin 9/27/2001 Reference Subject: CPPA Version 1.0 Comments And Issues _______________________________________________________________ Page 146 of 171 Category Tools Submitter Issue ID 14 Issue CPP and CPA tools Description This topic consists of non-normative discussion of the CPP and CPA tools as an addition to the CPA-composition discussion in appendix F of the Ver. 1.0 CPP-CPA specification. Tools include CPP composition tool, CPA composition tool and CPA installation tool. The result of this work might be a technical report. This might also be viewed as part of the Negotiation work item. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 147 of 171 Category Tools Submitter Issue ID 21 Issue Consistency of timeouts and installation tools Description The CPP-CPA-BPSS installation tools will have to check the consistency of the relative values of the timeouts at the three levels (business signals, business transaction, and binary collaboration. Some rules are already present in the BPSS spec. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 148 of 171 Category Tools Submitter Issue ID 52 Issue Clarity re Routing of Response Messages to the Correct Software Entry Point Description The specification should be reviewed for clarity in the definitions that determine how to route a reply message to the correct software entry point at the recipient of the reply message. Can the installation tools handle these definitions? In most cases it should be sufficient to route the message by using the Service and Action elements in the message header combined with which role the party receiving the message plays. The following should be checked for accuracy and clarity: 7.55 Role element, 7.5.5.1 name attribute, 7.5.7 Service element, and 7.5.8.1 action attribute. See below regarding the RefToMessageId element in the message header. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 149 of 171 Category Tools Submitter Mukkamala Issue ID 136 Issue Use the (only) digest algorithm mentioned in the XML DSig specification Description Change from http://www.w3.org/2000/09/xmldsig#dsa-sha1 to http://www.w3.org/2000/09/xmldsig#sha1 Origin email Date of Origin 9/18/2001 Reference Subject: Reference element in page 23 of CPP/A Spec _______________________________________________________________ Page 150 of 171 Category Tools Submitter Hayes Issue ID 150 Issue CPP/CPA Worksheets Proposal Description The ebXML Business Process Project Team developed a worksheet (form) based approach to business process analysis and modeling. This is documented in the ebXML Business Process Analysis Worksheets and Guidelines [bpWS] technical report. It struck me that the CPP and CPA are largely business documents even though they contain technical content (e.g. protocols) and have a technical representation (XML). Given the business-level nature of the CPP and CPA, it seems that there should be atleast one approach to providing CPP and CPA information that is low-end, low-tech, and, hopefully, very approachable to a typical business-level user. An approach similar to the bpWS may be ideal for doing this. I am proposing that the OASIS ebXML CPPA technical committee take on the task of developing a set of non-normative worksheets for CPPs and CPAs. See attached document as a suggested starting point for a technical report. As I have mentioned to Dale, I would be happy to give a presentation on this at the upcomming face-to-face and demonstrate how the content of the worksheets can be converted to XML. <<cppaWS-WIP-0.01.zip> Origin email Date of Origin Reference Subject: OASIS ebXML CPP/CPA Worksheets Proposal Page 151 of 171 ________ Category Transport Submitter Issue ID 68 Issue Additional Transport Protocols Description Consider adding support for additional transport protocols such as: ú IIOP ú BEEP (IETF peer to peer protocol) ú EDI value-added networks Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 152 of 171 Category Transport Submitter Issue ID 55 Issue FTP definition Description The FTP definition may need further elaboration. For example do the Parties to a CPA need to agree on: ú Transfer type (binary or character)? ú Password properties? ú Is PUT the correct operation for receiving messages? " Note: In the CPP, the delivery channel specifies RECEIVE properties ú GET as well as PUT? ú Passive mode (yes or no)? ú Control port number for passive mode? ú Anything else with regard to firewalls? ú Anything else? Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 153 of 171 Category Transport Submitter Chan Issue ID 98 Issue Transport compression Description HTTP allows transport level compression through the use of the Content-Encoding entity-header. The permissible compression algorithms include gzip, compress, and deflate. Should the use of transport level compression be specifiable in the CPA when the transport is HTTP? Origin email Date of Origin 8/21/2001 Reference Subject: Transport level compression _______________________________________________________________ Page 154 of 171 Category Transport Submitter Chan Issue ID 81 Issue Overlapping endpoint types Description Section 7.5.14 indicates that a Transport element may have multiple Endpoint elements, each of different types. The question I have is whether these types have to be non-overlapping. Can an Endpoint element of type allPurpose co-exist with another Endpoint element of type Response under the same Transport element? If so, does it mean that a response can be sent to either Endpoint? Origin email Date of Origin 8/1/2001 Reference Subject: Endpoint question _______________________________________________________________ Page 155 of 171 Category XML Submitter Issue ID 56 Issue PartyId definition and example Description Both examples of PartyId in ver. 1.0 have the type attribute included although according to the text, all the information is in the value of the attribute. We need to formulate an example in which the type attribute is essential. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 156 of 171 Category XML Submitter Issue ID 57 Issue PartyId type Description It has been suggested that a negotiation of PartyId type may be desirable since a given Party may not be capable of interpreting all possible PartyId types. One possibility is to add an element by which a Party can indicate which PartyId types it understands. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Category XML Submitter Issue ID 65 Issue Namespace Definitions Description Does the change to OASIS affect any of the namespace definitions? Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 157 of 171 Category XML Submitter Issue ID 63 Issue "generated by XML Authority" in DTD Description It is inappropriate to include the line "generated by XML Authority" in a normative DTD. (Sun submitted these quality-review comments after the version-1 specification was published.) Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Category XML Submitter Chan Issue ID 119 Issue name attribute in ProcessSpecification Description Section 7.5.4.1 (line 836) is not consistent with Appendix D. According to Appendix D, the name attribute should be of type tns: non-empty-string. Origin email Date of Origin 8/21/2001 Reference Subject: <1.0 bug> name attribute in ProcessSpecification _______________________________________________________________ Page 158 of 171 Category XML Submitter Chan Issue ID 114 Issue Protocol element's version attribute should not be FIXED Description Section 7.6.6.1 is incorrect. The version attribute should not be fixed, as it is not consistent with the schema definition in Appendix D. Since the Protocol element is declared at the top level and is used in a number of different contexts, it is also not appropriate to declare Protocol to have a required version attribute either. Somehow, section 7.6.6.1 needs to be rephrased. <element name="Protocol" type="tns:protocol.type"/> <complexType name="protocol.type"> <simpleContent> <extension base="tns:non-empty-string"> <attribute ref="tns:version"/> </extension> </simpleContent> </complexType> Origin email Date of Origin 8/20/2001 Reference Subject: <1.0 bug> Protocol element's version attribute should not be FIXED _______________________________________________________________ Page 159 of 171 Category XML Submitter Chan Issue ID 120 Issue action attribute in section 7.5.8.1and xlink:href attribute in section 7.3.7.4 Description The action attribute should not be equated with the name attribute of the desired BusinessTransaction. There are two activities within a Business Transaction, a RequestingBusinessActivity and a RespondingBusinessActivity. ... Similarly, in section 7.3.7.4 xlink:href attribute, the link should be to the corresponding RequestingBusinessActivity, or to the corresponding RespondingBusinessActivity. Origin email Date of Origin 8/21/2001 Reference Subject: <1.0 bug> action attribute in section 7.5.8.1 _______________________________________________________________ Page 160 of 171 Category XML Submitter Chan Issue ID 116 Issue attributeFormDefault in Appendix D incompatible with examples in Appendix A & B Description In Appendix D, line 2932, attributeFormDefault is set to unqualified, whereas in Appendices A and B, the example CPP and CPA instances all refer to qualified attributes (tp: prefixed). When I attempted to validate the CPA instance in Appendix B against the schema in Appendix D, I got a lot of errors due to lots of required attributes being missing. Most of these errors were fixed when I changed attributeFormDefault in the XSD to qualified. The remaining errors I got when validating Appendix B against Appendix D were due to reference to an undeclared attribute tp:name in element tp:ServiceBinding, and the missing of the tp:Service element under tp:ServiceBinding. This can be fixed by setting the tp:Service element to the value of the tp:name attribute and omitting the tp:name attribute. Origin email Date of Origin 8/20/2001 Reference Subject: <1.0 bug> attributeFormDefault in Appendix D is not compatible withexamples in Appendix A & B _______________________________________________________________ Page 161 of 171 Category XML Submitter Chan Issue ID 115 Issue cpaid is not of type CDATA Description Line 1913 in section 8.2 is inconsistent with the schema definition in Appendix D: cpaid should be of type tns:non-empty-string, not CDATA. Origin email Date of Origin 8/20/2001 Reference Subject: <1.0 bug> cpaid is not of type CDATA _______________________________________________________________ Page 162 of 171 Category XML Submitter Chan Issue ID 110 Issue Appendix D: Retries, RetryInterval, and PersistDuration Description In order to conform to the W3C Recommended version of XMLSchema, the following changes should be made to Appendix D: - Retries should be of type integer, not string. - RetryInterval should be of type Duration, not string. - PersistDuration should be of type Duration, not timeDuration. In addition, the example in section 7.6.4 should be changed accordingly: - The RetryInterval example should not assume the unit is second. - The PersistDuration example should look like PT30S. (The P designator must always be present; the T designator must be present if any time item is present.) Origin email Date of Origin 8/20/2001 Reference Subject: <1.0 bug> Retries, RetryInterval, and PersistDuration _______________________________________________________________ Page 163 of 171 Category XML Submitter Chan Issue ID 109 Issue Appendix D is out of date Description Appendix D needs to be replaced with the contents of cpp-cpa-v1_0.xsd and including the bug fixes I have reported in an earlier post. The default namespace has to be set to http://www.w3c.org/2000/10/XMLSchema. Otherwise, the element names like Element and Attribute would have to be qualified with the above namespace. The clause xmlns = "http://www.w3.org/2000/10/XMLSchema" is present in cpp-cpa-v1_0.xsd but is missing from Appendix D. Origin email Date of Origin 8/17/2001 Reference Subject: <1.0 bug> Appendix D is out of date _______________________________________________________________ Page 164 of 171 Category XML Submitter Chan Issue ID 108 Issue cpp-cpa-v1_0.xsd cannot be read by Internet Explorer 5.0 Description It complains: The XML page cannot be displayed Cannot view XML input using XSL style sheet. Please correct the error and then click the Refresh button, or try again later. --------------------------------------------------------------------- ---------The namespace prefix is not allowed to start with the reserved string "xml". Line 2, Position 72 <schema targetNamespace="http://www.ebxml.org/namespaces/tradePartner" xmlns:xml="http://www.w3.org/XML/1998/namespace" xmlns="http://www.w3.org/2000/10/XMLSchema" xmlns:tns="http://www.ebxml.org/namespaces/tradePartner" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0">------------------------------------------------------- ------- ---------^XML Authority 2.2 (which provides W3C XML Schema Recommendation support) also complainsabout a similar problem. To remove errors flagged by XML Authority, I had to:1. Remove the clause xmlns:xml="http://www.w3.org/XML/1998/namespace"2. Change the line<attribute name="messageOrderSemantics" type="tns:mos.type" use="optional" value="NotGuaranteed"/> to<attribute name="messageOrderSemantics" type="tns:mos.type" use="default" value="NotGuaranteed"/> Origin email Date of Origin 8/17/2001 Page 165 of 171 annot be read by Internet Explorer 5.0 _______________________________________________________________ Category XML Submitter Wang Issue ID 61 Issue Optional messageOrderSemantics attribute with value in XSD Description <attribute name="messageOrderSemantics" type="tns:mos.type" use="optional" value="NotGuaranteed"/> This should be: <attribute name="messageOrderSemantics" type="tns:mos.type" use="default" value="NotGuaranteed"/> Attributes with values specified in the schema must be declared as either default or fixed. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 166 of 171 Category XML Submitter Wang Issue ID 82 Issue SimplePart and NamespaceSupported elements Description Section 7.7.3 SimplePart element should probabaly be numbered as 7.7.2.1 and its title should be "NamespaceSupported element". (Section 7.7.2 already discusses SimplePart element.) NamespaceSupported should in this context be a child of SimplePart, and this should be straightened out for the v 1.1 specification. Origin email Date of Origin 8/2/2001 Reference (forwarded by Arvola Chan) Subject: Fw: renumber and retitle of section 7.7.3 _______________________________________________________________ Page 167 of 171 Category XML Submitter Wang Issue ID 60 Issue XML namespace usage Description You are not allowed to specify a Namespace prefix of "xml". So xmlns:xml="http://www.w3.org/XML/1998/namespace" should be removed. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 168 of 171 Category XML Submitter Collier Issue ID 101 Issue Super schema for CPP + CPA Description In addition, it is entirely feasible to develop a super schema that would combine a description of the CPP with description of the CPA and correlate the relevant components of the two using the key/keyref mechanism of XML schema. This would allow a contract validator to match the correlated components to make sure that the contract is actually met Origin ebXML Technical Architecture Risk Assessment v1.0 Date of Origin Reference _______________________________________________________________ Page 169 of 171 Category XML Submitter Saito Issue ID 62 Issue Errors in CPA example Description Yukinori Saito (5/16 and 5/17/01) pointed out errors and suggesting corrections to the CPA sample regarding incorrect use of ID attribute "N08". This could be corrected and distributed on the CPPA listserver until we issue a maintenance release. Origin 'Possible New Work' Document Date of Origin Reference _______________________________________________________________ Page 170 of 171 Category XML Submitter Hayes Issue ID 146 Issue Format of URI PartyID reference Description This example -- urn:www.example.com - does not follow the same format as the previous example which is:urn:<agency>:<agency-id>Recommend changing example to "urn:icann:example.com." (For those who are not familiar with the ICANN, "the Internet Corporation for Assigned Names and Numbers (ICANN) is the non-profit corporation that was formed to assume responsibility for the IP address space allocation, protocol parameter assignment, domain name system management, and root server system management functions" [http://www.icann.org/general/abouticann.htm].I also wonder if we would be well served to add "pid" or "partyid" to the format. Although, it can be easily argued that you know it is a party id by context. Origin email Date of Origin 9/27/2001 Reference Subject: CPPA Version 1.0 Comments And Issues _______________________________________________________________ Page 171 of 171
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC