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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

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


Subject: Prelim Minutes of WSRM TC 2/17/04


Prelim minutes are attached.

Please post any corrections to the list.

Tom Rutt
WSRM Chair

-- 
----------------------------------------------------
Tom Rutt		email: tom@coastin.com; trutt@fsw.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133


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

Prelim Minutes WSRM TC Conference Call – Feb 17, 2004

 

The meeting of the WSRM TC took place by teleconference 
Tuesday Feb 17 2004, from 5:30 to 6:45 PM Eastern Standard Time
(UTC - 5)
 
Conference call Dial-in number : Toll number (only): 1-512-225-3050 Participant code: 89772

0         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 Discussion of New Orleans Meeting and Conference papers

4 Discussions of Issues

 

Agenda approved

1         Roll Call

Attendance:

First Name

Last Name

Role

Company

Voting Level

Joseph

Chiusano

Member

Booz Allen Hamilton

1

Peter

Furniss

Member

Choreology Ltd

1

Jacques

Durand

Member

Fujitsu

1

Kazunori

Iwasa

Secretary

Fujitsu

1

Tom

Rutt

TC Chair

Fujitsu

1

Jishnu

Mukerji

Member

Hewlett-Packard

1

Robert

Freund

Member

Hitachi

1

Nobuyuki

Yamamoto

Member

Hitachi

1

John

Fuller

Observer

Individual

 

Alan

Weissberger

Member

NEC Corporation

1

Mark

Peel

Prosp Member

Novell

 

Sunil

Kunisetty

Secretary

Oracle

1

jeff

mischkinsky

Member

Oracle

1

marc

goodner

Secretary

SAP

1

Pete

Wenzel

Member

SeeBeyond

1

Doug

Bunting

Secretary

Sun Microsystems

1

Tony

Graham

Member

Sun Microsystems

1

Chi-Yuen

Ng

Member

University of Hong Kong

1

 

 

 Meeting was quorate.

2         Minutes Discussion

2.1      Appointment of Minute Taker

Tom Rutt will take minutes.

 

Minutes will serve to record issue resolutions.

2.2      Approval of previous meeting minutes

http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/5479/MinutesWSRMTC021004.htm
 
Joe  moved to accept the Feb 10 minutes. Jishnu  seconded.
 
No opposition, 2/10  minutes approved.

 

3         Discussion of New Orleans Meeting and Conference

Tom stated he told the OASIS staff that we wanted to meet all day Wednesday, and Thursday morning for our F2F.  This has been verified.

 

The chair of the EBMS TC has contacted Tom Rutt, and requested some time for a joint meeting of the two groups.

 

Bob F stated the first day would be best.  ½ morning or ½ afternoon would be preferred.

 

The schedule is now:

Small Room 1--Audubon (holds 18)

 

Wednesday -   OASIS XACML TC (10 participants)

Thursday -       OASIS XACML TC (10 participants)

 

 

Large Room 2--Balcony I (holds 30)

 

Wednesday -   OASIS WSRM TC (10 participants)

Thursday -       OASIS WSRM TC 8:00AM-12:00PM

                        OASIS ebXML IIC TC 1:00PM-5:00PM

 

 

Large Room 3--Balcony L (holds 30)

 

Wednesday -   OASIS LegalXML Electronic Court Filing TC (13 participants)

                        OASIS LegalXML Electronic Court Filing TC--Evening reception

Thursday -       OASIS LegalXML Electronic Court Filing TC and OASIS LegalXML

Integrated Justice TC (30 participants)

 

 

Large Room 4--Balcony M (holds 30)

 

Wednesday -   OASIS Emergency Mgmt TC (15 participants) 8:00AM-12:00PM

                       OASIS ebXML Registry TC  (6 participants) 1:00PM-5:00PM

Thursday -       OASIS ebXML Registry TC  (6 participants)

 

 

Small Room 5--Beauregard (holds 18)

 

