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: Preliminary face to face minutes

The preliiminary minutes are attached.

Please send your corrections to the list before Monday morning.

The open action items all have a common style (action) with a blue arrow 
bullet font.

Before monday I will compile a new open action item list.

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

Title: Bob Freund provided a new bridge number to allow us to dial in at the meeting

Prelim minutes WSRM TC Face To face Meeting at New Orleans Marriott


wed, April 28, 2004, from 9:00 am to 5:20 PM Central Daylight Time

Thur April 29, 2004, from 9:00 am to 12:00 Noon.


There was a conference bridge available on both days from 10:00 AM to 12:00 Noon CDT..


Tom Rutt agreed to take the minutes of this meeting.


1      Introduction. 2

1.1       Draft Agenda. 2

1.2       Roll Call 2

2      Approval of Meeting Minutes from 4/20 meeting. 2

3      Action Item Status Review.. 3

3.1       Action 033004-3 – (Jacques) 3

3.2       Action 033004-6 – (Tom) 3

3.3       Action editors-1 – (Marc and Doug) Pending. 3

3.4       Action 041304-1 – (Jacques) 3

3.5       Action 041304-2 – (Iwasa) 3

3.6       Action 042004-1 – (Jacques) Pending. 4

3.7       Action 040201-2 – (Pete) 4

3.8       Action 040201-3 – (Tom) 4

3.9       Action 040201-4 – (Tom) 4

3.10     Action 040201-5 – (Jacques) 4

4      Public review comments from OASIS Panel Discussion. 4

5      Editors Draft .993 Status Review.. 5

6      Status of Public Review.. 5

6.1       Comment 9.2. 5

6.2       Comment 7.10. 7

6.3       Comment 7.11. 9

6.4       Comment 7.12. 10

6.5       Comment 9.1. 10

6.6       Comment 3.14. 11

6.7       Comment 3.16. 12

6.8       Comment 3.17. 12

6.9       Comment 7.6. 12

6.10     Comment 7.9. 13

6.11     Comment 8.1. 13

6.12     Comment 8.2. 13

6.13     Comment 8.3. 14

6.14     Comment 8.4. 14

6.15     Comment 8.5. 15

6.16     Comment 9.3. 16

7      New Comments from Sunil 16

8      Tony Graham editorial comments: 21

9      Liaison activities with EbMS  - joint meeting. 28

10        Sunil new issues. 30

11        Planning for Future CD Balloting. 30

12        Review of Homework assignment status. 31

13        Draft resolution of CF public review comments. 32

14        Paper in response to Chris Ferris Presentation at OASIS Symposium.. 37

15        FAQ.. 38

16        Discussion of RMP in Soap Terms. 38

17        Planning for Future CD Balloting. 39


1         Introduction


1.1      Draft Agenda

To insert


1.2      Roll Call

First Name

Last Name




Voting Level





Booz Allen Hamilton






Cyclone Commerce

















TC Chair

























NEC Corporation






NEC Corporation





Prosp Member

Nortel Networks























Sun Microsystems






Sun Microsystems






University of Hong Kong



Meeting was quorate

2         Approval of Meeting Minutes from 4/20 meeting


Motion to approve Minutes of last meeting from Bob F, Doug B seconded.


No opposition 4/20 minutes approved.


3         Action Item Status Review


3.1      Action 033004-3 – (Jacques)

Jacques took action item to propose new FAQ text for the ws-reliability 
features. – 
Close by taking text from Sunil’s slides for the faq

3.2      Action 033004-6 – (Tom)

Need a general question on how can ws reliability be used with other ws 
reliability protocols. Answer : we design it as orthogonal, to work with any other ws- reliability protocol. An example on why we have a reply to element of our own would help.
Tom Rutt agreed to send a suggested question and proposal out regarding WS reliability composition. closed

3.3      Action editors-1 – (Marc and Doug) Pending


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

- open


3.4      Action 041304-1 – (Jacques)

- Jacques will send an email to initiate email discussion on poll response for fault conditions


·  treatment of aborted out-of-order seq
From Jacques Durand <JDurand@us.fujitsu.com> on 14 Apr 2004 00:15:05 -0000

Closed will discuss with issues

3.5      Action 041304-2 – (Iwasa)

- Iwasa to consolidated agreed comments in text with 
change bars against CD .992. A list indicating which meeting minutes’agreed changes were applied should also be included.

·  Groups - UpdatesListFromCD10Mar2004-0.992.pdf uploaded
From kiwasa@jp.fujitsu.com on 20 Apr 2004 14:41:05 -0000

·  Groups - WS-Reliability-2004-04-19.pdf uploaded
From kiwasa@jp.fujitsu.com on 20 Apr 2004 14:40:08 -0000





3.6      Action 042004-1 – (Jacques) Pending



Ø Action: Jacques will propose the text changes to the document to remove retry parameters

Provided for the agreements section 1, still open for section 3 and the annex

3.7      Action 040201-2 – (Pete)



Pete will provide an input to the F2F on the RMP / soap processing model to help resolve the XMLP WG’s concern.. Include a proper definition of RMP

Done – spawned New action item on Jacques and Pete


3.8      Action 040201-3 – (Tom)



Tom should put general document restructure on the agenda.



Spawned Jacques action item on document restructure


3.9      Action 040201-4 – (Tom)


Tom took an action a proposal to clarify when the Receiving RMP may need to send a SOAP fault to close the WSDL level response.



3.10Action 040201-5 – (Jacques)

Jacques will take an action to write a proposal to try to resolve Martin C’s comments.



4         Public review comments from OASIS Panel Discussion


The group formulated a set of public review comments.from the presentation by Chris Ferris:


Cf1:  Two schemas and namespaces are unnecessary for two soap versions.



Cf2:  Why are soap faults not used for RM-Fault?



Cf3: Not Acking until delivery to the application causes unnecessary delays?



Cf4: Unclear if the spec can compose with WS-Addressing or WS-MD?



Cf5: Persistence model will not work on devices with non volatile storage?



Cf6:  Mandatory Expiry time requires synchronization of clocks:



Cf7:  There is unnecessary complexity in the spec, headers have unnecessary elements making them larger than necessary?


Tom Rutt provided draft resolutions for discussion by the TC (see discussion below).


