[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Prelim minutes of WSRM TC 5/11 TC meeting
the prelim minutes are attached. Please send any corrections to the list. -- ---------------------------------------------------- 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
|
Prelim Agenda of WSRM TC Conference Call
– The meeting of the WSRM TC will take place by teleconference (UTC - 5) 1
Draft
Agenda:
Draft Agenda to WSRM TC Conference Call 1 Roll Call 2 Minutes Discussion 2.1 Appointment of Minute Taker 2.2 Approval of previous meeting minutes – 3 Action Item Status Review 4 Discussions of unresolved editorial comments 5 Discussion of Document progression 6 Discussion of FAQ for WS-Reliability 2
Roll
Call
Attendance:
Meeting isquorate. 3
Minutes
Discussion
3.1 Appointment of Minute TakerTom Rutt will take minutes. Minutes will serve to record issue resolutions. 3.1 Approval of previous meeting minutesThe corrected minutes (correcting the statement by
Sunil on composibility) for the f2f are posted at: Alan moved, Joe C seconded. No opposition, minutes
approved. Need to add Jeff M to the attendance list for the May 4 telecon meeting. Post new minutes with Jeff’s name on we will vote next week. 4 Status of Action Items · action item list from 5/4 meeting 4.1 Action editors-1 (Marc and Doug) PendingMarc G and Doug B to updated issues list to reflect agreements in CD .992.- openTom send email again on changes required.4.2 Action 042904-1 (Tom and Iwasa) needs discussionAction: Iwasa and Tom will provide text for the new fault code and the reference to it in the section of text Alan cites.Added GroupAborted error code to draft .996, however the paragraph which was cited to add the MUST return sentence was deleted. Did not add a sentence. Could add the following sentence somewhere: When group processing is aborted, the Receving RMP MUST return GroupAborted fault for all non-delivered messages which have not had an RM reply sent.Done 4.3 Action 042904-3 (Jacques) PendingJacques took an action item to propose this new subsection on special considerations for wsdl request/response operations.Will incorporate into next draft.4.4 Action 042904-4 (Jacques) PendingJacques 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 supportedleave open 4.5 Action 042904-7 (Iwasa) needs discussionAction: Iwasa to apply all editorial changes from Tonys mail, except for those he considers in need of discussion.Completed on 4/30, there are a few comments that require further discussion at May 4 TC teleconf. Closed, will discuss items from Tony.1.6 Action 050404-1 (Iwasa)Action on Iwasa to add new annex pointing at schema with the disclaimer of precidens.open4.7 Action 050404-2 (Iwasa)Action: Iwasa should check if item 7.13 is done.4.8 Action 050404-3 (Iwasa)openAction iwasa needs to clarify resolution of item 10.3.4.9 Action 050404-4 (Iwasa)Iwasa has action item to update figures to get rid of application layer.open4.10 Action 050404-5 (Iwasa)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.Also: Version number should be in the title of the document as version 1.1.Joe Chiusano moved to accept this change, Bob F seconded.No discussion.No opposition, motion passes.Aleady been applied to schema and text.Iwasa: action to ensure the two statements are included. Incorporate version 1.1 in title of spec.open.4.11 Action 050404-6 (Iwasa and Tony G)Action: Iwasa and Tony should work to resolve Tonys non resolved commentsClosed.4.12 Action 050404-7 (Iwasa and Jacques)Jacques, took action, with Iwasa, to produce a new editors draft .997 by Friday. Indicate which public review coments are resolved.open--
5
Discussion
of Issues and editorial Comments
The following issues list includes open items which need further discussion: http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/6677/PublicCommentsIsssues-051104Input.html 5.1 PC7.1 Targeting headers· about
"next" role/actor Title:
about "next" role/actor Should
we say anything about the use of "next" role/actor on RM headers? >
(Pete Wenzel) Line 98: Says "This specification addresses end-to-end
reliability, >
and is not concerned with intermediaries." However, there is nothing to >
prevent someone targeting Reliability headers to "next" role/actor. >
This case should be explicitly forbidden, rather than left undefined. The
use of "next" seems inappropriate in general, as our model ignores
intermediaries. However
I would not forbid this: after all, the receiving party may have deployed several
SOAP nodes to process incoming messages, the first one being supposed to handle
reliability. So this may be a topology that is assumed between sender and
receiver, even if an unlikely one. (E.g. we could imagine that there is a
reliability contract between each pair of intermediaries.) Proposal: warn that reliability headers should not be targeted to SOAP
intermediaries, unless it is the intent that the reliability contract precisely ends at the first intermediary. Jacques Jacques: Peter Wenzel remarked that it would not make sense to target an rm header to the next role. Peter Furniss complained about this strict restriction, especially when a soap node may be a gateway implementation. Tom: will it be normative. Jacques: I propose to place some text in the messaging model section regarding implementation transparency. Tom: is this intended to be an editorial clarification. Pete: Peter Furniss scenario of non reliable from intermediary to ultimate recipient. I am willing to allow that situation. Doug: I am not entirely sure if it is reasonable to go beyond our original requirement. I am worried about text on the document, without review by the group. On the underlying issue, we accept as group that we allow intermediaries, but I am worried about adding. Tom: would leaving the text as is satisfy Pete W. Yes. Motion to resolve issue as close with no change, seconded by Doug. No opposition, motion passes.. 5.2 PC9.2 Group Aborted Fault· RE: [wsrm]
Number of fault messages to send after the receiver aborts ordered delivery for
local reasons Jacques I agree with your rewording below …. -----
Original Message ----- From:
Jacques Durand Date:
Alan: "After
sending 5 abort faults in response to 5 received messages after ordered
delivery has been aborted for the group, the receiver will stop sending the
abort fault." that is better, yet could be worded something like: - "receiving RMP MUST publish a GroupAborted fault for each one of the 5 first messages received
for the aborted group, and MAY do so for subsequent messages." (so it is possible to accommodate other policies, e.g.
exponential back-off. Also "publish" accommodates "poll"
cases.) We
might still have a general provision for handling denial of service attacks
(not just in hat case), that say that in case
of suspicious pattern of communication that creates an obvious burden on
the receiver, the receiver may decide to drop any sending duty required by this spec, and send another
special fault about this ? Jacques Tom: why not three. The SNMP word, rpc on top of udp, uses three resends.Jacques: keep faulting for every new message, but not do this forever. If it is obvious the sender is igmoring the faults, this group abort fault would not be sent again. This number, 3 or 5 , is the minimum the receiver is required to send for each message.Tom: I am concernte that this should be a profiling decision.Doug: this group aborted fault occurs only when the group has been aborted, but has not been cleaned up. I think it is inappropriate that if the receiving system crash immediately after aborting the group, that it be required to remember the ability to send that fault.Tom: I agree with Doug.Jacques: The origin of this issue was that group aborted fault only makes sense that the group is still active on receiver side.GroupAborted: All processing for the groupID
associated with the reliable message request has been aborted by the Receiving RMP. No subsequent messages
within that group will be delivered by the Receiving RMP. Jacques: I am happy with the definition of the fault as is. No additional text required to resolve this issue. If we add text for one fault type, do we have to add it for the rest. Tom: Issue on not supported feature: this is application specific, leave to profiles. Ø Action: Tom will reopen issue on not supported feature fault for discussion at next week meeting. Bob F: I agree this detail can be left to profiles.Jacques: this is not critical to the reliablility protocol. An implementation would still work if it sends no faults at all. Faults could be viewed as convenience feature. We need to be consistent across the spec.Bob F Moves that group abort issue is already Resolved by draft .996, Iwasa secondse.No opposition motion passes.5.3 Editorial comments from Tony Graham (items PC11.x)Mail from Tony Graham: · Re: [wsrm] New Editor's draft .996 posted
(with Jacques Refactoringchanges) 5.3.1 PC11.61. Line 178: example.org
example.org (and example.net and example.com)
are reserved for examples and documentation.
See http://www.rfc-editor.org/rfc/rfc2606.txt for the explanation. Using
example.org makes it obvious that it is an example and avoids any conflict with a domain name that is in use or will one
day be in use.
Ø Action: Iwasa to apply PC11.6 resolution 5.3.2 PC11.112. Line 288, 304: Why must the time be
identifiable? I would
like this to be explained to me.
Ø Action Tony will take PC 11.11 to email discussion 5.3.3 PC11.143. Line 329: Reliable Messaging Fault Indication
for failure to receive a message Another
thing that I would like explained to me.
Tautology, if not received how can it give a fault. Remove “to receive or” Doug: it is a failure to invoke the deliver operation. It
signals to the Sending RMP of the referred message that there was a failure to invoke the deliver
operation for the message. Agreed editorial. Action:
editors will place into next draft. 5.3.4 PC11.154. Line 366 My
comment had to do with the sentence construction. Looking at the comment in the preliminary minutes, it seems likely that
the sentence will change anyway.
The line 336. has nothgin to do with multiple acks Tony: Action to send to the list the exact change required on the .996 text. 5.3.5 PC11.25. Line 388, 390, 392 My braino. It should be "Change 'details' to
'details.'." but I was thinking too much about periods so the wrong word came
out.
Ø Iwasa: action to add period if missing for PC11.20 5.3.6 PC11.24
5.3.7 Misc
Tony: we could leave to the Editors. Doug: the xml declaration is an optional part of an xml instance. Soap does not require the xml declaration. As long as it is in utf-8 any parser should work. Suggested to remove to xml declarations in the examples. Leave open have discussion on email.
Doug: smart quotes make the examples invalid. They are not allowed in XML examples. Ø Action: Iwasa will turn smart quotes to normal quotes. Tom will send the required edits to remove smart quotes to Iwasa Agreed not yet applied. Tools autocorrect need to be fixed. 5.4 PC13 HTTP POST as Mandatory
Need to clarify that HTTP POST only is used in mandatory mapping. Need to add something to conformance section about HTTP POST binding and conformance. Sunil: The WSDL 1.1 defines soap http bindings. We are soap only. Sunil: What is the conformance requirement of this spec with respect to soap over HTTP. The soap binding we have could be normative but optional complienace point. Define a compliance point in the conformance section. For this compliance point. Sunil The protocol is supposed to be transport agnostic. There has to be a soap binding to transport. Anish: you can use a binding which supports soap. Is it enough to say HTTP post binding. We could say HTTP post method. It would be more appropriate to state WSDL 1.1 soap binding. The bindind defined in soap 1.1 Tom: Agreed in principal, we will define a normative soap binding, but not require that binding for conformance. We talk about WSI compliant in another section. This is only meaningful with http binding. Ø Action: tom will start email discussion on this normative statement of our soap http post binding, and proper conformance text. 5.5 PC14 Extensibility of ReplyTo attribute
· Proposal to
resolve the WS-R issue regarding 'replyTo' attribute All. Here is a proposal to resolve the issue [1],
that I raised, regd. replacing the 'replyTo' attribute in WS-R with an extensible addressing
container. This proposal replaces the 'replyTo'
attribute with a 'ReplyTo' element with an open
content and defines the referencing scheme when the reply-to is a URI. This
allows WS-R to be used with URI and makes it extensible to use other addressing
schemes (WSRef, EPR or whatever may emerge out of
other standards TCs/WGs). The crux of the proposal is as follows: 1) The replyTo
attribute is used in two places: a) On the ReplyPattern
element, and b) PollRequest element. This attribute
is replaced with an element called 'ReplyTo'
described below. 2) Define a new global
schema type and element (in the existing <xsd:complexType
name="ServiceRefType"> <xsd:sequence> <xsd:any
namespace="##other" processContents="lax"
minOccurs="1" maxOccurs="1"/> </xsd:sequence> <xsd:attribute
name="reference-scheme" type="xsd:anyURI"
use="required"/> </xsd:complexType> <xs:element
name="ReplyTo" type="wsrm:ServiceRefType"/> The value of the attribute reference-scheme
specifies the "type" of the addressing scheme. One such scheme for
using URIs is defined in (3) below. 3) Use the URI
"http://www.ietf.org/rfc/rfc2396.txt" for the value of the
reference-schema attribute when the reply-to address
is a URI 4) For the type PollRequestType
convert the attribute 'replyTo' to an element 'ReplyTo' of type 'ServiceRefType'
with minOccurs=0. PollRequestType
schema type will be as follows: <xsd:complexType
name="PollRequestType"> <xsd:complexContent> <xsd:extension base="wsrm:HeaderBaseType"> <xsd:sequence>
<xsd:element
name="RefToMessageIds" type="wsrm:RefToMessageIdsType" maxOccurs="unbounded"/>
<xsd:element
ref="wsrm:ReplyTo" minOccurs="0"/>
</xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> 5) For the type ReplyPatternType
make it a complex content containing sequence of two elements 'Value' and 'ReplyTo as follows: <xsd:complexType
name="ReplyPatternType"> <xsd:sequence> <xsd:element name="Value"
type="wsrm:ReplyPatterTypeValues"/> <xsd:element ref="wsrm:ReplyTo" minOccurs="0"/> </xsd:complexType> Details of changes required: 1) Modify the schema as stated above. 2) Remove line 644 3) Table 5: s/none/Value, ReplyTo remove "replyTo(URI" 4) Section 4.2.3 will have to change to say that
the element 'Value' can have the values 'Response', 'Callback' or 'Poll'. In
addition, a table for element 'Value' and 'ReplyTo'
will have to be added. The description of replyTo
attribute has to change to describe the element wsrm:ReplyTo. The meaning of the attribute
'reference-scheme' will have to be added along with the special value
"http://www.ietf.org/rfc/rfc2396.txt". 5) Section 5.3, add a
table for describing the ReplyTo element 6) Table 9 should be modified to remove 'replyTo(URI)' from the attribute
row and 'ReplyTo" element should be added to the
child elements row. 7) Replace lines 742-745 with the description of
the 'ReplyTo' element, similar to (4) above. 8) Table 16, penultimate row, 2nd column: s/replyTo
attribute/ReplyTo element 9) replace 1331-1332 as
follows: <original> <ReplyPattern replyTo="http://wsrsender.org/abc/wsrListnener"> Callback </ReplyPattern> </original> <proposed> <ReplyPattern>
<Value>Callback</Value> <ReplyTo
reference-scheme="http://www.ietf.org/rfc/rfc2396.txt">
http://wsrsender.org/abc/wsrListnener" </ReplyTo> </ReplyPattern> </proposed> 10) Line 639, 723, 986, 1376, 1379, 1390, 1437,
1438, 1448, 1453: s/replyTo attribute/ReplyTo element 11) replace 1466-1473
as follows: <original> <PollRequest
xmlns="http://www.oasis-open.org/committees/wsrm/schema/1.1/SOAP1.1" replyTo=”http://wsr-sender.org/xyz/servlet/wsrmListnener” soap:mustUnderstand="1"> <RefToMessageIds groupId="mid://20040202.103832@wsr-sender.org"> <SequenceNumberRange from="0"
to="20"/> </RefToMessageIds> </PollRequest> </original> <proposed> <PollRequest
xmlns="http://www.oasis-open.org/committees/wsrm/schema/1.1/SOAP1.1""
soap:mustUnderstand="1"> <RefToMessageIds groupId="mid://20040202.103832@wsr-sender.org"> <SequenceNumberRange from="0"
to="20"/> </RefToMessageIds> <ReplyTo reference-scheme="http://www.ietf.org/rfc/rfc2396.txt">
http://wsr-sender.org/xyz/servlet/wsrmListnener </ReplyTo> </PollRequest> </proposed> 12) Section A.V.F (lines 1775-1777): Replace the section to conform to the new schema
type wsfm:ServiceRefType <original> A.V.F. ReplyTo URI This property is identified by the QName "wsrmf:ReplyTo"
and corresponds to the semantics specified by the
WS-Reliability reply-to. The type of this property is xs:anyURI. </original> <proposed> A.V.F ReplyTo This property is identified by the QName "wsrmf:ReplyTo"
and corresponds to the semantics specified by the
WS-Reliability reply-to. The type of this property is wsrm:ReplyTo. </proposed> 13) In section A.VI, a) add: <xs:import
namespace="http://www.oasis-open.org/committees/wsrm/schema/1.1"/> after line 1784 b) add a namespace
prefix 'wsrm' corresponding to the NS
http://www.oasis-open.org/committees/wsrm/schema/1.1 c) and replace 1797
with: <xs:element
name="ReplyTo" type="wsrm:ServiceRefType"/> Comments? Thanks! -Anish -- Anish: there are several TCs which are struggling with something similar. In my proposal I have included the complex type in our name space. Do we want to put it into a separate namespace, such is with wsrmf Doug: I was wondering why you decided to use a required attribute rather than describing a default to simple URI. Anish: There was no particular reason to not do this. Tom: I agree that this be the default for the attribute. If someone chose to put it in is it still valid. Doug I do not see the need to be explicit, as long as the default is described. Anish: specifying defaults in schema has been difficult. Doug: defining leaving out the optional value not being present, our protocol defines the default. Doug: Describe the semantics of leaving it out in text, with it being an optional attribute. Anish: He is also saying we do not need to define the value. Sending nothing means that No disagreement. Anish: I can come up with wordings now but I am not sure people are ready. Doug: we have another open issue on whether this is in a separate name space. In my opinion it should, and I appreciate the fact that Anish pointed this out. We need this to discuss before voting on a proposal next week. We should not be making changes without discussing this on the list. Anish: I would like the namespace of this new element type in a separate namespace controlled by WSRM that would be a good thing. WSS has done something like this. Doug: from my perspective is that it eases other specs to use this feature, by not bundling it in with all our other stuff. General agreed that this be in a separate namespace. Anish: Remove point 3, Describe semantics of not present. In schema make attribute optional. Suggest a namespace for service ref type. Ø Anish action to provide amended proposal on reply to element, target for approval at next meeting. Initiate discussion,. 6 Discussion of Document Progression.Iwasa to have a
new editorial draft done. By the end of this week. Friday morning .997 draft. Can resolve all open issues by next Tuesday evening meeting CD ballot possibliy initated. Two weeks from today May 25 Another cd ballot by May 25. Could have the June 15 date for submission Pete: I think after we vote to accept anish proposal we have to decide whether it is a substantive change. The TC process states there should be another public review period. Tom: we could have a one week public review. Action: time will check with Karl on this process issue. Bob F it is up to the committee to decide what Jacques: 30 days for a new public review seems like a waste of time. Doug: there are two questions: 1) do we as a TC believe the changes are substantive enough to require another public review , 2) is Karl ready to send out an announcement for public review longer than one month. We could make a case that we are only asking to review the changes since the last review. 7 Frequently Asked Questions· Updated WSRM FAQ The question: Q:
How does the WS-Reliability protocol relate to WSDL operation types?
There are three reliable messaging reply patterns which may
be used with WS-Reliability: · Response
RM-Reply Pattern: the outbound Reliable Message is sent in a request of the
underlying protocol and the RM-Reply is sent in a SOAP header element in the
response message of the underlying protocol that corresponds to the request. · Callback
RM-Reply Pattern: the RM-Reply of a previous message is contained in a SOAP
header element an underlying protocol request of a second request/response
exchange (or a second one-way message). · Polling
RM-Reply Pattern: a second underlying protocol request is issued to the
receiver of a previous message, in order to obtain a RM-Reply. The RM-Reply can
be either contained in the underlying protocol response to this request or in a
separate underlying request from the receiver to the sender. This polling
pattern is generally expected to be used in situations where it is
inappropriate for the sender of reliable messages to receive underlying
protocol requests (behind the firewall cases) or to avoid resending bulk
messages often. The current answer is only about reply patterns. Ø Jacques; Action: Jacques will write an answer to this question. After
that we can decide if we need another question about reply pattern
specifically. Jacques: reply pattern question should be about a more general question about firewall and delayed response use cases. This would be a better way to introduce the requirements to motivate the reply patterns. Have an email discussion on this one. Put this topic on agenda for next week. Put this whole FAQ on the block for email discussion before next week. Jacques: It is worth it to spend time on the FAQ. Target an agreement on intial faq by next week. Bob F moved to adjourn. Anish seconded/ Meeting
adjourned at | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]