[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Correction PreliminaryMinutes WSRM TC Meeting 4/5/2005
In section 8, Please restate the comment I made regarding improvement of the Composability spec:
"Alan: after feedback from Interop test we could augment the document accordingly."
Pls change this to:
Alan: The Composability interop event will be very valuable in providing feedback we can use to augment and improve the WS-Reliabilty And WS-Security - First Draft specification. We would therefore like to encourage more participants to join this interop event.
Thanks
alan
----- Original Message -----
From: "Tom Rutt"
To: wsrm
Subject: [wsrm] PreliminaryMinutes WSRM TC Meeting 4/5/2005
Date: Tue, 05 Apr 2005 18:27:11 -0400
>
> the prelim minutes are attached.
>
> Please post any corrections to the entire list before the end of this week.
>
> Tom Rutt
> WSRM TC Chair
>
> -- ----------------------------------------------------
> Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com
> Tel: +1 732 801 5744 Fax: +1 732 774 5133
Preliminary Minutes of WSRM TC Conference Call –April 5, 2005
The meeting of the WSRM TC will take place by teleconference
Tuesday, April 5, 2005, from 5:30 to 7:00 PM Eastern Standard Time
1 Draft Agenda to WSRM TC Conference Call
2 Roll Call
3 Minutes Discussion
3.1 Appointment of Minute Taker
3.2 Approval of previous meeting minutes –
4 Action Item Status Review
5 Status of WS-Reliability Specification
6 Interop SC Future activities
7 Next Step Documentation
7.1 Editorial Clarifications and Errata
7.2 Implementation Guidelines
7.2 Future Enhancement Requests
8 Composability with other WS-Specs
9 ws reliability PAS progression
10 Discussion of Future Meetings
11 New business
Attendance:
Last Name |
Role |
Company |
Durand |
Secretary |
Fujitsu |
Rutt |
TC Chair |
Fujitsu |
Freund |
Member |
|
Nishiyama |
ProspMember |
|
Yamamoto |
Member |
|
Weissberger |
Member |
NEC Corporation |
Knight |
ProspMember |
Nortel |
Peel |
Secretary |
Novell |
Wenzel |
Member |
SeeBeyond |
Bunting |
Secretary |
Sun Microsystems* |
Granqvist |
Member |
Verisign * |
Meeting Is quorate.
Tom Rutt will take minutes.
The minutes of the 3/22 meeting (amended attendance list from prelim minutes) are posted at:
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/12074/MinutesWSRMTC032205.htm
Bob Moved to approve the 3/22 minutes, Alan seconded.
No opposition minutes 3/22 minutes are approved
Action: Oracle will provide examples of soap header dumps with both ws-reliability and ws-Security headers in use, as in the interop demo.
Anish posted email:
WSS and WS-Reliability header dumps Anish Karmarkar 24 Feb 2005
Anish may post some additional examples of other combinations.
Action: Tom will investigate how to change the status of printed document. The posted standard still states CD.
Continuing action, need standard number from OASIS staff
Action: Tom will investigate how to post the three OASIS pas documents on our server.
Jamie Clark is investigating how to get the documents on the OASIS Site.
Action: Tom will check if there will be projectors available for the TC meeting.
The TC is responsible for supplying its own projector.
The public and member web site pages for the TC to have a single announcement, which refers by URL to spec and schema at the proper location on the OASIS web site.
http://docs.oasis-open.org/wsrm/2004/06/WS-Reliability-CD1.086.pdf
http://docs.oasis-open.org/wsrm/2004/06/fnp-1.1.xsd
http://docs.oasis-open.org/wsrm/2004/06/reference-1.1.xsd
http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd
http://docs.oasis-open.org/wsrm/2004/06/wsrmfp-1.1.xsd
The spec at the above link itself still shows status a CD.
Tom posted an edited cover page for review at:
The chair sent an email to OASIS staff about our need for an OASIS standard number to put in the edited cover page.
OASIS staff has not yet given WS-Reliability an OASIS standard Number.
Discussion of Future activities for Interop SC.
Alan Weisberger sent the following by email:
Proposal for new work item related to WS-R and WS-Security Composability Project:
Alan Weissberger, NEC and Jacques Durand, Fujitsu
Fujitsu and NEC are proposing a new activity associated with the composability of WS-R and WS-Security. We would like to demonstrate several interoperable implementations of these composed OASIS standards at an interoperability event to be hosted by Fujitsu in early June. The WS-R implementations may be based on those developed for previous interop demos, or on the open source RM4GS (which runs under Linux OS). The WS-Security implementations may be based on company implementations, new implementations for this demo, or the Apache open source_<URL TBD>.
Both Fujitsu and NEC will have implementations for this interop and we encourage other companies to participate as well.
Our test scripts/ test assertions will be compliant with both the WS-Security standard and the corresponding WS-I BSP WG drafts (to be identified).
We would like to base our interop test assertions on four security requirements:
-authentication
-authorization
-confidentiality (encryption)
-integrity (tamper proofing)
For each of these requirements, we plan to identify the constituent functionality and ordered WS-R/WS-S header processing at the sender. That is, we would like to allow for different composability processing configurations on the sender side, while specifying only the composed message format transmitted (we assume over HTTP transport) on the wire.
The transmitted message format will implicitly specify the test case for receiver processing. From this defined functionality, we will specify the test assertions, which will be the essence of the composed WS-R/WS-S implementations to be tested for interoperability.
Our goal is to specify no more than 12 test assertions.
Here are a few functionality type questions we have pondered:
· What parts of the SOAP message are signed, what type of signature?
· What parts of the SOAP message are encrypted (only the message body or headers too)?
· What type of encryption and key management should we select?
· Do we require integrity of the WS-R header, payload or both?
· What type of digital signature will be needed, e.g. detached (subset of SOAP message) or embedded (entire SOAP message/ envelope)?
· What token type(s) will be used for authentication- X.509, REL, SAML, Kerberos?
Our proposed TC work plan is as follows:
-Agree on requirements on the Tuesday April 5 call
-Agree on functionality and start work on test assertions this week (ending Friday April 8). We are willing to have a task force call this week, if there is sufficient interest.
-Agree on test assertions on April 19 call or f2f meeting (if call is cancelled)
-Begin implementations immediately thereafter. Assume implementations will be completed by end of May
-Interop event to be held at Fujitsu Software,
-Upon successful interop event testing, participants are invited to provide an Internet end point for future interoperability testing of the composed specs. Additional test assertions may be included at that time.
Alan Weissberger
NEC Labs
1 408 863 6042
Alan presented the proposal above.
Bob: I agree that this belong in the Interop SC. However
Jacques: I am currently the co chair of the Interop SC. I can be the leader for this activity.
Straw: participation, Fujitsu, NEC,
Bob:
Paul Knight: Nortel cannot provide an implementation.
Jacques: Oracle needs to be asked.
No opposition to interop SC starting this activity.
There will be an Interop SC meeting on April 6, at 4:00 PM west coast time.
Jacques will send out a notice of this meeting. If people are interested send mail to Jacques, and he can set up the bridge.
Comments have been requested on the following three draft documents.
Clarifications, editorial nits, interpretations of the actual specification,
which should be posted for others to see
ws-Reliability 1.1 Errata: Editor's Draft 0.1
Things to help implementers, which, would typically be specific to application environments.
WS-Reliability 1.1 Implementers Guide-ed0.1
Proposed changes for future versions which would ease implementation or enhance protocol capabilities.
Draft list of WS-Reliability Enhancement Requests
WS-Security Composition paper from Fujitsu,
WS-Reliabilty And WS-Security - First Draft
Alan: after feedback from Interop test we could augment the document accordingly.
A Newer version of composability aspects was posted by Jacques as:
Jacques: There have been no comments on what was posted. We have to add more to the current draft. Goal: have a document to send to other ws standard groups out of the face to face. This could be a white paper for a technical audience, or part of a much more complete document on composability.
Jacques: We will try to have it complete by the face to face meeting.
No response has been received yet from OASIS Staff regarding our request to pursue PAS progression of WS-Reliability 1.1.
Tom reserved all day Thursday and Friday Morning after the symposium for Our TC.
The hotel will supply a screen.
There will be a 30 dollar a day fee for attendees (there is a meeting registration form).
The TC is responsible for preparing a 3 slide, 3 minute summary of the TC progress for the general meeting on Tuesday afternoon. Tom agreed to capture status, the work in progress. Put a URL on the open source version of the spec.
Tom will post the slides by the end of the week for comments.
We will have to supply a projector [Fwd: Re: Are computer projectors available for TC meetings]
The Chair questions the need for Teleconference meeting on April 19 (one week before symposium).
Jacques: we could have a meeting next week on April 12.
Tom: the Interop SC can meet as many times as it wishes.
No opposition to canceling the April 19 meeting.
Face to face April 29.
TC teleconference meeting the first Tuesday of May, May 3.
Jacques posted an email about conformance
One of the difficulties we had in defining a conformance clause for WS-Reliability, is the existence of diverse profiles of implementations: a light personal device (e.g. cell phone) might only be required to act as a Receiving RMP, and only be required to send acks. Or, a monitoring device would only need to send, with the ability to resend. A message hub will need to act as both Sender and Receiver, and support all features.
It was hard to find a common basis of features to define conformance levels on.
But even so, it remains important to define conformance boundaries so that implementations know where they stand on interoperability.
An approach based on the QA guidelines (W3C / NIST, http://www.w3.org/TR/qaframe-spec/ ) may help:
That leads to distinguish:
- Usage profiles, based on the different roles an implementation can play:here Sender, Receiver, or both.
- within each profile, functional levels (core, etc.) can be defined, to which will correspond levels of conformance. For the sake of interoperability, "core" Sender must be able to interoperate with "core" Receiver, etc.
- functional Modules can also be distinguished (a profile would require the implementation of some modules, e.g. only {HTTP binding + resending mechanism} for an HTTP Sender profile at Level 0, { HTTP binding + resending mechanism + group management} for HTTP Sender level 1, etc.
These definitions could belong in an (non-normative) adjunct to the standard, something that helps developers characterize their implementations in terms of profile/level (and also promotes a reasonably small number of implementation profiles).
That adjunct may or may not be merged later with the next release of the standard.
I propose we start discussing this in the meeting tomorrow if time permits.
Jacques
Jacques: I think this activity is less important than the composability work. But we should get progress on this. I would like to have this be put on the face to face agenda.
If we provide conformance statements do we want them to be in a companion spec, or to be put in the next release of the spec.
Alan: NEC is supportive of this effort. Every ITU-T standard has built in conformance statements in the spec. It would be good to have a set of conformance classes.
Sender and receiver have different conformance.
There should be levels of capability (based on protocol capability). For example, a higher level of conformance could provide greater protocol capability.
Alan: this level of conformance is a new aspect which we can add to these activities.
Anyone can send comments on this conformance to the meeting.
Bob: I would like to put charter review on the Agenda for the face to face.
Bob: we should go back to the charter and see if we are going outside the charter, and if we are we should revise it.
Alan: I have always felt that conformance statements are an important part of any specification.
Tom: I will put both of these on the agenda for the f2f.
Alan: I would like to encourage TC members to at least review the work of the Interop demo, and at least participate by email.
Alan: Input is solicited on solid test assertions. Please send any answers to the questions on the email I sent today.
Bob : motion to adjourn, seconded by Mark Peel.
Propose Thursday for group dinner.
Alan Weissberger DCT 2013 Acacia Ct Santa Clara, CA 95050-3482 1 408 863 6042 voice 1 408 863 6099 fax
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]