5         Editors Draft .993 Status Review


Sunil moved to accept all changes in editors draft .993 and its associated schema, Alan seconded.


No opposition, motion passes.


6         Status of Public Review




10:30 12:00 Noon – Issues and Editorial comment resolutions


6.1      Comment 9.2





agreed text not yet applied

Faults for Aborted Ordered Deliver

treatment of aborted out-of-order seq


Action on Tom and Iwasa to provide final text to explain new group abort error..



Out of order sequence:

We talked about two Issues that are not unrelated,
yet after review, I believe only one remains:

----- Issue 1:

Should the Receiver warn the Sender that an out-of-order sequence has been
aborted on the Receiver side, due to a reason other than message expiration?
(in case of message expiration, the Sender can - generally - deduce the failure).

Position 1: This can't be more than just an optimization, as the reliability
contract would not be broken anyway (would not cause delivery of un-ordered messages !)
And also we never rely on error messages for critical RM logic.
Note also that any further "quantitative" aspect of RM (e.g. about max length of
out-of-order sequence) is out of scope for V1 (line 103, sec 1.2)

Position 2: This is more than just an optimization, as it is a special failure case
with potential high cost if not dealt with as efficiently as possible:
without knowledge that a sequence has been given-up, cumulative and useless
resending (and new sending) may overwhelm the Receiver.
We fault individual messages for various reasons, including lack of storage resource,
so why not fault such a multi-message failure?


