[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-cppa] Analysis of assigned issues 227, 57, &215
I agree that issue 57 is already resolved but not for the reason that Jean stated. It isn't the cardinality of the type attribute that resolves it. It is resolved because multiple PartyId elements are already provided for precisely the purpose indicated in issue 57. See 8.4.1 of version 1.10. It might be worthwhile to add some text in appendix E about the need to negotiate the use of partyId types that both parties understand. Also, regarding issue 57, there is one more potential problem. Today's discussion on the CPPA list indicates a desire by some individuals to include the possibility of privately defined partyId types including simple character strings such as "DUNS". Use of privately defined types would get in the way of automated negotiation since the one party may not understand the other party's type value and the same value might mean different things to different parties. For this case, it would not be sufficient for a party to indicate what types it understands. If we do continue to permit privately defined types, we will need a strong non-normative warning that use of privately defined partyId types might require a phone conversation between tthe two parties to decide what type systems can be used. 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: Dale Moberg <dmoberg@cyclonecommerce.com>, "Cppa (E-mail)" m> <ebxml-cppa@lists.oasis-open.org> cc: 03/21/2002 02:20 Subject: [ebxml-cppa] Analysis of assigned issues 227, 57, &215 PM 227: When a CPA has included "by value" certificates under the KeyInfo elements, and these certificates expire before its CPA expires, we should have a non-normative statement that (deployment of runtime sotfware)software MAY detect the use of an expired certificate and signal a warning or that CPA composition software may also warn of this condition during composition. If the CPA signing certificates expire before the CPA, software SHOULD warn of that condition and suggest aligning the expiration times. (How alignment is attained is implementation dependent.) <Jean> Status shall be "resolved". It has been explained in Section 9.4.2 "End Element" of ebcpp version 1.10.</Jean> 57: 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. <Jean> Status shall be "Resolved". Currently PartyID does have an optional Attr. "Type" (as current discussion thread has indicated) in Section 8.4.1 PartyID Element. So I will vote for "resolved" status of this issue in CPPA. However, we could transfer "Negotiation of PartyId type" part of the issue to the negotiation subteam. Just to keep it under consideration during CPA negotiation.</Jean> 215: Is the name for ProcessSpecification element tied to any element in BPSS instance document? Reopened: as discussed during the Feb 7 call, the spec should state that the name attribute is IMPLIED and characterize its value as informative only <Jean>Status shall be "Open". Section 8.4.4.1 Name Attribute, Currently it states that the name attribute MUST be set to the name for corresponding BPSS instance.</Jean> ---------------------------------------------------------------- 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