[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Prelim Minutes of WSRM TC f2f from Wednesday
alttached are the prelim minutes from Wednesday. There will be a new Requirements Document posted tomorrow, reflecting the comment resolutions from today. It is the intent to have a vote on friday morning teleconf to progress this as a TC WG draft, available for public review. The meeting was not quorate (2 members missing) so we need to vote on pending resolutions on the friday call. The wednesday minutes will not be sent tomorrow, only the thursday additions will be sent tomorrow. Tom Rutt WSRM Chair -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133Title: Prelim Minutes WSRM F2F Wednesday:
|
Prelim Minutes WSRM F2F Wednesday: 1 Roll Call
Monday morning is not quorate (28 voting members, need 15 voting members present) thus all resolutions will be recorded as pending. We will need a block motion on Friday morning to approve all pending resolutions in the minutes sent out on Thursday. 2 Admin2.1 Review of AgendaThe proposed agenda was approved. Here
is the proposed agenda: Friday
Meeting will close at Dial-In
numbers: Toll
Free - : 1-800-605-5167 International
- : 1-719-457-0339 Passcode:
732072 *Proposed
Agenda:* Wednesday:
AM: PM Thursday:
AM: PM Friday:
AM: The
following will be available for participation by teleconference: 2.2 Input contributions:WSRM Requirements – 0.8 WSRM Issues List – Aug 28th WSRM spec version 0.5 – Sep 2 Various WSRM Emails 3 Minutes ApprovalNot quorate, wait for Friday teleconf 4 Resolution of outstanding Requirements Issues.4.1 Issue 56 – Describe configuration info in spec.Jacques Durand provided the following proposal for an annex to the spec (separate issue on the name for TimeToLive). Discussion items from the meeting are in italics (non indented) Rel 56: ---------------------------------------------- 1. Maximum message lifetime/duration Discussion: determines upper bound on message
expiration time interval ,from date it is sent SUMMARY:
Set an expiration time for any
message, when no TimeToLive was set. (PREVENT
INDEFINITE/ NEVER ENDING MESSAGE EXPIRATION) REQUIREMENT: There
are two issues with messages for which TimeToLive has
not been set, in terms
of persistence handling: (1) on receiver side, messages may persist a long time in the
receiver store if "unclaimed" by the application, or application
unavailable (e.g shutdown). (2) on the sender side, message removal is normally controlled
by the Ack and resend mechanism. However,
e.g. in some cases of long shutdown, messages do be [re]sent should be
considered as too old
and not be processed anymore, to free resources for new messages. In
both cases, an RMP needs input to decide when it is time to discard an
"old" message from the
store, and to notify the loss. PARAMETER:
MessageMaxPersist
(perhaps have it be Default TimeToLive) MODE:
mandatory SENDER
HANDLING: remove from store all messages as specified in spec 2.2.3, or else
if no TimeToLive specified, with (sending date + MessageMaxPersist) > currdate. RECEIVER
HANDLING: remove from store all messages with either: TimeToLive
> currdate, or if no TimeToLive specified, with (sending date + MessageMaxPersist) > currdate. SCOPE:
apply to all received and sent messages. COMMENT:
- this parameter is mostly meaningful for message store
management, and is common to
messages for all connections Sender-Receiver. Is
equivalent to a "default" TimeToLive,
except that it does not rely on setting a default TimeToLive in messages (which requires all
Senders to do so and cannot be controlled by a Receiver). - as only applies when TimeToLive is
not set, will be override by TimeToLive. RELATED
POLICY ISSUES: Need
to decide (need a config param
for this?): - in case of persistence failure (no more room in store),
either new messages should be
bounced, or older messages be flushed. Discussion: We need a Fault for the receiver to return if the time
to live specified in the request is greater than the maximum time to live the
receiver is willing to accept. Another question:
why is the time to live parameter optional. If timeToLive was mandatory
to be sent with each reliable message then there would be no need for a
“default” time to live. Rejecting a message you are not willing to persist
would be based on a Maximum Time to Live (perhaps only visible through fault
message). Discussion Item: A Config parameters is only to be included the spec if that parameter
affects the observable behaviour of an endpoint using
the protocol. Issue: If spec
has a config parameter specified, there must be a way
whoever is using the configuration parameter. ---------------------------------------------- 2. Maximum message group (or message sequence)
lifetime SUMMARY:
Provides criterion for removing
group data from RMP store (PREVENT INDEFINITE/
NEVER ENDING MESSAGE SEQUENCE EXPIRATION) REQUIREMENT: Sequence
of messages (identified by GroupId) may be started,
yet not ended. In
case no message is sent with @status="end" or if @removeAfter
is never set, many sequences
may remain indefinitely open, tying up system resources. In
such case, we can either (a) set an overall max duration for all sequences, or (b)
set the max elapsed time between two messages of a sequence, so that when a
sequence is "inactive" beyond this time, it will be assumed it has
ended. Because
it is sometimes hard to estimate the max length of some sequences (some may be very long, or even never ending by nature, e.g.
a monitoring flow), we'll use
a parameter for (b) which seems also more intuitive. Discussion: Limiting the idle time between messages in the
sequence, allows the receiver to determine that the sequence is retired. The current protocol has a status in the sequence to
signal the last message in the sequence. If sender goes away, how long does the receiver wait
before it closes the “sequence”. Do sequences only close if the sender sends the “last
message” indication. Regardless of default time to live, there is a need to
cap max time to live on receiver. An error (group shut down by receiver) might be
required for use when the receiver gets a sequence member for a groupID which the receiver has shut down. PARAMETER:
GroupMaxIdle MODE:
mandatory SENDER
HANDLING: tracks for each group the elapsed time since last sending for the
group. Remove
the group data if elapsed time > GroupMaxIdle. RECEIVER
HANDLING: tracks for each group the elapsed time since sending date of last
message received for this group. Remove the group data if elapsed time > GroupMaxIdle. If
some unordered messages of this group were still awaiting to be passed to the
receiver app, then pass
them, and send error notice for the missing ones. SCOPE:
apply to all groups of all connections (sender/receiver) COMMENT:
3.
If one wants this
to apply only when “removeAfter” has not been specified, then Spec
3.3.1 should not consider “removeAfter” default =
forever. If
we consider the default is “forever”, then this idle time limit policy should apply
also to any group, which may be brutal, as cannot be override. 3.
Resend interval
(SEE REL 47) SUMMARY:
defines the elapsed time before
resending a non-acknowledged message. REQUIREMENT: When
guaranteed delivery is required, need to set the time to wait for an Ack before
resending the message. Assume
this is specific to each Sender/Receiver connection. Discussion: Does the sender have to have this be a fixed
parameter? It could be implemented as a
“soft” parameter which the sender could change by time of day, or by traffic
load. We need a use case for why the receiver needs to know
this parameter. Scott W stated that the
minimum retry interval would be useful for the piggyback implementation. Could it work if the receiver did not know
this parameter (yes but would give more traffic). It is necessary if we can find a benefit for the
receiver to know this. PARAMETER:
RetryInterval MODE:
mandatory when guaranteed delivery is
requested. SENDER
HANDLING: used to schedule the resending: minimum elapsed time before resend. RECEIVER
HANDLING: none. SCOPE:
apply to all messages of a connection
(sender/receiver) COMMENT:
-
could be used as a base-interval if a more complex interval algorithm is used
later. - it is important to define the scope: if specific to a
connection Sender/Receiver, an RMP
will have to manage a parameter for each connection, vs. just one for all
connections. ---------------------------------------------- 4. Retransmission count (SEE REL 47) SUMMARY:
define the max numer
of resent non-acknowledged messages, before generating
a delivery failure. REQUIREMENT: When
guaranteed delivery is required, need to set the max number of times a message will be
resent if not acknowledged (from 0 to N), so that a repeated failure to send will not
tie up processing and storage resources in the Sender, and will be notified to sender
application in a timely manner. Assume
this is specific to each Sender/Receiver connection. Discussion:
This parameter would be a nice thing for the receiver to know. However it is not required for the protocol
to work. PARAMETER:
RetryMaxNumber MODE:
mandatory when guaranteed delivery is
requested. SENDER
HANDLING: Used to limit the total number of message resend. RECEIVER
HANDLING: none. SCOPE:
apply to all messages of a connection
(sender/receiver) COMMENT:
- it is important to define the scope: if specific to a
connection Sender/Receiver, an RMP
will have to manage a parameter for each connection, vs. just one for all
connections. ---------------------------------------------- 5. Duplicate search scope (minimum number of
past messages to look-up) SUMMARY:
Defines minimum size of set of past messages to be considered for a duplicate
search. REQUIREMENT: Duplicate
search cannot be guaranteed over all previously received messages. It
is necessary to clarify the limits of the duplicate search, either in number of past
message IDs to look-up, or in terms of past date. The
trade-off scope of search / performance can also be adjusted and prevent doing exhaustive
expensive duplicate search over large logs of non-relevant message IDs. Discussion: Receiver cannot do a global “exhaustive” search for
duplicate messages. Payrits: This will change the definition of
“duplicate” elimination. Sunil: Can we keep the protocol simple, to assume that
the duplicate elimination is not limited in such a way. PARAMETER:
DuplicateSearchSetLimit,
DuplicateSearchTimeLimit MODE:
Mandatory if duplicate elimination
required. SENDER
HANDLING: none. RECEIVER
HANDLING: will limit (but guarantee) the search of duplicate over a number of
past message
IDs equal to DuplicateSearchSetLimit, or over the
past messages until the date defined
by (current date - DuplicateSearchTimeLimit). SCOPE:
apply to all messages of a connection
(sender/receiver) for which a duplicate elimination
is required. COMMENT:
- in case both parameters are also specified, the search is
limited by whichever defines
the larger set. - it is important to define the scope: if specific to a
connection Sender/Receiver, an RMP
will have to manage a parameter for each connection, vs. just one for all
connections. ---------------------------------------------- 6. Unordered messages window size (max number of
messages to hold) SUMMARY:
Defines max size of set of unordered received messages, before taking action
(notify, pass messages to application) REQUIREMENT: If a
message is missing in a received sequence, the Receiver may have to store a very
large number of messages, and delay their passing to the application in a damaging
way (a messages may loose value way before reaching its TimeToLive).
Relying
on the store capacity to decide of the size of this window is crude: space
resource may not be well allocated between several broken sequences. Discussion: Scott has homework on semantics of non-received
message in an ordered group. TimeToLive minus epsilon could be the trigger for
this decision by the receiver. This problem might require a configuration
parameter. Payrits: This could be an api issue, not a protocol interop
issue. PARAMETER:
UnorderedWindowSize MODE:
mandatory if Ordering required. SENDER
HANDLING: none. RECEIVER
HANDLING: When the unordered section of a particular sequence exceeds UnorderedWindowSize, Receiver
will notify of the unreceived messages, and pass all
pending messages to the application. SCOPE:
apply to all messages of a sequence / GroupId. COMMENT:
-
should the “reduction”
of an unordered sequence be lternatively controlled
by a time-based limit? RELATED
POLICY ISSUES: -
Behavior of
Receiver after a broken sequence has been reduced by reaching window size, is TBD:
keep ordering the rest? Give up? RMP-specific
resource capabilities: (TBD) These
parameters are not reflecting an RM agreement, like the previous ones. Rather,
they define the “profile” of an RMP, in terms of: - persistence capability (may include also some tuning info
such as MessageMaxSize, MessageAvgSize) - types of MEPs supported -
WS-RM spec options supported (e.g. sync/async) - alternative transport bindings supported (besides HTTP), RMP-specific
behaviors: (TBD) - recovery actions to be taken on failure and/or failure
recovery (power outage, no-ack count
expired, crash tolerance, etc). -
level of failure notification. General
RM agreement parameters: (?) These
parameters would represent the RM agreement, and would be interpreted by both
Sender and Receiver RMPs. Could be override by header
data: -
Duplicate elimination -
Guaranteed delivery -
Message Ordering <end of J. Durand email> The Discussion went back to
the Requirements Issue. The spec will describe semantics
of parameters. Alan: there are two types of parms: 1) those
needed to be know for protocol to work properly (e.g. expiry time) 2) those
as optimization or api parameters which only need to
be known by one side. Proposed requirement
statement: The spec will describe the
semantics of Reliable Message Processing Parameters that affect both sides of
the protocol. Need to generate a new spec
issue for each of the 6 parameters from the J. Durand proposal. Agreed to
Pending resolution of Rel 56 as closed with the above
requirement to be added to requirements doc. 5 Requirements review.Jeff M suggested that after
resolution of comments on the existing Requirements Document, we can vote to
make it a TC draft, to post on Kavi as status of
Working Group Draft Document. Doug: Once the WG draft is determine, we still need
to have a way to progress new comments and resolutions on the wg draft. Tom stated that the agenda
states that we will have a TC approved Requirements document by Wed afternoon. Jeff suggested we make the
requirements a working group draft by the end of this meeting. This means generally approved by the TC. Tom asked what the status of
the requirements document would be.
Should it be put on the public comments list before the spec is approved? There was general agreement
to make it available to the WSRM-comments list out of this meeting. It was determined that Kavi will make any document marked to be available to the
public, available to the public. The goal is to progress this
document from editor’s draft status to WG draft status. We will close all completed issues for this
requirements document. We will make the
document available to public. 5.1 Section 3.2 DefinitionsSunil suggested that the ack binding pattern definitions be modified to state the
pattern is for acks and faults. Agreed to
make this change. Agreed to change
“Acknowledgement Binding”
to “RM-Reply” wherever used in the document. 5.2 Mapping of oneway mepIn 5.1, Sunil wants to take away the association of oneway MEP to Request/Response MEP in the diagram. Doug B asked why we need the diagram, given the text in section 5.3. Sunil pointed to Requirement 3.3.1: R 3.3.1 – Sunil wants to change “MUST” to “MUST NOT”. Application mep of one way cannot have a response for the application. Sunil stated that for one way MEP at application layer, the RM-REPLY must be received on a callback or through polling. The WSDL contract, by WS-I BP 1.0, makes this required. Payrits stated that if WSDL is not being used for application contract, this would not be a problem. Sunil stated we cannot change the user’s WSDL, which is the contract for the service. Since we are using the WSDL definition for mep, we should consider it in our use. If we wanted to describe our headers in wsdl, it could not be done with Oneway wsdl mep, since it allows on output message parts. Jeff M pointed out that Sunil’s point is that if we ever want to use WSDL to describe our headers as message parts, we could not do that with WSDL Oneway, since it has no output message to place the reply headers in. Straw poll: Change 3.3.1 “MUST SUPPORT” to “MUST NOT SUPPORT” Doug suggested deleting 3.31 as an alternative. There was additional discussion on how to reform the requirements in this area. Change 3.2 3.3 and 3.4 with the following two new requirements: The spec must support the one way Message exchange pattern using both of the following: - Callback RM-Reply pattern - Polling RM-Reply pattern The spec must support the request response Message Exchange Pattern using all of the following: - Response RM-Reply pattern - Callback RM-Reply pattern - Polling RM-Reply pattern Payrits: We want to support WS RM for services described as WSDL one way and WSDL request response. New wording: Spec must support WSDL 1.1 one-way operation type Spec must support WSDL 1.1 request-response operation type. Spec must support response rm-reply pattern for oneway or request response operation. Spec must support callback RM-reply for one way. Spec must support polling RM-reply for one way. Discussion of 7.3.1: This requirement if for the polling for reply case. Agreed to delete 7.3.1. Editor shall fix the picture or delete it. 5.3 Basic profile requirementAdd basic requirement for supporting WS-I Basic profile. 5.4 Req 4.1The sentence in 4.1.1 is is required. R4.1.1.1 should be made the same level as R4.1.1. 5.5 R5.4.3Need to fix the wording of 5.4.1 and 5.4.2. Change 5.4.3 to be compatible with new decisions. 5.6 R6.2Iwasa stated the requirement needs to be fixed. This came from issue rel-7. Agreed to put in text from issue rel-7 resolution. Response from non RM node to RM request will most likely be an HTTP fault response. 5.7 Rel-5Failure recovery definition: The definition agreed to did not make it into the document. Agree to fix the requirements as indicated in Rel-5 resolution. 5.8 Rel – 6Doug asked: Do we need a definition for persistent data? Is persistent data connected to persistent storage? Both are not required. Leave requirements alone. 5.9
Req 7.2.1
Doug B stated this was not agreed. “Every implementation must be able to receive multiple acks and may be able to send it” May 20 minutes 2.5 is where it came from. Doug suggested that 7.2.1 is an implementation issue. It does not belong as a requirement. Doug asked if we need a requirement to reduce the number of implementation options in the spec. Tom Rutt example: “The semantics of spec options must be specified in such a manner, as to avoid interoperability problems.” One example of a spec conformance requirement to guarantee interop: “if there is a parameter which is optional so send, all receivers must implement the ability to receive that optional parameter.” The alternative is to have a fault the non-implementing receiver can return to indicate it does not implement. Discussion on deletion of the R 7.2.1. Agreed to add new requirement to requirements document: “The spec must have a conformance section which clarifies what is required to claim conformance to the spec.” Agreed to delete R 7.2.1. 5.10R7.4Doug stated this is not a requirements issue. This is a specification issue which has been resolved and agreed. Agreed to remove R7.4 from requirements document. 5.11Requirements wrapup.Payrits agreed to produce a new version of the requirements, to reflect the comment resolutions above. He will provide the new doc, with a list of the changes
made, for approval to progress as wg Draft for pubic revied, at the Friday morning teleconference, 6 Discussion of Spec Issues:6.1 Rel 22 – Optionality in SpecEmail discussion: Dock, Maybe a revisit of why something
might be optional: Here is a proposed resolution for
Rel22: Email from Martin Sachs: IMHO, the word "optional" must only be used where optionality for implementation is intended. RFC2119 is specifically about optionality for implementation. For any other uses of "optional", other words should be found instead of using the word "optional". Please also be aware that while use of the RFC2119 words in capital letters has become a common practice, RFC2119 does not require the use of capital letters for those words. Therefore, the use of lower case (e.g. "optional") when the word is for purpose other than optionality of implementation violates RFC2119 and will cause confusion. Regards, Marty There was discussion the keyword “optional” in Xml Schema definition language. They did not refer to rfc 2119. Strongest statement: “Receiver MUST be able to receive and process correctly all possible inputs defined in the protocol” This would guarantee interoperability. It is stronger than SOAP “mustUnderstand” = True. Weaker statement as a Fallback: spec describes which protocol inputs must be received and processed correctly, and which can allow returning a fault message. OPTIONAL on sending: the sender does not have to demonstrate the ability to send the parameter of initiate the feature. The sender of a reply is the server. An example: the use of queryStatus message might be OPTIONAL. When we use the word OPTIONAL (or MAY be present) use it as in 2119. Use a different word when we want different semantics. Doug stated that ebXML messaging spec qualified the scope, so it was not for the overall system “OPTIONAL for a message”, rather than “OPTIONAL for Implementation”. Text from 2119: MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) Agreed to have group examine every use of the word optional on Thursday, while going thru spec. Meeting closed for day at |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]