Opinion: In case a Poll request is used by the sender, it does not cost much to give
notice of the failure (see example in Issue #2 below) in the poll response.
So even if we see this notification as no more than an "improvement" (Position #1)
we can fault the dropped messages in the response.
But when callback is possible - and requested - should the Receiver send:
(a)- nothing at all
(b)- a special PermanentProcessingFailure for the entire group (so will that look like responses we do for "singleton" groups?)


Agreed on New RM-Fault type to indicate the failure of an entire group.  It MUST be sent by Receiving RMP for any request on that aborted group.


In the poll response the final reply range will indicate that fault code, with the range of sequence numbers which were not delivered by the Receiving RMP.


Faults will continue to be sent for each message received after the group is aborted.


Name of new fault should be “GroupAborted”


Ø Action: Iwasa and Tom will provide text for the new fault code and the reference to it in the section of text Alan cites.


Ø Action: Sunil will update schema for new fault code in the message processing failures sector.


c)- a PermanentProcessingFailure for each dropped message.
I personally favor (b) as a consistent complement to my opinion in poll request
case. A MAY or a MUST? I think again its just an optimization, so a MAY is OK.


----- Issue 2:

When we talk of generating Faults, and how to get them to Sender in case neither
callback or response pattern is possible. In that case, Polling is the only way a
Sender can get faults generated on Receiver.

Well, it appears that the Poll response can actually give the fault code,
so the issue is moot(so much for me).
A response to a poll about an aborted sequence, (assuming Position 2)
 would look like:
      <SequenceReplies groupId="mid://20040202.103832@oasis-open.org/">
        <ReplyRange from="0" to="5"/>
        <ReplyRange from="6" to="15" fault="wsrm:PermanentProcessingFailure"/>

NOTE: should we have a new fault code: "InvalidGroupId" for requests
concerning groups that are non-existent (possibly because already terminated?)


6.2      Comment 7.10




1025-1030: Example in which SOAP Fault may also convey an RM Acknowledgment requires a confusing or impossible processing order. (Process RM headers, remember that an Ack needs to be sent, continue with header processing and SOAP Body validation and finally "application processing space outside the realm of the receiving RMP".)  How does the RMP know when all processing has been completed, then intercept a possible SOAP Fault in order to attach its Ack?


Action Item to Tom Rutt for proposing better text.


Re: [wsrm] response to action item to clarify soap faults and WSRMresponses


Jacques too action item to incorporate the latest proposal from Tom and Pete into a new section on request/response.





Tom Rutt clarification of soap faults and RM faults:

This is the proposed text changes, taking into account Pete Wenzel's comments:


Clarification of Soap Faults and wsrm:response


Lines 1025 – 1030



“Example case 1:


For the WSDL Request/Response operation type, an operation request which was successfully delivered by the receiving RMP to the receiving application may result in an application-level Fault, (e.g., one specified in the WSDL description for the operation), to be returned.


In such a case, when the response reply pattern is in use, the SOAP fault message associated with this application-level Fault MUST carry the Acknowledgment indication in a wsrm:Response element within its Soap header.


This is required so that the Sending RMP gains knowledge of the successful Delivery of the Reliable message request, even though the operation encountered an application-level fault condition associated with the processing of the WSDL request/response operation.



line 1031 - 1047:




*Example case 2:*


A message with an RM Fault indication MUST NOT be delivered to the receiver by the receiving RMP. In this case, when the Response RM-Reply pattern is in use, a WSDL operation response will not be available for the receiving RMP to return with the RM-Reply including the RM-fault indication. In such a case, the Receiving RMP MUST cause an wsrm:Response to be sent in the header of a soap:fault message.


This same condition arises when the message in the request is a duplicate of a prior delivered message with Duplicate Elimination in use. The Receiving RMP, in such a case, when the Response reply pattern is in use, has no meaningful WSDL response to return for that WSDL request/response operation, so it MUST cause a soap:fault to be returned. The difference in behaviour with this duplicate elimination condition, is that an RM-Fault indication is not sent for that request in the soap:fault message, but an acknowledgement indication is sent.


In cases where a receiving RMP MUST NOT deliver a WSDL request/response operation request to the receiver, that receiving RMP MUST initiate the return of a SOAP Fault message, associated with that request, as follows:


   * If the RM-Fault indication was due to a problem with the request

     header element, a SOAP client fault MUST be returned.

   * If the RM Fault encountered was due to a problem with processing

     by the receiving RMP (including the inability to return a response

     due to Duplicate Elimination), a soap:server fault must be returned.



Tom: Need to clarify that we do not provide reliability on the response of wsdl request response operation, thus if duplicate is send due to sender not receiving first response, the receiving rmp will not have the prior response buffered to send in this condition.


Bob: we need to get rid of redundant sentences because people may think there is a difference.


There are special considerations for WSDL request response operations.


Jacques: the concept of wsdl request/response should occur in a specific section early in the document explaing how wsdl request/response operations would be designed to work with ws reliability.  Need an explicit section of wsdl request response operations, and this fault text could go there.


Ø Jacques took an action item to propose this new subsection on special considerations for wsdl request/response operations.



6.3      Comment 7.11




1990: Remove appendix if there is nothing to say here; the sole item listed is already done (App A)

agreed not yet applied

Agreed to delete appendix D futures list


6.4      Comment 7.12




The specification contains no reference to the schemas. 

agreed not yet applied

The two schemas should be listed in the normative appendix, and introduced at an appropriate location in the text, perhaps at the beginning of Section 4


Agreed to have a new normative appendix which points at the schema URL.  It also has to have the precedence statement copied from the schema.


At publication time the OASIS staff can decide to place the actual schema text.




6.5      Comment 9.1





agreed, not yet applied

Retry Parameters

reworded section on agreements

Jacques presented his proposal.


for now update second level in poace, to move to new level 1 section after Jacques reorganization action item.


Comment 9.1 – new proposal for rm-agreement first level section.

Jacques presented his new proposal.


Agreed to remove (s1) from section 2.4 of proposal.


There was discussion on the description of the expiryTime agreement parameter.


Bob: the precision of the expiry time should not be finer than the expected skew of the clocks between sender and receiver.  Perhaps using a timestamp, plus a time to live interval, would help this.


Jacques: on the wire it is date/time currently.


Bob: if the purpose is to have a course control we could get away with a course interval.


Bob: we always have a clock, but it may be grossly skewed from other system’s values.  We are creating a new cause of protocol failure if we rely on clock synchronization.


Bob: what degree of clock skew can our protocol tolerate.


Tom: we need a solution for the case of the receiving RMP having the wrong year (say 2003 instead of 2003) set by the sys admin after a disk restoration.


Bob if you have two values you give the receiver more information.  If the sender sends time time plus time to live interval  the receiver can calculate the average skew.


Leave open


Alan: two values are required to cover the case of a resend.


Defer discussion of time skew issue until Thursday morning.


Jacques continued reviewing his proposal for new section 2.


Change line 114 “smallest scope allowed” to “smallest applicable scope allowed”


Tom: currently the constraints are in the protocol section.


Jacques moved, Bob seconded to incorporate his proposal with the changes noted above.




6.6      Comment 3.14



Line 408-406:  If a reply pattern is sent that had not been previously agreed upon, it will be rejected, with a Fault message: Non Supported Feature returned to the sender

Alan suggested: MUST BE

agreed in princ but text still


Doug B: we tend to not use word reject, for this is to the sender end.  This needs to use the deliver operation terminology.


Agreed in principle.  Leave wordsmithing for action item.


Jacques: the text regarding MUST send for faults should be stated in a general manner to accommodate polling or delayed callback.  A single section to explain what “sending a fault” means. 


“Sending an RMfault must be interpreted differently depending on the reply pattern in use.”




Ø Jacques took action item to add appropriate text to also clarify that an RM-Fault must be returned if the message  cannot be delivered because the requested reply pattern is not supported

6.7      Comment 3.16




Section 3.3. Guaranteed Message Ordering Failure Case


closed see 9.1

Line 563-565:  Is the decision to abort ordered delivery totally implementation dependent?  Can we specify a Maximum Persistance time parameter for a received out of order message, so that after that time receiver aborts ordered delivery.  Otherwise, a skimpy implementation could give up almost immediately vs a robust implementation trying to recover for a much longer time after receiving multiple out of order messages without receiving any retransmitted sequential messages





6.8      Comment 3.17




Line 726: groupExpiry Time attribute:

Clarification:  No mention whether this parameter can be changed.  Suggest forward reference to line 1148- 1149. 6. Line 1148- 1149

agreed not yet applied

Suggest reference to appropriate section


Add the following to both groupexpiryTime and groupMaxIdleTime definitinons in


“Constraints on allowed values for this attribute are specified in section 5.


6.9      Comment 7.6




Section 1.5: Examples are placed in an awkward location.  Should appear after the protocol & features are described.  Suggest moving them to a non-normative appendix

agreed , text position to be determined

Agreement to move examples to a later section or annex of the document, position to be determined.


6.10Comment 7.9




569: Sequence Number is not a Feature; it is simply a mechanism used to Implement Guaranteed Message Ordering.  Should not be given equal status to the other 3 features.


Defer to the general document restructuring exercise.




Ø Jacques took an action on where to move the current section 3.4, with perhaps a re-title of section 3.  Jacques will also propose a new document structure to accommodate this and other problems he encounters

6.11Comment 8.1




Only one area needs major tree surgery: section 1.7 should be merged with appendix II and placed in its own top level section. This is the part of the doc that threw me most.

accom by 9.1

new section on reliability agreement


6.12Comment 8.2




Line 101 - 114: editorial: delete all these lines  as its castes too much doubt on the spec

agreed changes not applied

<JD> How about rewording instead like:

"Reliability is often associated with QoS quantitative measures, in areas other than Web services (e.g. networking). Thresholds such as rate of failures, minimal size of persistent store, average latency, and more generally quantitative measures that may appear in service level agreements, are out of scope for this version."

 <MC> fine </MC>


6.13Comment 8.3




Line 150 - 271: editorial: I find it strange that we launch into example messages without any form of introduction.    Maybe better to insert a paragraph to explain a scenario from whish these messages are derived. And also there really should be an fuller explainaion of a the reliability elements.

accom see 7.6 and 8.x

<JD> we have some explanation at the end of each example. We could move this up before introducing each example, instead of after. 

<mc> the text is very terse. If you look at other specs they really walk though all the relevant elements and explain what is going on </mc>

[Jacques Durand] Let us ask our editor, I think there was some intent to give an up-front flavor of the headers, that the reader could go back to as s/he progresses through the spec. (I expressed in the past my preference to see these examples at the end of doc, but can understand this rationale. Now, question remains how much walk through can we do up-front without much knowledge of the spec...)


Discuss with document reorganization, could move examples into a later section or annex.

agreed to put examples later in the document.


6.14Comment 8.4




line 358: editorial: the whole of section looks out of place. It uses a lot of terminology that has not yet been introduced. It is also strongly related to appendix II. I suggest moving the whole of 1.7 into a new top level section after section 5 (i.e. make it a new section 6) and then merge in appendix II.

accommodated by 9.1

<JD> the problem with moving the agreement definitions after Sec 5, is that we refer to them throughout the spec, starting with Sec 3, when introducing RM features. Why not have a new section between Sec 2 and Sec 3 (i.e. previous Sec 3 becomes 4, etc.) However, when doing so I would not import the entire Appendix A/II up front, as I think it is unsettling for the reader who expects to get right at the core features with as little distraction as needed... so I would provide some introduction material on the rationale for adding capability info to WSDL, and the approach recommended, and then refer to Appendix A for the hard stuff. Also if we combine the agreement and the   f&p stuff, clearly state that even if they complement each other, they don't need each other. </jd>


<mc> maybe i missed something but thr agreement stuff is sort of meaningless without a way to express it. Granted there may be many ways to do this, with f&p being one of them. If this is what you mean then fine. </mc>


<jd> We thought this over, and  concluded that agreements can remain abstract and still be meaningful here: in fact, it is the only proper way to connect to "outside" agreements while keeping their representation open. We describe our RM features like: "if <agreement-item-XYZ> is enabled (or has value ABC), then the message protocol must look like this, the behavior must be like that." Just describing the protocol on teh wire was ignoring the agreement aspect. Also, some features like resending messages (and related parameters, like # of retries, etc) would not even appear in the message protocol. We needed to be able to talk about the behavior they cause even if they don't have a concrete representation. </jd>


<mc>Generally though, the agreement stuff is very detailed, and the detail is launched into without any overview of rationale. This is my main concern so even putting that in its own section may not help. </mc>



6.15Comment 8.5




line 444: editorial: I suggest adding a paragraph or two here that does provide a very high overview of the model. The subsequenst sub section dive into details without giving the reader an overview on which to elaborate. I suggest using the text in the pre-Tc version that was published:


"In the Reliable Messaging Model described in this document, the sender node sends a message to the receiver node directly (i.e., intermediaries are assumed to be transparent in this specification). The receiver node sends back an Acknowledgment  message to the sender node. Figure 1 shows this model. Figure 1 Messaging Model"


This should provide enough context

agreed not yet applied

<JD> Isn't that very similar to the first bullet item of 2.1 ?

No problem with this rewording though.

But the transition to 2.2 (and Figure 1) probably calls for another sentence like:

" the basic exchange patterns described in 2.2 derive from the above messaging assumptions.

Reliability features defined in this specification will in turn rely on these patterns." 


<mc> fine </mc>

6.16Comment 9.3






Document Reorganization


Jacques took action item (previously recorded) to propose document restructuring.

7         New Comments from Sunil


·  Comments sent on behalf of Sunil
From "Bob Freund" <Bob.Freund@hitachisoftware.com> on 28 Apr 2004 17:12:50 -0000


·  Editorial changes to examples in Section 6.2
From Sunil Kunisetty <sunil.kunisetty@oracle.com> on 28 Apr 2004 03:44:54 -0000


More editorial comments:

1.  Changes to the Examples

-         XML payload uses namespace prefixes such as xlink, xsi, schemaLocation which are never used. 

Agreed editorial change

-         HTTP Headers for RM Requests mention a POST with a ‘/abc/servlet/wsrListner’. It will be good to make it more meaningful such as ‘/abc/servlet/wsrEndpoint’ or ‘/abc/servlet/wsrExampleEndpoint’.

Agreed editorial change

-         For Callbacks, response POST context URI doesn’t match the replyTo URI in the request

agreed editorial change

-         Why did we have 2 separate examples (Example 3 for Ack and Example 4 for Fault) for the same Poll Request (Example 3). It will be good if we can collapse Example 4 into Example 3 by adding the ReplyRange sub-element (for msg. 15) into Example 3’s <SequenceReplies> element.

Agreed editorial change

-         It will be good to add the attribute last=’true’ to the 3rd Message in Example 6 (SequenceNum Element). This way we will have illustrative example to show the usage of this (‘last’) attribute.

Agreed editorial change

2. Figure Updates:

Most of the figures use the word ‘Application Layer’, we need to better quantify what we mean by ‘Application Layer’ or say something like ‘Application Layer/SOAP Processor’.

Agreed that the word application and application layer need to be changed to more abstract terms (perhaps producer and consumer).

Ø Jacques took action item to propose appropriate change to using word application (perhaps producer/consumer).

3. Chapter 1/Section 1.6/Polling RM-Reply pattern/Line 352

Just add the word “poll” to better qualify it, i.e., make it “contained in the underlying protocol response to this poll request or in a separate …”

Agreed editorial change

4. Chapter 2/Section 2.3/Lines 483.

Line 483 states “This Message Identifier relies on the notion of group. A message always belongs to a group”.

The above is incorrect. A message can be independent/singleton or in a group.

We need to reword it.

Agreed to following editorial changes:

Line 413 414 488 of .993,  Delete parenthetical statements

Line 1193 – change “singleton groups,” to “groups”

5. mustUnderstand attribute used in tables 1, 9,12 must use lower case ‘m’ for mustUnderstand. It will be much better if we can qualify it as soap:mustUnderstand so as to distinguish this attribute with other RM specific attributes.

Agreed editorial changes

6. Chapter 4/Section’number’ attribute.

Reference to number attribute on lines (734,735) should start with a lower case ‘n’.


Lines 732-733 should be changed as follows:

The value of this attribute MUST be unique within the same group, and the combination of MessageId’s groupId attribute value and SequenceNum’s number attribute  MUST be globally unique to be used as a Message Identifier.

Agreed to change first para of section 4.21 to:

“Two messages with the same groupID, MUST NOT use the same sequence number value.”

7. Chapter 4/Section’last’ attribute/Lines 751-758

-         ‘False’/’True’ should be ‘false’ & ‘true’

-         We also need to mention that

Agreed to:  Remove “(Default value)” and add new sentence:  “When this attribute is not present, its value defaults to false.

We also need to mention that the first message in the group can also have this attribute with a value ‘true’, i.e., to indicate the first message in the group is also the last message, something similar to a singleton message.

Jacques: this is useful guidance; however has no normative impact on an implementation.  Perhaps a separate implementer’s guide could hold such statements, along with rationale for the decisions we made.

Bob: sometimes our guidance to the implementer breaks up the flow of the normative text.  We can go for a more concise readable document with normative specification.

Jacques: very few OASIS voters are developers.  Such reviewers may not appreciate implementation guidance.

Jacques it does not hurt to have a guideline document.  As I do my action item for the document reorg, I will put any such removed guidance text into a preliminary cut at the implementers guide.  And will place Sunil’s sentence above with that text.

8.      Section 4.4/Response Element.

Comments on replyPattern

1)      replyPattern on line 908 must start with a lower case ‘r’

Agreed editorial change.

2)      Did we decide that this is optional? I remember being it  mandatory to avoid potential errors. Schema says it mandatory.


