OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Issues list


Attached is a revised issues list for use at the F2F.  It was exported from 
Access in text format this time, which unlike RTF export format, has the 
advantage of preserving the complete descriptions :-)

Cheers,
Tony

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

CPPA Issues





          Category  BPSS

         Submitter

          Issue ID  39


             Issue  Link from action attribute to matching business 
transaction

       Description  - Currently, the link from the action attribute 
(Override element) to
                     the matching business transaction in the 
Process-Specification
                    document is the equality of the value of the action 
attribute to the
                    value of the name attribute in the desired 
BusinessTransaction
                    element. Use of an xlink may be better for the 
installation tools.
                    - At the July 24-25 meeting it was suggested that 
Xpointer be
                    considered to define the links.


            Origin  'Possible New Work' Document

    Date of Origin


         Reference

  _______________________________________________________________


















                                            Page 1 of 171



          Category  BPSS

         Submitter


          Issue ID  18

             Issue  BPSS timeToPerform for BusinessTransactionActivity and 
related CPPA
                    parameters

       Description  The BPSS Process Specification document has a 
timeToPerform attribute
                     of the BusinessTransactionActivity element. This is the 
maximum
                    allowed service time for a request, defined separately 
for each
                    business transaction.  However the BPSS does not define 
the number of
                     retries or retry interval. One could add number of 
retries and retry
                     interval to the CPP-CPA but it isn't clear that it 
makes sense
                    without including retries in the BPSS choreography. It 
isn't clear
                    whether the BPSS would have to be extended to cover 
retries or at
                    least to include  attributes that express number of 
retries and retry
                     interval.  If these were defined in the BPSS, then the 
corresponding
                     items in the CPP-CPA would define override values. 
Overrides of
                    timeToPerform and retry interval might make sense since 
these
                    quantities are probably system-dependent.



            Origin  'Possible New Work' Document


    Date of Origin

         Reference

  _______________________________________________________________















                                            Page 2 of 171



          Category  BPSS

         Submitter


          Issue ID  19

             Issue  BPSS timeToPerform for Binary Collaboration and related 
CPPA
                    parameters

       Description  The BPSS defines timeToPerform for a binary 
collaboration.  Should
                    this be in the CPA (with number of retries and retry 
interval)?
                    timeToPerform in a binary collaboration is the time to 
execute the
                    full set of business transactions.


            Origin  'Possible New Work' Document

    Date of Origin


         Reference

  _______________________________________________________________

























                                            Page 3 of 171



          Category  BPSS

         Submitter


          Issue ID  20

             Issue  BPSS timeToAcknowledgeReceipt and 
timeToAcknowledgeAcceptance


       Description  The BPSS also defines timeToAcknowledgeReceipt and
                    timeToAcknowledgeAcceptance.  These deal with business 
signals rather
                     than with application-level responses. Are override 
attributes for
                    these needed in the CPP-CPA?  Do these require number of 
retries and
                    retry interval?


            Origin  'Possible New Work' Document

    Date of Origin


         Reference

  _______________________________________________________________
























                                            Page 4 of 171



          Category  BPSS

         Submitter


          Issue ID  21

             Issue  Consistency of timeouts and installation tools

       Description  The CPP-CPA-BPSS installation tools will have to check 
the
                    consistency of the relative values of the timeouts at 
