[ebxml-iic] 8/4/2003: 4 August 2003 Mtg Minutes and Actions Attached.

[Monica Martin <monica.martin@sun.com>]

Everyone, minutes attached. Actions:

    * Durand specify 11 August 2003 call.
    * Kass compile the requirements in question with projected impacts,
      take team inputs and the team can decide on testability and what
      questions may forwarded to ebMS team.

Thanks.

>> Time: Monday 4 August 2003, 11am PT
>> Host: Sun Microsystems Toll Free - : 1-866-882-3998
>> Toll - : 1-865-525-0769
>> Participant code: 9081038
>>
>> Agenda: 1. Status of MS conformance test suite spec. (Mike Kass 
>> editor) - review current draft of MS conf test suite, and specific 
>> issues:
>> . Issue #1: the problem of "app-level" test cases: See those denoted 
>> in conformance document by Mike Kass. Be ready to discuss.
>> . Issue #2: ordering / partitioning based on config/CPA? (how to 
>> avoid too many reconfigs).  Be ready to discuss current list.
>> . Issue #3: conformance profiles or levels (detailed content?) - See 
>> 28 July minutes.  Three profiles suggested: core, more reliability 
>> and full. Suggest a decision.
>> . Issue #4: message correlation details: Action to Durand and Kass.
>> . Issue #5: check / fix parameter tables: Agreement reached; confirm.
>>
>> 2. BPSS test update (Serm K., Monica M.): - Discuss BSI testing 
>> definition.
>> - Discuss further idea of a prototype.
>>
>> 3. Implementers corner, and PR: - Drake Certivo test driver status 
>> (if Sakach present)
>> - IIC members demo (Test Framework, test suites) at XML 2003, 7-12 
>> December
>
ebXML IIC Meeting 4 August 2003

Michael Kass
Serm Kulvantunyou
Pete Wenzel
Steven Yung
Monica J. Martin

Regrets
Jacques Durand

MS conformance test progress
Kass:
1. Application level - Requirements are for an ebXML application (#46, for example)
This only applies to an industry test that includes this detailed level.
Wenzel: In ebMS, the goal was to guide implementations, with references to other
standards (Similar to implementation guidelines).
2. Test framework limitation - Black box
For example, for reqt#9 there is no way to test the character set of a message to
see if it matches that which is specified in MIME content header.
Do we need to consider extensions?
Martin: Do we consider extensions or leave this to implementation?
Wenzel: From reqt#177 on, does test driver have access to the raw message?
Kass: Test driver has access to MIME message. No TCP/IP and TLS has been included
in the testing yet.
Wenzel: How do we address communication between transport and application
transport?  Is this worthy of a test framework extension? Who decrypts the message and
tests signatures?  
Kass: The test driver theoretically should be able to do this.
Can't test reqt#179.
Wenzel: Reverse steps on receiving end, you can infer that the signature was placed
before encryption. Can then test by inference #175, 179.
Kass: Yes. For reqt#193, 194 - There is no way of reaching inside the candidate
MSH to get status of a message.
Wenzel: This is what the MSH thinks the status is.
Kass: Doesn't the MSH have dialog with the application?
Wenzel/Martin: reqt#193, 194 - The requirements around messageStatus are MSH level
not application. Partial testing possible
Wenzel: reqt#161 - Partially testable but not application level. Verify signature and
have From party's certificate.
Kass: Is the CPP/A is viewed as the configuration information or that it enforces the
rules for configuring the MSH.  Or does it provide parameters for the application?
Wenzel: CPP/A is static configuration of the MSH.  For dynamic changes, there 
are faults generated when the rules of the CPP/A are not followed.  Kass agrees
that partial testing is possible for reqt#161.
Kass: reqt#155, 156 - Sequence counter is restarted, per application
(Martin question).
Wenzel: Need to force MSH to do a reset - not testable. There is no end of
sequence marker (raised to ebMS team). Can verify that the MSH can generate such
a message. The error generation should be testable (See Section 9.2, ebMS).
Martin: reqt#149 - Isn't this application level testing? Only if known in the product.
Kulvantunyou: Are the gaps in the ebMS specification? The MSH should be able to
understand the sequences.
Kass: reqt#145 - Send many messages and expect a response. This could be testable.
Martin: How to address interruptions? #115, 138, 139.  See other interrupt
or system requirements as well.
Kass: We have maintained an viw of remote automated testing and this requires
intervention? Durand has suggested an abstract test that narratively describes
the test could be effected. 
Martin: What about persistent store? reqt#85-89 was discussed previously as an
out of band exercise (at one of F2F). See other persistent store requirements.
Kass: These are testable if you assume they are stored (is available).
Test message persistence - choreography, for example to show you have to have
a retransmission? Possible for partial testing.
Kulvantunyou: Can we assume that persistent storage items could handled by the
Test Service? The Test Service could query the persistent store?
Kass: Is this an API? Is this internal? Take a black box approach.
Kulvantunyou: This tests a functional MSH requirement. This is hidden
from other MSH and the application. 
Martin: Can we draw some parameters to test partially and maintain a black box approach?
Kass: Yes. Make a decision on each flagged requirement, decide and then go back
to ebMS as appropriate. Prepare list of requirement numbers, issue and resolution.

Action: Kass take team notes today, team inputs and construct the working 
requirements list for full team to decide. Then, after agreement, forward
questions to ebMS team as appropriate.
Action: Durand will specify call for next week, 11 August 2003.