[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Sachs [ebxml-cppa-negot] 9/16/2002: Message Contents Comments
Marty, I see your point. I would say that there has to be flexibility to have a unique NDD to differentiate the NDD to a specific CPA ID, particularly more than one NDD can reference it. If we turn that around, if you force another CPA ID, you are requiring more IDs just at the other side. I would say that you encourage the distinctness of the negotiation to the CPA. Not the CPA to the specific negotiation... Thanks. Monica -----Original Message----- From: Martin W Sachs [mailto:mwsachs@us.ibm.com] Sent: Wednesday, September 18, 2002 7:06 AM To: ebxml-cppa-negot@lists.oasis-open.org Subject: Re: [ebxml-cppa-negot] 9/16/2002: Message Contents Comments I would like to elaborate on the following reply of mine in the email below. "MWS: Here, the intent is that the value of the CPA ID can be used as the Negotiation Dialog ID. I don't think that it is really necessary to say whether or not the Negotiation Dialog ID is the same as the CPA ID. This statement is only intended to suggest that an implementation may chose to set the value of Negotiation Dialog ID equal the CPA Id rather than generating a separate Negotiation Dialog ID. In other words CPA ID and Negotiation Dialog ID both SHALL contain values. However, they might or might not contain the same value. It IS intended that CPA ID come from the cpaId attribute in the CPA template." There is an implication (which SHOULD be stated in the spec) in using the CPA ID as the Negotiation Dialogue ID. Please consider these points and reply indicating whether or not you want to allow using the CPA ID as the Negotiation Dialog ID.: If the value of the CPA ID is used as the Negotiation Dialogue ID, there MUST NOT be more than one Negotiation Dialogue in progress involving the same CPA ID at any time. However, the same CPA ID might be used in successive Negotiation Dialogues. The simplest case is where the negotiation fails and a new Negotiation Dialogue must be started after resolving the cause of failure. The new dialogue uses the same CPA template as the previous one. Could there be a reason to refer to the prior Negotiation Dialogue? I don't think so, but the specification should probably forbid referring to another Negotiation Dialogue from within a Negotiation Dialogue. Is the foregoing sufficient to prevent confusion of two different (non-concurrent) Negotiation Dialogues that have the same value of Negotiation Dialogue ID (because they are using the value of CPA ID as the value of Negotiation Dialogue ID)? One might also require that each CPA Template instance must have a unique CPA ID even if that template is in fact an exact copy of a previous one that failed to become an agreed CPA. This rule would prevent the situation described in the above paragraph. It might be simpler to REQUIRE that the Negotiation Dialogue ID NOT have the same value as the CPA ID in the CPA Template. That would avoid stating all the rules discussed above. Perhaps a non-normative note could be added to mention the dangers in using the value of the CPA ID as the value of the Negotiation Dialogue ID. If there are no replies to this posting, I will assume that silence gives consent to require that the Negotiation Dialogue ID MUST be a unique value that is not based on the CPA ID. Regards, Marty ************************************************************************ ************* Martin W. Sachs IBM T. J. Watson Research Center P. O. B. 704 Yorktown Hts, NY 10598 914-784-7287; IBM tie line 863-7287 Notes address: Martin W Sachs/Watson/IBM Internet address: mwsachs @ us.ibm.com ************************************************************************ ************* ----- Forwarded by Martin W Sachs/Watson/IBM on 09/18/2002 08:51 AM ----- Martin W Sachs To: Monica Martin <mmartin@certivo.net> 09/16/2002 10:46 cc: ebxml-cppa-negot@lists.oasis-open.org, Jean Zheng <jzheng@vitria.com>, PM Monica Martin <mmartin@certivo.net> From: Martin W Sachs/Watson/IBM@IBMUS Subject: Re: [ebxml-cppa-negot] 9/16/2002: Message Contents Comments Monica, I have some replies to your comments, labelled MWS: - Unique Business Message ID – uniquely identify the current Business Message within the scope of one negotiation dialog. Is this the MessageID from ebMS? MWS: I suggest NOT using the MessageId from ebMS. We would like to keep the negotiation protocol independent of what messaging service is used underneath. Such a messaging service might not have a usable message ID. So, in my mind, this message ID should be defined at the negotiation protocol level, not at the messaging service level. - Non-leaf node will indicates if? the entire subtree is subject to the corresponding change action. If both Non-leaf node AND its children leaf node are present in Negotiation Content, then the Negotiation Content SHOULD be considered invalid. Jean, these sentences need clarification. MWS: I agree that clarification is needed. Non-leaf node indicates that this node and the whole subtree below this node is subject to negotiation. If a non-leaf node is shown, its children SHALL NOT be shown since that could introduce contradictions. There is an assumption that a non-leaf node cannot be negotiable independent of its descendents. A possible exception is that an attribute of a non-leaf node might be negotiable without intending to allow anything else in that subtree to be negotiable. That can be indicated by showing the XPATH to that attribute. So one might consider the following rules: 1. If the XPATH expression leads to a non-leaf element, that whole subtree is negotiable. 2. If the XPATH expression leads to any attribute, it only means that that attribute is negotiable and doesn't imply anything about the containing element or the rest of the subtree descended from the element containing that attribute. 3. If the XPATH expression leads to a leaf node (element), only that element and its contained attributes are negotiable. Note that the above rules are really NDD rules to which the message definitions will conform. MWS: We need to be careful, in all of these discussions, not to introduce complexity that may get in the way of having a usable version 1 by the end of December. - Negotiation Dialog ID is used to identify a particular negotiation dialog thread. Negotiation Dialog ID can be CPA ID. The value of CPAID could be used as the value for Negotiation Dialog ID. If the CPA ID is used, this should be allowed to be null or the CPA ID element must be null to infer that the CPA ID is used for the Negotiation Dialog ID, correct? MWS: Here, the intent is that the value of the CPA ID can be used as the Negotiation Dialog ID. I don't think that it is really necessary to say whether or not the Negotiation Dialog ID is the same as the CPA ID. This statement is only intended to suggest that an implementation may chose to set the value of Negotiation Dialog ID equal the CPA Id rather than generating a separate Negotiation Dialog ID. In other words CPA ID and Negotiation Dialog ID both SHALL contain values. However, they might or might not contain the same value. It IS intended that CPA ID come from the cpaId attribute in the CPA template. Party A doesn’t need to send anything to Party B at the time of expiration happens. Party A records the current process as “expired”, and when Party B finally sends a reply, if it is anything other than a “reject”, then Party A can send a “reject” back, list the status as “expired”. You may wish to differentiate ‘expired’ from the lack of a response vs. the ‘Expiration Date’ for an accepted negotiated CPA. This could alleviate some confusion. MWS: I agree. - Unable to fulfill Security Requirements - Proposed Security Policy is inadequate Differentiate this item and the one above. MWS: The first bullet may mean that the proposed security requirements are too stringent or that the proposed certificate authority is unacceptable. The second bullet may mean that the proposed security policy is too weak. I agree that clarification is needed. - All elements specified in one’s NDD indicate negotiable items. The elements that are not mentioned in a party’s NDD shall be interpreted as NON-NEGOTIABLE. Given the first ‘offer’ starts the negotiation, should the entire CPA template be provided. That infers you will have negotiable and non-negotiable items. If they are not included, that infers that the trading partners must have a copy of their trading partner agreement to see non-negotiable items for evaluation purposes. How does this affect the business interaction? Would it not be advisable to at least include all items and tag them as negotiable or non-negotiable for the first ‘offer?’ MWS: Yes, the entire CPA template SHALL be provided with the initial offer. The CPA template is really the offer; the NDD indicates what is negotiable in the CPA template. Some of this will become a lot clearer when I distribute a complete draft specification after the open work items get farther along. Regards, Marty ************************************************************************ ************* Martin W. Sachs IBM T. J. Watson Research Center P. O. B. 704 Yorktown Hts, NY 10598 914-784-7287; IBM tie line 863-7287 Notes address: Martin W Sachs/Watson/IBM Internet address: mwsachs @ us.ibm.com ************************************************************************ ************* Monica Martin <mmartin@certivo. To: Martin W Sachs/Watson/IBM@IBMUS, Jean Zheng <jzheng@vitria.com> net> cc: ebxml-cppa-negot@lists.oasis-open.org, Monica Martin <mmartin@certivo.net> Subject: [ebxml-cppa-negot] 9/16/2002: Message Contents Comments 09/16/2002 12:56 PM See a few questions inline in the document attached. Thank you. Monica J. Martin Program Manager Drake Certivo, Inc. 208.585.5946 -----Original Message----- From: Martin W Sachs [mailto:mwsachs@us.ibm.com] Sent: Sunday, September 08, 2002 7:50 PM To: Jean Zheng Cc: ebxml-cppa-negot@lists.oasis-open.org Subject: Re: [ebxml-cppa-negot] message content version 09062002 Jean, I prefer the style of the CPPA specification, element by element in depth-first fashion, with example fragments in the text. Regards, Marty ************************************************************************ ************* Martin W. Sachs IBM T. J. Watson Research Center P. O. B. 704 Yorktown Hts, NY 10598 914-784-7287; IBM tie line 863-7287 Notes address: Martin W Sachs/Watson/IBM Internet address: mwsachs @ us.ibm.com ************************************************************************ ************* "Jean Zheng" <jzheng@vitria.co To: "Martin W Sachs" <mwsachs@us.ibm.com> m> cc: <ebxml-cppa-negot@lists.oasis-open.org> Subject: [ebxml-cppa-negot] message content version 09062002 09/06/2002 07:58 PM Here is the updated Message Content I have promised. I've gone through Marty's discussion with Bob and Monica regarding adding a "change list" to CPA template, and I have included a paragraph in section 1.1 that hopefully has captured your suggestions. Regarding what to include in the negotiation spec. I think we will probably follow the style of CPPA spec, where we have element by element descriptions of each item of message content. Or else, we can start with the current structure of this msg content doc. As we flush out more details, they will grow accordingly. What do you think? I will be working on the schema for the next few weeks. :) Jean #### NegotiationMessageContent.doc has been removed from this note on September 08 2002 by Martin W Sachs ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> **** Attachment NegotiationMessageContent_090602.doc has been removed from this note on 18 September 2002 by Martin W Sachs **** ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC