[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-cppa-negot] Comments on the negotiation spec draft
Here are my responses to your comments. Except for the following, I will make the change you suggest, unless there is discussion to the contrary this week. Suggested work items: I agree. Let's discuss at the F2F. Line 362: The intent for a virtual NCPA is that there is a default NCPA that the two Parties can use and that each Party could install the default NCPA once and reuse it many times. The idea was that the default NCPA could be defined in the specification, i.e. in Appendix C (and the corresponding text file). The point of this is to provide a default NCPA so that usually, Parties can use it to avoid the need to negotiate the NCPA. Perhaps the paragraph could be replace by one that says something similar to this explanation. Line 366: Issue to be discussed. Line 387: Lines 375-385 have to be discussed as part of the resolution of lines 387-388. The intent of lines 375-387 was to suggest a means of creating a custom NCPA in a way which is simpler than fully negotiating it. Maybe a better idea is to delete lines 375-388 and just rely on the revised lines 360-364. In other words, a pair of parties can either use the default NCPA in the spec or they are on their own to create a custom one. Line 466: Yes, if everyone agrees, we could simply change lines 466-468 to a suggestion. The real question is whether sections 5.3 and 5.4 belongs in the specification at all since they are only suggested items that are not being defined by this specification. Line 545: The question is whether there are other patterns that should be added. If not, I agree to removal of lines 545-546. The first step is to review all the loose end comments and assign work items. Line 571: Yes, this section needs a lot more work. Line 596: Here "the negotiation CPA" is a literary device to call attention to the absurdity of negotiating the negotiation CPA. :-) Line 600: This is part of the general question of what else has to be added to make this section adequate. Line 638: I believe the issue is that the packaging area in the NCPA is not complete. To be discussed. Line 642: The question is whether we can leave out all the loose end comments and still have an implementable specification. I think that the team needs to come to a consensus about each item (OK as is, defer to version 2, complete the work now). Line 669: I hope that someone will accept this task this week. Line 684: I agree. Line 763: See answer to line 642. Line 771: to be discussed. Line 786: Can we defer to version 2 or do we need to do this work? Line 861-862: They are corrections to misspellings of cpaid. Line 868: I agree if no one has a different view. Line 891: I am not sure what this comment refers to. I assume it refers to the preceding paragraph. We have to discuss. Lines 1126, 1130: to be discussed. Lines 1147-1555: Jean, please review these comments. Line 1734: The answer is that the presence of the CPA Signature element is negotiated. This has to be able to be indicated in the NDD. A reference to section 10.8 could be added here. Does the NDD cover this item? 1744-1751: Yes, this is an elaboration of the preceding paragraph. I will review to eliminate unnecessary redundancy. Line 1803: I agree but I am not sure there is a consensus. To be discussed. Lines 1812-2032: Hima has submitted some initial comments on this material. Line 3869: This line is <tp:AcceptedItem, identifying an accepted item that is no longer open. Jean, please comment. Regards, Marty At 12:54 PM 2/24/2003 -0600, Kartha, Neelakantan wrote: >Here are my comments on draft dated Jan 20, 2003. Most of these are my >thoughts on >the questions raised (in bold italics) in the spec. > >It seems to me that the following are the main items remaining to be done. > >1. Checking whether there is sufficient support in the NDD and the messages >to >do what is needed to support the PKI infrastructure (such as adding a new >CA). > >2. Making sure that the messages support the interactions suggested by the >NDD. A way to do this is to take the sample NDD instance document and verify >that all the interactions suggested by it can be carried out using the >messages. > >3. Makind sure that the BPSS support is correct and consistent. This >requires (a) fixing up the diagrams (b) incorporating the end stages of the >negotiation into the BPSS and (c)Rewriting the text accordingly. > >It might be good to assign people to these tasks, so that by the time we >meet in >San Diego, we have had a chance to go over this once. I volunteer for item >2. > >Kartha > >P.S. I have a conflict this Wednesday and will not be able to attend the >conference call. Please post your reactions to this note on the listserv. > > > >-----Original Message----- >From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com] >Sent: Monday, February 24, 2003 9:46 AM >To: ebxml-cppa-negot@lists.oasis-open.org >Subject: [ebxml-cppa-negot] Our next conference call will be Wed. Feb. >26, 3-4:30 pm US Eastern time. > > >Our next conference call will be Wed. Feb. 26, 3-4:30 pm US Eastern >time. > >Agenda: the usual. > >Call-in > >1-866-257-0472 > >International: 720.587.0509 > >Code: *6271676* > >Regards, > >Marty > >---------------------------------------------------------------- >To subscribe or unsubscribe from this elist use the subscription >manager: <http://lists.oasis-open.org/ob/adm.pl> > ************************************************* Martin W. Sachs email: m.w.sachs@post.harvard.edu phone: 203-226-0524 ---------------------------------------------------------------- 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] | [List Home]