[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Preliminary minutes from Wed F2F
Prelim wed minutes attached. -- ---------------------------------------------------- Tom Rutt email: firstname.lastname@example.org; email@example.com Tel: +1 732 801 5744 Fax: +1 732 774 5133Title: Bob Freund provided a new bridge number to allow us to dial in at the meeting
Prelim minutes WSRM TC Face To face Meeting (Day 1) at New Orleans Marriott
There was a conference bridge available on both days from to Noon CDT both days.
1.1 Draft Agenda
1.2 Roll Call
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) Pending
Jacques took action item to propose new FAQ text for the ws-reliability
features. – open
Close by taking text from Sunil’s slides for the faq
3.2 Action 033004-6 – (Tom) Pending
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. - open
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
Action 041304-1 – (Jacques) Needs Discussion
agreed text not yet applied
Faults for Aborted Ordered Deliver
Action on Tom and Iwasa to provide text.
Out of order sequence:
We talked about two Issues that are
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:
<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?)
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.
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.
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
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.
agreed, not yet applied
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.
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.
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
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
Jacques took action item to propose clarification about faults for aborted ordered delivery.
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 22.214.171.124
“Constraints on allowd values for this attribute are specified in section 5.
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.
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.
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
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>
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.
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>
[Jacques Durand] Agree. Will propose something.
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>
Jacques took action item to propose document restructuring.
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.
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 126.96.36.199/’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 188.8.131.52/’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.
Section 1.1, Purpose of WS-Reliability
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".
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
Change to "This specification focuses on the SOAP layer and
envelope. It defines reliable messaging as the mechanism supporting
any of the following requirements:".
Change to "Within this scope, this specification supports:".
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
The formatting on this list doesn't make it very clear. Should it be
redone as a table?
Change "e.g." to "E.g.,".
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.
Change "wsr-example.org" to "wsr.example.org" or "example.org/wsr" to
properly use the "example.org" example domain name.
Change "No Duplicate Delivery" to "Duplicate Elimination" and change
"Ordered Delivery" to "Guaranteed Message Ordering" to match the terms
used in line 90.
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
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?
Move to the next page (i.e., keep it with the following paragraph).
Change "Reliablity feature" to "reliability features".
Remove "A Message Identifier is". Remove the comma after "header".
Remove "Message delivery is". Change "deliver" to "Deliver".
Change "(application)" to "(e.g., the application)".
Line 316, 317, 319
"Acknowledgment messages" are not defined. There are now only
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?
A reply may now include multiple Acknowledgment Indications.
Remove one of the spaces in "in a".
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.
Change "behind the firewall cases" to "e.g., when behind a firewall".
Lines 297 to 356
Reorder the definitions to reduce the forward references:
Acknowledgment Message (new definition)
Reliable Messaging Fault Indication
Reliable Messaging Reply
Response RM-Reply Pattern
Callback RM-Reply Pattern
Polling RM-Reply Pattern
Section 1.7, The Reliability agreement
Change "agreement" to "Agreement" to match the capitalization style of
Change "notify operations on" to "and notify operations at".
"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.".
Should this list be a table with "Name", "Value", and "Definition"
Section 1.7.3, Messaging Scope of Agreement Items
Change "is affecting" to "affects".
Section 2, Messaging Model
Change "message" to "messages" twice.
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,".
Change "The figure 1" to "Figure 1".
Change ")," to ")".
Change "The figure 2" to "Figure 2".
Line 488, 491
Change "In case" to "When".
Section 3, Reliability Features
"Business payload" is undefined.
Section 5, Operation Aspects and Semantics
Number the table and make this the title for the table.
Why are "Supported" and "Disallowed" so large?
Change the section numbers to "A.1.", etc.
Add a space after ")".
Change "supported/required" to "supported or required".
Merge this section into Section 1.3.
Action: Iwasa to apply all editorial changes from Tony’s mail, except for those he considers in need of discussion.
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.
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.
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.
Tom should put out a call for IPR claims.
Look at this tomorrow.