[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ebxml-cppa-negot] RE: [ebxml-cppa] Ordering dependencies innegotiation
Yes, the last paragraph is the kind of thing I have in mind. I am going to put this topic in my growing "futures" document. I will also take a quick look at possibilities for a more general dependency graph. 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 ************************************************************************************* "Dale Moberg" <dmoberg@cycloneco To: Martin W Sachs/Watson/IBM@IBMUS mmerce.com> cc: "Cppanegotiation (E-mail)" <ebxml-cppa-negot@lists.oasis-open.org> Subject: RE: [ebxml-cppa] Ordering dependencies in negotiation 09/24/2002 07:18 PM Marty says "Dale's points are valid and we should document the cases of "incomplete but usable" and "incomplete and not usable". However, that is not my concern. The question I am asking is whether some items need to be negotiated in a particular order (i.e. that there are ordering dependencies). The example I gave was that it may not be useful or possible to negotiate about certificates before negotiating about how they are to be used. Given our current rule that negotiable items that have been agreed to shall not be reopened, there may be cases where order of negotiation is significant. If there are ordering dependencies, we will have to invent a way of expressing the dependency graph within the NDD (or put it on the post-v1 list)." I think it would be useless to have certificates for digital signature and then have an agreement that omitted digital signatures. Should we worry about preventing this usefulness by insisting on an order for negotiating items? Maybe so. However,... Would a NDD status of "conditionally negotiable" be one that would help us capture the ordering dependencies? That is, the NDD for TrustAnchors for digital signatures is conditionally negotiable upon having the isNonRepudiationRequired attribute true... Would we need boolean combinations for the antecedents of the conditionals? Dale
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC