[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Prelim minutes of 6/8 Teleconf
the prelim minutes are attached. We will have next week's meeting on monday instead of tuesday, at the normal time and number. Please post corrections before friday. Tom Rutt -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133Title: Draft Agenda to WSRM TC Conference Call – May 06, 2003
|
Preliminary Minutes of WSRM TC
Conference Call – The meeting of the WSRM TC will take place by teleconference 1
Draft
Agenda:
Draft Agenda to WSRM TC Conference Call 1 Roll Call 2 Minutes Discussion 2.1 Appointment of Minute Taker 2.2 Approval of previous meeting minutes – 3 Action Item Status Review 4 Discussions of unresolved editorial comments 5 Discussion of Document progression 6 Scheduled Vote for CD 7 Scheduled Vote to Submit to OASIS for member vote 6 Discussion of FAQ for WS-Reliability 2
Roll
Call
Attendance:
Meeting is quorate. 3
Minutes
Discussion
3.1 Appointment of Minute TakerTom Rutt will take minutes. Minutes will serve to record issue resolutions. 3.2 Approval of previous meeting minutesThe minutes of the June 01 teleconf are posted at: http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/7101/MinutesWSRMTC060104.htm Iwasa moved to accept, Abbie seconded. No opposition, minutes approved. 4 Status of Action Items · Action Item
status as of 6/3/04 New Action: Tom took a new action item to complete the status column of pre public review issues list, with correct URLs.
4.1 Action 060104-1 (Sunil) pendingAction: Sunil will come up with a proposal for the Namespaces and Schema file locations. complete 4.2 Action 060104-2 (Pete Wenzel) pendingPete: took action to find out the latest convention for Comment process in boilerplate. Pete incorporated into his editing draft. Contrbution 1.01G 4.3 Action 060104-3 (Tom Rutt) completedTom: action to have a complete proposal for soap must understand attribute text in document. Sent to list as: · Detailed
proposal for SOAP must understand text. 4.4 Action 060104-4 (Iwasa) completedAction: Iwasa should apply the editorial changes, and the agreed changes from the 6/1 meeting motions. · Groups -
WS-Reliability-2004-06-03.pdf uploaded 4.5 Action 060104-5 (Jacques) PendingAction: Jacques, will
propose further edits, on the FAQ for composability. 5
Discussion
of Issues and editorial Comments
The following issues list includes one open item which need further discussion: · · Updated
public comments issues list posted 5.1 Namespace for Schema, and location· Re: [wsrm]
Action Item status as of 6/3/04 · Groups -
ws-reliability-1.1.xsd uploaded · Groups -
reference-1.1.xsd uploaded · Groups -
fnp-1.1.xsd uploaded · Groups -
wsrmfp-1.1.xsd uploaded I haven't heard anything from the OASIS Technical Services
Manager w.r.t. mapping URIs
to Files inspite of ·
The namespaces
have ".xsd" in
them to make them easily referencible without any
mappings. ·
Namespaces follow both
MM/YYYY convention in the URI and also the version no. of the specification as
suffix to the file name.
There was no room for the fourth column. There is a description about the schema in the schema itself. Tom: changes applied to 1.01F, all filenames have 1.1 in their name. Sunil moved to accept namespace proposal, as implemented in 1.01F, Iwasa seconded. No opposition, motion passes. After voting we need to send the schemas to the web master. For the submission we will put into a zip file. 5.2 Editorial comments on Draft 1.015.2.1 Tom Rutt Comments· Detailed
Editorial Fixes for Sections 1 - 4 of ED 1.01 Editorial
Changes: For
PN18: Fix the namespace used for the ws reliability
schema in lines (138,
494, 524, 708, 744, 821, 849, 932, 998, 1014 Line
82 Rationale:
Middleware is an example of service provider Proposal:
insert “e.g.,” after “(“ Line
104 Rationale:
“the an” Proposal:
remove “an” Line
140 Rationale:
xpath notation is used Proposal:
Add a new paragraph stating that XPaths are used in
titles and other places in Section 4. Also
add a reference to XPath 1.0 in Section 8. Line
231 Rationale:
Since the term “publish reply” , and “publish fault”
is used in many places in the document, this definition needs to be
retained, but fixed as follows Proposal: : “ Reply
Publishing: A
party is said to publish an RM-reply when the RM-reply is made available to its destination, in accordance with the
RM-Reply pattern requested by the Sending RMP. For example, if the callback reply pattern is requested, publishing the reply requires sending a callback
message including the RM-reply information. If the poll reply pattern is
requested, publishing the reply requires making the RM-Reply information available to be
returned to the sender in response to a poll request. “ Doug B concerned about this edit. Reply Publishing: Reply
Publishing: A
party is said to publish an RM-reply when the RM-reply is made available to its destination, in accordance with the
RM-Reply pattern requested by the Sending RMP. For example, if the callback reply pattern is requested, publishing the reply requires sending a callback
message including the RM-reply information. If the poll reply
pattern is requested, publishing the reply requires making the RM-Reply
information available to be returned to the sender in response to a poll
request. Doug: if we changed this to an abstract operation I would be much more comfortable. We have Notify on sender side with submit, but there is no Publish operation on the Receiving side. My suggestion would be to use wording similar to operation definition. Jacques: I am all for finding a better expression. The Rationale for concept of publishing reply is that every time we had to mention that the receiver had to generate an ack or a fault, we used the term “sending back fault” This only made sense with response and callback reply patterns. For polling the receiver had to wait for the callback request. Doug: I would like it to be an abstract operation on the RMP. It is easy to read it as being ambiguous. (making available or sending it back). We need to be concrete. I cannot connect reply publishing with our use of word reply throughout the spec. Publish An abstract operation making an rm-reply available to its destination. For the various rm-reply patterns this entails: · response reply : publishing the reply requires sending the rm-reply on the response of the underlying transport protocol. · callback reply pattern: publishing the reply requires sending a callback message including the RM-reply information. · poll reply pattern: publishing the reply requires making the RM-Reply information available to be returned to the sender in response to a poll request No opposition to this edit. Will include in next editing draft Line
319 – GroupExpiryTime table entry Rationale:
non null positive value does not go with date/time Proposal:
delete “A non-nul positive value” Line
543 – groupId table entry Rationale:
the detail reference to 3.1.1 is wrong. It is not needed Proposal:
delete “*See 3.1.1 for details” Line
546 Rationale:
typo Proposal:
change “iidentifies” to “identifies” Line
557 Rationale:
grammar , semantics (plural) apply Proposal:
change “applies” to “apply” Lines
678, 763, 882, 903 Rationale:
page break causes first line of table to repeat in continuation Proposal:
remove designation of first line as table header Note:
this is not done in editing draft 1.01E Line
729 Rationale:
typo Proposal:
change “as” to “has” Line
777 Rationale:
there is no range in this case Proposal:
change “message range” to “group” Line
778-781 Rationale:
grammar and consistency with preceding paragraph Proposal:
change paragraph to: “When
the RefToMessageIds element has a groupId
attribute and SequenceNumRange element(s), the Receiving RMP MUST return
RM-Repies for the non-expired messages specified by the combination of groupId of RefToMessageIds and SequenceNumRange
element(s), that were either delivered or faulted.” Lines
882 and 895 – Value table entry Rationale:
RFC2396 is not the value of the element Proposal:
Replace “RFC2396” with “None” Line
961 thru 965 Rationale:
The last edit erroneously made a change which limited the cases of applicability of the soap fault to just header
problems Proposal: Delete
“of” in line 961 Insert
after line 962 “or other ws-reliability protocol
related causes (such
as elimination of duplicate delivery), ” Delete “that contains the RM fault“ Doug Concern on this edit: Doug does not remember extensive use of ws-reliability protocol wording in existing text. Edit in question is as follows “ In case of a Response RM-Reply Pattern was required, and when the message cannot be delivered to the Consumer due to a failure in processing the
RM headers, or other ws-reliability protocol related causes (such as elimination
of duplicate delivery), then a SOAP Fault MUST
be generated in addition to the RM-Reply that contains the RM Fault. Because either a
well-formed response or a SOAP Fault is expected on the sending side, then the response leg of the transaction
MUST contain a SOAP
Fault in the SOAP Body when no business response is available. More details are given in the HTTP Binding section. “ Jacques: this is the case where we need a soap fault and an RM fault indication. We cannot say RM-reply contains the soap fault. Doug: I would just In case a response rm reply pattern is required, and the message cannot be delivered to the Consumer, then a soap fault must be delivered in addition to the rm-reply. Doug: apparently our rmp does not know what the WSDL is. It is not an error to get a duplicate invocation. Doug: I would put nothing in the soap body in this situation. It does not know what the WSDL MEP is, there is no difference in stuffing in a queue, or sending it along directly to the app. Our protocol is designed only to support one way messages. No matter what happens when a message is sent the sender has to get the same message back. Deliver means make available to application. We cannot support request response MEPs from an applicaton perspective. Receving rmp to consumer interface does not allow the consumer to tell the receiving rmp anything. Suggest to leave it empty, let the receiver deal with it. End to end throughout this spec, an incoming message either does or does not get delivered to consumer. Jacques: as long as soap body is well formed, this might be enough. The reason to send soap fault, was to deal with some implementations of request response pattern. Proposal: In case a response rm reply pattern is required, and the message cannot be delivered to the Consumer, then the rm-reply MUST be sent in the soap header, with an empty soap body. Jacques: would soap stacks behave well when getting an empty soap body. We could get rid of soap faults altogether. Doug: I think we are having a number of overlapping conversations. We agree that the existing spec does not support request response mep. The body is always going to be empty when using ws-reliability. Doug: there is no response from the deliver operation, it is an anonymous queue. This is my concern. There is no way for the consumer to deliver a response to the RMP. Jacques: there are two ways the rmp can generate a response, either the rmp generates its own response with empty soap body when it cannot deliver the message. The RMP is able to wait for a response from application side, but this is outside the scope of our RMP specification and contract. Nothing stops an RMP from getting the Response. Doug: This is a different abstract model, the RMP in our model is between the producer and consumer. What I am worried about is that when using the resonse rm-reply pattern, one rmp sends a message to another, the receiver goes off thru a back channel gets payload and includes in response, the original rmp can blow up. We have an interoperability problem. If we say that the response rm-reply pattern is composible only with one way MEPs that would cover things. Doug: there is no way that people implementing duplicate elimination will look here. WSDL 1.1, http response to wsdl one way has no soap body. Doug we do not support request response mep, for we have no way to get information back. Sunil for the second part it is not an issue. For Oneway wsdl response pattern is not supported. Tom: this leads to a limitation of response rm-reply pattern to a wsdl request response operation type with no response message defined in the wsdl. Jacques: all that is asked of receiver rmp is to be able to add its own header in the response from the application. This is the only thing that is required to support the response reply pattern. We need to state this more clearly, that it has to be able to correlate a response with a request. Doug: then we would need a new deliver response operation, which would be a new one from that in our spec. We are missing a response submit operation in our model. Jacques: let me rephrase: with request response, not tied to transport request response. Maybe we have a problem with having to deal with BP 1.0 compliance. Formally it would take a submit response to model the deliver of the response to the receiving rmp from the consumer. Is is not a big stretch to require that the RMP must be able to correlate a request with a response, since current implementations allow that. We might not have to change the abstract model, if we add this requirement. Only require the rmp to correlate a response with an underlying request message. Jacques; Can do this as a Soap Node. Doug: people implementing duplicate elimination will not be looking at section 4.5. Jacques updated suggestion could work, however I would like to see what it means not to make any use of soap faults. Doug: Section: 4.5 could be fixed by stating that an empty body would be returned when the request is not delivered. There are other things we have touched on:
Tom: could use empty body instead of Soap fault.. Jacques: I talked with Hamid: if request response if you only send back empty soap body, there could be mishandling on the sender side. It is expecting conformance to signature or soap Fault. Doug: for question of cannot deliver in response reply operation. Hamid: The behaviour of an empty body depends on implementation of soap stack. Other stacks might get a higher level failure. Sunil I prefer a fault to an empty soap body. It could be dangerous. Hamid: for one way it is ok to send empty soap body, for request response he needs to send a soap fault. Tom: the receiving RMP knows the reply pattern. Tom: Doug has raised a new technical Issue. Sunil: I had sent some earlier options on this. Tom: this will take more than 15 minutes to resolve. Jacques: there might not be a lot of text changes, in the end. The handling of Soap Faults is related to our concern of implementation handling our Spec. Jacques we need to get back to our development expert. July 15th. Jeff M: it would be nice to resolve this quickly. Small Team to sheperd some text Doug Concern: Meeting
next Monday Doug: I will send out a proposal for the text in section 4.5. I do not understand Jacques comments enough to have any way to phrase his proposal of correlation into words. Doug: The dup elimination and faulting problem I am not sure how we are leaning. Hamid: have each company try a request response scenario, and have RMP send empty soap. Jacques: this decision is linked to implementation aspects., if we can get away with it we may not use soap faults at all. Doug: Action: Doug will propose text for in 4.5 to clarify that when you cannot deliver due to rm fault, then send back a soap fault, There is a separate issue for how to sneak around our abstract model to handle response correlation. . Third discussion is how to relate this to behaviour for duplicate elimination. Jacques took an action to describe the response reply pattern to work with our abstract model to sneak around to allow response correlation, and how it can be used for duplicate elimination. He will initiate discussion today. Jacques; an extreme solution would be to eliminate the response reply pattern. · Editorial
changes for Sections 5 onward to Draft 1.01 Editorial Changes: For PN18: Fix the namespace used for the ws reliability schema in lines (138, 494, 524, 708, 744, 821, 849, 932, 998,
1014, 1293, 1324, 1366, 1405, 1452, 1473, 1514, 1535 Line 1113 Rationale: plurality Proposal: change “time” to “times” Line 1256 Rationale: typo Proposal: insert space after Section Line 1270 Rationale: the third sentence is redundant. Proposal: Delete third sentence of para. Lines 1273, 1339, 1421 Rationale: other causes can require this behavour Proposal: change “due to a failure in
processing the RM headers” to “due to a ws-reliability protocol related cause” Doug B: I want to keep the 1.01 text. Tom:s concern. Whatever we agree on earlier discussion of on secton 4.5 should be could reflect here. Some discussion on semantics of “due to a failure of processing rm header” Tom : this sounds like it only applies to our subset of rm faults for Rm-headers. It might be read to exclude the messaging processing faults. Doug: I read it as including all RM-faults, they all occur while processing rm request header. For now, it was agreed to not accept this edit, and to take it out for the next editing draft. Lines 1341, Rationale: incorrect statement of requirement Proposal: change “no SOAP Fault MUST be
returned” to “a SOAP Fault MUST NOT
be returned” -- Related to discussion above. Tom: All changes applied to editing drafts 1.01E and 1.01F Doug had comments, the changes 5.2.2 Jacques Durand Comments· Re: [wsrm]
editorial comments on 101 I incorporated all of
Jacques edits into contribution 1.01F, with my own edit on the following text, proposed for the introduction paragraph to Table 26: "This
specification supports Reliable Messaging capabilities for WSDL 1.1 [WSDL 1.1] One-way and Request-response operation types only.
While a Request-Reponse operation can
use any of the three RM-Reply patterns to receive acknowledgments or faults, a One-way operation
SHOULD (for WS-I
BP 1.0 conformance) only use either Callback or Poll RM-Reply pattern. Table 26 indicates recommended usage of reply
patterns, for twe WSDL
operaton typed. An RMP MUST, at leat,
support the recommended combinations in Table 26, for the reply patterns it
supports. However, an RMP is not requried to disinguish WSDL operation types." Jacques
Durand wrote: >
Editorial changes suggested below: >
("Table 26" is the most significant change I suggest) > >
Jacques > >
---------------------------------------------------------------------------------
> > >
L68: is not --> are not > >
L171: >
"information" is too vague: need at least to say it is part of >
the message: >
"subset of message data that is intended for the consumer..." > >
L180: "when invoked, the operation..." --> >
"when invoked on a Receiving RMP, the operation..." > >
L214, L218, L222: >
Proposed better wording: >
"The XXXX RM-Reply pattern is used if the..." >
--> >
"When the XXXX RM-Reply pattern is in use, the..." > >
L222: "..a second" --> "..a separate" > >
L246: "e.g., For..." --> "e.g.
for..." > >
L383: Appendix A --> Appendix B > >
Figure 6: >
- the annotations "soap:envelope"
and "soap:header" are missing >
on the right half. >
- the comment (L452) should tell more: >
"Fig 6 shows the structure... in the SOAP Envelope, for two samples of >
messages. >
On the left side of the figure, a Reliable Message is characterized by >
the presence of >
the wsrm:Request element. On
the right side, a response to a Reliable >
Message >
contains a wsrm:Response
element. Both wsrm:Request
and wsrm:Response >
elements may be >
found in the same message." > >
Table 26: >
"Support matrix", "Supported" are not the appropriate
terms: >
This table is more about Usage than Capability, but currently mixes >
both notions, >
with capability ("supported") and usage
("disallowed"). >
It should tell users what reply patterns should be used with what >
operation type. >
It is not about the capability of an RMP, which can in fact support >
the "disallowed" >
case as well, as mentioned in the notes, since the RMP is not required >
to distinguish >
teh operation types. >
I suggest to introduce the table as *recommended* usage of <reply >
pattern / op type>: >
L1218: "...One-Way operations can only use.."
--> "...One-Way >
operations should only use.." >
Table: replace "Supported" by "Yes", and
"Disallowed" by "No" in the >
table. >
L1219: Introduce table as: >
"Table 26 indicates the recommended usage of reply patterns, depending >
on the WSDL operation type. An RMP is REQUIRED to
support at least all >
recommended combinations, > > although an RMP is not required to distinguish the operation
types." > > >
L1227: >
better wording: replace: >
"The Receiving RMP can do whatever..." >
with: >
"The Receiving RMP may determine its behavior entirely based on >
message header content, > regardless of the WSDL definition." > > -- Changes applied to Editing draft 1.01F 5.2.3 Mark Peel CommentsEmail from Mark Peel: Some
proofreading corrections: the line numbers are from the 06-04 document. I didn't
have time to proof the whole document.
If you don't feel these are appropriate, I don't mind if you omit them. Mark
Peel Web
Services Infrastructure Novell,
Inc. 134: Erroneous capitalization in Table 1, replace "E.g"
with "e.g." 150: Typo appears to contain a doublespace
after the comma 228:
Improper usage (e.g. is used to join parenthetical material within a sentence) replace "E.g.,
The" with "For example, the" 244:
Erroneous capitalization "For"
should be "for" 344:
omit needless word change "and to not support" into "and not
support" -- omits "to", which adds nothing to meaning. 328:
use a form consistent with definition "Group scope.
All" to "Group scope: all" 328:
use a form consistent with definition "Message scope.
A" to "Message scope: a" 348: Confusing phrase ",
that is a parameter affecting the entire group" -- I don't know what this clause means.
Does it intend to explain why GroupExpiryTime can change dynamically?
It doesn't do a good job of it. I
suggest striking this clause and putting a period after GroupExpiryTime. 401: typo appears to contain a doublespace
in "the resending" 498:
Inconsistent capitalization change "Schema" to "schema" to conform
to previous line. 498-499:
Wordy sentence construction "If
there are additional elements that are not described in this specification present in message," Better
as "If a message contains additional elements not described in this specification," 546:
Inconsistent capitalization "@GroupId" should change to "@groupId",
making it consistent with the other attribute descriptions that follow. 606:
typo "incremented of 1" should be "incremented by
1" 629:
Erroneous capitalization "Note:
Given" to "Note: given" 629-630:
unclear sentence construction "in case Duplicate Elimination is required, when a received
message is processed," Better
"when a received message requiring Duplicate Elimination is processed," 673:
Improper usage (e.g. is used to join parenthetical material within a sentence) "E.g.,
If" to "For example, if" 691:
typo "things," to "things" -- there's no balancing
comma to the one following "things" and we can omit it. 693:
series not properly punctuated "element)" should really be "element)," -- but
most written English seems to omit that comma these days, so I don't insist on
adding it here. 759: omitted article "by reference-schema" to "by the
reference-schema" -- adds back "the" into the sentence 764:
omitted article "of ReplyTo" to "of the ReplyTo" 765:
omitted article "with URI" to "with a value of type URI" 783: consistent usage "groupId attribute" to "@groupId attribute", a change required twice on this line. This is
consistent with earlier sections describing attributes. 801:
typo "ispecifies" to
"specifies" 805:
change passive voice to active voice, reduce wordy phrase "which is polling" to "asking" 837: change passive voice to active voice "is using" to "uses" 837: awkward sentence construction (too many
parenthetical clauses joined by commas) ",
if" to " and" 861:
omitted article "Response"
to "The Response" 866: typo "case ," to "case," -- there's an extra space
between "case" and the comma 867: omitted article "without sequence" to "without a sequence" 872: consistent usage "from and to" to "@from and @to" 877: consistent usage "groupID attribute" to "@groupId attribute" 885: consistent usage "groupID attribute" to "@groupId attribute" 877: consistent usage, improper punctuation "groupId attribute," to
"@groupId attribute" -- also remove a superfluous comma after "attribute". 895: consistent usage "groupId attribute" to "@groupId attribute" 917-918: typo 917
ends with "numb" and 918 begins "er",
suggesting a space snuck into the word "number". 918: typo extra spaces between "15" and "for" 958: excess word "case of a" to "case a" -- omit "of" 958: Clumsy construction "In
case of a Response RM-Reply Pattern was required, and when the message cannot" Better:
"When a Response RM-Reply Pattern was required and the message cannot" 965: Clumsy construction "In
case a Callback or Poll RM-Reply Pattern was required, and when the message" Better: "When a Callback or Poll RM-Reply
Pattern was required and the message" 1938:
typo change "conditions" to "contributions" Tom: All comments except the one on Line 629 was applied to editing draft 1.01F. Full sentence is allowed to be introduced by Note: prefix in specifications. Doug: I do not see the need for the word attribute if you are adding @foo and get rid of attribute. Tom agreed to apply this in the next editing draft.. 5.2.4 Tony Graham Comments· Re: [wsrm]
1.1-1.02 editorial I
will put the following changed sentence in the next edting
contribution: " However,
it is allowed to dynamically change the value of GroupExpiryTime
or GroupMaxIdleDuration, pertaining to a group. " Tony
Graham wrote: >Lines
347-348 include: > > However, it is allowed to change dynamically
the value of some > group-level items such as GroupExpiryTime, that is a parameter > affecting the entire group. > >The
spec should list the parameters that may be changed. "Some" is >too vague. > >(And change "change dynamically" to
"dynamically change".) > >Regards, > > >Tony Graham Tom: Change applied to draft 1.01F 5.2.5 Pete Wenzil edits on 1.01FEmail from Pete Wenzil: Tom,
here are a couple more small edits (line numbers against 1.01F): 19-22:
Replace comment instructions (see attached email). Bottom
Margin: Remove center tab-stop and extra tab from first line of footer; then the
date will be right-justified properly, rather than on a new line. 29+:
Table of Contents page numbering is off; remember to update it after switching
change-tracking display on or off each time. 17:
Figure 6 is out of alignment; double click on the wsrm:SequenceReplies
and wsrm:ReplyRange frames to bring up properties, then
"ok", and they will snap back to the right size. Move cardinality legend up a few lines so it
all stays on the same page and eliminates
the following blank page. Maybe link
together all the individual
frames to lock everything in place? 240,
1233: Duplicate period. --Pete 6 Discussion of Document Progression.Tentative Schedule: June 9 – Draft 1.01H :Tom will post a new document backing out the things not agreed from these minutes. June 11 – proposals from email discussions agreed in principle June 14 – Monday TC telecom, with potential CD and Submission Vote. Agreed to be 5:30 to 7:30 PM Eastern Time, on Monday. June 15 – submission sent to OASIS Staff Tom: we need the “member experience” statements to be sent before the 15th , to be cited in the submission sent in on the 15th of Jun. Jeff:
I am confused about the Bob F: that is wording from the boilerplate. Several companies have used this. 1 Potential Vote for CD progressionPostponed to Monday Jun 14 meeting 2 Potential Vote for OASIS Submission for Member vote of CDPostponed to Monday June 14 meeting. 3 Frequently Asked QuestionsTom posted the following: · Approved FAQ set for WSRM TC No time to discuss. Jeff M makes motion to adjourn Bob F seconded No objection, meeting adjourned. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]