Agreed to align text with schema delete “which defaults to the value “Response”


Mention the cardinality of attribute clearly when describing the attribute itself. We do mention sometimes at the element (that has this attribute) level. Examples:

1)      Mention that replyPattern attribute (line 937) is a MUST (see above comments).

2)      Mention that groupId attribute of NonSequenceReply (line 961) is a MUST.

3)      Mention that groupId attribute of SequenceReplies (line 972) is a MUST.

4)      Mention that the fault attribute of ReplyRange element is optional (Line 992)

1, 2, 3, and 4 above agreed as editorial changes

9.      Section 4.4.1 (NonSequenceReply)

While the ‘fault’ attribute is listed in Table 13, it is not described below. We need to describe this something similar to ‘fault’ (lines 992-995) attribute for ReplyRange. We need to mention that this is optional too.

Agreed editorial change add:

(2) fault attribute

This attribute is used to indicate a Reliable Messaging Fault code which was encountered while

processing the message. The Receiver RMP MUST NOT include this attribute for an acknowledgment indication.


10.  Section 4.5/Fault Codes/Lines 1008-1012.

I think this paragraph needs to be reworded. A suggested one would be:

Agreed to delete following text

The WS-Reliability protocol does not directly map our Reliable Messaging Faults to the

SOAP Fault model.


The SOAP Fault model is used for reporting faults due to the request payload, which fits the

SOAP fault model better. Thus a response may have a SOAP Fault message, but the reason for

the SOAP fault would be due to problems associated with the WSDL operation message payload.

(E.g., A problem with the soap:body of a request message or the inability of the Receiver RMP to

return the WSDL response in the soap:body of when using the Response RM-Reply pattern).


and add appropriate FAQ question with the following answer:

The SOAP Fault model was not used for RM Faults because:

-         SOAP Fault model doesn’t support batching of Faults which this protocol requires.

This text should also go into the new implementer’s guide document, along with other rationale text for the decisions we made.

Alan: I am concerned that such changes might delay the time to final specification.

Tom: we probably will have enough technical changes to justify another review round anyway.

11.  Section 4.5.1/Line 1037 should be: “Invalid Message Format Faults”. (plural Faults).

Agreed editorial change.

12. Will the final version have Appendix C(Revision History)? If not, could we remove it from the specification move it to a different document.

Agreed to remove appendix C and instead maintain a new parallel document on the server with this information.


8         Tony Graham editorial comments:


·  Editorial comments on 0.993
From Tony Graham <Tony.Graham@Sun.COM> on 28 Apr 2004 03:08:17 -0000


Section 1.1, Purpose of WS-Reliability



Line 74


Change "The purpose of WS-Reliability is to address reliable messaging

requirements, which become critical" to "WS-Reliability addresses

reliable messaging requirements, which are critical".



Line 77


Change "This specification is intended as an initial proposal for

defining reliability" to "This proposal defines reliability".



Section 1.2, Scope and Definition of Reliable Messaging



Line 81


Change to "This specification focuses on the SOAP layer and

envelope. It defines reliable messaging as the mechanism supporting

any of the following requirements:".



Line 88


Change to "Within this scope, this specification supports:".



Line 92


Change to "Some features are out of scope of this specification, yet

this design is compatible with their implementation.  They are:".



Section 1.3, Notational Conventions



Lines 121-127


The formatting on this list doesn't make it very clear.  Should it be

redone as a table?



Line 122


Change "e.g." to "E.g.,".



Line 128


Add the namespaces from the similar table in Appendix A and remove the

table in Appendix A.



Section 1.5, Examples of Messages Compliant with WS-Reliablity



Remove the "xmlns:xlink", "xmlns:xsi", and "xsi:schemaLocation"

namespace declarations and attributes from the examples since they are



Remove the XML Declarations since they are unnecessary.



Line 178


Change "wsr-example.org" to "wsr.example.org" or "example.org/wsr" to

properly use the "example.org" example domain name.



Lines 182-183


Change "No Duplicate Delivery" to "Duplicate Elimination" and change

"Ordered Delivery" to "Guaranteed Message Ordering" to match the terms

used in line 90.



Lines 239-242


The explanation should also explain the NonSequenceReply element.



Lines 229, 260, 262


Use 'straight' quotes instead of 'smart' quotes around attribute




Section 1.6, Terminology



Line 283


Change "e.g," to "e.g.,".



Line 288, 304


Why must the time be identifiable?  Why is it not sufficient to

just preserve the order of submissions, e.g., in a queue?



Line 292


Move to the next page (i.e., keep it with the following paragraph).



Line 294


Change "Reliablity feature" to "reliability features".



Line 297


Remove "A Message Identifier is".  Remove the comma after "header".



Line 302


Remove "Message delivery is".  Change "deliver" to "Deliver".



Line 304


Change "(application)" to "(e.g., the application)".



Line 316, 317, 319


"Acknowledgment messages" are not defined.  There are now only

"Acknowledgment indications".



Line 329


How can a "Reliable Messaging Fault Indication" signal a failure to

receive a message when this specification "expects that the transport

layer will not deliver a corrupted message" (line 1308) and there are

no fault codes for non-delivery of messages?



Line 336


A reply may now include multiple Acknowledgment Indications.



Line 340


Remove one of the spaces in "in  a".



Line 353


Make the sentence begining "This polling pattern is generally

expected..." into a note following the definition since this sentence