the three
                    levels (business signals, business transaction, and 
binary
                    collaboration. Some rules are already present in the 
BPSS spec.


            Origin  'Possible New Work' Document

    Date of Origin


         Reference

  _______________________________________________________________


























                                            Page 5 of 171



          Category  BPSS

         Submitter


          Issue ID  38

             Issue  Better way of specifying combinations of characteristics

       Description  Currently, there is one Characteristics element per 
delivery channel.
                     Yet each business transaction may have a different 
combination of
                    characteristics. We need a better way of specifying 
characteristics
                    than by multiplying the number of delivery channels.  
See
                    "alternatives and choices" below.


            Origin  'Possible New Work' Document

    Date of Origin


         Reference

  _______________________________________________________________

























                                            Page 6 of 171



          Category  BPSS

         Submitter


          Issue ID  42

             Issue  Guaranteed Delivery

       Description  In the BPSS, guaranteed delivery is stated as requiring 
third-party
                    guarantees of delivery and nothing is said about 
reliable messaging.

- Should the BPSS have some definitions related to use of reliable
                    messaging between each role and the third party?
                    - Do we need something in the CPP-CPA to cover 
third-party-based
                    guarantees?
                    - The BPSS has no definitions about reliable messaging 
between two
                    parties. Is any thing needed or is this a matter only 
for CPP-CPA and
                     messaging service?



            Origin  'Possible New Work' Document

    Date of Origin

         Reference


  _______________________________________________________________




















                                            Page 7 of 171



          Category  BPSS

         Submitter


          Issue ID  43

             Issue  Binary Collaboration with more than one business 
transaction

       Description  The BPSS says that a binary collaboration should not be 
used when
                    business transaction rollback is required. Presumably, 
issue is what
                    to do about earlier business transactions in the binary 
collaboration
                     when one has to be rolled back.
                    - Is there another way to specify a unit of work 
containing multiple
                    business transactions?
                    - The usual solution to rollback of a business 
transaction within a
                    larger unit of work is to roll back the failed business 
transaction
                    and perform compensating transactions on the earlier 
ones.  The
                    compensating transactions are application-dependent and 
would have to
                     be included in the choreography. Should the BPSS cover 
compensating
                    transactions?
                    - Is there a CPP-CPA issue here?



            Origin  'Possible New Work' Document


    Date of Origin

         Reference

  _______________________________________________________________
















                                            Page 8 of 171



          Category  BPSS

         Submitter


          Issue ID  45

             Issue  "Optional" attributes

       Description  If any BPSS attributes may or may not appear, we may 
need rules in
                    the CPPA spec about how to deal with an attribute in the 
CPP-CPA that
                     does not appear in the referenced Process Specification 
document.
                    Should such an attribute be treated as if it is present 
in the
                    Process Specification document? Should the installation 
tools
                    indicate an error?


            Origin  'Possible New Work' Document


    Date of Origin

         Reference

  _______________________________________________________________
























                                            Page 9 of 171



          Category  BPSS

         Submitter


          Issue ID  37

             Issue  Direct selection of binary collaborations

       Description  - Have the CPA directly select the binary 
collaboration(s) that are
                    applicable. Add to the ProcessSpecification element a 
child element
                    (cardinality one or more) that contains an xlink 
pointing directly to
                     a binary collaboration


            Origin  'Possible New Work' Document

    Date of Origin


         Reference

  _______________________________________________________________


























                                           Page 10 of 171



          Category  BPSS

         Submitter


          Issue ID  41

             Issue  Nonrepudiation of business signals

       Description  Does the CPP-CPA need definitions in the delivery 
channel, in
                    addition to listing the attributes in the 
Characteristics element,
                    that support nonrepudiation of origin and receipt?


            Origin  'Possible New Work' Document

    Date of Origin


         Reference

  _______________________________________________________________



























                                           Page 11 of 171



          Category  BPSS

         Submitter


          Issue ID  40

             Issue  BPSS isNonrepudiationRequired attribute and CPPA 
Nonrepudiation
                    element

       Description  The BPSS defines this attribute as requiring the message 
sender to
                    save an audit trail. It has no signing semantics. The 
isTamperProof
                    attribute controls signing of the business document. 
isTamperProof
                    may be needed in the CPP-CPA Characteristics element.

                    The CPP-CPA Nonrepudiation element is defined as 
covering signing and
                     "prevents later nonrepudiation".  Perhaps the 
definition should be
                    expanded to explicitly cover the rule about audit trail 
that is
                    stated in the BPSS



            Origin  'Possible New Work' Document

    Date of Origin

         Reference


  _______________________________________________________________



















                                           Page 12 of 171



          Category  BPSS

         Submitter  Chan


          Issue ID  44

             Issue  Other BPSS attributes to be reflected in CPPA?

       Description  Are there other attributes that need to be reflected in 
the CPP-CPA?
                     See, for example, Arvola Chan's comments posted to the 
CPPA list
                    7/22/01.


            Origin  'Possible New Work' Document

    Date of Origin


         Reference

  _______________________________________________________________



























                                           Page 13 of 171



          Category  BPSS

         Submitter  Chan


          Issue ID  78

             Issue  Relationship between Acknowledgement, 
DeliveryReceipt,and BPSS
                    Business Signals

       Description  According to the Messaging Service spec, the 
Acknowledgement element
                    is an optional element that is used by one MHS to 
indicate to another
                     MHS that it has received a message (to support the 
implementation of
                     reliable messaging). The DeliveryReceipt element is 
defined as an
                    optional element that is used by the To Party who 
received a message
                    to let the From Party who sent the original message know 
that the
                    message was received.


            Origin  email


    Date of Origin  7/22/2001

         Reference  Subject: Relationship between Acknowledgement, 
DeliveryReceipt,and
                    BPSS Business Signals

  _______________________________________________________________





















                                           Page 14 of 171



          Category  BPSS

         Submitter  Chan


          Issue ID  111

             Issue  Overriding Timing Parameters Specified in a Business 
Process

       Description  . BPSS parameters that can be overridden are essentially 
boolean
                    attributes. (In fact, it would be rather cumbersome for 
a party to
                    indicate that it can accept both True and False values 
for these
                    attributes. Essentially, all acceptable combinations 
would have to be
                     enumerated!) There is no established convention to 
specify the range
                     of acceptable values for non boolean attributes as well 
their
                    preferred values. Therefore, it is not clear to me 
whether such
                    enhancements can be introduced easily.



            Origin  email

    Date of Origin  8/20/2001

         Reference  Subject: Overriding Timing Parameters Specified in a 
Business Process


  _______________________________________________________________





















                                           Page 15 of 171



          Category  BPSS

         Submitter  Chan


          Issue ID  90

             Issue  T2 Non repudiation and MSG, CPP/A, BPSS spec alignment

       Description  The BPSS spec says that nonRepudiationOfReceipt (NRR) is 
tied to the

ReceiptAcknowledgement signal. NRR and reliable messaging are
                    orthogonal. A
                    business process may specify the non repudiation of 
receipt for the
                    requesting business activity business message and/or the 
repudiation
                    of
                    receipt for the responding business activity business 
message,
                    without
                    requiring that reliable messaging be used. I think the 
Messaging
                    Service
                    should not tie NRR to the DeliveryReceipt element if the 
latter is
                    used
                    exclusively in reliable messaging.

                    The MSH is not responsible for validating the syntax of 
payloads. NRR
                     at the
                    MSH level does not really implement NRR as called for by 
the business
                    process specification. NRR at the BPSS level includes 
syntax
                    validation on
                    the payloads. Receipt Acknowledgement business signals 
have to be
                    persisted
                    in order to satisfy legal requirements implied by NRR. I 
just don't
                    see the
                    utility of persisting the DeliveryReceipt generated at 
the MSH level
                    in
                    addition to the ReceiptAcknowledgement signal. This may 
just be
                    unnecessary
                    overhead.

                    Currently, NRR parameters are tied to the 
DeliveryChannel element in
                    the
                    CPP/A. According to Marty, these parameters may have to 
be relocated
                    / added
                    to the ProcessSpecification and/or the Role element in 
order to
                    properly
                    model the non repudiation requirements associated with 
the business
                    process.



                                           Page 16 of 171

email       Originemail











                    I strongly feel that non repudation is one area that the 
MSG, CPP/A,

                                                                        heir 
1.1
                    specifications.
    Date of Origin  8/30/2001

         Reference  Subject: T2 Non repudiation and MSG, CPP/A, BPSS spec 
alignment

  _______________________________________________________________



          Category  BPSS

         Submitter  Sachs

          Issue ID  135


             Issue  Technical report on interoperability across Messaging, 
BPSS and CPPA
                    specs

       Description  We might want to consider a technical report on 
interoperability
                    across the Messaging, BPSS and CPPA specifications. Dale 
agreed with
                    the idea and felt that someone needs to draft it, but 
wasn't sure
                    who.


            Origin  call

    Date of Origin  8/6/2001

         Reference


  _______________________________________________________________




                                           Page 17 of 171



          Category  BPSS

         Submitter  Sachs


          Issue ID  134

             Issue  isIntelligibleCheckRequired property from BPSS

       Description  The BPSS specification has a Boolean 
isIntelligibleCheckRequired
                    property associated with receipt acknowledgement to 
indicate if a
                    syntax check is entailed. Marty wasn't sure if not sure 
if we have
                    that in our version 1.0 [we don't] and opined that it's 
starting to
                    look like it ought to be included.


            Origin  call

    Date of Origin  8/6/2001


         Reference

  _______________________________________________________________

























                                           Page 18 of 171



          Category  BPSS

         Submitter  Moberg


          Issue ID  91

             Issue  Delivery Receipt, NRR and MSG/CPPA/BPSS (mis-)alignment 
and
                    thelayering mishmash

       Description  Details to be distilled.  See the thread starting with 
the cited


            Origin  email

    Date of Origin  8/31/2001

         Reference  Subject: Delivery Receipt, NRR and MSG/CPPA/BPSS 
(mis-)alignment and
                    thelayering mishmash (was jumbled into: reliable 
messaging - hop by
                    hop)


  _______________________________________________________________


























                                           Page 19 of 171



          Category  Business Collaboration Specs

         Submitter


          Issue ID  25

             Issue  Specializations of generic business processes for 
specific partners

       Description  Specialization of the Process-Specification document for 
specific
                    pairs of partners can be done using the 'substitution' 
capability
                    that was added to BPSS at Vienna. In general this 
concerns how to
                    have generic business processes, and yet be able to 
process
                    specializations of those for the specific partners. This 
would be
                    joint work with the CPPA and BP teams.


            Origin  'Possible New Work' Document


    Date of Origin

         Reference

  _______________________________________________________________
























                                           Page 20 of 171



          Category  Business Collaboration Specs

         Submitter


          Issue ID  46

             Issue  Overrides of details in BPSS Instance Document (Process 
Specification
                     Document)

       Description  Details to override include attribute values, business 
document
                    types, etc. An override capability permits tailoring a 
BPSS instance
                    document without having to replicate it, modify it, and 
treat it as a
                     new business collaboration.  Two proposals have been 
put forward,
                    which may be useful together. They were presented at the 
July 24-25
                    meeting/
                    ú Karsten Riemer's substitution proposal.
                    ú Tony Weida's proposal to use ds:Transforms to produce 
the effect of
                     modifying the Process Specification document. One 
example of a
                    transform is XSLT, but other may also be applicable.



            Origin  'Possible New Work' Document

    Date of Origin

         Reference


  _______________________________________________________________


















                                           Page 21 of 171



          Category  Business Collaboration Specs

         Submitter


          Issue ID  26

             Issue  Composition of Services

       Description  David Burdett asked whether it is possible to use the 
same service in
                     different business processes. An example is a payment 
authority that
                     offers a payment authorization service that accepts a 
payment
                    request and returns a payment response that conforms to 
some part of
                    the IFX specification. This could be used in many 
different processes
                     to make a payment, e.g. to pay an invoice, to get 
foreign exchange,
                    etc. It would be really good if a payment authority 
could just define
                     the service once and then everyone could use it in 
whatever business
                     process it is needed in. This can be done with the 
existing CPA
                    definition since a CPA can reference multiple Process 
Specification
                    documents, one of which could be the payment process.  
However, there
                     is no way to choreograph the interaction between the 
payment process
                     and the accompanying business process.  This is 
probably a BPSS
                    issue.  The IBM WSFL web-services proposal includes 
composition of
                    services from simpler services.





            Origin  'Possible New Work' Document

    Date of Origin

         Reference


  _______________________________________________________________












                                           Page 22 of 171



          Category  Business Collaboration Specs

         Submitter


          Issue ID  17

             Issue  Timeouts, number of retries, and retry interval

       Description  Should the CPA provide for specifying timeout, number of 
retries, and
                     retry interval for business-level responses?  If the 
Specification
                    Schema provides these parameters, then they probably 
have to be given
                     values in the CPA. As with the security attributes, 
what is in the
                    Process Specification document can be viewed as a 
default or
                    recommendation with the agreed values specified in the 
CPP/CPA. For
                    example, the timeout might depend on a Party's specific
                    implementation of the process.



            Origin  'Possible New Work' Document

    Date of Origin

         Reference


  _______________________________________________________________





















                                           Page 23 of 171



          Category  Business Collaboration Specs

         Submitter


          Issue ID  15

             Issue  Business collaboration specifications besides BPSS

       Description  We should provide for use of "foreign" 
business-collaboration
                    specifications as alternatives to the Specification 
Schema model.
                    Examples might be:
                    úHand-crafted collaboration protocols based on a 
tpaML-like language

úCollaboration protocols based on WSDL
                    úCollaboration protocols based on alternative models 
such as WSFL,
                    BPML, or whatever these evolve into.

                    Some of these may involve joint work with the BP team or
                    collaboration with the appropriate W3C team.



            Origin  'Possible New Work' Document

    Date of Origin


         Reference

  _______________________________________________________________



















                                           Page 24 of 171



          Category  Business Collaboration Specs

         Submitter  Moberg


          Issue ID  128

             Issue  Two-phase commit and long-running transactions

       Description  Dale mentioned the OASIS BTP team and the possibility of 
addressing
                    two-phase commits and long running transactions - is it 
feasible to
                    accommodate them?  Marty answered that we have very 
little about
                    conversations in version 1.0; he suspects that we need 
much more for
                    two-phase commit.  In terms of scope, we must decide if 
it's likely
                    to become important in the next 18 months.
                    .
                    We consider our relation with BTP.  Might we use BPSS, 
XLANG, WSFL or
                     similar specs together with BTP?  Tim cited a 
difficulty with BTP:
                    it dictates the message sequence, e.g., certain 
timeouts.



            Origin  Scottsdale F2F

    Date of Origin


         Reference

  _______________________________________________________________



















                                           Page 25 of 171



          Category  Business Collaboration Specs

         Submitter  Weida


          Issue ID  121

             Issue  Business rules and constraints

       Description  Capture business constraints and rules that specify 
context-dependent
                     validation of a B2BI system's runtime behavior (for 
both profiles
                    and agreements).  See cited reference for more details.


            Origin  Scottsdale F2F

    Date of Origin


         Reference  
http://www.oasis-open.org/committees/ebxml-cppa/meetings/business_rul
                    es_and_constraints.ppt

  _______________________________________________________________


























                                           Page 26 of 171



          Category  Business Collaboration Specs

         Submitter  Hayes


          Issue ID  148

             Issue  ProcessSpecification xlink:href attribute.

       Description  The ebXML Business Process Analysis Worksheets & 
Guidelines [bpWS]
                    recommends the use of a Business Process Identification 
Naming Scheme
                     (BPINS) which is a URN.  Recommend discussing its usage 
here.

                    [Also from Duane Nickull  Re: Why all this obsession 
over UIDs? As
                    forwarded by Marty Sachs on Sept 28 2001: THe CPP and 
CPA documents
                    should refer to BP schemas via the UIDmechnism too.  
This means I can
                     recognize the UID value in the CPP andCPA which 
prevents me from
                    having to get the sodding thing out of theregistry each 
time and read
                     it manually.]




            Origin  email

    Date of Origin  9/27/2001


         Reference  Subject: CPPA Version 1.0 Comments And Issues

  _______________________________________________________________


















                                           Page 27 of 171



          Category  Business Collaboration Specs

         Submitter  Hayes


          Issue ID  141

             Issue  State that a modified Process Spec should be registered 
in a Business
                     Library.

       Description  Modifying Process Specs: Recommend stating that the new 
Process
                    Specification is either registered in a Business 
Library.  The
                    Business Library can be public to the parties involved 
or could be a
                    local private Business Library.  In the case of local 
private
                    Business Libraries, the new Process Specification should 
be
                    registered and stored at each of the parties Business 
Libraries.


            Origin  email


    Date of Origin  9/27/2001

         Reference  Subject: CPPA Version 1.0 Comments And Issues

  _______________________________________________________________























                                           Page 28 of 171



          Category  Business Collaboration Specs

         Submitter  Hayes


          Issue ID  142

             Issue  Remove or elaborate on description of process 
specification
                    modification

       Description  If the process specification is digitally signed, there 
should be no
                    issue with this.  I think the sentence should be struck 
from the
                    document or the use case needs to be elaborated further 
(e.g. state
                    that the CPA information along with the new process 
specification is
                    exchanged between the two parties until agreement is 
reached).


            Origin  email

    Date of Origin  9/27/2001


         Reference  Subject: CPPA Version 1.0 Comments And Issues

  _______________________________________________________________
























                                           Page 29 of 171



          Category  Collateral

         Submitter


          Issue ID  27

             Issue  CPA Use Cases

       Description   It has been suggested that a technical report be 
prepared that
                    discusses various use cases for the CPA.


            Origin  'Possible New Work' Document

    Date of Origin

         Reference


  _______________________________________________________________


          Category  Collateral

         Submitter


          Issue ID  73

             Issue  Publication of text forms of the DTD and XSD files

       Description  We need to decide where to publish the text forms of 
future versions
                    of the specification.


            Origin  'Possible New Work' Document

    Date of Origin


         Reference

  _______________________________________________________________





                                           Page 30 of 171



          Category  Collateral

         Submitter  Collier


          Issue ID  85

             Issue  Primer on message construction

       Description   A primer on how the message is constructed gets my 
vote.
                    Especially, if it
                    addresses how the security features are incorporated.  
It might be
                    quite a
                    job though, as it should include the BP, CPP/A, and MSH 
teams.


            Origin  email

    Date of Origin  8/7/2001


         Reference  Subject: RE: T2: ackRequested attribute in Via element

  _______________________________________________________________

























                                           Page 31 of 171



          Category  Intermediaries

         Submitter


          Issue ID  11

             Issue  Third-party security services

       Description  Use of third-party security services (this is a special 
case of an
                    intermediary).


            Origin  'Possible New Work' Document

    Date of Origin

         Reference


  _______________________________________________________________




























                                           Page 32 of 171



          Category  Intermediaries

         Submitter


          Issue ID  42

             Issue  Guaranteed Delivery

       Description  In the BPSS, guaranteed delivery is stated as requiring 
third-party
                    guarantees of delivery and nothing is said about 
reliable messaging.

- Should the BPSS have some definitions related to use of reliable
                    messaging between each role and the third party?
                    - Do we need something in the CPP-CPA to cover 
third-party-based
                    guarantees?
                    - The BPSS has no definitions about reliable messaging 
between two
                    parties. Is any thing needed or is this a matter only 
for CPP-CPA and
                     messaging service?



            Origin  'Possible New Work' Document

    Date of Origin

         Reference


  _______________________________________________________________




















                                           Page 33 of 171



          Category  Intermediaries

         Submitter


          Issue ID  23

             Issue   Intermediaries and Multihop Scenarios

       Description  Use of intermediaries may need to be accounted for in 
the CPA.
                    Intermediaries include trading services of various 
kinds.  The use of
                     a proxy outside a Party's firewall is a specific case 
of an
                    intermediary.

                    Are there cases where an intermediary has to understand 
the value of
                    the CPAId element in the message header?

                    Reliable messaging through an intermediary might be a 
CPA matter.

                    The following discussion is from the Sept. 6 2001 
teleconference
                    minutes:  Marty told us that the multiparty case 
involves major
                    issues about which party is privy to what information; 
what state has
                     to be tracked by who, etc. He said that while BPSS has 
some
                    provision for multiparty collaboration, it really just 
amounts to a
                    set of binary collaborations. In his opinion, we should 
steer clear
                    of multipart collaborations until we have more immediate 
issues under
                     control - meanwhile we can get away with sets of binary
                    collaborations. Dale pointed out that the ebXML POC 
showed multiparty
                     collaboration, but all CPPA properties pertained to 
end-to-end
                    interaction, which Marty characterized as a case of 
passive store and
                     forward intermediaries. Dale suggested that if an 
intermediary's
                    role is important to a business process, that should be 
captured via
                    BPSS. Arvola mentioned the CPAId in the Messaging 
header. One can
                    also specify a CPA between the sender and (the first) 
intermediary,
                    probably using the Messaging specification's via 
element, which
                    Arvola thinks has its own Service and Action elements 
[it does]. Dale
                     suspects a gap between BPSS and intermediary provisions 
in MSH.
                    Brian will work with David Burdett on that. One point of 
view was
                    expressed that if Party A says to send to a 3rd party 
and Party B
                    does send it there, that's sufficient - Party B has 
fulfilled its
                    obligation under a CPPA. Another case occurs when Party 
A can only
                    send to an intermediary such as Commerce One, but has an 
obligation
                    (under a CPA) to send it to the ultimate recipient. Dale 
expressed
                    the view that the whole area of "interconnects" is out 
of scope for
                    version 1.1 - we don't even provide for VANs as 
transports. Although
                    VANs showed up in tpaML, Marty advised that it was 
merely as a
                    placeholder.


                                           Page 34 of 171

            Origin  'Possible New Work' Document













                    [Also see email re Draft of Requirements for 
Intermediary Support for
    Date of Origin   discussion - Aug 1, 2001 ff, and minutes of Sept. 6 
teleconference]

         Reference

  _______________________________________________________________
































                                           Page 35 of 171



          Category  Intermediaries

         Submitter  Sachs


          Issue ID  86

             Issue  Designation of mutually trusted third party

       Description  One of the scenarios I was wondering about was an 
intermediary that
                    functions as a mutually-trusted party that adds signed 
timestamps to

messages.  So if A sends a message to B through this IM, B receives
                    a
                    message that contains the original message from A, plus 
a time value,
                    signed by the IM, so that B can later prove (provide 
evidence) that
                    the message was generated before time T and that B 
received it after

time T.  This scenario has IM signing something that might have
                    already been signed by A, i.e. nested signing, which is 
not at all
                    uncommon in cryptologic protocols, but which doesn't 
seem to be
                    something contemplated by the existing Message Service 
spec.  So I
                    suppose this is a scenario that we do not propose to 
deal with.  But

one of the interesting things about it is that the fact that the
                    messages need to be timestamped by a mutually-trusted 
third party,
                    and
                    the question of who we mutually trust, are really parts 
of a business
                    agreement and would therefore logically belong in the 
actual CPA.

                    But just because someone can invent a scenario does not 
mean that
                    supporting it is a requirement!  The real question is 
what use
                    cases are actually required.






            Origin  email

    Date of Origin  8/14/2001

         Reference  Subject: Re: T2 - Assertions and Questions


  _______________________________________________________________





                                           Page 36 of 171



          Category  Messaging

         Submitter


          Issue ID  42

             Issue  Guaranteed Delivery

       Description  In the BPSS, guaranteed delivery is stated as requiring 
third-party
                    guarantees of delivery and nothing is said about 
reliable messaging.

- Should the BPSS have some definitions related to use of reliable
                    messaging between each role and the third party?
                    - Do we need something in the CPP-CPA to cover 
third-party-based
                    guarantees?
                    - The BPSS has no definitions about reliable messaging 
between two
                    parties. Is any thing needed or is this a matter only 
for CPP-CPA and
                     messaging service?



            Origin  'Possible New Work' Document

    Date of Origin

         Reference


  _______________________________________________________________




















                                           Page 37 of 171



          Category  Messaging

         Submitter


          Issue ID  22

             Issue  Alternative message services

       Description  The specification tries to make it clear that a user of 
a CPP or CPA
                    may use an alternative message service such as SOAP or 
XML Protocol.
                     However, the specification does not prescribe a formal 
way to add
                    the alternative messaging service.  The user must revise 
the schema
                    or DTD to eliminate the ebXMLBinding element and add 
whatever new
                    element is needed. For this approach, we need to change 
the
                    cardinality of ebXMLBinding to (0 or 1). Other 
possibilities:
                    - Add an extensibility element to be used when 
introducing an
                    alternative messaging service.
                    - Provide xxxBinding elements for commonly used 
messaging services.
                    SOAP 1.1 and XML Protocol (when available).  All these 
"supported"
                    elements would be defined as part of an enumeration (1 
out of the
                    list would be required).




            Origin  'Possible New Work' Document


    Date of Origin

         Reference

  _______________________________________________________________















                                           Page 38 of 171



          Category  Messaging

         Submitter


          Issue ID  69

             Issue  Payload Compression:

       Description  Should the CPP and CPA support payload compression?  
This element
                    would indicate whether the sending party is sending 
compressed
                    payload and what the compression algorithm is.  It could 
be:
                    ú Once for each party's set of business transactions
                    ú Once per message definition.
                    ú Interaction between compression and encryption (at a 
minimum,
                    compression must precede encryption since encryption 
reduces
                    compressibility.
                    ú Compression of part vs. the whole message.

                    See also email from Arvola Chan on 21 Aug 2001 re 
Transport level
                    compression and followups.




            Origin  'Possible New Work' Document


    Date of Origin

         Reference

  _______________________________________________________________
















                                           Page 39 of 171



          Category  Messaging

         Submitter


          Issue ID  47

             Issue  Normative Appendix on Use of the CPA with the ebXML 
Message Service


       Description  This appendix is an outstanding item from Ver. 1.0. 
There are
                    ambiguities in the Message Service Specification that 
result from
                    treating the CPA as optional.  Therefore, the CPP-CPA 
specification
                    has to define exactly how various elements in the 
message header are
                    to be used with a CPA.  This item should be joint work 
with the MSG
                    team. Some examples:
                    ú Possible clarification of the role of the Service and 
Action
                    elements in the header.
                    ú How the RefToMessageId element is to be used in 
application-level
                    request and response messages (see "Routing of Response 
Messages"
                    below).
                    ú Clarification of some of the Reliable Messaging issues 
pointed out
                    by Arvola Chan (see "Reliable Messaging Consistency" 
below).
                    ú List and discussion of all elements in the message 
header that
                    relate to the CPA.



            Origin  'Possible New Work' Document


    Date of Origin

         Reference

  _______________________________________________________________













                                           Page 40 of 171



          Category  Messaging

         Submitter


          Issue ID  132

             Issue  Is MSH the endpoint for Nonrepudiation of receipt?

       Description  Marty feels there is confusion about whether or not the 
MSH is the
                    endpoint for NRR functionality. That impacts where NRR 
information
                    belongs in a CPP/A.


            Origin  call

    Date of Origin  8/6/2001


         Reference

  _______________________________________________________________


          Category  Messaging


         Submitter

          Issue ID  49

             Issue  PersistDuration


       Description  There is some ambiguity in the Message Service 
specification as to
                    whether this is internal to each party or something that 
has to be
                    agreed upon.  Discussions with the MSG team are needed

            Origin  'Possible New Work' Document


    Date of Origin

         Reference

  _______________________________________________________________



                                           Page 41 of 171



          Category  Messaging

         Submitter


          Issue ID  50

             Issue  Delivery failure negotiation

       Description  Delivery failure notification is internal to each party. 
  However, if
                     the MSG team retains the optionality of delivery 
failure
                    notification, this team should consider whether to 
include an element
                     or attribute in the CPA that states whether the parties 
agree to
                    require guaranteed delivery failure notification.


            Origin  'Possible New Work' Document

    Date of Origin


         Reference

  _______________________________________________________________

























                                           Page 42 of 171



          Category  Messaging

         Submitter


          Issue ID  51

             Issue  Timeout for delivery failure notification

       Description  A party needs to know how long to wait for successful 
delivery or a
                    delivery failure notification.  The maximum waiting time 
is a bit
                    longer than the maximum time for retries.  Because 
RetryInterval may
                    be shorter or longer than the internal timeout that the 
Message
                    Service Handler uses for deciding whether to retry, some 
discussion
                    with the MSG team is needed on how to determine the 
maximum time and
                    whether anything is needed in the CPP or CPA.


            Origin  'Possible New Work' Document


    Date of Origin

         Reference

  _______________________________________________________________























                                           Page 43 of 171



          Category  Messaging

         Submitter


          Issue ID  54

             Issue  RefToMessageId element in Message Header

       Description
                    The following requires some definition work with the MSG 
team.

                    There is no explicit statement in the Message Service 
spec about the
                    use of the RefToMessageId element in messages other than 
message
                    service to message service control messages.  Use in
                    application-level messages is valuable and will not 
interfere with
                    the currently defined use and the necessary words should 
be added.
                    ú In an application-level response message, the 
RefToMessageId
                    element should contain the ID of the message that the 
message is
                    responding to. This is necessary to disambiguate the 
case described
                    in "Routing of Response Messages" above.
                    ú At the same time, words should be added which allow 
the
                    RefToMessageId to be used in an application-level 
request message.
                    This would, for example, allowing a message requesting a 
compensation
                     action to point to the message being compensated.
                    ú It may be necessary to add an indicator somewhere in 
the message
                    header that the message is a response to a prior 
application-level
                    message.  This indicator would be supplied by the 
sending application
                     and would enable the receiving system to recognize that 
the message
                    is a response and the RefToMessageId element should be 
used as part
                    of the information that routes the message to the 
appropriate
                    software entry point.





            Origin  'Possible New Work' Document

    Date of Origin

         Reference


  _______________________________________________________________




                                           Page 44 of 171



          Category  Messaging

         Submitter  Ferris


          Issue ID  80

             Issue  Advertise use of of NTP,  XNTP etc. in CPP

       Description  >>      mshTimeAccuracy
                    >>      >>>This is the accuracy to which a recipient of 
a message
                    claims
                    to keep their internal
                    >>      system clocks. This should probably be part of a 
CPP and not

vary from message to message
                    >>      therefore it does not need to be in the 
MessageHeader
                    >>      [David Fischer] Agreed, but what if there is no 
CPP?  I'm not
                    sure why this is necessary.

                    Chris Ferris>It isn't represented in the CPP, nor should 
it be. I
                    have
                    repeatedly expressed my
                    >belief that this is unnecessary at best, and more 
likely
                    unimplementable in any event [1].

                    >If anything, I could see parties agreeing to a 
requirement that
                    their
                    respective
                    >system's system clock be synchronized using something 
like NTP or
                    some
                    similar
                    >service and having this reflected in some manner within 
the CPP/A,
                    but
                    not mshTimeAccuracy!

                    >I for one would like to see this removed from the 1.1 
specification.

                    I agree with Chris that the use of
                    NTP to synchronize clocks at a distance
                    is something that is suitable for a CPA
                    and that the use of NTP
                    or XNTP or whatever could be
                    advertized in a CPP. I also agree
                    that putting the mshTimeAccuracy
                    in the MessageHeader
                    is definitely excess baggage!
                    Should be removed.


                                           Page 45 of 171

            Origin  email
    Date of Origin  8/1/2001
         Reference  (via Dale M) Subject: msh TimeAccuracy RE: T2 Reliable 
Messaging w/o
                    CPA or VIA...













  _______________________________________________________________



          Category  Messaging

         Submitter  Chan


          Issue ID  78

             Issue  Relationship between Acknowledgement, 
DeliveryReceipt,and BPSS
                    Business Signals

       Description  According to the Messaging Service spec, the 
Acknowledgement element
                    is an optional element that is used by one MHS to 
indicate to another
                     MHS that it has received a message (to support the 
implementation of
                     reliable messaging). The DeliveryReceipt element is 
defined as an
                    optional element that is used by the To Party who 
received a message
                    to let the From Party who sent the original message know 
that the
                    message was received.


            Origin  email


    Date of Origin  7/22/2001

         Reference  Subject: Relationship between Acknowledgement, 
DeliveryReceipt,and
                    BPSS Business Signals

  _______________________________________________________________






                                           Page 46 of 171



          Category  Messaging

         Submitter  Chan


          Issue ID  87

             Issue  RosettaNet Retry Parameter not Expressible in BPSS or 
CPP/A

       Description  Existing RosettaNet PIPs do not require exactly once 
delivery
                    semantics.
                    Asynchronous PIPs have a Retry parameter that governs 
how many
                    additional
                    retries a sender will send a message, if it has not 
received a
                    Receipt
                    Acknowledgement signal from the other party.

                    Currently, BPSS does not allow for the specification of 
a retry
                    count. At
                    the CPP/A level, the only available retry parameter is 
associated
                    with
                    reliable messaging. It is not clear if RosettaNet should 
always use
                    reliable
                    messaging for all PIPs.

                    Ideally, the DocExchange element should carry an 
alternate Retry
                    element
                    that is not tied to reliable messaging. Otherwise, it 
will be great
                    fi
                    extension mechanisms whereby namespace qualified 
extension
                    elements/attributes can be added. This is an approach 
that is used
                    both in
                    SOAP and in the Message Service to provide 
extensibility.

            Origin  email


    Date of Origin  8/23/2001

         Reference  Subject: RosettaNet Retry Parameter not Expressible in 
BPSS or CPP/A


  _______________________________________________________________






                                           Page 47 of 171



          Category  Messaging

         Submitter  Chan


          Issue ID  88

             Issue  Piggybacking of signals on application level messages 
via packaging

       Description  From response by Dale Moberg: We intended to handle the 
specification
                     of the agreement on how
                    piggybacking
                    was to be done via packaging. This has not yet occurred. 
Here are
                    some
                    issues needing resolution on the way to getting this 
done:

                    1. When we have signalsAndResponse true, and 
syncResponse true, then
                    the
                    packaging should describe how the signal and Response 
(payload) are
                    arranged
                    in a SOAP with attachments package.
                    2. When we have signalsOnly, we need to be able to 
indicate that
                    there
                    are
                    in effect two communication channels used in responding. 
The signal
                    will
                    be returned on the requesting connection as a HTTP 
reply. The payload
                    (business
                    response) needs a URL to specify the endpoint that it is 
returned to.
                     At
                    the
                    moment, we do not have enough apparatus available to 
express these
                    facts.
                    In addition, two different packaging formats need to be 
available to

reflect
                    the message containing the signal and the one containing 
the business
                    response.










            Origin

                                           Page 48 of 171

         Reference  Subject: One issue pertaining to Arvola response to 
Marty to Hima on
                    v1question4
  _______________________________________________________________












          Category  Messaging


         Submitter  Chan

          Issue ID  89

             Issue  Linkage of SimplePart element to BusinessDocument at the 
BPSS level



       Description  One or more business signals, along with a business 
response can
                    be carried in the same ebXML message in the synchronous 
reply
                    mode. I suspect that each of the above has to be treated 
as one
                    attachment to the SOAP message with attachments.

                    The CPP/CPA has a Packaging element that is supposed to
                    describe the constituents of a payload and its security 
packaging.
                    However, the SimplePart element in the CPP/A currently 
does not
                    seem to have any linkage to a BusinessDocument at the 
BPSS level

                    I think this is an alignment issue among the MSG, CPP/A, 
and
                    eBTWG workgroups.


            Origin  email


    Date of Origin  8/29/2001

         Reference  Subject: Re: "Primary Business Document"

  _______________________________________________________________






                                           Page 49 of 171



          Category  Messaging

         Submitter  Chan


          Issue ID  90

             Issue  T2 Non repudiation and MSG, CPP/A, BPSS spec alignment

       Description  The BPSS spec says that nonRepudiationOfReceipt (NRR) is 
tied to the

ReceiptAcknowledgement signal. NRR and reliable messaging are
                    orthogonal. A
                    business process may specify the non repudiation of 
receipt for the
                    requesting business activity business message and/or the 
repudiation
                    of
                    receipt for the responding business activity business 
message,
                    without
                    requiring that reliable messaging be used. I think the 
Messaging
                    Service
                    should not tie NRR to the DeliveryReceipt element if the 
latter is
                    used
                    exclusively in reliable messaging.

                    The MSH is not responsible for validating the syntax of 
payloads. NRR
                     at the
                    MSH level does not really implement NRR as called for by 
the business
                    process specification. NRR at the BPSS level includes 
syntax
                    validation on
                    the payloads. Receipt Acknowledgement business signals 
have to be
                    persisted
                    in order to satisfy legal requirements implied by NRR. I 
just don't
                    see the
                    utility of persisting the DeliveryReceipt generated at 
the MSH level
                    in
                    addition to the ReceiptAcknowledgement signal. This may 
just be
                    unnecessary
                    overhead.

                    Currently, NRR parameters are tied to the 
DeliveryChannel element in
                    the
                    CPP/A. According to Marty, these parameters may have to 
be relocated
                    / added
                    to the ProcessSpecification and/or the Role element in 
order to
                    properly
                    model the non repudiation requirements associated with 
the business
                    process.



                                           Page 50 of 171

email       Originemail











                    I strongly feel that non repudation is one area that the 
MSG, CPP/A,

                                                                        heir 
1.1
                    specifications.
    Date of Origin  8/30/2001

         Reference  Subject: T2 Non repudiation and MSG, CPP/A, BPSS spec 
alignment

  _______________________________________________________________































                                           Page 51 of 171



          Category  Messaging

         Submitter  Chan


          Issue ID  126

             Issue  SMTP Delivery Status Notification and Message 
Disposition
                    Notification

       Description  The following is an excerpt from section 2.4.3.3 in the 
RNIF 2.0 Core
                     Specification:

                    Email-based message transfer is a store-forward-based 
message
                    delivery mechanism and the SMTP messages need not be 
sent directly
                    between the source and the eventual recipient's SMTP 
nodes (due to
                    SMTP routing involved). Hence, trading partners cannot 
rely on any
                    synchronous transport level errors (analogous to HTTP 
response/error
                    codes) being returned. Therefore, trading partners MUST 
have a
                    mechanism in place to handle undeliverable email 
messages sent to
                    each other. Delivered messages with content problems 
SHOULD, however,
                     result in the recipient sending separate RosettaNet 
Exception
                    business signals. If desired, trading partners could use 
the SMTP
                    Delivery Status Notification (DSN) mechanism (see RFC 
1891) to
                    request that the recipient notify the sender of SMTP 
message delivery
                     status. Partners could also use the SMTP Message 
Disposition
                    Notification (MDN) mechanism as needed. These are part 
of the
                    standard SMTP message delivery mechanism / standard and 
can be used
                    by trading partners as needed and feasible, based on 
their SMTP
                    set-ups. RosettaNet does not provide any explicit 
specification in
                    this respect.

                    Should the use of DSN and MDN be specifiable as part of 
the SMTP
                    protocol?





            Origin  email

    Date of Origin  8/23/2001

         Reference  Subject: SMTP Delivery Status Notification and Message 
Disposition
                    Notification(RFC 1891 and RFC 2298)


  _______________________________________________________________

                                           Page 52 of 171




















































                                           Page 53 of 171



          Category  Messaging

         Submitter  Chan


          Issue ID  75

             Issue  Clarification of syncReplyMode Attribute

       Description  Line 1171 in the 1.0 CPPA spec talks about four possible 
values for
                    the syncReplyMode attribute: signalsOnly, responseOnly,
                    signalsAndResponse, and none.

                    Line 1178 is confusing. I think it should say "the 
sending
                    application expects in a response" rather than "the 
receiving
                    application expects in a response".

                    The explanation of signalsOnly is not clear. Depending 
on the
                    definition of the business transaction (i.e., whether 
there is a
                    responding activity), the sending application may still 
expect a
                    business response message separately. This response 
message in turn
                    will trigger a business level acknowledgement that may 
or may not be
                    returned synchronously.

                    The meaning of responseOnly is also unclear. Does it 
mean that no
                    business signals should be sent at all or are they only 
to be sent
                    separately and asynchronously? What if non-repudiation 
of receipt is
                    required?

                    In the case of signalsAndResponse, I suppose the 
multiple business
                    level messages have to be packaged into a single message 
at the MHS
                    level as multiple MIME body parts. I don't think this 
point is
                    clearly stated. Also, if the responder returns the 
business signals
                    and business response synchronously, how is the 
initiator expected to
                     send its business level receipt acknowledgement? Will 
that have to
                    be sent asynchronously?

                    The RosettaNet Implementation Framework 2.0 supports 
synchronous
                    response but makes a number of simplifying assumptions. 
For a
                    one-action PIP, the responder can return a signal or not 
at all. For
                    a two-action PIP, the responder can return a business 
response but no
                     business signal. Thus, there is no non-repudiation of 
receipt for
                    the request action from the responder. It is also 
assumed that the
                    initiator is not required to return a receipt 
acknowledgement for the
                     response action. Therefore, there is no non-repudiation 
of receipt
                    of the response action from the initiator either. In 
other words,
                    synchronous response mode can only be used for certain 
PIPs that


                                           Page 54 of 171












                    don't require response or non-repudiation of receipt.

                    The ebXML message is more flexible to allow signal(s) 
and response to
                     be packaged into the same message, so it may be 
unnecessary to
                    impose any of the above simplifying assumptions. Still, 
it is useful
            Origin  email                                               tion 
of receipt

    Date of Origin  7/26/2001

         Reference  Subject: Clarification of syncReplyMode Attribute

                    See also Subject: <1.0 bug> syncReplyMode attribute 
values are not
                    clearly explainedA - Aug 21 2001


  _______________________________________________________________
























                                           Page 55 of 171



          Category  Messaging

         Submitter  Chan


          Issue ID  83

             Issue  Are signals meaningful in case syncReplyMode is not set 
to none?

       Description  Whether response for a business process is to be 
returned
                    synchronously is specified in the CPA rather than in the 
business
                    process specification itself. This may lead to 
inconsistent
                    specifications that can be rather meaningless.

                    Consider the case of a business process that calls for 
the use of
                    both receipt acknowledgement and acceptance 
acknowledgement for the
                    request activity. Let's say their corresponding timeouts 
are 5
                    minutes and 10 minutes, and the time to perform is 30 
minutes. Now
                    suppose the CPA specifies syncReplyMode = 
signalsAndResponse, does it
                     mean that both the signals and the response have to be 
returned
                    within 5 minutes? If not, isn't the requesting party 
supposed to
                    consider the transaction null and void due to not 
getting the receipt
                     acknowledgement in time?

                    If the purpose of the receipt acknowledgement is to 
indicate that the
                     request message has passed the intelligible check, and 
the purpose
                    of the acceptance acknowledgement is to indicate that 
the request
                    message has passed additional business rules validation, 
there isn't
                    much of a point to return these signals along with the 
response
                    synchronously (being packaged into the same ebXML 
message). The fact
                    that the response is returned implies that both forms of 
validation
                    have passed. Batching these signals with the response 
essentially
                    make them redundant and worthless.

                    Among RosettaNet PIPs, 2A9 (Query Electronic Components 
Technical
                    Information) is the only one that allows both 
synchronous and
                    asynchronous response. In the case of synchronous 
response, time to
                    perform is 5 minutes. For asynchronous response, time to 
perform is
                    24 hours. It does not seem possible to model PIP 2A9 
using BPSS and
                    CPP/A as a single business process specification. Only a 
single time
                    to perform can be specified at the BPSS level. There is 
no mechanism
                    at the CPP/A level to override the time to perform 
parameter.

                    In fact, I think it will be useful if time to 
acknowledge receipt,
                    time to acknowledge acceptance, and time to perform for 
a business
                    process specification can all be overridden at the CPP/A 
level to
                    suit the performance requirements between the two 
trading partners.


                                           Page 56 of 171

            Origin  email














    Date of Origin  8/2/2001

         Reference  Subject: Are signals meaningful in case syncReplyMode is 
not set to
                    none?

  _______________________________________________________________



          Category  Messaging

         Submitter  Chan

          Issue ID  84


             Issue  ackRequested attribute in Via element (of MSH) and QOS

       Description  To be distilled from the cited email thread.

            Origin  email


    Date of Origin  8/7/2001

         Reference  (reply to David Burdett forwarded by Marty Sachs) 
Subject: Re: T2:
                    ackRequested attribute in Via  element

  _______________________________________________________________








                                           Page 57 of 171



          Category  Messaging

         Submitter  Chan


          Issue ID  48

             Issue  Possible need for TimeAccuracy and TimeToLive

       Description  Arvola Chan (posting of 7/15/01) reported a number of 
problems with
                    the Reliable Messaging definition in the Message Service
                    Specification. Fixing some of these may require 
coordination between
                    the CPPA and MSG teams. For example, he questioned 
whether
                    TimeAccuracy and TimeToLive should be added to the CPA.

                    Items discussed at the July 24-25 meeting:
                    ú TimeToLive is intended to be on an individual message 
basis; hence
                    it is not an agreement matter.  If it is necessary to 
specify it per
                    message type or business transaction, it may have to be 
specified in
                    the Process Specification document with an override in 
the CPA
                    Characteristics element.
                    ú MSHTimerAccuracy.  This appears to be an internal 
matter at each
                    party. We need to discuss this with the MSG team.



            Origin  'Possible New Work' Document


    Date of Origin

         Reference

  _______________________________________________________________















                                           Page 58 of 171



          Category  Messaging

         Submitter  Chan


          Issue ID  118

             Issue  Problem with Non Repudiation over a Synchronous Delivery 
Channel

       Description  The CertificateRef under NonRepudiation is presumably 
the
                    certificate used by the sender for signing.

                    What happens if syncReplyMode is set to something other
                    than None? In that case, the receiver (responder) has to
                    deliver the response document over the same channel. 
Where
                    is the CertificateRef for signing by the responder?


            Origin  email


    Date of Origin  8/21/2001

         Reference  Subject: Does CPA support SSL mutual authentication?

  _______________________________________________________________























                                           Page 59 of 171



          Category  Messaging

         Submitter  Chan


          Issue ID  77

             Issue  Idempotency attribute

       Description  This concept is not mentioned any where in the Messaging 
Service
                    spec. In order to implement the OnceAndOnlyOnce delivery 
semantics,
                    the MSH already performs duplicate detection and 
filtering. It is not
                     clear how the idempotency test applied at the document 
exchange
                    layer (described on line 1575) differs from the 
duplicate detection
                    and handling described in Section 10.3 in the Messaging 
Service spec.

                    Is the document exchange layer part of the MSH?

                    What is the meaning of deliverySemantics=OnceAndOnlyOnce 
and
                    idempotency=false?




            Origin  email

    Date of Origin  7/26/2001


         Reference  Subject: Idempotency attribute (Section 7.6.4.2, line 
1569)

  _______________________________________________________________

















                                           Page 60 of 171



          Category  Messaging

         Submitter  Sachs


          Issue ID  133

             Issue  Clarify MSH, Middleware, and their relationship

       Description  Marty wants to make sure that we distinguish between the 
formal
                    definition of MSH [editorial: which is not entirely 
clear] and
                    related middleware.

                    Dale believes a crucial issue is how much work the MSH 
does when
                    generating NRR. For example, invoking an XML parser 
extends its scope
                     from an architectural point of view. In the case of NRR 
for
                    RosettaNet, MSH alone is not sufficient; cooperation of 
another
                    middleware component is needed -- maybe we should 
undertake to
                    specify division of labor in this area. Arvola observed 
that our
                    specification is currently tied to BPSS. Marty 
elaborated that we
                    have links for BPSS instance documents and roles, along 
with a set of
                     security attributes to override information in a BPSS 
instance, but
                    we say little about those attributes in terms of what 
functionality
                    must be where.

                    . Returning to syntax checking as part of receipt 
acknowledgement, it
                     was mentioned that the MSH could provide a plug in. 
This again
                    raises questions about the scope of MSH and division of 
labor among
                    middleware components. Someone (Engkee?) asked if the
                    Interoperability committee might address such matters.




            Origin  call


    Date of Origin  8/6/2001

         Reference

  _______________________________________________________________







                                           Page 61 of 171



          Category  Messaging

         Submitter  Sachs


          Issue ID  93

             Issue  Clarity of text re NRR / Delivery Channel and/or 
separate send
                    delivery channel

       Description  NRR is expressed in the CPA by the NonRepudiation 
element under
                    ebXMLBinding in the delivery channel.  The delivery 
channel describes
                     a
                    Party's receive properties.  Nonrepudiation requires 
action by both
                    parties.  However signing is done by the From Party.  So 
having it
                    NRR in
                    the delivery channel (receive properties) is a bit 
peculiar.  The
                    points
                    that I don't think I made previously are these:

                       Although NonRepudiation is in the delivery channel 
(receive
                    properties),
                       the certificate which must be referenced is for 
signing the
                    message.
                       This certificate belongs to the From party, not the 
To party.  If
                    we
                       leave NonRepudiation where it is, the text must make 
it clear that
                     the
                       certificate is one belonging to the other party, not 
the party
                    that owns
                       this delivery channel.

                        Because the certificate belongs to the other party, 
the
                    certificate
                       reference is meaningless in the CPP.  The text should 
state that
                    the
                       certificate referenced in the CPP must be replaced  
by a reference
                     to
                       the other party's certificate when the CPA is 
composed.

                    A better solution is to provide "send" delivery channels 
along with
                    the

            Origin  email


    Date of Origin  9/6/2001

         Reference  Subject: Nonrepudiation of receipt in CPA
                                           Page 62 of 171
                                                         ________







          Category  Messaging

         Submitter  Sachs


          Issue ID  131                 hannels though this is probably out 
of scope for
                    V1.1.
             Issue  MSH timeout

       Description  . We do not define the actual timeout that the MSH uses 
to determine
                    when to retry.  That timeout could be longer or shorter 
than
                    RetryInterval.  We also do not say whether RetryInterval 
is measured
                    from the sending of the message or the expiration of the 
MSH timeout.
                      I recommend defining the MSH timeout and adding it to 
the CPA. .



            Origin  email

    Date of Origin  8/12/2001


         Reference  Subject: RE: T2 Clarify TimeToLive

  _______________________________________________________________



















                                           Page 63 of 171



          Category  Messaging

         Submitter  Sachs


          Issue ID  130

             Issue  Routing ambiguity when two different BPSS instance
                    documents are used at once

       Description  Details to be distilled from cited email thread.


            Origin  email

    Date of Origin  8/12/2001

         Reference  Subject: RE: T2 The answer isn't always "you need a CPA"


  _______________________________________________________________




























                                           Page 64 of 171



          Category  Messaging

         Submitter  Sachs


          Issue ID  135

             Issue  Technical report on interoperability across Messaging, 
BPSS and CPPA
                    specs

       Description  We might want to consider a technical report on 
interoperability
                    across the Messaging, BPSS and CPPA specifications. Dale 
agreed with
                    the idea and felt that someone needs to draft it, but 
wasn't sure
                    who.


            Origin  call

    Date of Origin  8/6/2001


         Reference

  _______________________________________________________________

























                                           Page 65 of 171



          Category  Messaging

         Submitter  Moberg


          Issue ID  91

             Issue  Delivery Receipt, NRR and MSG/CPPA/BPSS (mis-)alignment 
and
                    thelayering mishmash

       Description  Details to be distilled.  See the thread starting with 
the cited


            Origin  email

    Date of Origin  8/31/2001

         Reference  Subject: Delivery Receipt, NRR and MSG/CPPA/BPSS 
(mis-)alignment and
                    thelayering mishmash (was jumbled into: reliable 
messaging - hop by
                    hop)


  _______________________________________________________________


























                                           Page 66 of 171



          Category  Messaging

         Submitter  Collier


          Issue ID  95

             Issue  Lack of processing rules

       Description  The TRP document addresses wire format only.  Given the 
complex
                    nature of composing a message that adequately reflects 
both security
                    and reliability in addition to the correct business 
process data,
                    there is a good deal of the processing of a business 
message through
                    the MSH to the SOAP process that is left as an exercise 
for the
                    reader. While the TRP specification makes a 
recommendation on how
                    signatures should be applied to a Message Envelope, 
there are still
                    areas of overlap between the SOAP envelope and the ebXML 
envelope
                    that probably need further definition.  As is mentioned 
in Section
                    12.1 item 7, there is no defined line of communication 
to the MSH
                    from the SOAP layer.   There are several areas in which 
the
                    specification of the sequence of processing of a message 
would be
                    helpful.



            Origin  ebXML Technical Architecture Risk Assessment v1.0


    Date of Origin

         Reference

  _______________________________________________________________
















                                           Page 67 of 171



          Category  Middleware

         Submitter


          Issue ID  74

             Issue  Business Service Interface

       Description  Business Service Interface (BSI) design may be outside 
our scope, but
                     statement of BSI requirements may be in.

                    see also email re "Suggestions from Karsten Riemenr" - 
June 25 ff


            Origin  Scottsdale F2F

    Date of Origin


         Reference

  _______________________________________________________________


























                                           Page 68 of 171



          Category  Middleware

         Submitter


          Issue ID  66

             Issue   Interaction between configuration inside a Party and 
the CPA

       Description  In general, configuration matters are internal to each 
party and
                    should not appear in the CPA. However there may be CPA 
implications,
                    especially if internal configuration information 
overrides fields in
                    the CPA.  If that can happen, it needs to be documented 
in the CPA
                    specification.


            Origin  'Possible New Work' Document

    Date of Origin


         Reference

  _______________________________________________________________

























                                           Page 69 of 171



          Category  Middleware

         Submitter


          Issue ID  16

             Issue  Middleware interoperability

       Description  úUpper interface of  Message Service
                    úInterface between middleware and bridge to legacy 
applications
                    úAnything else to support interoperability aspects of 
CPA and
                    middleware?
                    úReliable messaging delivery failure notification may be 
an issue
                    that involves the interfaces within the middleware/

                    Probably this should be joint work among CPPA, MSG, and 
BP teams.
                    Perhaps some new OASIS team should be created to lead 
this work.




            Origin  'Possible New Work' Document

    Date of Origin


         Reference

  _______________________________________________________________



















                                           Page 70 of 171



          Category  Middleware

         Submitter


          Issue ID  132

             Issue  Is MSH the endpoint for Nonrepudiation of receipt?

       Description  Marty feels there is confusion about whether or not the 
MSH is the
                    endpoint for NRR functionality. That impacts where NRR 
information
                    belongs in a CPP/A.


            Origin  call

    Date of Origin  8/6/2001


         Reference

  _______________________________________________________________



























                                           Page 71 of 171



          Category  Middleware

         Submitter  Sachs


          Issue ID  133

             Issue  Clarify MSH, Middleware, and their relationship

       Description  Marty wants to make sure that we distinguish between the 
formal
                    definition of MSH [editorial: which is not entirely 
clear] and
                    related middleware.

                    Dale believes a crucial issue is how much work the MSH 
does when
                    generating NRR. For example, invoking an XML parser 
extends its scope
                     from an architectural point of view. In the case of NRR 
for
                    RosettaNet, MSH alone is not sufficient; cooperation of 
another
                    middleware component is needed -- maybe we should 
undertake to
                    specify division of labor in this area. Arvola observed 
that our
                    specification is currently tied to BPSS. Marty 
elaborated that we
                    have links for BPSS instance documents and roles, along 
with a set of
                     security attributes to override information in a BPSS 
instance, but
                    we say little about those attributes in terms of what 
functionality
                    must be where.

                    . Returning to syntax checking as part of receipt 
acknowledgement, it
                     was mentioned that the MSH could provide a plug in. 
This again
                    raises questions about the scope of MSH and division of 
labor among
                    middleware components. Someone (Engkee?) asked if the
                    Interoperability committee might address such matters.




            Origin  call


    Date of Origin  8/6/2001

         Reference

  _______________________________________________________________







                                           Page 72 of 171



          Category  Miscellaneous

         Submitter


          Issue ID  24

             Issue  TPA reference element

       Description  It has been proposed to add an optional element to the 
CPA that
                    provides a reference to an associated "traditional" 
contract or TPA.
                     This should be able to be either a text string or the 
URI of an
                    electronic (e.g. XML) representation of the contract or 
TPA. It
                    should be stated this element is for information only; 
its presence
                    or absence is independent of whether a contract does or 
does not
                    exist.

                    It will be necessary to consider the relation of this 
element to the
                    isLegallyBinding attribute in the Process Specification 
document.
                    (See listserver discussion June 26-27, 2001).


            Origin  'Possible New Work' Document

    Date of Origin


         Reference

  _______________________________________________________________



















                                           Page 73 of 171



          Category  Miscellaneous

         Submitter


          Issue ID  70

             Issue  Include higher-level abstractions in the CPA

       Description  There has been a suggestion to extend the CPA to include 
higher level
                     abstractions like service information and contractual 
obligations.


            Origin  'Possible New Work' Document

    Date of Origin

         Reference


  _______________________________________________________________




























                                           Page 74 of 171



          Category  Miscellaneous

         Submitter


          Issue ID  59

             Issue  Publishing Party capabilities with a CPA template 
instead of a CPP

       Description  There was discussion on the list server Feb. 6-8 about 
use of CPA
                    Templates in place of CPPs. This would simplify things 
for a small
                    business so that it doesn't have to go through the whole 
CPP and
                    composition process when all he needs to do is fill in a 
few items in
                     a CPA prepared large business.  The words in the spec 
are
                    sufficiently permissive to allow the possibility of the 
use of CPA
                    Templates but one could make it more explicit


            Origin  'Possible New Work' Document


    Date of Origin

         Reference

  _______________________________________________________________























                                           Page 75 of 171



          Category  Miscellaneous

         Submitter


          Issue ID  67

             Issue  Multiparty CPAs

       Description  Extension of the CPA to more than two parties could be 
considered.
                    Some (but not all) issues are:
                    ú Enforceability across more than two parties.
                    ú Namespace scope
                    ú Business signals
                    ú Conversation state tracking across more than two 
parties: does each
                     party need to know about interactions between the 
others?  How can
                    this be accomplished?



            Origin  'Possible New Work' Document

    Date of Origin

         Reference


  _______________________________________________________________





















                                           Page 76 of 171



          Category  Miscellaneous

         Submitter


          Issue ID  53

             Issue  Ambiguity re Routing of Response Messages to the Correct 
Software
                    Entry Point

       Description  ú There appears to be an ambiguity for the following 
case. The
                    ambiguity should be confirmed or refuted and, if it is 
ambiguous,
                    either fix the ambiguity or put in a statement that this 
is not a
                    valid case. The case boils down to the same party 
playing both roles
                    in the same business transaction.
                    " Each Party to the CPA includes two CollaborationRole 
elements that
                    point to the same Process-specification document.
                     In one CollaborationRole element, Party A has the role 
"seller"
                    (for example) and Party B has the role "buyer".
                     In the other CollaborationRole element, Party B has 
the role
                    "seller" and party A has the role "buyer".
                    " The same combination of binary collaboration and 
business
                    transaction is performed in both of the above cases 
(i.e. the two
                    Parties can switch roles).
                    " Both CollaborationRole elements specify delivery 
channels with the
                    same transport address (e.g. URL).
                    " The message service cannot tell whether an arriving 
message is a
                    request or a response message. It can only route based 
on transport
                    address, service, action, and role. If the same delivery 
channel
                    (same transport address) is used with both 
CollaborationRole
                    elements, the messaging service cannot tell whether to 
route the
                    message to Party A as "seller" (the first 
CollaborationRole element)
                    or to Party B as "seller" (the second CollaborationRole 
element).
                    " Use of ConversationId and CPAId in routing may resolve 
the
                    ambiguity. In addition, we could make use of the 
RefToMessageId
                    element in the message header as part of the routing 
information.
                    See the "RefToMessageId" below.





            Origin  'Possible New Work' Document

    Date of Origin


         Reference

                                           Page 77 of 171________








          Category  Miscellaneous

         Submitter  Chan

          Issue ID  127


             Issue  Specializations of generic business messages for 
specific partners

       Description  The schema of a business document may contain certain 
optional
                    fields.
                    However, two trading partners may specifically require 
some of these

optional fields be always present in their exhanged messages. Should
                     this be
                    specifiable through the CPP/A?


            Origin  email

    Date of Origin  8/23/2001


         Reference  Subject: Potential 2.0 requirement

  _______________________________________________________________



















                                           Page 78 of 171



          Category  Miscellaneous

         Submitter  Weida


          Issue ID  121

             Issue  Business rules and constraints

       Description  Capture business constraints and rules that specify 
context-dependent
                     validation of a B2BI system's runtime behavior (for 
both profiles
                    and agreements).  See cited reference for more details.


            Origin  Scottsdale F2F

    Date of Origin


         Reference  
http://www.oasis-open.org/committees/ebxml-cppa/meetings/business_rul
                    es_and_constraints.ppt

  _______________________________________________________________


























                                           Page 79 of 171



          Category  Miscellaneous

         Submitter  Hayes


          Issue ID  140

             Issue  invocationLimit attribute appears to be a CPA Lifetime 
attribute

       Description  CPA Lifetime and Conversation Constraints: The 
invocationLimit
                    attribute appears to be a CPA Lifetime attribute and not 
a
                    conversation constraint.


            Origin  email

    Date of Origin  9/27/2001


         Reference  Subject: CPPA Version 1.0 Comments And Issues

  _______________________________________________________________



























                                           Page 80 of 171



          Category  Miscellaneous

         Submitter  Hayes


          Issue ID  143

             Issue  Adding a ccpid element to the 
CollaborationProtocolProfile.

       Description  CPP Structure: Recommend adding a ccpid element to the
                    CollaborationProtocolProfile.  This would be used to 
uniquely
                    identify the CPP and will be useful when a business has 
more than one
                     CPP.  I also recommend that we provide a recommendation 
(even a
                    non-normative one ) on the format of the identifier.  
See the BPINS
                    scheme in [bpWS].


            Origin  email


    Date of Origin  9/27/2001

         Reference  Subject: CPPA Version 1.0 Comments And Issues

  _______________________________________________________________
























                                           Page 81 of 171



          Category  Miscellaneous

         Submitter  Hayes


          Issue ID  144

             Issue  CPP Categories

       Description  Recommend that there be an optional way of categorizing 
CPPs. Perhaps
                     this implemented by registries; however, I much prefer 
there could
                    be a category element as part of the 
CollaborationProtocolProfile.
                    It should be possible to specify one or more categories. 
  The
                    category should be a URI and a recommend categorization 
scheme would
                    be TBD (the values might have semantics of MRO goods, 
direct goods,
                    aerospace, etc.  Interesting enough, the categories 
could possibly be
                     used as part of the Core Components Context).Putting 
the category
                    information into the CPP is preferred over the registry 
approach
                    since the registry (or a sophisticated registry) is not 
required for
                    use of CPPs.



            Origin  email

    Date of Origin  9/27/2001


         Reference  Subject: CPPA Version 1.0 Comments And Issues

  _______________________________________________________________


















                                           Page 82 of 171



          Category  Miscellaneous

         Submitter  Hayes


          Issue ID  145

             Issue  CPA Categories

       Description  Recommend CPA Categories.  See comment regarding CPP 
Categories
                    (ISSUE 144).


            Origin  email

    Date of Origin  9/27/2001

         Reference  Subject: CPPA Version 1.0 Comments And Issues


  _______________________________________________________________


          Category  Negotiation

         Submitter


          Issue ID  12

             Issue  Negotiation of CPA contents

       Description  The negotiation team is currently elaborating on this 
general issue.
                     Marty Sachs suggested that we defer inclusion of 
specific
                    negotiation issues in this database for now.


            Origin  'Possible New Work' Document

    Date of Origin


         Reference

  _______________________________________________________________




                                           Page 83 of 171



          Category  Negotiation

         Submitter


          Issue ID  57

             Issue  PartyId type

       Description   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.


            Origin  'Possible New Work' Document

    Date of Origin


         Reference

  _______________________________________________________________


          Category  Negotiation


         Submitter

          Issue ID  13

             Issue  Negotiation of Business-level parameters


       Description  This issue is a general placeholder to be elaborated on 
some time in
                    the future.

            Origin  'Possible New Work' Document


    Date of Origin

         Reference

  _______________________________________________________________



                                           Page 84 of 171



          Category  Packaging

         Submitter


          Issue ID  5

             Issue  Packaging

       Description  Improvements to packaging definition including security 
capabilities.
                     Specific problems related to XMLDSIG have been noted 
(Dale Moberg
                    5/3/01)

                    See also email re: S/MIME, Dale Moberg, August 16, 2001 
ff


            Origin  'Possible New Work' Document

    Date of Origin


         Reference

  _______________________________________________________________

























                                           Page 85 of 171



          Category  Packaging

         Submitter


          Issue ID  36

             Issue  Virtual Packaging

       Description  Enhance notation to capture the "virtual packaging" used 
by XMLDsig
                    external references.


            Origin  'CPA-CPP Changes to Consider' document

    Date of Origin

         Reference


  _______________________________________________________________




























                                           Page 86 of 171



          Category  Packaging

         Submitter  Chan


          Issue ID  89

             Issue  Linkage of SimplePart element to BusinessDocument at the 
BPSS level


       Description  One or more business signals, along with a business 
response can
                    be carried in the same ebXML message in the synchronous 
reply
                    mode. I suspect that each of the above has to be treated 
as one
                    attachment to the SOAP message with attachments.

                    The CPP/CPA has a Packaging element that is supposed to
                    describe the constituents of a payload and its security 
packaging.
                    However, the SimplePart element in the CPP/A currently 
does not
                    seem to have any linkage to a BusinessDocument at the 
BPSS level

                    I think this is an alignment issue among the MSG, CPP/A, 
and
                    eBTWG workgroups.



            Origin  email

    Date of Origin  8/29/2001


         Reference  Subject: Re: "Primary Business Document"

  _______________________________________________________________
















                                           Page 87 of 171



          Category  Packaging

         Submitter  Moberg


          Issue ID  35

             Issue  Grammars for packaging

       Description  Investigate using "grammars" to provide more compact 
means of
                    expressing packaging parsing and generative 
capabilities.


            Origin  'CPA-CPP Changes to Consider' document

    Date of Origin

         Reference


  _______________________________________________________________


          Category  Packaging

         Submitter  Hayes


          Issue ID  152

             Issue  Need for packageId attribute if there is only one 
Package per CPP/CPA


       Description  xxx


            Origin  email

    Date of Origin  9/27/2001

         Reference  Subject: CPPA Version 1.0 Comments And Issues


  _______________________________________________________________





                                           Page 88 of 171



          Category  Security

         Submitter


          Issue ID  10

             Issue  Security attributes under Characteristics element

       Description  Define security attributes under the Characteristics 
element in
                    enough detail to understand what has to be specified in 
doc exchange
                    and transport to support them and enable a tool to check 
for
                    consistency between Characteristics and the details in 
DocExchange
                    and Transport.


            Origin  'Possible New Work' Document

    Date of Origin


         Reference

  _______________________________________________________________

























                                           Page 89 of 171



          Category  Security

         Submitter


          Issue ID  9

             Issue  Certificates

       Description  Replace ds:keyinfo element by a definition that does not 
embed the
                    actual ceritficate in the CPP or CPA.

                    From Security Issues 01-08-26.doc (via Tim Collier): 
Depending on how
                     it is used, the ds:keyinfo element can contain an 
actual
                    base-64-encoded certificate. Except for signing of the 
CPP or CPA,
                    there is no need for actual certificates to be embedded 
in the CPP or
                     CPA. The Certificate element should be changed to point 
to
                    information at a key-management service instead.



            Origin  'Possible New Work' Document

    Date of Origin

         Reference


  _______________________________________________________________




















                                           Page 90 of 171



          Category  Security

         Submitter


          Issue ID  8

             Issue  Signing of payload and header

       Description  Signing of payload and header vs. signing only of 
payload and
                    response.


            Origin  'Possible New Work' Document

    Date of Origin

         Reference


  _______________________________________________________________


          Category  Security

         Submitter


          Issue ID  7

             Issue  Nonrepudiation of receipt

       Description  Specification of nonrepudiation of receipt.


            Origin  'Possible New Work' Document

    Date of Origin

         Reference


  _______________________________________________________________






                                           Page 91 of 171



          Category  Security

         Submitter


          Issue ID  6

             Issue  NonRepudiation element improvements

       Description  Nonrepudiation improvements including possible addition 
of other
                    elements that reflect choices that can be made 
(Transform?). A
                    possibility is that this element could take the form of 
a Signature
                    "template" which effectively provides the entire 
requisite binding
                    information including reference URI(s) with only the 
Digest and
                    actual signature omitted. This would be similar to the 
way we now
                    define the signature.  See listserver discussion 6/13-01 
- 6/14/01.


            Origin  'Possible New Work' Document


    Date of Origin

         Reference

  _______________________________________________________________























                                           Page 92 of 171



          Category  Security

         Submitter


          Issue ID  5

             Issue  Packaging

       Description  Improvements to packaging definition including security 
capabilities.
                     Specific problems related to XMLDSIG have been noted 
(Dale Moberg
                    5/3/01)

                    See also email re: S/MIME, Dale Moberg, August 16, 2001 
ff


            Origin  'Possible New Work' Document

    Date of Origin


         Reference

  _______________________________________________________________

























                                           Page 93 of 171



          Category  Security

         Submitter


          Issue ID  58

             Issue  Digests of Other External Documents

       Description  If other external documents, such as security profiles, 
are
                    introduced, the possibility of creating digests of those 
document,
                    similar to what is specified for the Process 
Specification document
                    should be considered in order to detect alterations.


            Origin  'Possible New Work' Document

    Date of Origin


         Reference

  _______________________________________________________________


          Category  Security


         Submitter

          Issue ID  4

             Issue  Public-Key Infrastructure


       Description  Public-Key Infrastructure issues.

            Origin  'Possible New Work' Document

    Date of Origin


         Reference

  _______________________________________________________________




                                           Page 94 of 171



          Category  Security

         Submitter


          Issue ID  3

             Issue  Security policy element

       Description  We should consider a Security policy element.


            Origin  'Possible New Work' Document

    Date of Origin

         Reference


  _______________________________________________________________


          Category  Security

         Submitter


          Issue ID  11

             Issue  Third-party security services

       Description  Use of third-party security services (this is a special 
case of an
                    intermediary).


            Origin  'Possible New Work' Document

    Date of Origin

         Reference


  _______________________________________________________________






                                           Page 95 of 171



          Category  Security

         Submitter


          Issue ID  2

             Issue  Security profile

       Description  Security profile developed by the ebXML security team.  
From the
                    Technical Architecture Risk Assessment technical report:

                    This element would advertise the set of security 
mechanisms a party
                    understands, the profiles for those mechanisms, and the 
trust anchors
                     that will be issuing the credentials used within that 
policy.  The
                    policies can be asymmetric, allowing separate 
identification of what
                    it can accept from what it will, itself, generate. For 
example, a
                    party might accept SSL-protected messages, but will 
itself, only
                    generate [XMLDSIG] signed acknowledgements.



            Origin  'Possible New Work' Document

    Date of Origin


         Reference

  _______________________________________________________________



















                                           Page 96 of 171



          Category  Security

         Submitter


          Issue ID  1

             Issue  Technical Architecture Risk Assessment

       Description  Technical Architecture Risk Assessment technical report
                    recommendations related to CPP/CPA.  (Note:  some items 
below may
                    duplicate material in that report.)


            Origin  'Possible New Work' Document

    Date of Origin


         Reference  http://www.ebxml.org/specs/ebTA.pdf

  _______________________________________________________________



























                                           Page 97 of 171



          Category  Security

         Submitter


          Issue ID  40

             Issue  BPSS isNonrepudiationRequired attribute and CPPA 
Nonrepudiation
                    element

       Description  The BPSS defines this attribute as requiring the message 
sender to
                    save an audit trail. It has no signing semantics. The 
isTamperProof
                    attribute controls signing of the business document. 
isTamperProof
                    may be needed in the CPP-CPA Characteristics element.

                    The CPP-CPA Nonrepudiation element is defined as 
covering signing and
                     "prevents later nonrepudiation".  Perhaps the 
definition should be
                    expanded to explicitly cover the rule about audit trail 
that is
                    stated in the BPSS



            Origin  'Possible New Work' Document

    Date of Origin

         Reference


  _______________________________________________________________



















                                           Page 98 of 171



          Category  Security

         Submitter


          Issue ID  41

             Issue  Nonrepudiation of business signals

       Description  Does the CPP-CPA need definitions in the delivery 
channel, in
                    addition to listing the attributes in the 
Characteristics element,
                    that support nonrepudiation of origin and receipt?


            Origin  'Possible New Work' Document

    Date of Origin


         Reference

  _______________________________________________________________



























                                           Page 99 of 171



          Category  Security

         Submitter  Chan


          Issue ID  117

             Issue  Clarify and detail support of SSL mutual authentication

       Description   took a look at the Communication Protocol Bindings 
section (Appendix
                     B) in
                    the Message Service Spec. Lines 2843 to 2845  state:

                    "Both [RFC2246] and [SSL3] require the use of server 
side digital
                    certificates. In addition client side certificate based
                    authentication is
                    also permitted. ebXML Message Service handlers MUST 
support
                    hierarchical
                    and peer-to-peer trust models."

                    Therefore, I think the CPP/A 1.1 spec needs to be fixed 
to support
                    mutual
                    authentication.

                    In addition, lines 2823 to 2828 in the Message Service 
spec state:

                    "Implementers MAY protect their ebXML Message Service 
Handlers from
                    unauthorized access through the use of an access control 
mechanism.
                    The HTTP
                    access authentication process described in "HTTP 
Authentication:
                    Basic and
                    Digest Access Authentication" [RFC2617] defines the 
access control
                    mechanisms allowed to protect an ebXM L Message Service 
Handler from

unauthorized access. Implementers MAY support all of the access
                    control
                    schemes defined in [RFC2617] however they MUST support 
the Basic
                    Authentication mechanism, as described in section 2, 
when Access
                    Control is
                    used."

                    More changes to the CPP/A spec will be necessary to 
support Basic
                    Authentication. However, I seriously doubt if basic 
authentication
                    which
                    sends user name and password in cleartext is suitable 
for conducting
                    E
                    business transactions. Perhaps we should lobby the MSG 
TC to remove
                    the


                                          Page 100 of 171

            Origin  email











                                                                        .1 
spec.


    Date of Origin  8/21/2001

         Reference  See separate email threads started by Arvola Chan on 21 
Aug 2001
                    regarding "Does CPA support SSL mutual authentication?" 
and on 23 Aug
                     2001 "Re: SSL Mutual Authentication and the Message 
Service Spec".
                    Also thread by Dale Moberg re "Transport related 
authentication in
                    CPA (was SSL Mutual Authenticationand the Message 
Service Spec)" on
                    29 Aug 2001.


  _______________________________________________________________


























                                          Page 101 of 171



          Category  Security

         Submitter  Chan


          Issue ID  124

             Issue  Possible addition of CipherSuites element under 
TransportSecurity

       Description  Section B.2.7 in the Message Service spec states:
                    ebXML Message Service Handlers MAY use any of the 
allowable
                    encryption algorithms and key sizes specified within 
[RFC2246]. At a
                    minimum ebXML Message Service Handlers MUST support the 
key sizes and
                     algorithms necessary for backward compatibility with 
[SSL3].The
                    following cipher suites are defined in [RFC2246]: [ . 
see cited email
                     for complete list . ]


                    Do we have to add a CipherSuites element to the 
TransportSecurity
                    element to indicate the cipher suites that are supported 
by the
                    destination party?

                    [See cited email for detailed list of suites]



            Origin  email


    Date of Origin  8/23/2001

         Reference  Subject: Encryption Algorithms and Key Sizes for 
Transport Level
                    Security

  _______________________________________________________________














                                          Page 102 of 171



          Category  Security

         Submitter  Chan


          Issue ID  90

             Issue  T2 Non repudiation and MSG, CPP/A, BPSS spec alignment

       Description  The BPSS spec says that nonRepudiationOfReceipt (NRR) is 
tied to the

ReceiptAcknowledgement signal. NRR and reliable messaging are
                    orthogonal. A
                    business process may specify the non repudiation of 
receipt for the
                    requesting business activity business message and/or the 
repudiation
                    of
                    receipt for the responding business activity business 
message,
                    without
                    requiring that reliable messaging be used. I think the 
Messaging
                    Service
                    should not tie NRR to the DeliveryReceipt element if the 
latter is
                    used
                    exclusively in reliable messaging.

                    The MSH is not responsible for validating the syntax of 
payloads. NRR
                     at the
                    MSH level does not really implement NRR as called for by 
the business
                    process specification. NRR at the BPSS level includes 
syntax
                    validation on
                    the payloads. Receipt Acknowledgement business signals 
have to be
                    persisted
                    in order to satisfy legal requirements implied by NRR. I 
just don't
                    see the
                    utility of persisting the DeliveryReceipt generated at 
the MSH level
                    in
                    addition to the ReceiptAcknowledgement signal. This may 
just be
                    unnecessary
                    overhead.

                    Currently, NRR parameters are tied to the 
DeliveryChannel element in
                    the
                    CPP/A. According to Marty, these parameters may have to 
be relocated
                    / added
                    to the ProcessSpecification and/or the Role element in 
order to
                    properly
                    model the non repudiation requirements associated with 
the business
                    process.



                                          Page 103 of 171

email       Originemail











                    I strongly feel that non repudation is one area that the 
MSG, CPP/A,

                                                                        heir 
1.1
                    specifications.
    Date of Origin  8/30/2001

         Reference  Subject: T2 Non repudiation and MSG, CPP/A, BPSS spec 
alignment

  _______________________________________________________________































                                          Page 104 of 171



          Category  Security

         Submitter  Chan


          Issue ID  104

             Issue  Nonrepudiation archival

       Description  Don't non repudiation of origin and non repudiation of 
receipt imply
                    that the recipient has to keep a persistent copy of the 
message for
                    some rather long period of time (typically of the order 
of years)?

                    Is this duration implicit (i.e., has the same value for 
all cases) or
                     should it be represented explicitly in the CPA?

                    Another related question is whether the logging 
functionality to
                    support non repudiation belongs above or below the 
Message Service
                    Interface.



            Origin  email

    Date of Origin  8/16/2001


         Reference  Subject: Non Repudiation

  _______________________________________________________________



















                                          Page 105 of 171



          Category  Security

         Submitter  Chan


          Issue ID  113

             Issue  Clarification of NamespaceSupported element advertising 
in CPP

       Description  From response by Dale M.  on 20 Aug 2001: . .. because 
adding
                    namespaces is one way that XML infosets are extended,
                    interoperability can be expected to involve support for 
namespaces
                    that are used, either in the header or in the payload. 
Is this
                    obscure? We can certainly add some more text to clarify 
that the
                    point of a CPP is to advertise capabilities with the 
view of
                    promoting interoperability.  .

                    From Tim C.'s Security Issues 01-08-26.doc: Yes. Perhaps 
an example
                    omitting XMLDsig and using SMIME encryption would have 
been more
                    useful. In addition, when a namespace URI for XML 
encryption emerges,
                     we can add that to the list if it is to be used even 
though it is
                    not a part of MS
                    G spec now. Finally, the constituent specs are to be 
modular and
                    possibly independent. What is required by MSG is not 
necessarily
                    required by CPPA. So what can be a default because it is 
part of MSG
                    would be OK if we agree to make all features of MSG the 
default for
                    CPPA. That has not been proposed as yet, and it may tend 
to conflict
                    with the intent to have each spec remain modular and 
independent.





            Origin  email


    Date of Origin

         Reference  Subject: What is the purpose of the NamespaceSupported 
element?

  _______________________________________________________________








                                          Page 106 of 171



          Category  Security

         Submitter  Chan


          Issue ID  123

             Issue  Indicate use of  basic authentication

       Description  Request from Arvola Chan, with the following response 
from Dale
                    Moberg: OK, I could see that we could add a detail
                    under TransportSecurity element, even if MSG decides to
                    drop discussion of any HTTP auth. mechanism.
                    Is there a standardized way of referring to
                    different HTTP auth mechanisms that we could reuse
                    (like a URI, OID or whatever...)?


            Origin  email


    Date of Origin  8/28/2001

         Reference  Subject: Re: SSL Mutual Authentication and the Message 
Service Spec


  _______________________________________________________________






















                                          Page 107 of 171



          Category  Security

         Submitter  Chan


          Issue ID  118

             Issue  Problem with Non Repudiation over a Synchronous Delivery 
Channel

       Description  The CertificateRef under NonRepudiation is presumably 
the
                    certificate used by the sender for signing.

                    What happens if syncReplyMode is set to something other
                    than None? In that case, the receiver (responder) has to
                    deliver the response document over the same channel. 
Where
                    is the CertificateRef for signing by the responder?


            Origin  email


    Date of Origin  8/21/2001

         Reference  Subject: Does CPA support SSL mutual authentication?

  _______________________________________________________________























                                          Page 108 of 171



          Category  Security

         Submitter  Mukkamala


          Issue ID  29

             Issue  Signed delivery receipt

       Description  Hima,

                    I have added a comments to the first question below.
                    We can follow up tomorrow if time permits.

                    Dale

                    Hima wrote:
                    "1) How could you request a Delivery Receipt 
signed/unsigned
                    using CPA as the governing document for messaging"

                    DWM>>
                    I assume we are talking about Delivery Receipts within 
the
                    ebxml Oasis MSG specification, and not any other flavor.

                    The MSG spec now has both Acknowledg(e)ments (primarily 
used
                    for support of RM) and Delivery Receipts, which are 
apparently
                    classified as business level messages.(!) Moreover, the 
Delivery
                    Receipts appear to be quite similar to Acknowledgements, 
and
                    Acknowledgements can include a Reference and hash of the 
original
                    message. I hope that usage and distinctions pertaining 
to
                    all these "signals" or messages
                    can be one item we get clear on
                    at the joint meeting.

                    I believe that in v1.0, some information about Delivery 
Receipts
                    is found under the 
../DocExchange/ebXMLBinding/nonRepudiation path,
                    when the CollaborationRole is for the Response side of a
                    conversation.
                    Other information is under
                    
../DeliveryChannel/Characteristics/[@='nonRepudiationOfReceipt'],
                    a boolean that tells us that the conversation is making 
use of
                    nonRepudiationOfReceipt
                    and with ebXML bindings, which means to do it "the" MSG 
way,
                    we know we need to return a Delivery Receipt, I think.

                    Now, since there is an Ack. with some receipt like 
characteristics
                    and a DeliveryReceipt with receipt like characteristics, 
which is to


                                          Page 109 of 171













be used. I think this is one thing we have to straighten out. We
                    might
                    disambiguate by means of something in Packaging that 
indicates
                    whether
                    the SOAP Header is an Ack or DR. Anyway, I think we need 
to nail this
                    down by 1.1. There was a lot of seemingly minor 
adjustments in MSG
                    at the 1.0 level and I am not certain that we tracked 
them all.

                    We also need to investigate whether to remove the scope 
barriers to
                    capturing interop info about signals. And how to 
indicate MSH to MSH

layer traffic and how to indicate APP to APP traffic...

                    3 SOAP-SEC extensions and signatures in ebXML messages
                    Given that an ebXML message is carried within a SOAP 
message, there
                    are currently two ways of signing messages. This may 
cause some
                    confusion or runtime failures due to misinterpretation. 
There has
                    been a note posted to the W3C, which identifies one 
possible set of
                    processing instructions for signing SOAP messages.  
Below are some
                    "similarities and differences" that may help people wade 
through the
                    notations. In addition, there is a good reminder in the 
concluding
                    section of the XMLDSIG note about digital signature not 
itself
                    preventing replay attacks. The "no-dupes" of reliable 
messaging can
                    be used to address this type of attack.
                    1. SOAP-SEC[SOAP-SEC] uses its own namespace and has a 
schema that
                    wraps around the XMLDSIG namespace, unlike the ebXML 
example.
                    2. SOAP-SEC and ebXML Digital Signatures both have the 
signature
                    under the SOAP-ENV:Header.
                    3. The SOAP-SEC schema allows just one signature
                    4. SOAP-SEC uses the SOAP-ENV:actor and 
SOAP-ENV:mustUnderstand
                    elements, whereas the ebXML example does not.
                    5. The actual W3C XMLDSIG machinery is shared. Of 
course, the ebXML
                    example illustrates using an XPATH transform to cut out 
the
                    TraceHeaderList (though the S1 value for the id 
attribute doesn't
                    point to anything in the ebxml example)
                    6. The ebXML-Sig Reference [ebMS] mechanism uses cid: 
style URIs, but
                     these are also acceptable in SOAP-SEC (section 3.2).
                    7. SOAP-SEC uses the soap protocol conventions of the 
mustUnderstand
                    and actor constructs. It is not certain whether this is 
an advantage


                                          Page 110 of 171

    Date of Origin  8/22/2001
         Reference  Subject: 1.0 Questions
  _______________________________________________________________











                    or just overhead. It might be a disadvantage if SOAP 
processing and
                    ebXML MSH processing are "walled-off". In that case, no 
defined lines
                     of communication to the MSH from the SOAP layer exist 
so that MSH
                    won't have access to the outcomes of checking. In 
general, it is
                    difficult to assess the impact on implementations, but 
using SOAP-SEC
                     within ebXML would tend to promote writing a SOAP 
processing layer


































                                          Page 111 of 171



          Category  Security

         Submitter  Sachs


          Issue ID  93

             Issue  Clarity of text re NRR / Delivery Channel and/or 
separate send
                    delivery channel

       Description  NRR is expressed in the CPA by the NonRepudiation 
element under
                    ebXMLBinding in the delivery channel.  The delivery 
channel describes
                     a
                    Party's receive properties.  Nonrepudiation requires 
action by both
                    parties.  However signing is done by the From Party.  So 
having it
                    NRR in
                    the delivery channel (receive properties) is a bit 
peculiar.  The
                    points
                    that I don't think I made previously are these:

                       Although NonRepudiation is in the delivery channel 
(receive
                    properties),
                       the certificate which must be referenced is for 
signing the
                    message.
                       This certificate belongs to the From party, not the 
To party.  If
                    we
                       leave NonRepudiation where it is, the text must make 
it clear that
                     the
                       certificate is one belonging to the other party, not 
the party
                    that owns
                       this delivery channel.

                        Because the certificate belongs to the other party, 
the
                    certificate
                       reference is meaningless in the CPP.  The text should 
state that
                    the
                       certificate referenced in the CPP must be replaced  
by a reference
                     to
                       the other party's certificate when the CPA is 
composed.

                    A better solution is to provide "send" delivery channels 
along with
                    the

            Origin  email


    Date of Origin  9/6/2001

         Reference  Subject: Nonrepudiation of receipt in CPA
                                          Page 112 of 171
                                                         ________







          Category  Security

         Submitter  Moberg


          Issue ID  91                  hannels though this is probably out 
of scope for
                    V1.1.
             Issue  Delivery Receipt, NRR and MSG/CPPA/BPSS (mis-)alignment 
and
                    thelayering mishmash

       Description  Details to be distilled.  See the thread starting with 
the cited

            Origin  email


    Date of Origin  8/31/2001

         Reference  Subject: Delivery Receipt, NRR and MSG/CPPA/BPSS 
(mis-)alignment and
                    thelayering mishmash (was jumbled into: reliable 
messaging - hop by
                    hop)

  _______________________________________________________________






















                                          Page 113 of 171



          Category  Security

         Submitter  Moberg


          Issue ID  122

             Issue  Generalized credential container

       Description  Possibly we could use an xlink/xpointer/URI to within 
the CPA to
                    reference a generalized credential container if there is 
a need to
                    establish links between CPAs and credentials. (This 
credential
                    container would be something like the pkcs12 container 
used for
                    keypairs; I haven't yet encountered an XML credential 
store container
                     format that has been proposed, though.)


            Origin  email


    Date of Origin  8/28/2001

         Reference  Subject: RE: SSL Mutual Authentication and the Message 
Service Spec


  _______________________________________________________________























                                          Page 114 of 171



          Category  Security

         Submitter  Collier


          Issue ID  94

             Issue  Signature Method Element

       Description  In the 1.0 CPPA spec (lines 3116 to 3118), we have the 
following
                    declarations:

                        <element name="HashFunction" type="string"/>
                        <element name="EncryptionAlgorithm" type="string"/>
                        <element name="SignatureAlgorithm" type="string"/>

                    On the other hand, the April 19, 2001 W3C Candidate 
Recommendation of
                     XML-Signature shows:

                       <element name="SignatureMethod" 
type="ds:SignatureMethodType"/>
                       <complexType name="SignatureMethodType" mixed="true">
                         <sequence>
                           <element name="HMACOutputLength" minOccurs="0"
                    type="ds:HMACOutputLengthType"/>
                           <any namespace="##other" minOccurs="0" 
maxOccurs="unbounded"/>
                           <!-- (0,unbounded) elements from (1,1) external 
namespace -->

      </sequence>
                        <attribute name="Algorithm" type="anyURI" 
use="required"/>
                       </complexType>

                    This means that the SignatureMethod element in 
XML-Signature may have
                     an optional HMACOutputLength sub-element plus 0 or more 
wildcard
                    elements from other namespaces. Shouldn't 
SignatureAlgorithm be
                    defined in the CPPA spec accordingly?

                    Likewise, I think it may be useful to allow wildcard
                    attributes/sub-elements in the declaration of 
HashFunction and
                    EncryptionAlgorithm to provide for the specification of 
properties
                    like encryption strength.

                    In addition, the following sentence on lines 874-876 
does not seem to
                     make sense:

                    "As an alternative to the string value of the 
ds:DigestMethod, shown
                    in the above example, the child element, 
ds:HMACOutputLength, with a
                    string value, MAY be used."



                                          Page 115 of 171












                    It does not correspond to the example on lines 811-814 
(which in
                    itself seems erroneous, the HMACOutputLength should be a 
number, not
                    a string) or to the schema definition of ds:DigestMethod 
in
                    XML-Signature:

                       <element name="DigestMethod" 
type="ds:DigestMethodType"/>
                       <complexType name="DigestMethodType" mixed="true">
                         <sequence>
                           <any namespace="##other" processContents="lax" 
minOccurs="0"
                    maxOccurs="unbounded"/>
                         </sequence>
                         <attribute name="Algorithm" type="anyURI" 
use="required"/>
                       </complexType>

                    According to the above definition, any sub-element under 
DigestMethod
                     would have to come from some other namespace!

            Origin  Security Issues 01-08-26.doc


    Date of Origin

         Reference

  _______________________________________________________________















                                          Page 116 of 171



          Category  Security

         Submitter  Collier


          Issue ID  96

             Issue  Key Management

       Description  Key management is a major issue that needs to be 
addressed with
                    respect to the capabilities of the TR& P Message Service 
Handler. In
                    particular, if the MSH will be called upon to apply 
digital
                    signatures, the appropriate private keys must be 
available to the
                    MSH. Private keys must be managed very carefully and 
deliberately.
                    Thus, some configuration will be necessary to establish 
the key
                    management mechanisms to be used by the MSH.


            Origin  ebXML Technical Architecture Risk Assessment v1.0


    Date of Origin

         Reference

  _______________________________________________________________























                                          Page 117 of 171



          Category  Security

         Submitter  Collier


          Issue ID  99

             Issue  Signing Message Parts

       Description  To address the secure packaging part of the Transport 
Routing &
                    Packaging configuration in the CPP, the CPP should also 
document the
                    packaging of the message header, payload and attachments 
so that
                    S/MIME or XMLDSIG can be used to protect the appropriate 
elements of
                    the message.  If the packaging is well defined, it will 
allow the
                    security tags within the CPP to specify the appropriate 
certificate
                    data (X.509, PGP, etc.) to be applied to securely 
sign/encrypt the
                    elements of the Message.



            Origin  ebXML Technical Architecture Risk Assessment v1.0

    Date of Origin

         Reference


  _______________________________________________________________





















                                          Page 118 of 171



          Category  Security

         Submitter  Collier


          Issue ID  100

             Issue  Use of Schema: Application to individual elements

       Description  In the current version of the CPP/CPA, the specification 
of security
                    elements is limited.  It is recommended that XML schema 
be considered
                     to more effectively express security attributes.  For 
example, the
                    security characteristic is a single element that 
contains attributes
                    with Boolean values indicating whether or not a security 
attribute
                    has been addressed.  It would be useful to have the 
security
                    characteristics have a type and be able to have a 
reference id to
                    include on lower elements (like the transport element), 
which contain
                     the details like the protocol.



            Origin  ebXML Technical Architecture Risk Assessment v1.0

    Date of Origin

         Reference


  _______________________________________________________________




















                                          Page 119 of 171



          Category  Security

         Submitter  Collier


          Issue ID  102

             Issue  Nonrepudiation in the delivery channel vs. the 
certificate in the
                    role tag.

       Description  Discussion is needed on the function of nonrepudiation 
in the
                    delivery channel vs. the certificate in the role tag. 
Chris Ferris'
                    comment on this:

                    I for one believe that it is only useful when signing 
both header and
                    payload together. Of course, there has also been 
discussion that the

only meaningful NR signature is that where the "application" signs
                    the
                    payload (or header and payload) and the ack. This needs 
more scrutiny

                    [TW: Tim included this from Marty's "CPPA Changes to 
Consider"
                    document.  Should possibly combine this with 
"NonRepudation Tags"
                    issue]



            Origin  Security Issues 01-08-26.doc


    Date of Origin

         Reference

  _______________________________________________________________















                                          Page 120 of 171



          Category  Security

         Submitter  Collier


          Issue ID  103

             Issue  non-repudiation of receipt (NRR) at the message level

       Description  [TW: I'm keeping this discussion  intact for now to aid 
clarity; when
                     the constituent issues are actively addressed, they 
should be split
                    out as suggested below] Note This discussion focuses on 
message level
                     NRR. Application level responses are out of the scope 
of this
                    discussion.
                    From a top level (business level) perspective, the most 
important
                    issue is to determine exactly what parts of the message 
are subject
                    to NRR. For example, should NRR be applied to the 
payload items
                    and/or the header? One suggested solution would be to 
apply NRR to
                    only those parts of the message that were signed by the 
originator.
                    Another issue concerns how the NRR response should be 
sent back to
                    the message originator. Should the message be sent back 
as part of
                    another ebXML message, or should a separate mechanism be 
used (such
                    as AS1 and/or AS2)?
                    The third and final issue is determining what format the 
NRR response
                     should take. If it is chosen to use an externally 
defined transport
                    and format such as AS1 or AS2, then this decision is 
already made.
                    If, however, ebXML is the chosen transport, it needs to 
be decided
                    where the NRR response should reside (in the SOAP 
header, or body,
                    etc.). Additionally, the content of the NRR needs to be 
decided. It
                    has been proposed within the TRP group that a NRR 
response should
                    simply be the acknowledgements element which has been 
signed, but
                    that neglects to include a hash of the parts of the 
original document
                     for which the NRR is being generated. At a minimum, the 
hash of the
                    original message parts and a reference to those parts 
(such as the
                    acknowledgements element) must be signed to supply NRR. 
As part of
                    the format used, there much be a decision made about 
what algorithms
                    and transformations will be used to sign the NRR 
response.
                    Once all of those issues have been decided, there must 
be some
                    mechanism within the CPP for any optional information 
(such as the
                    scope of the desired NRR) to be supplied.







            Origin  ebXML Technical Architecture Risk Assessment v1.0

                                          Page 121 of 171

         Reference
  _______________________________________________________________











          Category  Security


         Submitter  Collier

          Issue ID  97

             Issue  Encouragement of selected protocols


       Description  In order to encourage maximum interoperability, the 
following
                    standard mechanisms are identified and vendors are 
encouraged to
                    implement them:
                    ú When exchanging identity information, use X.509v3 
Certificates that
                     follow the IETF profile (RFC2459 and its successors). 
[PKIX]
                    ú When symmetric-key encryption is needed, use  3DES or 
the AES.
                    ú When asymmetric encryption is needed, use RSA 
encryption with the
                    OAEP encryption scheme and a key size of 1024 or 2048 
bits.
                    ú When hashing (or digesting) is needed, use SHA-1.
                    When transport-level security is required, use SSLv3 or 
TLS with RSA
                    keys and the RC4 (or ARC4) stream cipher.


            Origin  ebXML Technical Architecture Risk Assessment v1.0


    Date of Origin

         Reference

  _______________________________________________________________









                                          Page 122 of 171



          Category  Security

         Submitter  Collier


          Issue ID  34

             Issue  Policy conditionals for security

       Description  Can we provide a way to determine the appropriate policy 
to use based
                     on some expressible condition.  Like,  if the value of 
the purchase
                    order is over $15,000 then use a digital signature of 
type "manager".



            Origin  Security Issues 01-08-26.doc

    Date of Origin


         Reference

  _______________________________________________________________


























                                          Page 123 of 171



          Category  Security

         Submitter  Collier


          Issue ID  33

             Issue  Minimum requirement for security

       Description  It is currently assumed that the collaboration agreement 
  (CPA)
                    reached between two Trading Partners adequately reflects 
the ordering
                     and priority of security policies stated in the CPP, 
but there is no
                     mechanism for establishing minimum security 
requirements.  The
                    current CPP DTD does not allow the tagging of security 
configuration
                    at a level that indicates what is required, what is 
optional, or what
                     is preferred.


            Origin  ebXML Technical Architecture Risk Assessment v1.0


    Date of Origin

         Reference

  _______________________________________________________________























                                          Page 124 of 171



          Category  Security

         Submitter  Collier


          Issue ID  31

             Issue  Trust anchor

       Description  This document proposes that a trust anchor element be 
created within
                    the CPP and that it be represented as an XML Digital 
Signature
                    [XMLDSIG] KeyInfo element. It is an endpoint for a set 
of credentials
                     used by the party. It is important to recognize that a 
single policy
                     will probably have multiple anchors. For example, a 
small enterprise
                     might have an SSL certificate from a DNS registrar, yet 
use PGP
                    [PGP] keys signed by a particular staff member for all 
purchasing
                    agents.

                    <SecurityPolicy>
                     <TrustAnchors>
                         <!-a set of <ds:KeyInfo> elements. -->
                         <ds:KeyInfo ID='foo'>...</ds:KeyInfo>
                         <ds:KeyInfo ID='bar'>...</ds:KeyInfo>
                         <ds:KeyInfo ID='chumley'>...</ds:KeyInfo>
                     </TrustAnchors>
                     <Profiles>
                         <!-- A set of "Profile" elements.  Each profile
                       identifies a profile, and then the anchors
                       used in that profile.  -->
                         <Profile ID="pf1" URN="urn" ANCHORS="foo bar"/>
                     </Profiles>
                     <WillUse>
                         <--  A set of profiles the party  will use. -->
                         <ProfileRef>pf1</ProfileRef>
                     </WillUse>
                     <WillAccept>
                         <--  A set of profiles the party  will accept. -->
                         <ProfileRef>pf1</ProfileRef>
                     </WillAccept>
                        </SecurityPolicy>






            Origin  ebXML Technical Architecture Risk Assessment v1.0

    Date of Origin
                                          Page 125 of 171

  _______________________________________________________________



















































                                          Page 126 of 171



          Category  Security

         Submitter  Collier


          Issue ID  30

             Issue  SOAP-SEC extensions and signatures in ebXML messages

       Description  Given that an ebXML message is carried within a SOAP 
message, there
                    are currently two ways of signing messages. This may 
cause some
                    confusion or runtime failures due to misinterpretation. 
There has
                    been a note posted to the W3C, which identifies one 
possible set of
                    processing instructions for signing SOAP messages.  
Below are some
                    "similarities and differences" that may help people wade 
through the
                    notations. In addition, there is a good reminder in the 
concluding
                    section of the XMLDSIG note about digital signature not 
itself
                    preventing replay attacks. The "no-dupes" of reliable 
messaging can
                    be used to address this type of attack.
                    1. SOAP-SEC[SOAP-SEC] uses its own namespace and has a 
schema that
                    wraps around the XMLDSIG namespace, unlike the ebXML 
example.
                    2. SOAP-SEC and ebXML Digital Signatures both have the 
signature
                    under the SOAP-ENV:Header.
                    3. The SOAP-SEC schema allows just one signature
                    4. SOAP-SEC uses the SOAP-ENV:actor and 
SOAP-ENV:mustUnderstand
                    elements, whereas the ebXML example does not.
                    5. The actual W3C XMLDSIG machinery is shared. Of 
course, the ebXML
                    example illustrates using an XPATH transform to cut out 
the
                    TraceHeaderList (though the S1 value for the id 
attribute doesn't
                    point to anything in the ebxml example)
                    6. The ebXML-Sig Reference [ebMS] mechanism uses cid: 
style URIs, but
                     these are also acceptable in SOAP-SEC (section 3.2).
                    SOAP-SEC uses the soap protocol conventions of the 
mustUnderstand and
                     actor constructs. It is not certain whether this is an 
advantage or
                    just overhead. It might be a disadvantage if SOAP 
processing and
                    ebXML MSH processing are "walled-off". In that case, no 
defined lines
                     of communication to the MSH from the SOAP layer exist 
so that MSH
                    won't have access to the outcomes of checking. In 
general, it is
                    difficult to assess the impact on implementations, but 
using SOAP-SEC
                     within ebXML would tend to promote writing a SOAP 
processing layer
                    as part of the MSH to facilitate communication.








                                          Page 127 of 171
                                                         essment v1.0
    Date of Origin
         Reference
  _______________________________________________________________















          Category  Security

         Submitter  Collier

          Issue ID  28


             Issue  Nonrepudiation of message parts

       Description  The move to using an underlying SOAP message envelope 
may require the
                     restructuring of the current CPP definition of the 
"nonrepudiation"
                    element and its sub elements.  The current tag specifies 
a protocol
                    and hash algorithm but does not adequately express how 
this can be
                    applied to an ebXML message (either parts or the 
complete message) to
                     provide evidence that the receiver has adequately 
verified the
                    receipt of a signed message and replied with a receipt 
acknowledging
                    the same hash value over the signed message.




            Origin  ebXML Technical Architecture Risk Assessment v1.0

    Date of Origin

         Reference


  _______________________________________________________________







                                          Page 128 of 171



          Category  Security

         Submitter  Collier


          Issue ID  79

             Issue  NonRepudiation tags

       Description  If two parties agree on complimentary roles within a 
process
                    specification, and agree on the document properties (in 
particular
                    signing)
                    don't the nonrepudiation elements in the delivery 
channel
                    characteristics
                    become superfluous?  After all, the parties have agreed 
on a process

specification that includes acknowledgement of receipt, and they
                    have agreed
                    on which documents have signatures attached (in the 
document
                    exchange).  To
                    me NRR sounds like a requirement on the BP, and NRO is a 
document
                    requirement for digital signature.
                     I have heard that the delivery channel is an 
implementation
                    convenience, which is ok, but it seems even for that the
                    authenticated tag
                    covers the digital signature requirement. And the 
implementation
                    already is
                    monitoring the runtime process according to the BPSS.
                     Do you think the nonrepudiation tags in the delivery 
channel express
                    unique requirements that are not already covered?







            Origin  email

    Date of Origin  7/31/2001

         Reference  Subject: Security - question about nonrepudiation


  _______________________________________________________________





                                          Page 129 of 171



          Category  Security

         Submitter  Collier


          Issue ID  32

             Issue  Public key policies

       Description  See example from Appendix C: Sample Certificate Policy 
Element


            Origin  ebXML Technical Architecture Risk Assessment v1.0

    Date of Origin

         Reference


  _______________________________________________________________





























                                          Page 130 of 171



          Category  Security

         Submitter  Clark


          Issue ID  129

             Issue  Non-PKI security

       Description  Jamie pointed out that the PKI and Certificate Authority 
(CA)
                    approach is not the only way; that peer-to-peer and PGP 
are also
                    good; we may not want to marry ourselves to PKI.

                    Marty mentioned that version 1.0 stops at the point of 
identifying
                    the certificate and doesn't get into other PKI issues.  
It was
                    observed that the spec doesn't talk about CA at all.


            Origin  Scottsdale F2F


    Date of Origin

         Reference

  _______________________________________________________________























                                          Page 131 of 171



          Category  Specification document

         Submitter


          Issue ID  64

             Issue  Title of XSD Appendix

       Description  The title of Appendix D should be "W3C XML Schema 
Document" or "XSD
                    Schema Document instead of "XML Schema Document". Note 
that the title
                     of the schema specification is "XML Schema".  (Sun 
submitted these
                    quality-review comments after the version-1 
specification was
                    published.)


            Origin  'Possible New Work' Document

    Date of Origin


         Reference

  _______________________________________________________________

























                                          Page 132 of 171



          Category  Specification document

         Submitter


          Issue ID  71

             Issue  Figures in version 1.0 specification

       Description  The figures should be redrawn with Word's own drawing 
tool.  This may
                     allow better control over the positioning of the 
figures than is
                    true with the current figures imported from PowerPoint.  
The
                    positions of the current figures are notoriously 
unstable with
                    respect to nearby text changes.

                    During the July 24-25 meeting, it was suggested that 
unchecking "move
                     object with text" would freeze the position of the 
figure and
                    eliminate the instability.

                    Redrawing the figures with the Word drawing tool should 
also allow
                    automatically numbered captions to be used instead of 
the captions
                    currently drawn within the figures.



            Origin  'Possible New Work' Document


    Date of Origin

         Reference

  _______________________________________________________________
















                                          Page 133 of 171



          Category  Specification document

         Submitter


          Issue ID  72

             Issue  Definitions of terms (post Vienna)

       Description   If the post-Vienna disposition of the ebXML 
specifications renders
                    global documents, such as the ebXML glossary, 
inoperative, the
                    definitions of terms should be restored to the CPA-CPP 
specification.
                      The definitions in the TP Requirements document are a 
starting
                    point but this list will have to be updated.


            Origin  'Possible New Work' Document

    Date of Origin


         Reference

  _______________________________________________________________

























                                          Page 134 of 171



          Category  Specification document

         Submitter  Chan


          Issue ID  106

             Issue  Incorrect cross-reference to BPSS element

       Description  Line 952 contains an incorrect reference to the 
business-partner-role
                     element.

                    ú name attribute of the business-partner-role element. 
952

                    It should be BusinessPartnerRole.


            Origin  email


    Date of Origin  8/17/2001

         Reference  Subject: <1.0 bug> Incorrect cross-reference to BPSS 
element

  _______________________________________________________________
























                                          Page 135 of 171



          Category  Specification document

         Submitter  Chan


          Issue ID  76

             Issue  Minor inconsistency in Section 8 of the CPPA spec

       Description  Section 8.1 shows an example CPA while Section 8.2 
describes the
                    element structure. The Packaging and Comment elements 
shown in
                    Section 8.1 are missing from Section 8.2.

                    To be consistent, Section 8.2 should mention the 
Packaging and
                    Comment elements and there should be a sub-section on 
Packaging added
                     to Section 8. There already is a Comment sub-section 
(8.8).


            Origin  email


    Date of Origin  7/26/2001

         Reference  Subject: Minor inconsistency in Section 8 of the CPPA 
spec

  _______________________________________________________________























                                          Page 136 of 171



          Category  Specification document

         Submitter  Chan


          Issue ID  105

             Issue  Non Meaningful Example of a Packaging element

       Description  Lines 1712 to 1733 in section 7.7 contains an example of 
the
                    Packaging element. The example is not meaningful because 
the
                    attributes are not given meaningful values. In 
particular, the
                    mimetype attribute in the Composite element has the 
value "type".
                    This is not consistent with the statement on line 1792 
that "this
                    will be some MIME composite type, such as 
"multipart/related" or
                    "multipart/signed". The mimetype "type" is also not a 
meaningful
                    illustration of the Encapsulation element.

                    I recommend substituting this example with the example 
on lines
                    1058-1074 from http://www.ebxml.org/specs/secRISK.pdf



            Origin  email

    Date of Origin  8/16/2001


         Reference  Subject: Non Meaningful Example of a Packaging element

  _______________________________________________________________


















                                          Page 137 of 171



          Category  Specification document

         Submitter  Chan


          Issue ID  112

             Issue  All examples that refer to tp:version="0.98b" should be 
updated.

       Description  Issue says it all.


            Origin  email

    Date of Origin  8/20/2001

         Reference  Subject: <1.0 bug> References to tp:version 0.98b


  _______________________________________________________________





























                                          Page 138 of 171



          Category  Specification document

         Submitter  Chan


          Issue ID  125

             Issue  Spelling of NonRepudiation element

       Description  The spelling for the NonRepudiation element is not 
consistent with
                    the spellings for the nonrepudiationOfOrigin and
                    nonrepudiationOfReceipt
                    attributes.

                    I recommend that the latter be changed to
                    nonRepudiationOfOrigin and nonRepudiationOfReceipt.


            Origin  email


    Date of Origin  8/23/2001

         Reference  Subject: Minor spelling inconsistency

  _______________________________________________________________























                                          Page 139 of 171



          Category  Specification document

         Submitter  Chan


          Issue ID  109

             Issue  Appendix D is out of date

       Description  Appendix D needs to be replaced with the contents of 
cpp-cpa-v1_0.xsd
                     and including the bug fixes I have reported in an 
earlier post.

                    The default namespace has to be set to
                    http://www.w3c.org/2000/10/XMLSchema.  Otherwise, the 
element names
                    like Element and Attribute would have to be qualified 
with the above
                    namespace.

                    The clause xmlns = "http://www.w3.org/2000/10/XMLSchema" 
is present
                    in cpp-cpa-v1_0.xsd but is missing from Appendix D.




            Origin  email

    Date of Origin  8/17/2001


         Reference  Subject: <1.0 bug> Appendix D is out of date

  _______________________________________________________________


















                                          Page 140 of 171



          Category  Specification document

         Submitter  Chan


          Issue ID  110

             Issue  Appendix D: Retries, RetryInterval, and PersistDuration

       Description  In order to conform to the W3C Recommended version of 
XMLSchema, the

following changes should be made to Appendix D:

                    - Retries should be of type integer, not string.

                    - RetryInterval should be of type Duration, not string.

                    - PersistDuration should be of type Duration, not 
timeDuration.

                    In addition, the example in section 7.6.4 should be 
changed
                    accordingly:

                    - The RetryInterval example should not assume the unit 
is second.

                    - The PersistDuration example should look like PT30S. 
(The P
                    designator
                      must always be present; the T designator must be 
present if any
                    time item
                      is present.)





            Origin  email


    Date of Origin  8/20/2001

         Reference  Subject: <1.0 bug> Retries, RetryInterval, and 
PersistDuration

  _______________________________________________________________








                                          Page 141 of 171



          Category  Specification document

         Submitter  Chan


          Issue ID  107

             Issue  Inconsistent spelling of uriReference

       Description  It is "anyURI" now in any event;-)

                    Cheers,

                    Chris

                    > Arvola Chan wrote:
                    >
                    > The example on lines 650 and 651 (section 7.5.1) uses 
