Full agenda for WSRM TC Teleconf 4/5/05

[Tom Rutt <tom@coastin.com>]

the full agenda is attached.

Note that there is a new passcode, but the number is the same.

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

Title: Draft Agenda to WSRM TC Conference Call – May 06, 2003

Full Agenda for 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

 

Conference Bridge number Toll only : 1-512-225-3050 new Participant code: 375491

 

 

1         Draft Agenda:

 

    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

 

2         Roll Call

Attendance:

 

Meeting ?? quorate.

 

3         Minutes Discussion

 

Tom Rutt will take minutes.

 

3.1      Approval of previous meeting minutes

The minutes of the 3/8 meeting (amended attendance list from prelim minutes) are posted at:

http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/11863/MinutesWSRMTC030805.htm

 

xx Moved to approve the 3/8  minutes, yy seconded.

 

?? opposition minutes 3/8  minutes ?? approved

 

 

4         Status of Action Items

4.1      Action 121404-2 (Anish) Open

 

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 23:22:27

 

Anish may post some additional examples of other combinations.

 

4.2      Action 012505-1 (Tom Rutt) Pending

 

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

4.3      Action 020805-2 (Tom Rutt) open

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.

 

 

4.4      Action 032205-2 (Tom Rutt) closed

 

Action: Tom will check if there will be projectors available for the TC meeting.

 

The TC is responsible for supplying its own projector.

5         Status of WS-Reliability Specification

 

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:

               EditedWS-ReliabilityCover  

 

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.

6         Interop SC Future activities

Discussion of Future activities for Interop SC.

7         Next Step Documentation

Comments have been requested on the following three draft documents.

7.1      Editorial Clarifications and Errata 

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  

 

 

7.2      Implementation Guidelines / Application Notes

Things to help implementers, which, would typically be specific to application environments.

 

WS-Reliability 1.1 Implementers Guide-ed0.1  

 

 

7.3      Future Enhancement Requests

Proposed changes for future versions which would ease implementation or enhance protocol capabilities.

 

Draft list of WS-Reliability Enhancement Requests  

 

8         Composability with other WS-Specs

 

WS-Security Composition paper from Fujitsu, Hitachi and NEC:

               WS-Reliabilty And WS-Security - First Draft  

 

A Newer version of composability aspects was posted by Jacques as:

                Composability Analysis (V0.5)

 

 

9         WS-reliability PAS progression

 

No response has been received yet from OASIS Staff regarding our request to pursue PAS progression of WS-Reliability 1.1.

10   Discussion of Future Meetings

 

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. [Fwd: Re: Are computer projectors available for TC meetings]

 

The Chair questions the need for Teleconference meeting on April 19 (one week before symposium).

11   New Business

 

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