is more a comment than a definition.



Line 355


Change "behind the firewall cases" to "e.g., when behind a firewall".



Lines 297 to 356


Reorder the definitions to reduce the forward references:


Message Identifier

Duplicate Message

Message Delivery

Reliable Message

Acknowledgment Indication

Acknowledgment Message (new definition)

Reliable Messaging Fault Indication

Reliable Messaging Reply

Response RM-Reply Pattern

Callback RM-Reply Pattern

Polling RM-Reply Pattern

PollRequest Message



Section 1.7, The Reliability agreement



Line 357


Change "agreement" to "Agreement" to match the capitalization style of

similar headings.



Line 362


Change "notify operations on" to "and notify operations at".



Line 366


"between the application layer, the sender and receiver RMPs" does not




Section 1.7.2, RM Agreement Items



Line 388, 390, 392


Change "period" to "period.".



Lines 388-406


Should this list be a table with "Name", "Value", and "Definition"




Section 1.7.3, Messaging Scope of Agreement Items



Line 415


Change "is affecting" to "affects".



Section 2, Messaging Model



Line 450


Change "message" to "messages" twice.



Line 458


Change to "The three ways to send back an Acknowledgment message or a

Fault message are as follows:".



Line 461, 467, 474


Remove "With this message reply pattern,".



Line 463


Change "The figure 1" to "Figure 1".



Line 468


Change ")," to ")".



Line 469


Change "The figure 2" to "Figure 2".



Line 488, 491


Change "In case" to "When".



Section 3, Reliability Features



Line 499


"Business payload" is undefined.



Section 5, Operation Aspects and Semantics



Line 1263


Number the table and make this the title for the table.



Line 1271


Why are "Supported" and "Disallowed" so large?



Appendix A



Line 1604


Change the section numbers to "A.1.", etc.



Line 1605


Add a space after ")".



Line 1606


Change "supported/required" to "supported or required".



Line 1628


Merge this section into Section 1.3.






Tony Graham


Ø Action: Iwasa to apply all editorial changes from Tony’s mail, except for those he considers in need of discussion.


9         Liaison activities with EbMS  - joint meeting


Met jointly.


Alan: can EBMS be used with WS-Reliability.


Ian: today the answer is no.


Ian: the main issue for discussion is how eb-ms can use ws-reliability in a future version of eb-ms.


Tom: we are trying to facilitate a-future version of eb-ms being able to use ws-reliability.


Jeff T: we would need to have a ws-reliability header in a message but used in a non-reliable manner.


Jeff T: they have a need for messageID but not for reliability purposes.  We need a reference to a message ID. 


Doug B: There is a need to use message correlation features in eb-ms without need for guaranteed delivery or duplicate elimination.


Iwasa: The current spec has all three qos values optional.  Guaranteed delivery, duplicate elim, and ordered delivery are all optional.  If neither are present in an rm-request without syntax errors, there will be no rm-reply under the current ws-reliability protocol.  However, a header being broken would cause an rm-headerFault returned.


Doug: ref to message id in ws-reliability supports single or multiple references to messages.


Doug: this is ok.


Ian: another discussion is how to reorganize grouping of the header blocks to work out what is what. 


Doug: the ws-reliability TC has also discussed putting our header blocks in a common wrapper header element.


Ian: my point of view is that we could define a common style for having grouping elements to identify which specs are in use.  Wss has a security container.


Sunil: having wrappers might affect composition.


Jeff T: having a wrapper can ease implementation.  One handler can be dispatched for all ws-reliability features.


Doug B: the reason to ask the question here is to, if we agree, we can send a message to the tab for a common style.


Matt M: putting things with a common default namespace in the same header type can ease implementation as well.


Jacques: Hamid, in our TC, wanted a way for the rmp to make decisions without looking into the soap body.  He wanted to have an attribute to put in the reliability header to distinguish whether an rm-request is piggybacked with a rm-reply.


Sunil: this is purely style concern, however I like it, because it puts a context around the headers named simply request and response.


Ian: this allows implantations which are not properly namespace aware.  It allows for evaluation of an xpath by a processor which is not fully namespace aware.


Jeff: it helps the readability of the schema.


Ian: if wsrm TC decides to add a common header wrapper (as WSS and each ws-caf spec drafts) then Tom and I as chairs should send a note to the TAB to recommend a common specification practice for OASIS specs.


Take it as a public comment from eb-ms group on suggesting a common security header.


In the future, when there are TC meetings collocated, we should ensure that the only overlap time for eb-ms and wsrm TC is joint meeting time.


10   Sunil new issues


Sunil: for a group we say qos should be the same for all messages in the group.  If so, why do we have to send the qos parameters every time.  Why not send them only on the first message for the group.


Jacques: the first time the receiver receives a message from the group takes those qos values and use them for the lifetime of the group.


Tom: could send them until the first ack is seen by the sending RMP.


Will discuss on Thursday.


Sunil: if the receiver demands a qos level, but the sender does not assert it, how does the receiver react.


Tom: we discussed this in the past that the receiver can send a soap client fault in this case. 


Jacques: but this will not work for wsdl one-way operation type.


Tom: we decided this condition is out of scope of this spec.


Jacques: receiver side only enforces reliability requirements visible in the protocol.  The concern Sunil is expressing is out of the scope of this specification.


Tom will send a pointer for the original issue resolution in this area.


11   Planning for Future CD Balloting


Most aggressive timing: assuming 3 implementations by May 10


May 29 : Final Editors draft posted


May 3 – member editorial review comments due


May 4 – TC votes for editorial changes, and to initiate final CD 1.0 ballot


May 5 – CD ballot begins


May 12 – CD ballot closes


May 14 – Submit package to OASIS for OASIS Standard Processing


Alternative: to agree on all changes by May 4 TC meeting


Editors post final review draft by Friday May 7.


May 11 meeting we vote on a CD 1.0 completely ready to go.


May 14 – submit to OASIS.


Ø Action: Tom should put out a call for IPR claims.


Look at this further on Thursday.


12   Review of Homework assignment status


Iwasa produced draft .994:

Document Description:

April 28,2004(WD0.994)

This was updated for:



