Preliminary Minutes WSRM TC Conference Call –May 25, 2004

The meeting of the WSRM TC  will take place by teleconference

Tuesday, May 25, 2004, from 5:30 to 7:30 PM Eastern Standard Time

(UTC - 5)

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

1 Draft Agenda:

Draft Agenda to WSRM TC Conference Call

1 Roll Call

2 Minutes Discussion

2.1 Appointment of Minute Taker

2.2 Approval of previous meeting minutes –

3 Action Item Status Review

4 Discussions of unresolved editorial comments

5 Discussion of Document progression

6 Discussion of FAQ for WS-Reliability

7 Discussion of potential f2f meeting in Brussels in October

2 Roll Call

Attendance:

First Name	Last Name	Email	Role	Company	Voting Level
Joseph	Chiusano	chiusano_joseph@bah.com	Member	Booz Allen Hamilton	1
Jeff	Turpin	jturpin@cyclonecommerce.com	Member	Cyclone Commerce	1
Jacques	Durand	jdurand@us.fujitsu.com	Member	Fujitsu	1
Kazunori	Iwasa	kiwasa@jp.fujitsu.com	Secretary	Fujitsu	1
Tom	Rutt	tom@coastin.com	TC Chair	Fujitsu	1
Jishnu	Mukerji	jishnu@hp.com	Member	Hewlett-Packard	1
Robert	Freund	bob.freund@hitachisoftware.com	Member	Hitachi	1
Eisaku	Nishiyama	nishiy_e@itg.hitachi.co.jp	Member	Hitachi	1
Nobuyuki	Yamamoto	no_yama@bisd.hitachi.co.jp	Member	Hitachi	1
John	Fuller	jfuller@wernervas.com	Observer	Individual
Junichi	Tatemura	tatemura@sv.nec-labs.com	Member	NEC Corporation	1
Alan	Weissberger	ajwdct@technologist.com	Member	NEC Corporation	1
Abbie	Barbir	abbieb@nortelnetworks.com	Member	Nortel Networks	1
Mark	Peel	mpeel@novell.com	Member	Novell	1
Anish	Karmarkar	Anish.Karmarkar@oracle.com	Member	Oracle	1
Sunil	Kunisetty	Sunil.Kunisetty@oracle.com	Secretary	Oracle	1
Pete	Wenzel	pete@seebeyond.com	Member	SeeBeyond	1
Doug	Bunting	doug.bunting@Sun.com	Secretary	Sun Microsystems	1
Tony	Graham	Tony.Graham@Sun.com	Member	Sun Microsystems	1
Chi-Yuen	Ng	cyng@csis.hku.hk	Member	University of Hong Kong	1

Meeting is quorate.

3 Minutes Discussion

3.1 Appointment of Minute Taker

Tom Rutt will take minutes.

Minutes will serve to record issue resolutions.

3.2 Approval of previous meeting minutes

The minutes of the May 4 teleconf are posted at:

http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/6811/MinutesWSRMTC050404b.htm

These include Jeff M in the roll call.

The minutes of May 11 Teleconf are posted at:

http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/6782/MinutesWSRMTC051104.htm

The minutes of May 18 Teleconf are posted at:

http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/6882/MinutesWSRMTC051804.htm

Bob F moved to approve all three minutes, Jeff T seconded.

No opposition, all three minutes are approved.

4 Status of Action Items

4.1 Action editors-1 (Marc and Doug) Pending

Marc G and Doug B to updated issues list to reflect agreements in CD .992.

- open

Doug did a cleanup of the documents.

Closed action

Ø New Action: Tom took a new action item to complete the status column of pre public review issues list, with correct URLs.

4.2 Action 050404-1 (Iwasa)

Action on Iwasa to add new annex pointing at schema with the

disclaimer of precidence.

complete

4.3 Action 050404-4 (Iwasa)

Iwasa has action item to update figures to get rid of application layer.

complete

4.4 Action 051104-10 (Jacques)

The current answer to the FAQ question on wsdl operation types is only about reply patterns.

Jacques; Action: Jacques will write an answer to the FAQ question on how WS-Reliability relates to WSDL operation types.

closed