Wednesday -   OASIS Li-XML TC (5 participants) 8:00AM-12:00PM

                       OASIS ebXML CPPA (? participants) 1:00PM-5:00PM

Thursday -       OASIS CAM TC (? participants)

 

 

Large Room 6--Balcony N (holds 30)

 

Wednesday -   OASIS WS-CAF TC (15-20 participants)

Thursday -       OASIS WS-CAF TC (15-20 participants)

 

 

Small Room 7--Jackson (holds 18)

 

Wednesday - OASIS ebXML Messaging TC (10-12 participants)

Thursday -  OASIS ebXML Messaging TC (10-12 participants)

 

 

Suite ONE

 

Wednesday - OASIS Board (12 participants)

Thursday -       OASIS Board (12 participants) 8:00AM-12:00PM

 

 

Suite TWO

 

Wednesday - OASIS XDI TC (12 participants)

Thursday -       OASIS WSDM TC (? participants)

 

***Wait List; OASIS XDI TC (needs another day), OASIS ebXML BP TC ((?

participants), OASIS Legislative TC (10-12 participants), FWSI (10-12

participants) need phone***

 

4         Discussion of Issues

4.1      Rel 108/115 Semantics of Polling and Fault Returns

Tony Graham sent reference to requirement: Protocol must support fault information.

 

Mail from Tom Rutt:

 

I propose that we resolve rel 108  and 115 with the following resolution:

 

a) accept the unified response schema (eliminating the fault element) posted at:

http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/5496/ws-reliability-uniresponseOpt.xml

 

The Idea is simple, one element returned per group being reported.

 

That element has a groupID attribute, and one or more lists.

 

a) a list of sequence numbers to report messages in that group which have been delivered.

 

b) for each fault code which has been encountered for messages in that group, an element which has the fault code and a list of sequence numbers which faulted due to that code.  This proposed schema does not include fault detail info, however that could go into the fault detail element if so warranted.

 

The following restrictions are to be applied:

 

1) for response reply pattern, only one ack or only one fault can be reported in the response.

 

2) for callback reply pattern, acks may be batched, but only one fault can be reported in the callback. (this is to use the underlying fault

mechanisms for timely repoting of fault conditions via callback).

 

3) for poll requests (on messages send using any reply patternt), both acks and faults must be batched in the poll response.

 

Tom Rutt

 

Doug opened discussion.  He is not sure why we are restricting use of these elements. Simply not requiring more heavyweight extension, might be enough.  The restriction on response reply pattern, forces them to use poll or callback for sending data back on earlier message.  We might want to rethink our earlier discussions on this.  Adding restrictions is too much, It would be better to just not requiring extra features.

 

Doug: Messages that had been held due to missing message. Those that had been held cannot be acked until retry.

 

Eg: System a sends 1-4.  2 does not get to B, eventually 2 is resent, system b, could now ack 2 thru 4 in same response.

 

Sunil: how do you know it is the same sender.

 

Doug: it is in the same group.

 

Sunil: that does not mean it is the same sender.   Two problems: initial reliability spec had from field. 

 

Sunil assumes that a group could span more than one sending endpoint. 

 

Tom: what about callback.

 

Sunil the callback case does not allow multiple faults.  The faults would have to be delayed, by batching.

 

Tom: in some cases the RMP may want to batch outstanding faults to send back.

 

Tom: there is the mapping to the underlying Soap Fault mechanism.

How important is the mapping to the soap fault model.

 

Need to carefully map to Soap model for faults.

 

Jacques: there might be issues to merge soap faults with wsrm faults.  WS-I cannot send fault on oneway operation.  WSDL one way should not contain soap fault on http response.

 

Sunil: However, callback has fault on request.

 

We have to harmonize the way we handle faults.

 

Need to harmonize with Soap 1.2.

 

HTTP request has soap fault for callback of fault.

 