1.4, 2.2, 2.6, 3.17, 5.1, 6.1, 7.2, 7.3, 7.4, 7.5, 7.8, 7.11, 7.13, 8.2, 8.5,

and editorial updates for examples as described in a minutes on 4/28/2004.


And here are some comments:


 *This was already resolved at 0.993:


7.12 Schema in appendix

 *The latest schemas Needed.

Action: Iwasa needs to make a new appendix, with the disclaimer for schema precedence (as in the schema text) and a URL pointing at the current schema on the WSRM server.



 526: "nor to notify failure on the sender side" should be "nor to notify  the RMP Sender of the failure".

 *Replaced "RMP Sender" with "Sending RMP"



 527: "it's" should be "its".  Schemas: "it's" (in comment blocks) should be "its"

 *Schemas was not taken care of. Other items in 7.13 was implemented.

Sunil has action item to apply comment 7.13 resolution to schema.


Ø Action on Jacques: incorporate his new Agreement section while doing the document restructure.


13   Draft resolution of CF public review comments

We need to prepare a paper which rebuts the concerns of Chris Ferris, expressed in his presentation to the OASIS Symposium, and provides a counter argument as to the perceived problems with the WS-ReliableMessaging spec from Microsoft, IBM and partners.


The following was provided by Tom Rutt as a starting point for resolving the CF public review comments:


Cf1:  Two schemas and namespaces are unnecessary for two soap versions.



Proposed change:

remove the soap 1.2 schema, and change the following lines on the soap 1.1 schema:

soap 1.1 schema has:

<xsd:schema targetNamespace="http://www.oasis-open.org/committees/wsrm/schema/1.1/SOAP1.1" xmlns:wsrm="http://www.oasis-open.org/committees/wsrm/schema/1.1/SOAP1.1" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap11="http://schemas.xmlsoap.org/soap/envelope/" elementFormDefault="qualified" attributeFormDefault="unqualified" version="0.62">
   <xsd:import namespace="http://schemas.xmlsoap.org/soap/envelope/" schemaLocation="http://schemas.xmlsoap.org/soap/envelope"/>
   <!-- 4WSRM Headers -->
   <xsd:element name="Request" type="wsrm:RequestType"/>
   <xsd:element name="Response" type="wsrm:ResponseType"/>
   <xsd:element name="PollRequest" type="wsrm:PollRequestType"/>
<!-- Describe the BaseTypes -->
   <xsd:complexType name="HeaderBaseType">
           <xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
       <xsd:attribute ref="soap11:mustUnderstand" use="required" fixed="1"/>
       <xsd:anyAttribute namespace="##other" processContents="lax"/>

to the folloing:

<xsd:schema targetNamespace="http://www.oasis-open.org/committees/wsrm/schema/1.1/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"

   <!-- 4WSRM Headers -->

   <xsd:element name="Request" type="wsrm:RequestType"/>
   <xsd:element name="Response" type="wsrm:ResponseType"/>
   <xsd:element name="PollRequest" type="wsrm:PollRequestType"/>
   <!-- Describe the BaseTypes -->
   <xsd:complexType name="HeaderBaseType">
        <!--mustUnderstand attribute for soap version used must be present with value = 1 -->
           <xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
        <!--mustUnderstand attribute for soap version used must be present with value = 1 -->
       <xsd:anyAttribute namespace="##other" processContents="lax"/>

And add the following text to the spec, in the new annex pointing at the schema:

When used with soap 1.1, the soap1.1 mustUnderstand attribute MUST be present with value equal to 1 in all RM header blocks.

When used with Soap 1.2, the soap1.2 mustUnderstand attribute MUST be present with value equal to 1 in all RM header blocks.


Cf2:  Why are soap faults not used for RM-Fault?


The SOAP Fault model was not used to report RM Faults is because:

  - SOAP Fault model doesn’t support batching of Faults which this protocol requires.

  - While it is not illegal to send a Soap Fault in an HTTP Request,  it is unusual to send a Fault in a request message.


Proposed change: none required


Cf3: Not Acking until delivery to the application causes unnecessary delays?


The definition of delivery in the specification is abstract, and allows implementation architectures using queues and other mechanisms not actually requiring the ultimate receiving application to participate in the acknowledgment procedure.  Delivery can occur as soon as the Receiving RMP can ensure that the delivery contract associated with the request is satisfied (e.g., all prior messages in an ordered sequence have been received).  In most cases delivery occurs immediately after receipt of the message.


The initial contribution to the TC work had a protocol which returned an ack to the sender as soon as the message was received (assuming it is not expired).  However, this behaviour admitted failure use cases where the sender would think the message was delivered, while a failure condition after this ack, admitted cases where the message could not be delivered (e.g., the receiving RMP has a processing failure while a received messages is being held waiting for a prior message in an ordered sequence).


Also, the state machine was simplified significantly by sending the ack only when the receiving RMP delivers the message (e.g, makes it available to the next processing element in a chain by putting it in a queue).


Proposed change: none required


Cf4: Unclear if the spec can compose with WS-Addressing or WS-MD?


An important consideration in design of the WS-Reliability protocol was to have it be composable with 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).   The syntax for this element is URI, since that way of referencing a soap endpoint is independent of any specific adressing or message delivery specification.


We want ws-reliability to compose with many other mechanisms.


The WS-Reliable messaging protocol, since it relies on ws addressing From address as the callback destination, does not support a callback to a different endpoint than the from address.


Proposed change: clarification text under discussion in TC


Sunil suggested we might want to modify the schema to allow for extensibility in the syntax for the Reply to attribute. 


Tom stated we do not want to tie the syntax down to either WS-addressing or the new WS-Message Delivery format for endpoint references.


Cf5: Persistence model will not work on devices with volatile storage?


WS Reliability does not explicitly prescribe persistence requirements.


The persistence requirements (e.g., holding a received message in a buffer until all priors have been delivered in an ordered sequence; holding a list of integer ranges of sequence numbers which have been delivered, or faulted) are identical for WS-Reliability protocol and WS-ReliableMessaging protocol.


A device with volatile storage (e.g, memory goes away when power goes away) can meet the requirements of the protocol as long as its storage remains in tact.  Because messages are only acked when delivered, in cases where failure of the non-volatile storage results in a message not being delivered, the sending RMP will not receive an ack.  The sending RMP can notify the producer of the message that the message is not assured to have been delivered.