4.5 Action 051804-1 (Iwasa)

Action: Iwasa will complete the agreed resolutions from public comments Resolution Issue list.

PC6.2 , PC7.12 , PC10.3 , PC11.5 , PC11.6 , PC11.9 , PC11.11 , PC11.13 , PC11.14 , PC11.20 , PC11.25 , PC12 , PC14

Included .998 closed.

4.6 Action 051804-2 ( Bob F )

Action: Give it to the Demo Subcommittee to work on “company Using Spec” letters. Successfully using consistent with OASIS IPR policy.

Bob sent a draft to the subcommittee.

Closed.

Companies should send these letters to the list.

Do as soon as we do the final CD vote.

Wait till CD1.0 draft exists to send it out.

Forward to Sunil.

June 1 and June 8 is the target to send these forms out.

4.7 Action 051804-3 ( Tom )

Action: Tom will try to locate earlier submission to show Bob.

Closed.

5 Discussion of Issues and editorial Comments

The following issues list includes open items which need further discussion:

http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/6924/PublicCommentsIsssues-052504Input.html

5.1 PC 11.15

PC11.15	Spec	Editorial	open	Tony Graham
	Title: line 336 of .993
	Description: A reply may now include multiple Acknowledgment Indications.
	Proposal: Tony provided the following suggestion: From Tony Graham on 18 May 2004 21:22:25 -0000Lines 201-202 of 0.997:"An indication referring to a previous message, that is either anAcknowledgment Indication or a Reliable Messaging Fault Indication."Proposed replacement:"An indication from the Receiving RMP of the success or failure of the deliver operation of one or more previous messages that were sent by the Sending RMP." Discussion at 5/18 meeting Tom: the term reply was intended to be for a single request message. The response could contain the replies for multiple messages. Response could be defined to include for multiple replies. Take this back to the list for further discussion.
	Resolution:

Email from Tom Rutt on 5/25/04 Subject (Proposal to resolve PC11.15):

Lines 204-206 currently state:

Reliable Messaging Reply (RM-Reply):

An indication referring to a previous message, that is either an Acknowledgment Indication or a

Reliable Messaging Fault Indication.

Change the definition to:

An indication referring to a previous reliable message, that is either an Acknowledgement Indication or a Reliable Messaging Fault Indication. For the Callback and Poll reply patterns, RM-Reply indications for multiple reliable messages MAY be included in a single Reliable Messaging Response.

Tony Graham moved to accept Tom proposal, Iwasa seconded.

No opposition, motion passes.

5.2 PC11.24

PC11.24	Spec	Editorial	open	Tony Graham
	Title: Section 3, Reliability Features
	Description: "Business payload" is undefined.
	Proposal: Line 499 Needs definition for Business payload or replacement text
	Resolution:

Email from Tom Rutt on 5/25/04: Subject ( Proposal to resolve PC 11.24)

Proposal to resolve PC11.24

The word payload is used in the following lines of draft .998 without the word “business” preceding :

169, 170, 171, 172, 173, 176, 177, 178, 181, 376, 390, 403, 405, 418, 425

The two words “business payload” are used in the following lines of draft .998:

373, 401, 404, 408, 417, 415, 411

Proposal:

Change “business payload” to “payload” wherever occurring in the spec.

Add the following definition for Payload:

Payload: the contents within the SOAP body of a Reliable Message.

This definition does not include attachments.

Jacques: I do not think we need a definition at this level of detail. The abstract definitions of deliver etc needed a term, other than message. We only need to stick to that.

Tom suggested the following definition:

Payload: information passed in the submit operation to the sending RMP.

Doug: that definition includes configuration and parameter information. The receiver of a reliable message may include in the response some payload information.

Tony: define as the non reliable messaging parts of the message.

Tony the word payload is not used in SOAP 1.1 or SOAP 1.2.

Jacques: Payload appears in the definitions of produce and consumer.

Pete: SOAP 1.1 – information intended for the ultimate recipient of the reliable message.

Payload: information intended for the consumer of the reliable message.

Pete moved to remove prefix Business in front of payload, and the define payload as:

Above, Seconded by Jacques.

No oppostion motion passes.