uriReference.
                     This is consistent with all
                    > other examples with the exception of the one on line 
694 (section
                    7.5.2.3) which uses
                    > uri-reference.
                    >
                    > -Arvola
                    >




            Origin  email

    Date of Origin  8/17/2001

         Reference  (reply by Chris Ferris) Subject: Re: <1.0 bug> 
Inconsistent spelling
                    of uriReference


  _______________________________________________________________











                                          Page 142 of 171



          Category  Specification document

         Submitter  Sachs


          Issue ID  92

             Issue  Dependency on ebXML Requirements spec.

       Description  I suggest not referring to the ebXML Requirements 
Specification.  It
                    is not
                    clear to me that ebRS will continue to be updated by a 
global
                    requirements
                    team or that the individual new teams will keep it 
updated in another
                     way.
                    Important requirements-type matters should be spelled 
out in the MSG

specification.




            Origin  email

    Date of Origin  9/2/2001

         Reference  Subject: ebXML Requirements spec.


  _______________________________________________________________




















                                          Page 143 of 171



          Category  Specification document

         Submitter  Wang


          Issue ID  82

             Issue  SimplePart and NamespaceSupported elements

       Description  Section 7.7.3 SimplePart element should probabaly be 
numbered as
                    7.7.2.1 and its title should be "NamespaceSupported 