Proposed change: TC is checking if there is any mention of persistence remaining, which will be removed.


Cf6:  Mandatory Expiry time requires synchronization of clocks:


The precision of the expiry time selected by the sending application needs to be selected to allow for normal skews in system clock.


Although there may be some merit in designing a more robust mechanism to deal with excessive clock skews, the expiry time mechanisms used is consistent with other specifications, such as ebxml Messaging, ws lifecycle management.


Propose change: under discussion by the WSRM TC.


Cf7:  There is unnecessary complexity in the spec, headers have unnecessary elements making them larger than necessary?


The TC charter required the WSRM TC to produce a requirements document to determine features, required by members of the TC, to be met by the protocol.


These requirements led, amongst other features, to the need for three RM reply patterns to cover the use cases identified in the requirements.


The WS-Reliable messaging specification, from Microsoft IBM and partners, does not support all the use cases identified in the WS-Reliability requirements (e.g., it does not support polling for RM replies), thus its protocol may seem to be less complex. 


However, conformance claims can be made by an implementation to any valid subset of WS-Reliability features. A receiving RMP can return a notSupportedFeature rm-fault code in response to a request for features it cannot satisfy.  Thus a WS-Reliability implementation needs only be as complex as required by the use cases it is designed to support.


The cost of adding necessary indicators of features requested in request header elements is minimal in terms of header size and processing complexity.


Proposed change: None required.


Cf8    Spec does not state a Reciever MUST acknowledge all delivered messages with each acknowledgment indication.


WS-reliability requires an ack to be sent for all delivered messages. It states “If a receiving RMP receives a message with AckRequested element, the receiver MUST send an Acknowledgment message even when the message is a duplicate, and if it has already been previously delivered.”


Sending the complete ack history for a sequence along with every ack indication was deemed unnecessary for the WS-Reliability protocol.


Ws-Reliability has a polling mechanism to allow the Sending RMP to request the acknowledgment status for all the messages sent within a Group.  .


Proposed change:

TC is currently working on clarification wording which covers the polling case, where the ack is made available for a poll response (but not sent until the poll is received).



Cf9   There is unnecessary implementation details in the spec.


The spec has several, non-normative, implementation guidance notes.


Proposed change: TC has agreed to move many of these non-normative implementation notes into an informative companion document.


1         Paper in response to Chris Ferris Presentation at OASIS Symposium


The TC agreed to prepare a paper to address the concerns express by Chris Ferris at the presentation, and to provide a balanced comparison, from our point of view, with the Microsoft IBM and partners WS-Reliable messaging specification.


Points to be included in our comparison:

Lack of polling support


Why is “to” field needed for reliability.


If both From and Reply to are present in the ws-addressing header, it is not clear where to send either the ack or the fault.


They do not send any policy directives on the wire.  Since there is no policy property defined for indicating duplicate elimination or other qos contracts, there is no specification on how this is accomplished.


The spec does not address rm processing failures of any kind.


Unclear what behaviour of NACK is when a fault is already sent for a particular message in a sequence.


Poor support for groups with one message.


Batching of faults is not supported.


Sending an ack at time of receipt admits potential failure cases.  Sending the entire ack history is not sufficient. (we should give one or more use cases which show their deficiency)


Their spec is not clear with respect to a wsdl oneway operation how the destination for the ack is determined.


The schema is not fully explained in the spec, and there appear to be inconsistencies


Ø Bob F took action to lead a team to provide an initial draft of the comparison paper of WS-Reliability/WS-ReliableMessaging, for review by the TC.  Sunil and Jacques joined the team.


2         FAQ

Agreed that we should come back to addressing the FAQ after we prepare the paper.


No discussion at this meeting.


3         Discussion of RMP in Soap Terms

Def of

Reliable Messaging Processor (RMP):

A module capable of processing and enforcing Reliable Messaging as described in this

specification. With regard to the transmission of a message from one RMP to another, the former

will be act in the role of “sender” and the latter in the role of “receiver”.



Pete: Need to relate this definition to base terms which have a normative definition in the soap specification.  We also have to relate this to the diagrams.  Sometimes they are called nodes, which is a soap term.


Is an RMP an entire soap node, or soap processor, or is it just a slice of a soap node.  This impacts the interfaces the rmp must expose and use to communicate with other processing elements.


Jacques: It could be a soap node, but does not have to be.  It could be implemented as a Java handler, which extends a soap node.


Pete: we need to give it a definition which is flexible enough to allow alternative implementations.


Jacques: the definition of deliver was left abstract for this reason.  It does not necessarily mean reaching the ultimate application.  It could be another handler in a chain within a node.


We agreed to change “application” to “producer” and “consumer” throughout the document.


Fig 7 and fig 4 are not consistent.


These figures should be updated to use the terms “producer” , consumer and Sending rmp and receiving rmp.


Pete: is the consumer role only on the receiving rmp end?


We need to formally define “producer’ and “consumer”  in the spec.


Ø Action: Jacques will lead a team to ensure the terminology used in the spec is consistent with normative terms in the soap spec.  Pete W will work with Jacques to provide a proposal to resolve this.


4         Planning for Future CD Balloting


April 29: Iwasa posts all agreed edits in a new .995 editor’s draft.


May 4 morning: Jacques posts a change barred .996 editor’s draft for review by TC (including a rough draft implementers guide holding non-normative text removed from .995 draft.


May 4 evening - resolve all comments at TC meeting with editing instructions for editors.


May 6 - Final Editors draft posted resolving all comments.

May 10 – member editorial review comments due


May 11 – TC votes approval of CD 1.0 ballot and vote to submit to OASIS at call


May 14 – three letters from members on “using the spec”


May 14 – Submit package to OASIS for OASIS Standard Processing


Sunil expressed concern that there is not enough time for member review of the final editor’s draft between May 7 and May 11.


Bob: Jamie clarified that once it is submitted for OASIS review, no changes are allowed by the process (no edits at all).  We are doing restructuring and may editorial text changes.  We should have a proof reading



Tom will schedule 2 hour Tuesday phone calls for the next four weeks 5:30PM to 7:30 PM EDT.


12: noon – Meeting adjourned adjourn.


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