5.3 PC13 HTTP POST as Mandatory

PC13	Spec	Editorial	open	Tom Ruttl
	Title: HTTP POST Binding Clarification
	Description: We need to clarifiy that the mandatory binding in the spec is to use htttp post.This is not stated clearly.In fact we need to clarify the exsting lines 1310, 1311, 1312"(3) The Acknowledgment Message is sent with another HTTP connection from the Receiving RMP to the Sending RMP. Example 15 is an example of this message.(4) The HTTP response for (3) has no HTTP message body. Example 14 is an example for this HTTP Response."to require an http post request.This clarification is needed, for interoperability, to avoid the use of http get when http post is expected.
	Proposal: From Tom Rutt on 18 May 2004 21:22:35 -0000Add the following paragraph to the intro to section 6"This section specifies a normative binding of WS-Reliability soap header elements, using the SOAP binding to HTTP, as specified in Section 6 of SOAP 1.1. The WS-Reliability header elements, when mapped to an HTTP request, must be carried in an HTTP POST operation."Add the following sentence to the conformance clause:"The binding of WS-Reliability protocol specified in Section 6 of this specification, using SOAP HTTP binding defined in section 6 of SOAP 1.1, must be used when this specification is bound to SOAP over HTTP."Meeting discussion 5/18:Anish: What do you intend on this wording. Are other protocol transport bindings allowed.Tom: the intent is If you use this spec with SOAP over HTTP you must use the binding in section 6.Take this to the list for wordsmithing.
	Resolution:

· Re: [wsrm] Clarification of HTTP POST Binding for WS_Reliability
From Tom Rutt <tom@coastin.com> on 24 May 2004 16:11:28 -0000

Here is my refined proposal to satisfy the HTTP mapping issue:

Tom Rutt wrote:

> Add the following paragraph to the intro to section 6

> "

> This section specifies a normative binding of WS-Reliability soap

> header elements, using the SOAP binding to HTTP, as specified in

> Section 6 of SOAP 1.1. The WS-Reliability header elements, when

> mapped to an HTTP request, must be carried in an HTTP POST operation.

> "

Change to:

This section specifies a normative binding of WS-Reliability header

elements, as SOAP headers carried using HTTP, as specified in Section 6

of SOAP 1.1. In particular, WS-Reliability header elements, when

mapped to an HTTP request, must be carried in an HTTP POST operation.

> Add the following sentence to the conformance clause:

> "

> The binding of WS-Reliability protocol specified in Section 6 of this

> specification, using SOAP HTTP binding defined in section 6 of SOAP

> 1.1, must be used when this specification is bound to SOAP over HTTP.

> "

Change the new conformance statement to the following:

An implementation which uses SOAP over HTTP transport to carry

WS-Reliability header elements, MUST conform to the normative mapping

defined in Section 6 of this specification, for all RM-reply patterns

supported by the implementation.

Mail from Tony:

What about SOAP 1.2, e.g., Section 7, SOAP HTTP Binding, of SOAP 1.2

Part 2:

http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#soapinhttp

Regards,

Tony Graham

Tony, we need to refer to both of these soap versions, since there are normative references to both.

Anish: we probably want to say something more than that. We need to state that if the initial request is soap 1.1 the response must be soap 1.2.

The exact words might require some wordsmithing.

Defer to next week, small team of Anish and Tom will come up with a proposal for next week.

5.4 Editorial Comments

On draft .998

5.4.1 ReplyTo Property

· Editorial change to reply to property
From Tom Rutt <tom@coastin.com> on 25 May 2004 16:31:57 -0000

Lines 1741 - 1742 of draft .998

The property for reply to needs to be updated to the new type:

Currently states:

A.V.D. ReplyTo URI

This property is identified by the QName "wsrmf:ReplyTo" and corresponds

to the semantics specified by the WS-Reliability reply-to. The type of this property is wsrm:ReplyTo.

delete the word "URI" from the title of the subsection.

Change the type from "wsrm:ReplyTo" to "ref:ServiceRefType"

need to add the namespace prefix "ref" to the document’s namespace table.

Seems to make sense.

No disagreement with editorial cleanup.

agreed

5.4.2 Namespace for Schema, and location

· [Fwd: [Fwd: How do we post schemas at the namespace location forOASIS specs.]]
From Tom Rutt <tom@coastin.com> on 25 May 2004 16:09:29 -0000

Sunil wrote:

This is what WS-Security is also doing. To achieve this, we need to CHANGE the

namespaces of all the 3 schemas to start with the following:

http://docs.oasis-open.org/wsrm/2004/05/<filename>

Could you add this as an issue for tomorrow's con. call?

-Sunil

Need to change namespaces of our schemata to be the same as URL for final location on OASIS server. Also, may need to revisit the use of version 1.1 in our namespace as a “direictory”.

Oasis has given us a document directory http://docs.oasis-open.org/wsrm

WS security followed the convention of year and month.

:Action: Sunil will come up with a proposal for the namespace for all four of our schemas.

5.4.3 Editorial Comments from Sunil on draft .998

· Re: [wsrm] Groups - WS-Reliability-2004-05-24.pdf uploaded
From Sunil Kunisetty <sunil.kunisetty@oracle.com> on 25 May 2004 05:05:00 -0000

Iwasa,

Some comments on the latest version:

Table 2(line 138) should also include the namespace for ServiceReferenceType

schema..

Prefix: ref

Namespace: http://www.oasis-open.org/committees/wsrm/schema/1.1/reference

Agreed editorial, Iwasa should implement in next version

Line 176/Definition of ‘Deliver’.

I’m uncomfortable with the usage of the word ‘transfer’ in the definition of the ‘payload’.

I prefer the words ‘makes available’. Proposed new definition:

Transfers implies the consumer is ready. The word makes available.

Pete: responsibility for the payload is transferred.

Deliver:

An abstract operation supported by the RMP. When invoked, the operation transfers the payload

data of one reliable Message from the receiving RMP to the Payload Consumer (e.g., a request to the application layer to take responsibility for the Reliable Message).

Sunil:

Jacques : we should make the example more straight forward. Example (eg, the payload is placed into a queue by the receiving RMP). Or

Sunil moved, Doug seconded to Change definition of deliver to:

An abstract operation supported by the RMP. When invoked, the operation makes the payload of one reliable Message available to the Consumer (for example, in one specific implementation choice, the payload is placed into a queue by the receiving RMP to be consumed by an application component).

No opposition, motion passes.

Line 274 should be reworded to also cover the async. case. I believe I’ve mentioned this couple of times before.

Proposal, change to the following

“The RM-Reply can either be sent in underlying response of the request or sent as a different request.”

Agree as editiorial change.

Table 3/Line 309:

Is ReplyTo to an agreement item? The schema on page 59 (line 1743) seem to

include this, where as the table doesn’t reflect it. I believe it shouldn’t be there, and table content is correct. If so, we need to update the schema.

Easiets fix is to delete A.V.D Reply to property and remove reply to from the schema in A.VI

Sunil moved to delete “reply to” property section A.V.D and to delete that property from schema. , Iwasa seconded.

No opposition motion passes.

Example 1 (pg. 17/line 510) still uses the old version of ReplyPattern type.

Same thing with Example 3/Pg 23/Line 683. Should use the new ReplyPattern with Value sub-element.

Same thing with Example 10.

Agreed editorial fix.

Appendix A:

Please include links to the 2 new schemas (fnp.xsd for the F,P, & C constructs and wsrmf.xsd for WSRM properties).

Agreed to Put in a table with four rows, on row per schema.

Column 1 is namespace, and column 2 is a URL to the WSRM web page.

Remove the schema A.VI. from the document. If it has to be included, it needs to be correct with the correct namespaces.

Agreed to remove section A.VI from the document, already has been placed into a file.

Examples A.VII.A, A.VII.C, and A.VII.D use “wsrmf:DuplicateElimination” which should be replaced with “wsrmf:NoDuplicateDelivery”.

Agreed editorial fix.

-Sunil

Action: iwasa to apply editorial changes.

5.4.4 Pete Wenzel comments on draft .997

· Re: [wsrm] Groups - WS-Reliability-2004-05-18.pdf uploaded
From Pete Wenzel <pete@seebeyond.com> on 18 May 2004 21:49:36 -0000

There are a few problems with the section numbering in this draft:

Section numbers are missing from level-3 and level-4 headers in

Sections 3 and 5.1.3.

Some sections are numbered (1) instead of X.Y.1; prefer the latter,

so they can be referred to completely and will appear in TOC

sensibly.

Appendix A numbering format should be A.2.2 instead of A.II.B, for

example.

Table of Contents needs to be refreshed.

--Pete

Pete took action to see what changes are still required.

5.5 Rel 25 on Requirements Doc

REL-25 Req feature Design Active Tom Rutt Jeff Mischkinsky

Title: Compatibility

Description: How do we consider other specifications? WS-attachments, ws-security, which other specifications should we strive to be compatible with?
[see 4/22 minutes]
Note that WS-Security is huge and now includes features such as an acknowledgment mechanism that "has nothing to do with security" [who said that, I didn't catch it?]. This is the Secure Receipt Protocol [??].
What does it mean to ensure compatibility? Depends upon portion of the large specification of importance. Might include such things as provision for identifiers in each of our elements.
Definitely want to be able to secure a reliable message, avoid "re-inventing the security wheel".

10 Feb 2004: Somebody should confirm that our specification can be composed with WSS TC output. Jeff M. will search at Oracle for appropriate investigator. (He suggested that a tutorial on WSS use with WS-R may be even better but did not promise to resolve that larger concern.)

Proposal: iwasa: Include a requirement as follows: The spec should be usable with other open standard technologies, if appropriate.
Updated proposal: Add requirement reading "Ensure that WS-Reliability is usable in combination with WS-Security to implement secure reliable messaging."

Resolution: Accept new wording as updated above. [[Is this an "in particular" for existing general "works well with others" requirement?]]
28 Aug 2003:

Implementation note: The originally proposed words remain in the Requirements document, is this in line with the resolution?

Is the requirements document what we wanted.

Leave it open to discuss next week.

6 Discussion of Document Progression.

Action: Iwasa sould have a new document, .999 available by Wed .

Tentative Schedule:

June 1 – all changes agreed at TC Teleconf.

June 2 – Frozen document available for informal 6 day review.

June 7 – editorial changes required to be posted to list.

June 8 – TC votes to approve CD at Teleconf, and also votes to submit to OASIS member vote.

June 15 – submission sent to OASIS Staff

Question from chair: Is everyone happy with not having another public review?

No opposition was reported.

Pete expressed a concern that it might be a concern raised by outsiders.

Tom: Only two things have changed in the schema: 1) we changed the name of an attribute and took away values; and 2) we changed an attribute to an element to make it extensible. There were extensive editorial clarifications made to the text.

7 Frequently Asked Questions

· Updated WSRM FAQ
From Tom Rutt <tom@coastin.com> on 11 May 2004 01:11:54 -0000

Frequently Asked Questions about WS-Reliability Specification

Q:What is the need for the WS-Reliability specification?

Answer:

As Web Services (WS) start to be deployed across enterprise boundaries and for collaborative e-business and e-transaction scenarios, message reliability becomes a critical issue. This is because communications over the Internet (and Intranets) is inherently unreliable, as usage of the “transport protocols” (e.g., HTTP, SMTP, and other message delivery protocols) admit conditions which do not offer guaranteed or ordered delivery. Yet WS messages need be delivered to the ultimate receiver, even in the presence of component, system, or network failures. If a message can’t be reliably delivered, then the user must be so informed.

Q: What are the reliability features supported by the WS-Reliability specification?

Answer:

A] Guaranteed delivery Delivery at least once - the sent message must be delivered at the receiver, or else a notification of potential delivery failure is given to the sender.

B] Duplicate elimination - Delivery at most once -with duplicates detected and eliminated by the RMP receiver,

C] Guaranteed message ordering – messages are delivered in the order sent

Q: When will the WS Reliability spec be completed and what is it based on?

Answer:

Agreement was reached in Nov 2003 on a committee draft spec (v0.52),

which was implemented in a demo at the Philadelphia XML Conference, in

Deceber 2003. The TC has recently voted on a committee draft spec

(v.0.992) which completed its 30 day public review, April 19, 2004.

Note that the spec is based on Requirements issues that have been

compiled for the committee’s internal use (over 100 requirements have

been identified).

- An OASIS standard could be approved in the 2nd Quarter of 2004

Q: How is WS-Reliability designed to compose with other web service protocols?

Answer:

Web service specifications which can compose with WS-Reliability are likely to fall under the following (fuzzy) categories :

(a)- "Under WS-R": Add-ons to SOAP transport like routing, addressing, that WS-R may need to accommodate or profile.

Status: nothing in the open space yet

(b)- "Supporting WS-R" specifications (policies, WSDL annotation), that support some function assumed by WS-R but not central to its deployment:

Status: not finalized or not open.

(c)- "Over WS-R", Higher level specifications (BPEL, Choreography, CAF, ASAP...) would use/profile reliability, not the reverse.

(d)- "Complementary to WS-R" specifications (Security, transactions, Context...)

that support other business requirements likely to be used in conjunction with reliability, and share message footprint.

SOAP header composability and processing model make this possible.. An important consideration in design of the WS-Reliability protocol was to have it be orthogonal to any other web services protocols which define the use of soap header elements. WS-Reliability defines elements to be sent in Soap headers . Our header elements only contain parameters essential for the operation of the WS-reliability protocol. For example, WS-reliability defines a reply to element for the sending Reliable Message Processor to convey a call back address for the Reliable messaging reply. This address is independent of any other reply mechanisms used for other protocols (e.g., WSDL response is not influenced by the WS-Reliability reply To parameter). Apparent redundancy (message ID, reply to address for callback) should not be an issue

Appropriate profiling and guidelines may apply.

Q: What is the relationship between WS-R and ebXML V2.0?

Answer:

Overall, they both have same messaging reliability contracts as objectives: guaranteed delivery, no duplicate delivery, ordered delivery, and combinations

of these.

However, WS-R has improved on scalability and performance by generalizing the use of sequence numbers, and can accommodate different security and access conditions on each party, as this is more frequently the case with a Web service and its clients, compared to more symmetrical access conditions in messaging. The reliability contract is more "application-oriented" in WS-R, where acknowledgment is on final delivery, in contrast to "on receipt" by the message handler in ebMS.

Q: Why does the spec have a different name than the TC?

Answer:

The difference in naming of the TC (WS Reliable Messaging) and the specification (WS Reliability) is a result of how materials were originally submitted to OASIS to initiate this activity. The TC chose not to rename the specification to avoid confusion with a similarly named, though unrelated, specification (WS-ReliableMessaging) that has not been submitted to a standard body. This permits one to unambiguously refer to the exact specification being discussed.

The question:

Q: How does the WS-Reliability protocol relate to WSDL operation types?

Answer:

The current answer is only about reply patterns.

Ø Jacques; Action: Jacques will write an answer to this question.

Question on whether we need another question about reply pattern specifically.

There are three reliable messaging reply patterns which may be used with WS-Reliability:

· Response RM-Reply Pattern: the outbound Reliable Message is sent in a request of the underlying protocol and the RM-Reply is sent in a SOAP header element in the response message of the underlying protocol that corresponds to the request.

· Callback RM-Reply Pattern: the RM-Reply of a previous message is contained in a SOAP header element an underlying protocol request of a second request/response exchange (or a second one-way message).

· Polling RM-Reply Pattern: a second underlying protocol request is issued to the receiver of a previous message, in order to obtain a RM-Reply. The RM-Reply can be either contained in the underlying protocol response to this request or in a separate underlying request from the receiver to the sender. This polling pattern is generally expected to be used in situations where it is inappropriate for the sender of reliable messages to receive underlying protocol requests (behind the firewall cases) or to avoid resending bulk messages often.

Jacques this needs to be cast in a more user friendly manner.

Relate these to user requirements.

Action: Sunil and Jacques will work on a more user friendly way to form a question and answer about reply patterns.

Mail from Jacques:

Tom keeps reminding me over a lingering action item for the FAQ,

about WSDL operations support.

Here is my proposal:

Q: How does the WS-Reliability protocol relate to WSDL operation types?

WS-Reliability has been designed to support One-Way and Request-Response operations.

The two following requirements are observed by WS-Reliability:

1- An implementation of WS-Reliability is not supposed to be aware of the type

of WSDL operation associated with the messages it is processing.

2- The RM protocol specified is compatible with current WS-I profiles.

One-Way operations: All RM features specified apply to these operations,

with the following restriction: In order to comply with current WS-I profiles,

the "Response" reply pattern must not be used with these operations.

Request-Response operations: These are often supported in a synchronous way by SOAP implementations, and in general this gives to the application a level of control that reduces the benefits of RM features. Some reliability features clearly are not much relevant (like Ordered Delivery, given that the application layer itself has control on the sequencing). The application can also be certain that a delivery occurred, when it receives the response.

Agreed to Delete the parenthetical statement above. Soften the wording, to “may be less relevant to many implementations (e.g., if HTTP piplining is used, ordred delivery is less relevant).

Although the RM features defined may still be used, the Guaranteed Delivery protocol defined here does not apply to the "response" leg of Request-Response operations because its transport-synchronous nature (as required by WS-I profiles) requires special handling left out of 1.0.

Because an implementation is not required to distinguish messages based on their associated WSDL operation type, enforcing the above restrictions (with the exception of the "response" leg) depends on the user layer, e.g. messages have to be sent under the reliability agreement that is appropriate to their WSDL operation type.

Action: Tom Agreed to put the agreed text from Jacques in the next draft.

TC members should Review between now and next meeting, so we can target a faq to post after next week’s meeting.

8 Discussion of Potential Face to Face meeting in Brussels in October

WSRM TC members, all OASIS chairs received an e-mail from the OASIS staff and they need a quick reply.

All TC chairs are being asked if their TCs would be interested in holding a F2F meeting in Europe, probably the week of October 4-8 at an event hosted by OASIS in Brussels. I think the plan is that this will be similar to the recent New Orleans event.

For right now, OASIS are just looking for an informal "yes we might be interested" or "no we probably won't be interested".

Pete: what do we expect the status of the TC to be at that time.

Tom: we have a implementers guide we could finalize at that time. We could start working on future protocol features.

Bob F: the idea of European f2f is a good idea. However constructing a meeting without a reason does not seem appropriate. We should define what we would do if we had a meeting at that time.

Doug B: I would go one step further, in that the use of the combined meeting time was not leveraged for joint meetings. If we do see a reason to liaison with other TCs we should do it.

Bob F: We should use it as a lobbying and inter-working meeting, than our usual agenda.

Answer is “Yes we might be interested”, and if we are done it would be a liaison meeting. Go around to liaison.

Would two ½ days be enough. Would be more interested if other TCs are meeting:

Before we would do our final decision we would want to know what other TCs are meeting.

Pete: this would be an OASIS showcase.

Tom: what about another interop demo at that venue.

Jacques: that would make sense if we are done by June 15 with a spec.

Bob F moved to adjourn, seconded by Mark Peel.

wsrm message

1 Draft Agenda:

2 Roll Call

3 Minutes Discussion

3.1 Appointment of Minute Taker

3.2 Approval of previous meeting minutes

4 Status of Action Items

4.1 Action editors-1  (Marc and Doug) Pending

4.2 Action 050404-1 (Iwasa)

4.3 Action 050404-4 (Iwasa)

4.4 Action 051104-10 (Jacques)

4.5 Action 051804-1 (Iwasa)

4.6 Action 051804-2 ( Bob F )

4.7 Action 051804-3 ( Tom )

5 Discussion of Issues and editorial Comments

5.1 PC 11.15

5.2 PC11.24

5.3 PC13 HTTP POST as Mandatory

5.4 Editorial Comments

5.4.1 ReplyTo Property

5.4.2 Namespace for Schema, and location

5.4.3 Editorial Comments from Sunil on draft .998

5.4.4 Pete Wenzel comments on draft .997

5.5 Rel 25 on Requirements Doc

6 Discussion of Document Progression.

7 Frequently Asked Questions

8 Discussion of Potential Face to Face meeting in Brussels in October

4.1 Action editors-1 (Marc and Doug) Pending