[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Prelim minutes for thursday meeting
the prelim minutes for the thursday meeting are attached. -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133Title: *Proposed Agenda:*
|
Thursday Prelim Minutes WSRM meeting 8 Review of Homework Assignments8.1 New messageID schemaSunil sent mail Here is the proposal for
consolidating the GroupId and SequenceNumbers
elements. The new element in the MessageHeader
would be: <MessageId groupId=" ">
<SequenceNum status=" "
number=" " /> </MessageId> The element in PollHeader
and Response would be: <RefToMessageIds groupId="
">
<SequenceNumRange from=" "
to=" " /> * <!-- 0 or more occurrence's of this --> </RefToMessageIds> 8.2 Review of Sunil Fault ClarificationSunil sent email This proposal lists the fault codes
to be sent in the RM Fault Headers. Note that SOAP 1.1 disallows using the <fault:detail> element to send
faults that happen during the processing of Headers. Such faults should be send in SOAP Headers itself. This exercise is for SOAP 1.1 msgs. only. A SOAP 1.2 version
will be done at a later stage. Invalid Msg. Format Faults:
* InvalidGroupId: This fault is sent if the GroupId format is wrong or invalid
* InvalidRefToGroupId: This fault is sent if
the RefToGroupId format is wrong or invalid.
* InvalidSequenceNumber: This fault is sent if
the SequenceNumber format is wrong or invalid The same fault is sent if the value of status attribute is
not of begin|continue|end.
* InvalidRefToSequenceNumberRange: This fault
is sent if the RefToSequenceNumberRange format is wrong or
invalid
* InvalidExpiryTime: This fault is sent if the
ExpiryTime format is wrong or invalid
* InvalidReplyPattern: This fault is sent if
the ReplyPattern format is wrong or
invalid or when the replyTo attribute is missing for
the Callback pattern.
* InvalidGroupParameters: This fault is sent
for any of these cases: o groupExpiryTime is wrong or invalid o groupMaxIdleDuration is wrong or invalid o when both
group parameters are present o when groupExpiryTime decreases for a subsequent msgs. in an ordered group
* InvalidMessageHeader: This fault is sent
when the MessageHeader element is wrong or invalid.
Examples are: o When one of the
mandatory elements (GroupId, ExpiryTime,
ReplyPattern) is missing
* InvalidPollRequest o When GroupId is missing o When SequenceNumberRange element is wrong or invalid Faultcode
for all the above faults should be env:Client. Request Processing Faults: RequestProcessingFault:
This fault is thrown by the receiving RMP when it cannot process the request
for any of the following cases:
* It doesn’t support the ReplyPattern sent by
the Sender
* Doesn’t support any of the RM agreement items
* Persistence problems
* Cannot send an Ack. Faultcode
for the above fault should be env:Server. Sunil stated he would updated this list to accommodate changes due to the new message id schema. Sunil also stated that the processing Fault discussion should occur with the discussion of the new issue from Jacques, on resource limitation faults. ACTION: Iwasa needs to remove the sentence on the description of invalidExipiryTime stating it is sent when the message expires. 8.3 Review of New Editor’s draftIwasa went through his new editor’s draft. http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/5024/WS-Reliability-2004-01-15.pdf He did not yet incorporate the resolution to 56, and 83 to 86. ACTION: Iwasa has to factor in the new syntax for the message Id schema in section 3.3. The sections need to be rearranged since some items have been changed from elements to attributes., and some of the names have changed After we agree on Sunils new faults, on fri morning, Iwasa should update the document. Review of new state chart Tom: Is it required to Send ack if duplicate was delivered and messages was not expired Jacques objected to accepting this as an agreement. He stated it has a cost, and benefit needs to be discussed. He stated it should be allowed, but not required. Doug: These assumptions are explicit in the existing spec. Tom: perhaps we should add a new issue to answer this question. Tom asked Jacques to explain why the received list plus the held waiting list is not enough to determine if the earlier receipt was acked. Add new issue. Discuss first thing tomorrow. Agreed to add the following clarifications to the document: - for response reply pattern, the ack cannot be sent back on the response to a later request. - Multiple acks to same reply to are Allowed for callback reply pattern. 8.4 Group definitions refined.Deferred until Friday morning. a) Check for usage of Optionality “SHOULD, MUST, MAY, etc” (Rel 22) b) Determine candidates for Optional Implementation (Rel 29) Thursday Jan 15 AM: 9 Resolution of “Requirments” Issues (Rel 59-79) and others9.1 WSDL Operation Type and Reply Pattern Requirements:Tom Rutt send the following email: From Issues Rel
63, 64, 65, 89, 90, 91: *REL-63* Spec feature Design Active *Title:* Meet *Usage of WSDL 1.1
One-Way ops, R3.2* requirement *Description:* The Specification
must support services with WSDL 1.1 One-Way operations. Close as requirement met *REL-64* Spec feature Design Active *Title:* Meet *Usage of WSDL 1.1 req/resp ops, R3.3* requirement *Description:* The Specification
must support services with WSDL 1.1 Request-Respose
operations. *REL-65* Spec feature Design Active *Title:* Meet *Response RM-Reply
Pattern req/resp, R3.4* requirement *Description:* The Specification
must support the Response RM-Reply Pattern for WSDL 1.1 Request-Response
operations. Requirement met for reliable delivery of request only. Doug: but we do not need any further reliability on reply. *REL-89* Spec feature Design Active *Title:* Meet *Response RM-Reply
Pattern one way, R3.5* requirement *Description:* The Specification
must support the Callback RM-Reply Pattern for WSDL 1.1 One-Way operations. ** * * *REL-90* Spec feature Design Active *Title:* Meet *Polling RM-Reply
Pattern one way, R3.6* requirement *Description:* The Specification must
support the Polling RM-Reply Pattern for WSDL 1.1 One-Way operations. *REL-91* Spec feature Design Active *Title:* Meet *Polling RM-Reply
Pattern req/resp, R3.7* requirement *Description:* The Specification
must support the Polling RM-Reply Pattern for WSDL 1.1 Request-Reply
operations. Close as ----------------- Rel 91 associated
with a requirement, in Requirements .91.
This is met by our protocol. The requirement to support:
Response RM-Reply pattern for WSDL Request-Response operations is partially
covered by the WS-Reliability protocol in its current form. The current
protocol has features to satisfy all three of the reliability Qos requirements (GD, DE, OD) for
the request message of the Request-Response operation. Since Piggybacking is allowed in
the protocol (or not disallowed) the current protocol can support duplicate
elimination feature for the response, since this does not require an ack for the response. We agreed at the South San
Francisco F2F to not support Guaranteed Delivery (and thus not supporting
Ordered Delivery) for the response message of the request response operation,
at least for the first version of the protocol. The requirement to support callback
and poll RM-Reply patterns for One-way wsdl
operations is met by the current protocol. The protocol does not support (and
there is no requirement to do so) mapping a wsdl 1.1
one-way operation onto the response RM-Reply pattern, since this disobeys the
WS-I BP 1.0. However, the protocol should not require the Receiver RMP to
detect that a one-way request has erroneously been sent with the response
RM-Reply parameter set, since it should not require knowledge of the WSDL to
operate. That it, if the sender erroneously sends a one way wsdl
operation with the response reply pattern set, then the Receiving RMP may send
an HTTP response with a soap envelope, in violation of the profile. Thus I propose we close all these issues, since the protocol meets the requirements stated. Add a table to the spec:
· * - The WS-Reliability protocol does not support treating a wsdl response as a reliable message. It only supports delivery of the WSDL request as a Reliable message. · ** - WS-I BP 1.0 disallows sending soap envelope in HTTP response. However, the protocol does not required Receving RMP to enforce this restriction. The receiver can do whatever the header asks for. Jacques asked about WS-I compatibitly. Tom: the protocol should disallow use of oneway with response reply patter. Tom: should we also add support for reliable response in WSDL request response operations to a future version “wish list”. Jacques, guaranteed delivery of the Business response requires an ack to the response. Doug: The only requirement to reliably deliver a business response using response reply pattern, is that it be combined with an ack the original sender will retry until it successfully received. Doug: concerned about clarifying what is not covered by existing protocol. Close all these issues as supported by protocol. Future work is required to determine additional requirements for reliable delivery of wsdl response. ACTION: Sunil will provide text to include in the specification 9.2 Rel 93*REL-93*
*Title:* Meet *Combatibility, R8.2* requirement -- ACTION: Sunil will put this statement in a note to add to the operation/replypattern table. Will not change protocol in WS-reliability from its current features. 10 Simple Spec Issues10.1Rel 96*Title:* Reliable WSDL req/resp The support of Guaranteed Delivery of the response message of a WSDL request response operation is for further study. 10.2Rel 97
“All messages in a group MUST have the same values for the three Reliable Messaging qos parameters in their Message header.” 10.3Rel 99*Title:* ReplyPattern
mandatory subelement *Proposal:* The value of the ReplyPattern element in the RM Reply must match the value
in the RM Request -- This proposal is
accepted. The text is already in the
WS-Reliability Spec, 3.1.4 in a normative manner. Thus we should close Rel 99 as completed.
11 Continued Review of Completed Issues11.1Rel 33Still needs to check usage of terms deliver and submit. 11.2Rel 36MessageID as one word or two. There is no longer MessageID. Section 2.4 is still messy, 2.5 is a mess. Leave in completed state until Iwasa fully reflects. 11.3Rel 37Change syntax of Message ID schema. Section 3.1.1 added RFC reference Need to complete the reference Leave as completed. 11.4Rel 38Done 11.5Rel 40Done 11.6Rel 443.1.1 clarifying statement done 11.7Rel 51Leave to be verified. Heading 3.4 was lost in editing 11.8Rel 52Question on the title for the new section. Also, need to add lead in text introducing the group termination parameters in Secion 2.5.1. 2.5 made forward references to section which was moved. Need to change title to group termination parameters. Add intro text to define the two group termination parameters. Leave in completed state. 11.9Rel 87Amendment of Sunil’s email for headers. Done except for the need for two new issues. ADD NEW ISSUE ON FAULT CLEANUP ADD NEW ISSUE ON RESOURCE LIMITATION PROCESSING FAULT 11.10 Rel 98Done. Jacques was given action item to cleaup group semantics explanation. ADD NEW ISSUE TO CLEANUP GROUP SEMANTIC Explanation. 11.11 Rel 100Attachments: Create 2.9 attachments with description. Included in November version. Done 12 Resume Discussion of Issue resolutions12.1Rel 22Check for usage of Optionality “SHOULD, MUST, MAY, etc” (Rel 22) Doug proposal (from wed minutes): Need globally change (as part of rel 22) for items that cannot repeat: the tables “ required – no” to “cardinality – 0 or 1”, and “required – yes” to “cardinality – 1”. In addition: things that can repeat should have upper cardinality greater than 1. that is - required-no to cardinality 0 or more, and - required-yes to cardinality – 1 or more. AGREED Jacques provided the following text for discussion: In order to be conform to this
specification, an implementation must satisfy all the following
conditions: · It
complies with the following interpretation of the keywords OPTIONAL and
MAY: When these keywords apply to the
behavior of the implementation, the implementation is free to
support these behaviors or not, as meant in [RFC2119]. When these keywords apply to received
message contents relevant to a module of features, a
conforming implementation of such a module MUST be capable of processing these optional
message contents according to the described semantics. · If
it has implemented optional features and/or behavior defined in this
specification, it MUST be
capable of interoperating with another implementation that has not implemented the
optional syntax, features and/or behavior.
It MUST be capable of processing the prescribed
failure mechanism for those optional features it has chosen to implement. · If
it has chosen NOT to implement optional features, It
is capable of interoperating with another
implementation that has chosen to implement these. It MUST be capable of generating
the prescribed failure mechanism for those optional features it has chosen to NOT
implement. Jacques based this text on the EBMS specification. The first bullet addresses two concerns. The second is on optionality of parameters. Doug suggested that we can eliminate the second concern, regarding message item presence, by avoiding the use of OPTIONAL or MAY, instead with cardinality constraints. Looking at spec the word Required is throughout the spec for message parameters.: Bob: Some parameters stated “Item xxx is REQUIRED if yyy” Doug: suggested global change to “Sender of the message must include this item if yyy” Bob: Several items state “OPTIONAL” or “OPTIONAL if yyy” Doug: change to “Sender May include xxx “ or “sender May include xxx if yyy” Eg from 3.2.1: The AckRequested element is an OPTIONAL element. It is REQUIRED for guaranteeing message delivery and message ordering. If the MessageOrder element is present, the AckRequested element MUST also be present Change to: The AckRequested must be present for guaranteeing message delivery and message ordering. If the MessageOrder element is present, the AckRequested element MUST also be present. Later in the same para: “ If a receiver receives a message with AckRequested element, the receiver is REQUIRED to send an Acknowledgment message even when the message is a duplicate. “ Change to: “ If a receiver receives a message with AckRequested element, the receiver MUST send an Acknowledgment message even when the message is a duplicate. “ There is an issue on the exact semantics of when Dups must be acked. But the wording change to replace required with MUST is the issue here. Jacques: we need to make a first pass using the new rules above. Try to get rid of OPTIONAL or MAY in specifying presence of message items. BOB: there are 11 instances of OPTIONAL in message parameter definitions. Doug: there are many more cases of MAY or MUST for parameter definitions. Element cardinality of 1¨ This element MUST be present Doug: Just use the table, and have the cardinality row of the table express the presence requirements. Fixed cardinality is easy. Conditional cardinality – 0 or more, how to specify the conditions. Example: Change: DuplicateElimination Element
The DuplicateElimination element is used to
require the receiver node to identify duplicate messages it has received and
process them accordingly (see section 2.6). A duplicate message is a message
with the same Message Identifier as another message. This element is OPTIONAL.
It is REQUIRED when duplicate elimination is mandated. If the MessageOrder element is present, the DuplicateElimination
element MUST also be present. Table9 DuplicateElimination
Element
Change to: DuplicateElimination Element
The DuplicateElimination element is used to request
the receiver node to identify duplicate messages it has received and process
them accordingly (see section 2.6). A duplicate message is a message with the
same Message Identifier as another message.. The
sender MUST include the DuplicateElimination element if
the MessageOrder element is present,. Table9 DuplicateElimination
Element
“ Bob: can we put the conditions in the table somehow. Jacques: we can rely on the text. Doug: we only use MUST, MAY, SHOULD, OPTIONAL only to characterise behaviour. ACTION: Iwasa will do this for the entire document. Question: does WS-Reliability spec make schema constraints normative. Doug: if we do we have to say what happens if text and schema do not agree. Tom: either pick which one takes precedence, or have both normative and any discrepancy must be resolved by defect procedures. Bob: until the spec is more mature, we should consider them both normative, and fix the discrepancy. ADD NEW ISSUE, which takes precedence if discrepancy is identified, the text or the Schema. Agreed to move this issue to status of COMPLETED. Pointing to these minutes. 12.2Determine candidates for Optional Implementation (Rel 29)After taking out the use of MUST, MAY, OPTIONAL for parameter presence, Jacques proposal becomes: In order to be conform to this
specification, an implementation must satisfy all the following
conditions: · It
complies with the following interpretation of the keywords OPTIONAL and
MAY: When these keywords apply to the
behavior of the implementation, the implementation is free to support these behaviors or not, as meant in [RFC2119]. · If
it has implemented optional features and/or behavior defined in this
specification, it MUST be
capable of interoperating with another implementation that has not implemented the
optional syntax, features and/or behavior.
It MUST be capable of processing the prescribed
failure mechanism for those optional features it has chosen to implement. · If
it has chosen NOT to implement optional features, It
is capable of interoperating with another
implementation that has chosen to implement these. It MUST be capable of generating
the prescribed failure mechanism for those optional features it has chosen to NOT
implement. Tom opened the discussion with the question of whether we need any minimal Conformance class, which all Receiving implementations must implement. Bob: SAML came up with a minimal set of core features which all implementations must support. AGREE: We need proper fault message to allow the Receiving RMP to indicate non-support of a requested WS-Reliability feature. Alan: we should have guaranteed delivery in the core set.. Tom: example, an enterprise only needs duplicate elimination, and will never use guaranteed delivery. Why should its receiving RMP be required to implement the ability to send the reply headers. Marc: what about requiring full support in order to claim WS-Reliability. Tom: requiring the persistence of messages an IDs is too heavy for some minimal devices. That is why Guaranteed delivery might be a valid core feature. Jacques: why do we need a core set for receivers. Marc: guaranteed delivery is so widely used; it might be justified as a core feature. Tom: we could rely on profiles to do the grouping of features for conformance. Bob: if we have groups of features, they can be reflected in the fault messages for not implemented. Jacques: minimal conformance- of you do it you must conform to the spec. Jacques: could have three orthogonal functional units “guaranteed delivery, duplicate elimination, ordered delivery”. An implementation can implement any valid combination of these functional units. Three Faults mirroring FUs- GD not supported, DE not supported, OD not supported. Sunil: is there ever a need to send more than one of these faults. Especially if we have faults for the different reply pattern supports, we would need to send a fault with a list of non supported FUs. Sunil: I would prefer a single fault, “not supported” Tom: if have FUs the spec must state what conformance to the FU entails for sender RMP and for Receiver RMP. Doug: Having a single error is more practical. It avoids the sender assuming that it can automagically determine the feature support by subsequent attempts at different feature requests. Is there a need for packaging protocol feature into a small set of feature modules? Sunil: I do not see a need for this. Example of potential feature modules: · GD for req response using response reply pattern · GD for req response using callback · GD for req response using Poll · GD for one way using callback · GD for one way using Poll · DE for req response using response reply pattern · DE for req response using callback · DE for req response using Poll · DE for one way using callback · DE for one way using Poll · OD for req response using response reply pattern · OD for req response using callback · OD for req response using Poll · OD for one way using callback · OD for one way using Poll Sunil: the current protocol does not have negotiation mechanisms to determine such support. Bob: this results in 2 to 15 power different combinations of these feature modules. Bob: There can be shadings of each of these 15 (eg, are multiple acks supported). Cardinality limits. Etc Bob: perhaps the patterns can be the groupings: · Response reply pattern · Calback reply pattern · Poll reply pattern Straw poll Choice 1 – Single Fault (NotSupportedFeatureFault) any implementation across the choices is conformant. Choice 2 – Select subsets of the 15 feature modules which are mandatory for all Receiving Implementations to support. Question: Who cannot live with choice 1 – none Who cannot live with choice 2 - (“we are not smart enough to do this”, “I cannot accept it” Bob: what about a feature probe. Alan: how about GD for any reply pattern that is supported. Tom: I detect an emerging consensus that conformance classes cannot be determined by this group at this point in time. The work is more properly done by profile groups dealing with a specific field of use. Pending close with this resolution. Single fault will be defined “NotSupportedFeatureFault” Rel 49 Revisited Edit of sunil’s mail Example of a <service-config> usage inside the operation 'foorBar'. <portType name="fooPortType"> <operation name="fooBar"> <wsrm:service-config xmlns:wsrm="some URI" <wsrm:guaranteed-delivery usage=”required|optional”> <!-- List the reply patterns supported by this service. Can have one or more such patterns --> <wsrm:reply-pattern> Callback <!—possible values are Response/Callback/Polling -> </wsrm:reply-pattern> </wsrm:guaranteed-delivery > <wsrm:duplicate-elimination usage=”required|optional” /> <wsrm:message-ordering usage=”required|optional”/> </wsrm:service-config> <input message="fooMessageIn" /> <input message="fooMessageOut> </operation> </portType>
operations/binding/bindingOperation/port/Service-every place BP 1.0 allows extensible elements There was discussion on the user adding “wsdlRequired=“true” to one of these capability annotations. It was pointed out that if a person put this on a capability, the they would not be able to work with senders which did not support this wsdl extension. The group expressed a desire to see the entire proposal before making a decision. ACTION: Sunil will provide a complete spec of the feature before we decided on the resolution. 12.3Rel 101 need resource faultsJacques: When the receiver needs to persist some material, and cannot do so due to memory shortage, we need a fault for it to return. Sunil: request processing fault could be used, if we have a fault string which the receiving rmp can populate. Jacques: receiving this fault must be interpreted a message failure when received by the Sending RMP. Tom: what about transient conditions vs permanent condition. Bob: This might not be known at the time the fault is sent by the Receiving RMP. Bob: how about a single fault which can carry a Unicode string reason. Have some standard strings. Eg: · “loss of persistence mechanism” – catastrophic failure of protocol persistence not likely to be able to process future message.. · “failure to delivery” · “resource limitation” – cannot process this message, may work for future messages. Jacques: It is important that the fault is sent on a per message basis, this should not a bulk fault message. All agreed. Bob: how about two levels of fault: · endpoint: out of service, vs · this message failed, others may work. Sunil: how does the receiving RMP know this. Bob: but if the RMP does know this, it could send it. What about third value, do not know. Bob: two semantics – do not even think about trying another invocation on this endpoint - this message failed, try again later, the endpoint might work Bob: the first semantic tells the sender to request manual intervention before the endpoint will work. Proposal two new Faults defined, each using fault string to further qualify. – PermanentProcessingFailureFault – MessageProcessingFault Bob moved to add these two faults into the spec. Doug seconded. No opposition. Motion passes Move to completed state. ACTION; Sunil will incorporate into his fault proposal for review on Friday morning. 12.4Rel 102Title: Termination of Receiver persistence requirements Description: section 2.6 describes when a Sender may discard persisted information but (by comparison) makes the persistence requirements for a Receiver seem to last forever. Proposal: Replace final two paragraphs of this
section (presently "The receiver MUST persist out
of order messages to support Guaranteed Message Ordering. The receiver MUST persist the Message Identifier to support Duplicate
Elimination. Both sender and receiver MUST behave as if there was no system
failure or system down after recovery.") with "When supporting Guaranteed Message Ordering, the receiver is REQUIRED
to persist out of order messages until one of the following conditions are met: When supporting Duplicate Elimination, the receiver is REQUIRED to persist
the Message Identifier until one of the following conditions are met: Both the sender and receiver MUST seamlessly recover from any system failure
or system down condition." Notes: Final statement remains too strong and is not enforceable. First sentence in this section should say "When supporting Reliable Messaging" and not "With Reliabile Messaging". Jacques: I have a new proposal:, related to When duplicate elimination is requested, the Receiver rmp is required to persist message IDs of delivered messages until they are expired. Leave issue open until we resolve the ack of duplicate issue rel 103 12.5Rel 105Close with following Pending resolution: Make Group expiry time as xsd:dateTime Use xsd:duration for groupMaxIdleTime attribute. Pending Resolution. 12.6Rel 104Is spec or schema normative when they are in conflict. Jeff: if there is an inconsistency discovered, there is a bug in the spec. If you have a statement that one takes precedence over the other, then users know what to do before the bug is fixed. Jeff: the one which is most reviewed and understood would be the preferred one to determine the intent. OASIS specs fix bugs by issuing new specs. There is no defect reporting or Corrigenda process. Marc: If we say the words take precedence Proposed statement: The protocol message items are specified using English text in Section 3, as well as using XML schema in appendix A. In the case where a discrepancy is found between the English text definition and the XML schema definition, the xxx takes precedence. Straw poll: Who prefers the schema taking precedence - 5 Who prefers the text taking precedence. - 4 Jeff: if it is the schema you can extract the schema from the document and implement that. If it is the text, there could be more than one way to fix the schema. Jacques: what about further qualification in text which cannot be expressed in shema. Jeff: this is not a discrepancy. Example of conflict: - text says cardinality of 0 or 1 - schema says maxOccurs=5 Another example - schema says it is a string - text says it is an integer E.g, Text says cardinality 0 or 1, schema says min 0 max 5 -> use intersection of two for implementation. – lesser discrepancy E.g, Text says cardinality 1, schema says min-3, max 5 -> no intersection – major discrepancy. Leave the issue open for now. ----------- Homework: Jacques Dup of delivered. Group semantics RM agreement section. Iwasa – Come up with new edition incorporating as many changes as he can. Sunil – Faults discussion Descriptions of operations/patterns. Schema for WSDL annotations. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]