[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Prelim Wed Minutes:
attached are the minutes. -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133Title: *Proposed Agenda:*
WSRM Face To Face Proposed Agenda: 350 Oracle Parkway Conference Bridge
Call in Info: Each day ( Host:
Fujitsu Wed Jan 14: AM: Note: Roll call is on Wednesday Morning you must be present or on bridge to have attendance count for voting rights. 0 Draft AgendaWed Jan 14: AM: Note: Roll call is on Wednesday Morning you
must be present or on bridge to have attendance count for voting rights. PM a) Check
for usage of Optionality “SHOULD, MUST, MAY, etc” (Rel 22) b) Determine
candidates for Optional Implementation (Rel 29) Thursday Jan 15 AM: PM Friday Jan 16: AM: PM 1 Introduction1.1 Earliest Possible timelineTom Rutt displayed the following possible timeline Jan 27 – CD 1 7 day Ballot issued Feb 3 – CD 1 ballot closes Feb 4 – 30 day Review initiated March 5 – 30 Day public Review ends March 15, submit to oasis staff for member vote April 1 – Membership two week review April 15 – start member two week vote April 30 – member vote concludes. Earliest Oasis Standard. 1.2 Roll Call
1.3 Identification of input contributionsIwasa prepared a new spec Version updated with Sunil’s comments and some technical fixes to meet resolved comments. Doug asked that we use the 1-06 document, because his annotation were against that version. Doug uploaded a new version of the issues list, dated 2 Approval of 1/06 minutesSunil moved to approve the 1/6 minutes. Bob seconded. No opposition , minutes approved. 3 Discussion of Active Issues3.1 Rel 56, and 83 thru 86Jacques email sent on Here is a proposal for Rel 56, attached, for further review. It already reflects some earlier
comments from some of you (most from Doug). As for the former list of REL
83-84-85-86: REL 83: current proposed resolution
for R83 is assumed by R56, although parameter is renamed in R56. REL 84: current proposed resolution
for R84 is
assumed by R56, although parameter is renamed in R56. REL 85: propose to close without
action: not relevant anymore since we can guarantee to NOT deliver duplicate regardless
of scope (i.e. "forever", thanks to the semantics of ExpiryTime) REL 86: propose to close without action: REL 57 is
handling the termination of pending
out-of-order sequences. Any other reason to cancel an out-of-order sequences hinges on storage capacity, which
should be handled
separately (and in a consistent way across several other RM features. E.g. with appropriate Faults.) Jacques <<RM-agreement.txt>> REL 56: Proposal ================ Summary: - the
proposal is independent from resolution for REL 83-84-85-86, although we assume
here that REL 85-86 are dropped. (rationale to be sent
separately) - Instead of talking of
"configuration parameters", this proposal will talk more
abstractly (and more generally) of "reliability agreement items", or
RM-agreement items. - "RM-agreement items"
describe the reliability contract between parties. They cover both the RM parameters
that show up in the protocol, and those which do not (like
"retry interval", "number of retries"). This distinction is
not essential at this level. Some items may, at implementation
level, translate into configuration parameters for RMPs. - the
proposal is that the spec identifies and describes the RM-agreement items, so
they have a
formal existence independent from their protocol representation (as some do not appear in
protocol). This allows for treating all of them in a uniform way in the spec. The proposal does not mandate a
concrete representation. Later on, a formal representation
could be recommended (e.g. a policy language, an
agreement representation...) Detailed proposal: Reliability Agreement (or RM
Agreement): ----------------------------------------- An RM Agreement describes the set
of agreed contracts between: - a
Sending "application layer" and the associated RMP. - a
Sending RMP and a Receiving RMP. - a
Receiving "application layer" and the associated RMP. The way these contracts are
established or communicated to each party is out of scope, although
for the contract RMP-RMP, the assumption is that all the needed synchronization is
achieved through the message protocol, i.e. the Receiver RMP does not need
other input than
the message headers. The highest-level items of the RM
Agreement are the main RM features themselves: - Guaranteed delivery (or
at-least-once delivery): When a Sender application submits a
well-formed business payload to the RMP, the
agreement requires that either: (1) the payload
is delivered to the Receiver application, or (2) the
Sender application is notified in case of failure. - Duplicate elimination (or
at-most-once delivery): When an RMP delivers a business
payload to a Receiver application, the agreement requires that no
future business payload from a message with same identity as the message
containing the first
payload (GroupId and SequenceNumber
if any) will ever be delivered to the
Receiver application. - Guaranteed ordered delivery: When a Sender application submits
an ordered sequence of business payloads to an RMP, the
agreement requires that when delivering a business payload to the Receiver
application, all
previous payloads in the sequence have already been delivered. RM Agreement Items: ------------------- An RM Agreement is a list of
Agreement Items. An RMP implementation MUST be
capable of: (1) taking
knowledge (e.g. either via configuration, or via an API call, or via a message,
or via the
result of an algorithm) of a set of values that represent the RM Agreement
Items described
in this specification, (2) processing
them according to the semantics described in this specification. Some of these items will map to
some message header field, some will not. They are: - GuaranteedDelivery
(enabled/disabled): for setting
guaranteed delivery. - GuaranteedOrdering
(enabled/disabled): for setting
guaranteed message ordering. - AtMostOnceDelivery
(enabled/disabled): for setting message delivery without duplicates. - GroupMaxIdleDuration
(number of seconds): For setting the elapsed time limit
from the last message sent or received in a group, after
which the group can be terminated. - GroupExpiryTime
(number of seconds): For setting the
date and time after which the group can be terminated. - ExpiryTime
(number of seconds): For setting the date and time after
which a message must not be delivered to the
receiving application. - RetryMaxTimes
(integer number): For setting how many times a
message must be resent if not acknowledged. - RetryTimeInterval
(number of seconds): For setting the
minimal elapsed time between two re-sending of the same message. - ReplyPattern
("response", "callback", "poll") For setting the
mode of response for Acks or Faults. Messaging Scope of Agreement Items: ----------------------------------- The messaging scope of these
agreement items may be: (s1) All messages sent over a
connection between a Sender RMP and a Receiver RMP (default). (s2) All messages sent within a
Group. (s3) a single message, within a
group of several messages (non-singleton group). Some agreement items obviously
relate to a particular scope, e.g. ExpiryTime is
affecting each message separately, while GroupExpiryTime
is an agreement about groups. Such scopes are
"required" scopes that must be supported. The smallest required scope for
each RM agreement item is: Message scope (s3): - ExpiryTime - RetryMaxTimes - RetryTimeInterval - ReplyPattern - GuaranteedDelivery - AtMostOnceDelivery Group scope (s2): - GuaranteedOrdering - GroupExpiryTime - GroupMaxIdleDuration NOTE: although an RMP must support
each agreement item at the scope level above, the RMP
implementation may also provide a way to specify these values for a broader
scope. Example: an RMP implementation may
decide to provide a way to specify the ExpiryTime value for
all messages of a group. Rules about Agreement Items, when
used in an RM Agreement: --------------------------------------------------------- - If GuaranteedOrdering
is enabled for a messaging scope, then GuaranteedDelivery
and AtMostOnceDelivery
MUST also be enabled for that messaging scope. - If GuaranteedDelivery
is enabled for a messaging scope, then the items (RetryMaxTimes,
RetryTimeInterval) MUST also be
defined for that scope. - If GroupExpiryTime
is enabled for a messaging scope, then the item GroupMaxIdleTime
must not
be enabled, and vice versa. Jacques summarized that the notion of RM-agreement, without explicit representation in protocol, allows these terms to be used in the specification. Jacques moved to adopt his proposal. Bob seconded. If motion passes, this text will be put into the spec. Editoral changes could be incorporated later. No opposition. Motion passes. Close 56, 83 to 86. 3.2 Rel 49 WSDL annotationSunil Email: This proposal not only addresses
the main issue as mentioned in REL 49, but it also touches
upon the client side config that was mentioned in
other issues. I'd like to discuss this more at the F2F Salient points are:
* This should either be normative and optional (wrt
to compliance) or should be made non-normative. Oracle prefers former.
* Has 2 different schema elements. <service-config>
is defined for service side WSRM config to be used in
the Service WSDL. <client-config> element is
used for client side config to be used in vendor
specific client property/config file.
* <service-config> o Based wsdl extensibility elements concept. o Per
operation or per binding. Note that while wsdl 1.1 is
ambiguous about extensible elements under portType/operation,
BP does allow it. o This
extensible element can be either used in portType/operation
or binding/operation. If it has to be shared by all bindings, then it could be
used in the portType/operation [abstract part]. If
this (wsrm usage) is per binding, then it can be
defined only in the binding operation It can also be
used at the binding level directly, if it is common for all the binding
operations (note that extensibility elements are prohibited at the portType level though). o This
service element could be used inside any vendor specific policy elements or
directly. If used directly, one could use the wsdl:required (set
to true) attribute, to enforce the config element..
Once we finalize the schema, we could define them in the same schema we
are
defining for the WSRM SOAP Headers and use the
same namespace. Example of a <service-config> usage inside the operation 'foorBar'. <portType
name="fooPortType">
<operation name="fooBar">
<wsrm:service-config
xmlns:wsrm="some URI" wsdl:required="true"> <!-- Spec.
version> <wsrm:version>1.0</wsrm:version> <!-- We can
also have some kind of capability parameters <wsrm:batching-support> {true|false} </wsrm:batching-support> <wsrm:piggyback-support> {true|false} </wsrm:piggyback-support> --> <wsrm:guaranteed-delivery> <!--
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> true </wsrm:duplicate-elimination> <wsrm:message-ordering> true </wsrm:message-ordering>
</wsrm:service-config>
<input message="fooMessageIn"
/>
<input message="fooMessageOut>
</operation> </portType> Client side config
sample: <wsrm:client-config xmlns:wsrm="some
URI">
<!-- No. of retries to send for non ack. messages and
return interval --> <wsrm:retry-config> <wsrm:retry-count>5</wsrm:retry-count> <wsrm:retry-interval>10</wsrm:retry-interval> <!-- 10 secs
</wsrm:retry-config>
<!-- Can have only one such pattern. If the
pattern is 'Callback', the
reply-to attribute can also be used -->
<wsrm:reply-pattern
wsrm:reply-to="SomeURIToSendAcksAndFaults"> Callback <!—possible values are
Response/Callback/Polling -> </wsrm:reply-pattern> <wsrm:group-config> <wsrm:group-expiry-time>dateTime</wsrm:group-expiry-time> <wsrm:group-max-idle-duration>dateTime</wsrm:group-max-idle-duration> </wsrm:group-config> </wsrm:client-config> -Sunil Sunil summarized some issues:
If we decide on the general approach, we can refine the schema. Jacques: at high level this is to specify capability of a service with respect to Reliable message capabilities Sunil: others have used ws-policy for such things. Jacques – is someday a standard policy language is adopted we will have collistion. Sunil – this would be replaced by the WSDL 2 features and properties (F&P). Jacques: Some of thes capabilities may not depend on the web service itself , but on the deployment. Sunil: at abstract level it is less useful. It would be more useful at the port level (or perhaps binding). Sunil : it definitely would be optional. Tom: what requirement are we trying to solve here. Bob: I have a concern about finishing this in the 1.0 timeframe. I suggest postponing this beyond ws-reliability 1.0 as a future feature. We only have a few weeks to reach or committee draft status. Sunil: This thing is high level concept, once we decide the specifics are not that difficult. Bob: we should focus on fundamentals required to get us to 1.0. Bob: we should focus on getting a tightly specified document in the limited time we have. There are activites being started, WS-PL as part of WS-XACML Bob F suggestd to close the issue 49 be closed, and that the annotation be put on the “wish list” for future protocol versions. Doug: is the problem that this solution appears large at this late date, or whether it is addressing something separate from the raised issue. Bob: both. I would like to be able to use features which have not yet been adequately baked in standards committees. Doug: there is that and the WSDL 2.0 approach of F&P. Doug: how about a simple annotation: this endpoint requires the use of WS-Reliablity (or a list of the three Reliability features). Tom: thus the main requirement in R49 is to allow a WSDL service definer to specify which of the three QOS features are required to be used with a service instance. Sunil we would not put wsdlrequired true on these extensibility elements. The group decided to keep issue open for now, perhaps decide later in the week. Bob: we are on the fence about an optional feature, I would like to close now. Leave it open for now. 4 Walk thru of WS draft/ Schema to confirm reflection of completed resolutionsDoug: there are 6 accepted issues to check if they have been applied to the document. Iwasa and I can do this online. There are 20 completed issues to confirm that they are reflected in the document. We need to decide on moving from completed to closed. All in order: 4.1 Rel 14– in appendix c line 997 this is done 4.2 Rel 16- Issue resolution for (a) carried, will maintain MUST link between message ordering and use of the AckRequested element. Issue resolution for (b) carried, will maintain MUST link between message ordering and use of the DuplicateElimination element. Done in 3.2.3 – line 715 4.3 Rel 31– Meaning of Guarantee – done in 2.7. 4.4 Rel 32– editorial definition of reply patterns, done in section1.8 4.5 Rel 33– meaning of acknowledgement – done in definition of Acknowledgement message. However, the first paragraph now needs to be removed (lines 177 to 180) since the third paragraph is better. It was agreed to remove the first paragraph. This was reopened below. 4.6 Rel 36- Eliminate message id from WSRM headers, and use the groupID/sequence number as a concatenated unique ID for WSRM identity purposes. Note: The sequence number defaults to zero for senders that choose not to implement order delivery (though that does not help recipients). - Search for message ID Line 251 on page 9 , section 2.4 needs to have messageID fully spelled out. This needs another check by the editor. Question for group: is it worth linking, at least informally, from occurrences of message Identifier back to definition in 2.2. Leave this as requiring further checks. 4.7 Rel 37– Use of MessageID – agreed to make URI with rec for MID scheme. Done in Section 3.1.1, however rfcn 2392 does not appear in refs The
sentence” It is RECOMMENDED to use a syntax of Message-ID,
as defined in [RFC2392].” Agreed
to editorial change from “a syntax of Message-ID” to “the Message-ID scheme” 4.8 Rel 38– remove timestamp. There were some changes made in latest document. These will be closed later. Need to remove the timestamp fault 4.9 General Fault CleanupACTION: Need to endure faults in general being Cleaned up Sunil will try to get a proposal to clean up fault text before the end of the F2f.. 4.10Rel 40– time to live is change to expiry time, and made mandatory. There is a comment on 3.1.3, which it was agreed can be removed. The text states “delivery to the application”, where the definition of delivery uses “next processing entity”. In
3.1.3 we agreed to Change “MUST NOT deliver a received message to
the application.” To “
MUST NOT invoke the deliver operation for the received message.” Agreed
to change “modified in any case by Sender,” to “modified in any manner by the Sending
RMP” Sunil : the pictures show the rmp communicating with the receiving application. It was agreed to reopen Rel 33 to refine the definition of Message Delivery. 4.11Rel 33 reopenedPropsed to Change resolution to Rel 33: Doug: suggested: add “(application layer)” immediately after the term “next processing entity” in the definition of Message Delivery. Agreed as important editorial. Doug: either define application layer as next application entity, or redefine ack in terms which are visible on the wire. Eg: “message in ordered sequence is not acknowledge until all previous messages are acknowledged.” Doug: we could eliminate the need for formal definition of delivery. Tom: Maybe use the term delivery, informally, in the def of ack. But the formal semantics required for acks, should be defined directly. Doug: there is no way to test delivery. Doug: Two approaches 1) Define application layer, and use as we do in this spec. This is a little bit messy for a protocol spec. 2) Do our best to avoid discussion of Application layer matters entirely within a single system. Jacques: define a delivery operation that every Receiving RMP must support in some application manner. Then define, send ack after invoking this abstract operation. Tom: eg: Delivery – an abstract operation invoked by the Receiving RMP to transfer responsibility for Reliable message. Doug: delivery can be defined as some operation that transfers responsibility for message shifting from RMP to application layer. Doug: I agree that for ordered delivery, non ordered delivery of acks is not quite sufficient to cover the semantics we want. Doug: I like leaving the application layer in the spec, so that ordered delivery has a useful meaning. Jacques: we should define two abstract operations: Submit from application to sending rmp, and deliver from Receiving RMP to application. Tom: Delivery: an abstract operation (implementation specific realization) which is used by the Receiving RMP to transfer responsibility of the Reliable message to the application layer. Jacques: Require that the RMP invokes an operation called deliver. Then have examples (e.g, RMP transfers responsibility for the message to the application layer through an implementation specific mechanism, such as putting the message into persistent storage.) Proposal: add new definitions. Deliver: an abstract operation the Receiving RMP may invoke per Reliable Message (e.g, a request to the application layer to.take responsibility for the Reliable message). Submit: an abstract operation the Sending RMP supports, invoked per Reliable message (e.g., a request to the sending RMP to take responsibility for the reliable message. Notify: an abstract operation the Sending RMP may invoke per Reliable Message (e.g, a notification that the Sending RMP cannot insure that the Requested Reliability feature were realized) Everywhere else use words “deliver operation invoked” to describe the action of delivery. Change first sentence of definition of Message Delivery to “Message Delivery: Message delivery is the action of invoking
the deliver operation for a Reliable Message. “ This is a new resolution to Rel 33. The group also agreed to add labels of these operations to the arrows in Figures 1, 2, 3. 7. 8. and 9. Remove the arrow showing a receiving app invoking an operation on the Receiving RMP. 4.12Rel 44Senders must not reuse message IDs Doug: We need to add statement in definition of group id that states it must not be reused. Change second sentence of 3.1.1 from: “This element MUST have a globally unique
identifier as its value.” To “The sending RMP MUST use a distinct globally unique Group ID for any distinct Group of messages. Any group of messages will have a common Group ID value” Action: Iwasa to apply changes, then we will change status after done. 4.13Rel 50 Semantics of Expiry TimeIwasa incorporated the email from Tom, verbatim into the document. Agreed to close this issue 4.14Rel 51 Message PiggybackingProposal: Enable acknowledgement piggybacking by removing the distinction between Reliable Message and Acknowledgement Message. Specifically: 1) Remove the MessageType element. – This was done 2) Any RMResponse element could coexist with other elements." Change “is containing” to “contains” in definition of message Acknowledgment. There are problems in English phrasing in four lines: “ This
Response element can co-exist with Request element, and it enables to send back Acknowledgment message with the business response to the original
message. It also enables the receiver sending an another independent message
to the sender with an Acknowledgment message to reduce network traffic. “ to “A
Response element can coexist with a Request element, enabling the combination
of an Acknowledgment message with the business response to the original
message. This coexistence also enables a receiver sending another independent
message to the sender with an Acknowledgment message (e.g., to reduce network
traffic).” Doug: we need to globally change (as part of rel 22) the tables “ required – no” to “cardinality – 0 or 1”, and “required – yes” to “cardinality – 1”. 4.15Rel 52 New rules for persistenceMessage 70 in December had the agreed resolution. This added all the new timing rules, and termination stuff. Section 2.5. and parameters are defined in section 3. Doug: it would be better to move abstract definitions for the group termination parameters to section 2. Section 3 should simply state that the “xxx” attribute”corresponds to the abstract definition in section 2. Move everything after table in 3.1.1 (lines 546 thru 571) into a new section 2.5.1, after the lead in text, pushing the rest of 2.5 down. Change: “ A
request message MAY contain one of the following group termination parameters: –
a groupExpiryTime
attribute –
a groupMaxIdleDuration
attribute “ To: “ A
request message MAY contain one of the following Attributes
corresponding to the group termination parameters specified in section 2.5.1: –a groupExpiryTime
attribute –a groupMaxIdleDuration
attribute “ Agreed to add new issue to update Section 2.6 “message persistence”, now that we have resolved the timing parameter issues. Mark Rel 57 as closed. Leave Rel 53 open until we verify that the changes are complete. Action: Iwasa is to produce a change barred version of all the changes made from the 1-06 document. Use compare documents under Edit to do it. 4.16Rel 58 Namespace Identifier updateDone in 3.0 an also in the schema. Agreed to close this issue. 4.17Rel 82Agreed to close as resolved by resolution to timing parameters. 4.18Rel 87Fixes to resolve Rel 87 are in Sunil’s comments in his email from 1/06: Technical Change second 3.3.1 to 3.4.1 and fix is sub-clause numbers as well. Delete “(to be added)” from 3.3 and
3.3.1 - Section 3 (Message Format).
- replyTo is not an
element rather an attribute of ReplyPattern (pgs. 15
& 16) - AGREED
- For PollRequest, GroupId
is a required element (minOccurs = 1) (pg. 16) -
AGREED - Section 3.1/Table1 (pg. 17)
- Timestamp should be removed from the child elements. It was removed
when - AGREED
- Many more Faults to be added - SUNIL Took Action item to complete
this. - Section 3.1.1/Table 2 (pg. 18)
- Add InvalidGroupParameter fault to the table
(also change INVALID_GROUP_PARAMETER to InvalidGroupParameter
on line 555) - AGREED,
but this will be in the new section 2.5.1 - Section 3.3.1/Pg. 24
- GroupId under PollRequest
is different from GroupId in MessageHeader
in 2 ways. i) It has zero
or more SequenceNumberRange elements - AGREED ii) It also has an attribute called
'value'. it's type is the same as the type of GroupId in MessageHeader - AGREED (because of
REL-94)
- Section 3.3.1.1/SequenceNumberRange
- It has 2 attributes called 'from' and 'to', both of type unsignedLong (pg. 24-25) (because of REL-94) - AGREED to ADD two
new attrbutes
- Section 3.4/ResponseElement (pg. 25). - Response Element has only one child element called RefToGroupId. – AGREED to delete ref to seq no range in table and delete line 747
- Section (now 3.4.1/Table 14 (RefToGroupId/pg.
26)
- Should have a new attribute called 'value' - AGREED
- RefToGroupId has an attribute called 'value'
of type MIDType and can have zero or more RefToSequenceNumber elements. - AGREED - Section now 3.4.1.1/Table 15 (RefToSequenceNumber/pg.
26)
- Should have 2 new attributes called 'from' and 'to', and no value -
AGREED These agreed changes resolve Rel 87. Delete (needs updating ) from the new section 3.4.1 section and subsection headers. 4.19Rel 88Agree it has be implemented in the spec. Agreed to Close it. 4.20Rel 94 – Polling supportTom: does it clearly state that the poll can only be done for messages which were originally send with this pattern set. Sunil: it does state this. Need to add a section about polling in section 2, with the model. Sunil: there is no general section on the model for polling. The header elements are properly defined in sections 3.3 and 3.4. ACTION: Sunil took action to come up with additions to the model text for section 2.1 by Friday. Left open until modeling text is complete. 4.21Rel 98 – sequence number usageThe informative note in second para of 2.4 was questioned by the meeting. “ Informative
NOTE: It is recommended that an RMP removes the ID of a singleton message (message with GroupId but no SequenceNumber) from its persistent store after it expires. However,
unlike for singletons, it is recommended to not remove the ID of a message that belongs to a non-singleton group, when the message
expires. The reason is that message IDs for groups can be stored efficiently as intervals of
integers. When doing duplicate checks for messages of a group, there is no loss of performance in
checking over all past message IDs of the group, whether expired or not. The check will in
fact be faster, because not discarding expired IDs means fewer intervals to look up. ” Jacques agreed that the informative not is not needed with normative text. It could go in implementation guidelines, but we do not have them. AGREED to remove the informative NOTE. Doug:: a message that does not contain a sequence number is semantically identical to a message containing the explicit sequence number zero. Tom: need to update section 2.10 to correspond to 3.1.2. Sunil: everything is based on existence of sequence no. Doug: my real concern is that you are allowed to leave sequence number out, but the conditions are not clear. Tom:
Tom: For interoperability, all receivers MUST be able to handle sequence numbers for non-ordered messages. Doug: I agree with this statement of Tom. Tom: For interoperability, all receivers MUST be able to handle non-ordered messages which do not use sequence numbers. Doug: the sender is deciding whether this “optimization” is used, even though the receiver benefits. Doug: eg. Sun version only uses sequence number for Ordered delivery. Fujitsu Receiver RMP works much more efficiently when ordering is used. In this case the sun sending implementation would make the Fujitsu receiver work very inefficiently. Doug: we are describing an allowed optimization. Some senders may choose to generate a new group ID for each un-ordered message, and they would conformant. The simplest sender may not want to maintain the state of the last sequence number used in each group. This could be a significant cost for some minimal sending implementations. It is easier to generate global unique ids, not being concerned with separate integer sequences per group. Tom: A receiver implementation must be able to deal with singleton groups for non-ordered messages. Doug: Any receiver implementation of an optimization for un ordered groups is not likely to be exercised, given that may senders will not implement sequence numbers with un-ordered group. Jacques: Agree that there is no way to enforce the sender to use sequence numbers for non-ordered delivery. However, if the sender and receiver agree together to use the feature, it would be realized in practice. The last sentence in 2.2 is incorrect: “ Presence
of SequenceNumber indicates the Group has more than
one message. ” Replace with “SequenceNumbers are required only for groups that have more than one message. Doug: what is def of group. Bob: a group is a collection of one or more messages with the same group ID. Doug: then there can be groups of one. Doug, there are semantics we do not capture in the text. The sequence numbers when used must be unique within the group, and monotonic. We do not say that no two messages in a group can leave out the sequence number. It needs to be stated “ Groups with more than one message must have the sequence number included for all messages in that group. “ One logical place for this text to go is 2.10. This needs to be consolidated with 3.1.2 text on sequence number. Bob: some of this belongs in 3.1.2, other stuff is in 3.1 The section about groupID needs to be enhanced to discuss the definition of group and its use of sequence numbers. Jacques- we could have a section to define groups in section 2. ACTION: Jacques will make a proposal to fix these group semantic concerns. Doug has another schema issue with the messageID structure being a sequence with two elements, while the ref to group ID is different. Have sequence number be a child of group ID would allow more expressive schema. Currently: “ <xsd:element
name="GroupId" type="wsrm:GroupIdType" /> <xsd:element name="SequenceNumber" type="wsrm:SequenceNumberType" minOccurs="0" /> “ Doug proposed to unify the schema for the message Id with the schema for the refs. Agreed to change “SequenceNumber” to “SequenceNum” Agreed to keep name of the attribute of a new messageId element “groupId” Change name “RefToMessageID” to
The winner was RefToMessageID. Action: Jacques is to 5 Editorial CleanupSunil sent the following email against the 1/04 draft: Hi Iwasa, Editorial: - The Termination conditions (in pg. 11) uses GroupExpiryTime and GroupMaxIdleDuration.
It should be consistent with the actual attribute names (starting with
lower cases). - When attributes are mentioned in the Table,
please list their types. Ex. status (string) - ReplyTo attribute
(in Section 3.1.4/pg. 21) should be replyTo (all
attributes start with lower
case). - Please add the schema as an appendix - Section 2.4/Line no. 259.
It should read "after the message has been processed and delivered
to the "next processing layer". - Figures
new definitions. - All the new terms such as Group Termination,
Removal, Complete etc... should be defined
in the terminology section Thanks, -Sunil AGREED to accept these editorial comments 5.1 General Parameter Name Cleanupe.g. ID, Identifier, Number, etc. Agreed to add a new issue 6
Discussion of
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]