[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