element".
                    (Section 7.7.2 already discusses SimplePart element.)

                    NamespaceSupported should in this context be a child of 
SimplePart,
                    and this should be straightened out for the v 1.1 
specification.



            Origin  email


    Date of Origin  8/2/2001

         Reference  (forwarded by Arvola Chan) Subject: Fw: renumber and 
retitle of
                    section 7.7.3

  _______________________________________________________________






















                                          Page 144 of 171



          Category  Specification document

         Submitter  Hayes


          Issue ID  149

             Issue  Explicitly identify/discuss ds:URI and ds:Digest 
elements (of
                    ds:Reference)

       Description  The ds:URI and ds:Digest elements (of ds:Reference) 
should be
                    explicitly identified and discussed.


            Origin  email

    Date of Origin  9/27/2001

         Reference  Subject: CPPA Version 1.0 Comments And Issues


  _______________________________________________________________



























                                          Page 145 of 171



          Category  Specification document

         Submitter  Hayes


          Issue ID  142

             Issue  Remove or elaborate on description of process 
specification
                    modification

       Description  If the process specification is digitally signed, there 
should be no
                    issue with this.  I think the sentence should be struck 
from the
                    document or the use case needs to be elaborated further 
(e.g. state
                    that the CPA information along with the new process 
specification is
                    exchanged between the two parties until agreement is 
reached).


            Origin  email

    Date of Origin  9/27/2001


         Reference  Subject: CPPA Version 1.0 Comments And Issues

  _______________________________________________________________
























                                          Page 146 of 171



          Category  Tools

         Submitter


          Issue ID  14

             Issue  CPP and CPA tools

       Description  This topic consists of non-normative discussion of the 
