[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Sachs [ebxml-cppa-negot] 9/18/2002: Message Contents Comments
I understand your premise and the further clarification. It is in line
with my concern, and the suggestion you made seems like a good one to
consider.
Monica
-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Wednesday, September 18, 2002 2:14 PM
To: Monica Martin
Cc: ebxml-cppa-negot@lists.oasis-open.org
Subject: Re: Sachs [ebxml-cppa-negot] 9/16/2002: Message Contents
Comments
Monica,
Let me clarify. There are three entities:
- The CPA Template, identified by CPA ID, the value of the cpaId
attribute
in the CPA template
- The NDD, which may be physically included as an attachment to the
offer
message or referenced in the offer message by its URL
- The Negotiation dialog, the exchange of messages that negotiates a
CPA.
It is identified by negotiationDialogId, which must be unique within the
set of all negotiation dialogues that might be currently in progress
between two Parties. The negotiationDialogId is used like a
conversation
ID but is defined at the negotiation protocol level rather than at the
MSH
level.
In our current design there are exactly one CPA Template and exactly one
NDD associated with each negotiation dialog. My concern about equating
the
negotiationDialogId to the CPA ID was that if there are situations where
the CPA ID can persist after the end of a negotiation dialogue, and the
negotiationDialogId is explicitly given the same value as the CPA ID,
that
could violate the rule about uniqueness of the negotiationDialogId. The
example I gave was where a negotiation fails and the original CPA
template
is reused with the same cpaId for another negotiation. I don't know if
there is any real danger of a problem arising but to me, it seems safest
to
generate the negotiationDialogId independently of the value of the
cpaID.
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,
ebxml-cppa-negot@lists.oasis-open.org
net> cc:
Subject: Sachs [ebxml-cppa-negot] 9/16/2002: Message Contents Comments
09/18/2002 03:34
PM
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>
----------------------------------------------------------------
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