Soap 1.2 clarifies this.

 

Action: Can we use our own rm fault in header without the soap fault stuff.

 

Leave open for further discussion.

 

If there are any acks in reply is should not be fault.

 

The polling response should allow mixtures of acks and fault info.

 

Schema: Sunil, Tom, Jacques. Tony , Soap fault model issues.  Tony Graham

 

4.1      Rel 114 - Ack and Fault Response Contents

Would be accommodated by proposal for Rel 108/115

 

4.2      102 Message persistence at receiver

 

Current 2.7 text:

With Reliable Messaging, the sender is REQUIRED to persist the message until one of the following conditions are met:

Receipt of an Acknowledgment message from receiver, indicating the message has been successfully delivered.

All retry attempts have failed, and a delivery failure is reported to the application layer.

The span of time indicated by the ExpiryTime element has expired.

The receiver MUST persist out of order messages to support Guaranteed Message Ordering.

The receiver MUST persist the Message Identifier to support Duplicate Elimination. Both sender

and receiver MUST behave as if there was no system failure or system down after recovery.

 

Proposal from Jacques email:

Rel-102 (Persistence requirements):

Overall proposal:

just remove the section 2.7, because it is redundant with what RM features require. I.e. when implementing most of these features, persistence will automatically appear as necessary. It is an implementation aspect.

In addition, some persistence requirements may actually NOT be necessary to satisfy some RM requirements, i.e. are encroaching on implementation choices.

Details:

<JD>
- the Sender side has to be able to resend the same message (retry). We don't need to state more than that.

How is that achieved, is an implementation decision. Some form of persistence is likely to be needed, but after all there may be alternatives that we should not preclude (e.g. the RMP fetching messages to be resent, from an external store...)

- Receiver side: same proposal: persistence is implied by the RM features. In addition, here again the current proposal in the Feb 4 issue list, will unnecessarily restrict implementation choices.
</JD>

The current proposal:
"When supporting Guaranteed Message Ordering, the receiver is REQUIRED to persist out of order messages until one of the following conditions are met:
* Receipt of all previous messages and successful invocation of the deliver operation.
* The span of time indicated by the ExpiryTime element has expired.

<JD> The first bullet is a repeat from the definition of Ordering, along with a way to implement it (persist messages). The second bullet is also a consequence of our definition of Expiry time, obvious to an implementor.

Finally, the REQUIRED above is too strong: memory constraints can also limit the persistence of such sequences.

Finally, there are other ways to implement ordering, by relying on the persistence of the Sender instead of the Receiver: As Jun mentioned, there is a way to implement Ordering without persisting any pending out-of-order sequence, e.g. just by relying on the resending window to get messages in the right order. This may not allow long out-of-order sequences, but this is an implementor's discretion to decide how much can be stored based on physical constraints.</JD>

When supporting Duplicate Elimination, the receiver is REQUIRED to persist the Message Identifier until one of the following conditions are met:
* The span of time indicated by the ExpiryTime element has expired
* anything else?.

<JD> again, this is implied by the definition of Duplicate Elimination, and the definition of Expiry time. We might as well make this a more explicit and abstract requirement of Duplicate elimination: "when D.E. is required, the receiver RMP MUST check duplicates over all previous non-expired messages." Plus, this persistence requirement is somehow confusing, as for groups we don't need to actually persist every ID but just remember intervals of seq nums.</JD>

Jacques moves to remove 2.7 from the specification.  Alan seconded.

No opposition, agreed.  Close Issue 102 with this change.

4.3      Rel 113 Message Delivery processing after Fault.

Jacques sent the following mail, which includes a dialog with Sunil:

Sunil:

Case 1- a message requires an Ack, yet the receiver does not implement this feature.

Should the Receiver drop the message and just send back the Fault? Why not deliver the message?
 

 It all should  depend on the mustUnderstand (mU) attribute. If the mU=1, and the
 receiver doesn't understand it, then it MUST generate a Fault and message should
 not be delivered.
[Jacques Durand] I realize that we always generate a SOAP fault for every RM fault header element (should we make that more explicit in spec). If that is teh case then yes, although the decision how to interpret "understand" being the RMP decision, the level of processing done to the message before deciding of a fault could include delivery to upper layer if we wanted.

In any case, I agree now we should not "RMP-deliver" on a fault...


 If mU=0, then if the receiver understands it, then it will deliver and send an Ack. back
 and if if the receiver doesn't understand it, it MUST still deliver the message.
[Jacques Durand] I believe we always require mU=1 for RM headers, so that case should not occur? If "does not understand" means an RM failure, we would not deliver I guess - I think you talk about the SOAP node "delivery" , not RMP delivery.

 

 

  
Jacques 

 

We make a principle that we will not give a fault for delivered message, and that we will not deliver a message with an RM fault.

 

Jacques stated we should state this more clearly.

 

 

 

Tom Rutt also sent the following email related to this issue:

It has been pointed out that the spec needs to be clarified regarding the affect of a faulted message on the processing of messages in a group.

 

Text needs to be added to section 4 on the affect of a fault on guranteed delivery, duplicate elimination and ordered delivery processing by both the sending and Receiving RMP.

 

Perhaps some of the statements in Section 3 need to be qualified as to pertaining to delivered messages only.

 

Tom Rutt.

 

 

Tony – section 2.4 does not mention faults. The receipt of a fault might change the processing

 

Sunil: affect of fault messages of group termination parameters.

 

Keep it open,

Everyone send their fault concerns by Thursday end of day.  We can discuss at next meeting.  Feel free to propose replacement text.

 

4.4      New issue on elimination of Message Header on Replies

Tom Sent out the following email:

I propose to resolve the new issue on elimination of message header on reply with the following proposal:

Add a ReplyPattern attribute to the response header.  For a reply to the request reply pattern it must have value request, for a callback reply pattern it must carry value callback, and any response to a poll request must carry the value poll.

Add protocol statement that rm-reply messages (that are not themselves carrying reliable message request) do not
send the request header.

Tom Rutt

Open discussion:

Sunil: I see value in the reply pattern attribute.

 

Add to the schema team to work on complete text for this.

 

No opposition to this way forwared.

4.5      Issue 49 WSDL Annotation

No discussion on Email list, recommend we defer until proposal in front of us.

 

Three alternative for extension mechanism:

  • informative,
  • Optional but normative.
  • Mandatory support required by processor.

 

Jacques, it would be hard to require a mandatory extension support.

 

We need a proposal soon if we expect to meet our schedule.

 

Jeff: Interop comes from how the information is communicated on the wire.  We are talking about portability here.

 

Meta information needed when setting it up.  Optional but normative, if done, it should be done that way.

 

Tom: Wsdl required means you cannot process the wsdl if you cannot understand it. 

 

Jeff: This is different than making it mandatory.

 

 

5         Timing of WS-Reliability progression

Timeline proposed at F2F meeting.

  1. Feb 10   Tuesday call, final editing instructions agreed.
  2. Feg 12 – Document posted for TC internal review.
  3. Feb 24 – TC review comments resolved, editing instructions produced.
  4. Feb 25  Frozen document completed, TC review begins.
  5. March 2 – CD 1 ballot closes
  6. March 5 – 30 day Review initiated
  7. April 5 – 30 Day public Review ends
  8. April 15, submit to oasis staff for member vote
  9. May 01– Membership two week review
  10. May 15  – start member two week vote
  11. May 30 - member vote concludes.  Earliest Oasis Standard.

 

Sunil,

 

Editorial comments on table of contents.

 

Here is a proposal for purely editorial but sweeping changes - mostly a "Table of Content" remodeling, consolidating observations from Iwasa and I in some previous exchange with Iwasa, in case you missed these:

1. Section 2 "Messaging Model" is covering much more than just the messaging model. Reduce it so it only contains current 2.1. and 2.2.
- Also split 2.1 in two: "Assumptions" (new 2.1 with first paragraphs) and "Message Reply Patterns" (new 2.2)
- rename "Groups of Messages  and Message Identity" into:
"Message Identification and Grouping" (new 2.3), to emphasize message identity.

So Section 2 would become:

- Section 2 "Messaging Model"
- 2.1 "Assumptions"
- 2.2 "Message Reply Patterns"
- 2.3 "Message Identification and Grouping"

 

2. Introduce New Section 3: "Reliability Features" covering former 2.3 to 2.6:
This section introduces the reliability features, their logic, yet not at the
level of detail of message headers, which are only introduced in next
section "Message Format" (formerly Section 3).
- Message Persistnce (2.7) is removed.
- section 3.3 on Ordering will consolidate previous 2.5 and 2.6 (seq numbers)
- formerly section 2.8 (Group Termination) is moved down after "Message Format"
section, because it relies on header data that is only introduced in Message Format.

So Section 3 would become:

- Section 3 "Reliability Features"
- 3.1 "Guaranteed Delivery"
- 3.2 "Duplicate Elimination"
- 3.3 "Message Ordering"

 

3. "Message Format" (formerly sec 3) section becomes Section 4.
- We could move the "Fault Processing" section (formerly sec 4)
under "Message Format", as it really describes fault codes, a part of message format.
In fact, Fault Processing has a single subsection "Fault Codes for ...", so
just make this subsection a sub of "Message Format". So former Section 4 disappears.

So new Section 4 becomes:

- Section 4 "Message Format"
(same sub-sections as before, introduce header structure and semantics, and how RM agreement items map to header elements/attributes)
- 4.6 "Fault Codes for Reliable Messaging Failures"

 

4. Introduce a new section, which we could name "Operational Aspects and Semantics", with former 2.9 (WSDL ops) 2.10 (Poll Reply patterns) 2.11 (attachments).
- We could move in it the current "Group Termination and State Removal", renamed "Message Group Life Cycle".
- These sections rely on header data introduced in Message Format.
- These sections are really about detailed operational semantics,
closer to  deployment concerns.

So Section 5 becomes:

- Section 5 "Operational Aspects and Semantics"
- 5.1 "Message Group Life Cycle"
- 5.1.1 "Group Termination Rules"
- 5.2 "WSDL Operation Type"
- 5.3 "Poll Reply Pattern Semantics and Usage"
- 5.4 "Attachments"

---------------- proposed overall structure:

Section 1 "Introduction"
...
Section 2 "Messaging Model"
- 2.1 "Assumptions"
- 2.2 "Message Reply Patterns"
- 2.3 "Message Identification and Grouping"
Section 3 "Reliability Features"
- 3.1 "Guaranteed Delivery"
- 3.2 "Duplicate Elimination"
- 3.3 "Message Ordering"
Section 4 "Message Format"
 ...
- 4.6 "Fault Codes for Reliable Messaging Failures"
Section 5 "Operational Aspects and Semantics"
- 5.1 "Message Group Life Cycle"
- 5.1.1 "Group Termination Rules"
- 5.2 "WSDL Operation Type"
- 5.3 "Poll Reply Pattern Semantics and Usage"
- 5.4 "Attachments"
Section 6 "HTTP Binding"
...

Jacques presented his editorial proposal.

 

It involves reshuffling the text, and deciding what to put where. 

 

Jacques: no new text to write.

 

Iwasa: I am not sure what is required.

 

Jacques: another way to do it would be to make a diff with the current document.

 

Jacques will take action to make the proposal more precise.

 

 

Jeff M talked to Chris Ferris, about the complexity of our spec. 

 

We need to justify our changes.

 

They have not shared a latest version.

 



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