CPP and CPA
                    tools as an addition to the CPA-composition discussion 
in appendix F
                    of the Ver. 1.0 CPP-CPA specification.  Tools include 
CPP composition
                     tool,  CPA composition tool and CPA installation tool.

                    The result of this work might be a technical report.  
This might also
                     be viewed as part of the Negotiation work item.


            Origin  'Possible New Work' Document


    Date of Origin

         Reference

  _______________________________________________________________























                                          Page 147 of 171



          Category  Tools

         Submitter


          Issue ID  21

             Issue  Consistency of timeouts and installation tools

       Description  The CPP-CPA-BPSS installation tools will have to check 
the
                    consistency of the relative values of the timeouts at 
the three
                    levels (business signals, business transaction, and 
binary
                    collaboration. Some rules are already present in the 
BPSS spec.


            Origin  'Possible New Work' Document

    Date of Origin


         Reference

  _______________________________________________________________


























                                          Page 148 of 171



          Category  Tools

         Submitter


          Issue ID  52

             Issue  Clarity re Routing of Response Messages to the Correct 
Software Entry
                     Point

       Description  The specification should be reviewed for clarity in the 
definitions
                    that determine how to route a reply message to the 
correct software
                    entry point at the recipient of the reply message. Can 
the
                    installation tools handle these definitions? In most 
cases it should
                    be sufficient to route the message by using the Service 
and Action
                    elements in the message header combined with which role 
the party
                    receiving the message plays. The following should be 
checked for
                    accuracy and clarity: 7.55 Role element, 7.5.5.1 name 
attribute,
                    7.5.7 Service element, and 7.5.8.1 action attribute. See 
below
                    regarding the RefToMessageId element in the message 
header.



            Origin  'Possible New Work' Document

    Date of Origin

         Reference


  _______________________________________________________________


















                                          Page 149 of 171



          Category  Tools

         Submitter  Mukkamala


          Issue ID  136

             Issue  Use the (only)  digest algorithm mentioned in the XML 
DSig
                    specification

       Description  Change from http://www.w3.org/2000/09/xmldsig#dsa-sha1 
to
                    http://www.w3.org/2000/09/xmldsig#sha1


            Origin  email

    Date of Origin  9/18/2001

         Reference  Subject: Reference element in page 23 of CPP/A Spec


  _______________________________________________________________



























                                          Page 150 of 171



          Category  Tools

         Submitter  Hayes


          Issue ID  150

             Issue  CPP/CPA Worksheets Proposal

       Description  The ebXML Business Process Project Team developed a 
worksheet (form)
                    based
                    approach to business process analysis and modeling.  
This is
                    documented in
                    the ebXML Business Process Analysis Worksheets and 
Guidelines [bpWS]

technical report.  It struck me that the CPP and CPA are largely
                    business
                    documents even though they contain technical content 
(e.g. protocols)
                     and
                    have a technical representation (XML).  Given the 
business-level
                    nature of
                    the CPP and CPA, it seems that there should be atleast 
one approach
                    to
                    providing CPP and CPA information that is low-end, 
low-tech, and,
                    hopefully, very approachable to a typical business-level 
user.  An
                    approach similar to the bpWS may be ideal for doing 
this.

                    I am proposing that the OASIS ebXML CPPA technical 
committee take on
                    the
                    task of developing a set of non-normative worksheets for 
CPPs and
                    CPAs.
                    See attached document as a suggested starting point for 
a technical
                    report.  As I have mentioned to Dale, I would be happy 
to give a
                    presentation on this at the upcomming face-to-face and 
demonstrate
                    how the
                    content of the worksheets can be converted to XML.

                     <<cppaWS-WIP-0.01.zip>






            Origin  email


    Date of Origin

         Reference  Subject: OASIS ebXML CPP/CPA Worksheets Proposal
                                          Page 151 of 171
                                                         ________







          Category  Transport

         Submitter


          Issue ID  68

             Issue  Additional Transport Protocols

       Description  Consider adding support for additional transport 
protocols such as:
                    ú IIOP
                    ú BEEP (IETF peer to peer protocol)
                    ú EDI value-added networks


            Origin  'Possible New Work' Document

    Date of Origin


         Reference

  _______________________________________________________________





















                                          Page 152 of 171



          Category  Transport

         Submitter


          Issue ID  55

             Issue  FTP definition

       Description  The  FTP definition may need further elaboration.  For 
example do the
                     Parties to a CPA need to agree on:
                    ú Transfer type (binary or character)?
                    ú Password properties?
                    ú Is PUT the correct operation for receiving messages?
                    " Note:  In the CPP, the delivery channel specifies 
RECEIVE
                    properties
                    ú GET as well as PUT?
                    ú Passive mode (yes or no)?
                    ú Control port number for passive mode?
                    ú Anything else with regard to firewalls?
                    ú Anything else?



            Origin  'Possible New Work' Document

    Date of Origin


         Reference

  _______________________________________________________________

















                                          Page 153 of 171



          Category  Transport

         Submitter  Chan


          Issue ID  98

             Issue  Transport compression

       Description  HTTP allows transport level compression through the use 
of the
                    Content-Encoding entity-header. The permissible 
compression
                    algorithms include gzip, compress, and deflate.

                    Should the use of transport level compression be 
specifiable in
                    the CPA when the transport is HTTP?


            Origin  email


    Date of Origin  8/21/2001

         Reference  Subject: Transport level compression

  _______________________________________________________________
























                                          Page 154 of 171



          Category  Transport

         Submitter  Chan


          Issue ID  81

             Issue  Overlapping endpoint types

       Description  Section 7.5.14 indicates that a Transport element may 
have multiple
                    Endpoint elements, each of different types. The question 
I have is
                    whether these types have to be non-overlapping.

                    Can an Endpoint element of type allPurpose co-exist with 
another
                    Endpoint element of type Response under the same 
Transport element?
                    If so, does it mean that a response can be sent to 
either Endpoint?




            Origin  email

    Date of Origin  8/1/2001

         Reference  Subject: Endpoint question


  _______________________________________________________________





















                                          Page 155 of 171



          Category  XML

         Submitter


          Issue ID  56

             Issue  PartyId definition and example

       Description   Both examples of PartyId in ver. 1.0 have the type 
attribute
                    included although according to the text, all the 
information is in
                    the value of the attribute.  We need to formulate an 
example in which
                     the type attribute is essential.


            Origin  'Possible New Work' Document

    Date of Origin


         Reference

  _______________________________________________________________


























                                          Page 156 of 171



          Category  XML

         Submitter


          Issue ID  57

             Issue  PartyId type

       Description   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.


            Origin  'Possible New Work' Document

    Date of Origin


         Reference

  _______________________________________________________________


          Category  XML


         Submitter

          Issue ID  65

             Issue  Namespace Definitions


       Description  Does the change to OASIS affect any of the namespace 
definitions?

            Origin  'Possible New Work' Document

    Date of Origin


         Reference

  _______________________________________________________________




                                          Page 157 of 171



          Category  XML

         Submitter


          Issue ID  63

             Issue  "generated by XML Authority" in DTD

       Description  It is inappropriate to include the line "generated by 
XML Authority"
                    in a normative DTD. (Sun submitted these quality-review 
comments
                    after the version-1 specification was published.)


            Origin  'Possible New Work' Document

    Date of Origin


         Reference

  _______________________________________________________________


          Category  XML


         Submitter  Chan

          Issue ID  119

             Issue  name attribute in ProcessSpecification


       Description  Section 7.5.4.1 (line 836) is not consistent with 
Appendix D.
                    According to Appendix D, the name attribute should be of
                    type tns: non-empty-string.

            Origin  email


    Date of Origin  8/21/2001

         Reference  Subject: <1.0 bug> name attribute in 
ProcessSpecification

  _______________________________________________________________



                                          Page 158 of 171



          Category  XML

         Submitter  Chan


          Issue ID  114

             Issue   Protocol element's version attribute should not be 
FIXED

       Description  Section 7.6.6.1 is incorrect. The version attribute 
should not be
                    fixed, as it is not consistent with the schema 
definition in Appendix
                     D. Since the Protocol element is declared at the top 
level and is
                    used in a number of different contexts, it is also not 
appropriate to
                     declare Protocol to have a required version attribute 
either.
                    Somehow, section 7.6.6.1 needs to be rephrased.

                    <element name="Protocol" type="tns:protocol.type"/>

                    <complexType name="protocol.type">
                    <simpleContent>
                    <extension base="tns:non-empty-string">
                    <attribute ref="tns:version"/>
                    </extension>
                    </simpleContent>
                    </complexType>




            Origin  email

    Date of Origin  8/20/2001

         Reference  Subject: <1.0 bug> Protocol element's version attribute 
should not be
                     FIXED


  _______________________________________________________________











                                          Page 159 of 171



          Category  XML

         Submitter  Chan


          Issue ID  120

             Issue   action attribute in section 7.5.8.1and xlink:href 
attribute  in
                    section 7.3.7.4

       Description  The action attribute should not be equated with the name
                    attribute of the desired BusinessTransaction. There are
                    two activities within a Business Transaction, a
                    RequestingBusinessActivity and a 
RespondingBusinessActivity.

                    ...

                    Similarly, in section 7.3.7.4 xlink:href attribute, the 
link should
                    be
                    to the corresponding RequestingBusinessActivity, or to 
the
                    corresponding RespondingBusinessActivity.


            Origin  email

    Date of Origin  8/21/2001

         Reference  Subject: <1.0 bug> action attribute in section 7.5.8.1


  _______________________________________________________________


















                                          Page 160 of 171



          Category  XML

         Submitter  Chan


          Issue ID  116

             Issue  attributeFormDefault in Appendix D incompatible with 
examples in
                    Appendix A & B

       Description  In Appendix D, line 2932, attributeFormDefault is set to 
unqualified,
                     whereas in Appendices A and B, the example CPP and CPA 
instances all
                     refer to qualified attributes (tp: prefixed).

                    When I attempted to validate the CPA instance in 
Appendix B against
                    the schema in Appendix D, I got a lot of errors due to 
lots of
                    required attributes being missing. Most of these errors 
were fixed
                    when I changed attributeFormDefault in the XSD to 
qualified.

                    The remaining errors I got when validating Appendix B 
against
                    Appendix D were due to reference to an undeclared 
attribute tp:name
                    in element tp:ServiceBinding, and the missing of the 
tp:Service
                    element under tp:ServiceBinding. This can be fixed by 
setting the
                    tp:Service element to the value of the tp:name attribute 
and omitting
                     the tp:name attribute.



            Origin  email


    Date of Origin  8/20/2001

         Reference  Subject: <1.0 bug> attributeFormDefault in Appendix D is 
not
                    compatible withexamples in Appendix A & B

  _______________________________________________________________












                                          Page 161 of 171



          Category  XML

         Submitter  Chan


          Issue ID  115

             Issue  cpaid is not of type CDATA

       Description  Line 1913 in section 8.2 is inconsistent with the schema 
definition
                    in Appendix D: cpaid should be of type 
tns:non-empty-string, not
                    CDATA.


            Origin  email

    Date of Origin  8/20/2001


         Reference  Subject: <1.0 bug> cpaid is not of type CDATA

  _______________________________________________________________



























                                          Page 162 of 171



          Category  XML

         Submitter  Chan


          Issue ID  110

             Issue  Appendix D: Retries, RetryInterval, and PersistDuration

       Description  In order to conform to the W3C Recommended version of 
XMLSchema, the

following changes should be made to Appendix D:

                    - Retries should be of type integer, not string.

                    - RetryInterval should be of type Duration, not string.

                    - PersistDuration should be of type Duration, not 
timeDuration.

                    In addition, the example in section 7.6.4 should be 
changed
                    accordingly:

                    - The RetryInterval example should not assume the unit 
is second.

                    - The PersistDuration example should look like PT30S. 
(The P
                    designator
                      must always be present; the T designator must be 
present if any
                    time item
                      is present.)





            Origin  email


    Date of Origin  8/20/2001

         Reference  Subject: <1.0 bug> Retries, RetryInterval, and 
PersistDuration

  _______________________________________________________________








                                          Page 163 of 171



          Category  XML

         Submitter  Chan


          Issue ID  109

             Issue  Appendix D is out of date

       Description  Appendix D needs to be replaced with the contents of 
cpp-cpa-v1_0.xsd
                     and including the bug fixes I have reported in an 
earlier post.

                    The default namespace has to be set to
                    http://www.w3c.org/2000/10/XMLSchema.  Otherwise, the 
element names
                    like Element and Attribute would have to be qualified 
with the above
                    namespace.

                    The clause xmlns = "http://www.w3.org/2000/10/XMLSchema" 
is present
                    in cpp-cpa-v1_0.xsd but is missing from Appendix D.




            Origin  email

    Date of Origin  8/17/2001


         Reference  Subject: <1.0 bug> Appendix D is out of date

  _______________________________________________________________


















                                          Page 164 of 171



          Category  XML

         Submitter  Chan


          Issue ID  108

             Issue  cpp-cpa-v1_0.xsd cannot be read by Internet Explorer 5.0

       Description  It complains:
                    The XML page cannot be displayed Cannot view XML input 
using XSL
                    style
                    sheet. Please correct the error and then click the 
Refresh button, or
                     try
                    again
                    later.
                    
---------------------------------------------------------------------
                    ---------The namespace prefix is not allowed to start 
with the
                    reserved
                    string "xml". Line 2, Position 72  <schema
                    
targetNamespace="http://www.ebxml.org/namespaces/tradePartner"
                    xmlns:xml="http://www.w3.org/XML/1998/namespace"
                    xmlns="http://www.w3.org/2000/10/XMLSchema"
                    xmlns:tns="http://www.ebxml.org/namespaces/tradePartner"
                    xmlns:xlink="http://www.w3.org/1999/xlink"
                    xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
                    xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
                    elementFormDefault="qualified"
                    attributeFormDefault="unqualified"
                    
version="1.0">-------------------------------------------------------
                    -------
                    ---------^XML Authority 2.2 (which provides W3C XML 
Schema
                    Recommendation
                    support) also complainsabout a similar problem. To 
remove errors
                    flagged by
                    XML Authority, I had to:1. Remove the clause
                    xmlns:xml="http://www.w3.org/XML/1998/namespace"2. 
Change the
                    line<attribute
                    name="messageOrderSemantics" type="tns:mos.type" 
use="optional"
                    value="NotGuaranteed"/>    to<attribute 
name="messageOrderSemantics"

type="tns:mos.type" use="default" value="NotGuaranteed"/>





            Origin  email

    Date of Origin  8/17/2001
                                          Page 165 of 171
                                                         annot be read by 
Internet
                    Explorer 5.0
  _______________________________________________________________










          Category  XML


         Submitter  Wang

          Issue ID  61

             Issue  Optional messageOrderSemantics attribute with value in 
XSD


       Description  <attribute name="messageOrderSemantics"
                                  type="tns:mos.type"
                                  use="optional"
                                  value="NotGuaranteed"/>
                       This should be:
                       <attribute name="messageOrderSemantics"
                                  type="tns:mos.type"
                                  use="default"
                                  value="NotGuaranteed"/>

                       Attributes with values specified in the schema must 
be declared as
                       either default or fixed.


            Origin  'Possible New Work' Document


    Date of Origin

         Reference

  _______________________________________________________________









                                          Page 166 of 171



          Category  XML

         Submitter  Wang


          Issue ID  82

             Issue  SimplePart and NamespaceSupported elements

       Description  Section 7.7.3 SimplePart element should probabaly be 
numbered as
                    7.7.2.1 and its title should be "NamespaceSupported 
element".
                    (Section 7.7.2 already discusses SimplePart element.)

                    NamespaceSupported should in this context be a child of 
SimplePart,
                    and this should be straightened out for the v 1.1 
specification.



            Origin  email


    Date of Origin  8/2/2001

         Reference  (forwarded by Arvola Chan) Subject: Fw: renumber and 
retitle of
                    section 7.7.3

  _______________________________________________________________






















                                          Page 167 of 171



          Category  XML

         Submitter  Wang


          Issue ID  60

             Issue  XML namespace usage

       Description  You are not allowed to specify a Namespace prefix of 
"xml".
                       So xmlns:xml="http://www.w3.org/XML/1998/namespace" 
should be
                    removed.


            Origin  'Possible New Work' Document

    Date of Origin


         Reference

  _______________________________________________________________



























                                          Page 168 of 171



          Category  XML

         Submitter  Collier


          Issue ID  101

             Issue  Super schema for CPP + CPA

       Description  In addition, it is entirely feasible to develop a super 
schema that
                    would combine a description of the CPP with description 
of the CPA
                    and correlate the relevant components of the two using 
the key/keyref
                     mechanism of XML schema. This would allow a contract 
validator to
                    match the correlated components to make sure that the 
contract is
                    actually met


            Origin  ebXML Technical Architecture Risk Assessment v1.0


    Date of Origin

         Reference

  _______________________________________________________________
























                                          Page 169 of 171



          Category  XML

         Submitter  Saito


          Issue ID  62

             Issue  Errors in CPA example

       Description  Yukinori Saito (5/16 and 5/17/01) pointed out errors and 
suggesting
                    corrections to the CPA sample regarding incorrect use of 
ID attribute
                     "N08". This could be corrected and distributed on the 
CPPA
                    listserver until we issue a maintenance release.


            Origin  'Possible New Work' Document

    Date of Origin


         Reference

  _______________________________________________________________


























                                          Page 170 of 171



          Category  XML

         Submitter  Hayes


          Issue ID  146

             Issue  Format of URI PartyID reference

       Description  This example -- urn:www.example.com - does not follow 
the same format
                     as the previous example which 
is:urn:<agency>:<agency-id>Recommend
                    changing example to "urn:icann:example.com."  (For those 
who are not
                    familiar with the ICANN, "the Internet Corporation for 
Assigned Names
                     and Numbers (ICANN) is the non-profit corporation that 
was formed to
                     assume responsibility for the IP address space 
allocation, protocol
                    parameter assignment, domain name system management, and 
root server
                    system management functions"
                    [http://www.icann.org/general/abouticann.htm].I also 
wonder if we
                    would be well served to add "pid" or "partyid" to the 
format.
                    Although, it can be easily argued that you know it is a 
party id by
                    context.



            Origin  email

    Date of Origin  9/27/2001


         Reference  Subject: CPPA Version 1.0 Comments And Issues

  _______________________________________________________________

















                                          Page 171 of 171




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC