[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Preliminary Minutes of 8/3/ teleconf
I will be posting these minutes tomorrow morning, since I will not have internet access until next tuesday. Please post any corrections before tomorrow morning. tom Rutt -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133Title: Draft Agenda to WSRM TC Conference Call – May 06, 2003
|
Preliminary Minutes WSRM TC Conference
Call – The meeting of the WSRM TC took place by teleconference 1
Draft
Agenda:
1 Draft Agenda to WSRM TC Conference Call 2 Roll Call 3 Minutes Discussion 3.1 Appointment of Minute Taker 3.2 Approval of previous meeting minutes – 4 Action Item Status Review 5 Discussions of unresolved comments 6 Scheduled Vote for CD (only if all comments are resolved and we are quorate, else we could initiate a Kavi 7 day ballot, or wait till Aug 10) 7 Scheduled Votes for further progression (only if CD is voted yes) 7.1 Vote on whether changes from CD .992 are substantive 7.2 Vote to Submit to OASIS for member vote (subject to no vote on 7.1)) 7.3 Vote for second 30 day public review (subject to yes vote on 7.1) 8 Discussion of document progression and future meeting schedule 2
Roll
Call
Attendance: Meeting ?? quorate. 3
Minutes
Discussion
3.1 Appointment of Minute TakerTom Rutt will take minutes. Minutes will serve to record issue resolutions. 3.2 Approval of previous meeting minutesThe minutes of the July 27 teleconf are posted at: http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/8384/MinutesWSRMTC072704.htm Iwasa moved to approve, Bob F seconded. No opposition, minutes are approved. 4 Status of Action Items4.1 Action 052503-1 (Tom Rutt) pendingTom took an action item to complete the status column of pre public review issues list, with correct URLs.
4.2 Action 060104-5 (Jacques) PendingAction: Jacques, will propose further edits, on the FAQ for composability. Still open, low priority 4.3 Action 070604-1 (Anish and Doug B) ClosedAction on Doug and Anish to come up with a proposal before the end of the week to resolve the schema for references. Included in Spec 5
Discussion
of Issues and editorial Comments
The following issues list includes items which
have been resolved as of the output of the Additional
issues and comments were circulated to the list for discussion. These
need to be resolved before we can vote on a next CD. The editing team posted draft 1.07 to the server which resolved the editorial action items from the 7/29 minutes: http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/8413/WS-Reliability-2004-08-02.pdf Doug posted the following Document, which explains the editorial action items which were incorporated into Draft 1.07: http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/8409/ListOfActionItemsAndStatus-2004-08-02.pdf Doug B posted the following email, with a list of open issues for discussion: · What changed in 1.07? This has identified issues to be resolved by the TC. 5.1 MP8· RE: [wsrm] About MP8 Subject: RE: [wsrm] About MP8 * From: Jacques Durand
<JDurand@us.fujitsu.com> * To: wsrm
<wsrm@lists.oasis-open.org> * Date: Title: RE: [wsrm] About MP8 About MP8: Frankly
, re-reading B6 in Appendix B, I think we would
save ourselves some trouble by just deleting B6 and replacing it by a simple
note in B.5 that "not all agreement items need be mapped by a property (e.g. GroupExpiryTime, ... etc.)" For
a starter, the "property" definition in B.3.3. (repeated from
B.1) includes association with "WSDL element" (although a doubt
remains whether this is only the RM Capabilities that are associated with WSDL
in this def, but other places suggest the initial assertion is true). The way
property is referred to in B.6 (to define the kind "sender
properties") seems to counter this definition, and that is confusing (when
deriving from a former definition, you can specialize/extend it, but not
invalidate it like this). Then I am not sure
what B.6 brings here, except confusion: where would these "other (sender) properties" be represented if not in
WSDL? what is the use case for this? we don't even know
if these should be represented in a static XML doc, or better off be
dynamically calculated, like message ExpiryTime which
may partially depend on network conditions. Intuitively, these sender
properties may be relevant to some RMP configuration, but that is
implementation specific. For example, ExpiryTime may
result from some combination of a "static" value representing some QoS, and of a network-defined parameter. The part that is
then defined in a "property" document has then a different meaning
from the final ExpiryTime
result/duration. Also, the expiry
times as currently defined in our spec, are dates and
not durations, and it is a bit
confusing to say that their property counterpart must be "durations" (and this is a MUST because this section is normative though
optional...) SO I am for simply
removing B.6., I don't think we would loose anything: on the contrary, it is
premature to figure what proerties are needed that
are only specific to the Sender side. Sorry for the late wake-up... Jacques Jacques stated he has a wording with this B6 section. It might be fixed, but it would be better to eliminate this section on sender side properties. The two subsection sections included are close to implementation concerns. Alan W supported this, as such material should be in the implementers guide. Sunil has no problem with it. Doug pointed out that the client side agreement elements are in the schema. Jacques moved to remove section B6 and to delete these client side elements from the schema, Iwasa seconded. No opposition motion passes. 5.2 CF4· RE: [wsrm]
Proposal for CF4 · Proposal for CF4 · Re: [wsrm] Proposal for CF4 Subject: RE: [wsrm] Proposal for CF4 * From: Jacques Durand
<JDurand@us.fujitsu.com> * To: "'Doug Bunting'"
<Doug.Bunting@sun.com>, Jacques Durand <JDurand@us.fujitsu.com> * Date: Title: RE: [wsrm] Proposal for CF4 Doug: agree with most of your
improvements below. This section needs a bit of discussion though: >I suspect the
entire list of resend termination cases results in group >termination
for an ordered list. Is the Receiver
RMP required to use the >GroupAborted fault in that case or should the clarification
mention that >group
termination of an ordered group happens in all cases of resend >termination? Now that you
suggest this, I would favor sending GroupAborted
fault (in addition to the precise message fault) whenever the Receiver
considers that further resending will not help to recover from this. This is
more explicit... in all other cases,
the groups will terminate by normal expiration of pending out-of-order
messages. Jacques -----Original
Message----- From: Doug Bunting
[mailto:Doug.Bunting@sun.com] Sent: To: Jacques Durand Cc: WSRM (E-mail) Subject: Re: [wsrm] Proposal for CF4 Jacques, I must have lost
track of all the CF issues and their status.
Back on the 15th I sent an
email entitled "Proposed resolutions for ChrisF
issues 3,4,6,8,10" that started to cover this and thought we
were done. Your proposal covers other
edits to "line 489" (way back then) which have happened in the meantime
and introduces the need for another clarification. Glad you remembered we were not done. I agree with the
direction your update to Section 5.1.3.5 but am unsure about using a general
reference to section 3.2.1 from there, where the previous update lies. If we provide the clarification you mention
in section 3.2.1, that
reference would cover both the general list of resend terminations and the specific
list of (abnormal) group terminations.
Might be better to list
the specific faults in 5.1.3.5 (provide the clarification there). The reference would then go in the other
direction -- something like "In some
cases, the group containing this message terminates as well (see Section 5.1.3.5 for more information)." after the "delivery failure instead" bullets in
3.2.1. I suspect the
entire list of resend termination cases results in group termination for an ordered
list. Is the Receiver RMP required to
use the GroupAborted fault in that
case or should the clarification mention that group termination of an
ordered group happens in all cases of resend termination? thanx, doug On > Proposal for
C.F. comment #4: > > agree with
C.F. (use MUST), although this is more a matter of > optimization vs ease of
implementation > > "A
Sending RMP MUST NOT
resend a message for which an RM-Reply with one > of the following Fault types has been received, and must
notify its > Producer of a
delivery failure instead: > > "An Invalid Message Format
fault code (Table 22) > "A NonSupportedFeature
fault code > "A PermanentProcessingFailure
fault code" > > Also, group
termination must be updated consequently: > Section
5.1.3.5 (termination by ordering failure), the Triggering event > (in both
Sender and Receiver) > should be
extended with: > "...or a
[sent] message is faulted with one of the codes mentioned in > section
3.2.1" > (replace
"sent" with "received", for Receiver) > > Another a
related issue, when a Sender receives Faults such as > GroupAborted, or PermanentProcessingFailure,
is that not only resending > but also new sendings for the
group should be stopped. That needs be > made more
explicit. > > > Jacques > There was some discussion of sending a groupAborted fault “doubled” with other permanent processing faults. This was generally considered unwise, since our syntax is designed to support up to one fault code per reliable message request. Doug: I have a question for the group as a whole, as to the acceptability of the general approach to use group terminated error as the primary sender key to abort the group. Agreed that Sender RMP behavior needs to include new terminates group condition, when it receives group abort fault. Agreed that On receiver side show example cases when receiver may abort group, such as permanent processing failure of a message holding up the ordered deliver. No disagreement with approach. Action item to editors to implement approach with text.: 5.3 Response@ReplyTo and other Issues from Doug B final editing· !! IMPT: Technical issues as I go through
action items... !! Subject: !! IMPT: Technical
issues as I go through action items... !! * From: Doug
Bunting <Doug.Bunting@Sun.COM> * To: wsrm <wsrm@lists.oasis-open.org> * Date: Thu, I should have mentioned, this question needs an
immediate response since it is a clarification
and, therefore, a minor technical concern we should have considered a bit ago. The existing words do not explain the
semantics sufficiently enough to give an
interoperable meaning to the Response@replyPattern value except in a
few restricted situations (and the specification does not
currently enforce those restrictions). I
do not want to decide upon
our answer while doing the CD vote! On > First, my apologies that the speeded-up schedule agreed to on Tuesday is > not coming true. While I strive to meet your
wishes, I am (obviously) > falling back to the previous publication schedule. > > As I finish up on the action items, I keep coming back to section 4.4.1, > "Attribute: Response@replyPattern". I am unsure what it is trying to say. > Specific questions for the group: > > 1. This attribute value
is difficult to
choose when the
published >
RM-Replies relate to messages with varying RM-Reply Patterns. Only for > an underlying response to a
message with the Response RM-Reply Pattern, > is the choice clear. For the
other RM-Reply Patterns, which
may >
"bundle" information about multiple Reliable Messages, how should this > value be chosen? As
one possibility, must all
described messages have > arrived using the same RM-Reply Pattern (seems a bit
restrictive)? > > I note that the ReplyPattern agreement item has message scope, meaning > it may change "randomly" even within a group. > > A potential confusion
may have existed between the
implied(??) reply > pattern when responding to a PollRequest
versus the reply pattern of the > queried Reliable
Message(s). This case is already covered since the > Response@replyPattern value clearly refers to the reply pattern of the > Reliable
Message and not the most recent incoming message. > > The most obvious
problems arise when responding to a
"general status >
query" PollRequest asking about Reliable
Messages with varying RM-Reply > Patterns
but this is not the
only cause for confusion. More
generally, > the Receiving
RMP is allowed to supply
information about additional > messages
if it so
chooses. (At least, no current restrictions prevent > this.) For example, a
single Callback publication may
optionally > include additional
information about Reliable Messages
which arrived > with other
RM-Reply Patterns (and which the
Receiving RMP "somehow" > knows were from
the same Sending
RMP). A single
response to a > PollRequest may do
the same, regardless of
the number of RM-Reply >
Patterns relevant to
the Reliable Messages
identified in the > PollRequest. (This is also true
for the underlying response to
a > Response
RM-Reply Pattern Reliable Message but the "primary" message and > therefore @replyPattern value
is clear in that
case and that case > alone.) > > 2. The restrictions identified in the final
two bullets prevent sending > additional information
about other singleton (no SequenceNum) messages > when responding to a message received as part of a sequenced
group. The > SequenceReplies element must be first in this case and only additional > SequenceReplies elements are allowed according to the specification and > the schema. In the opposite case, a NonSequenceReply
element must be > first and may be followed
with additional NonSequenceReply and
/ or > SequenceReplies elements (though never mixed according to our schema). > Was this
the intent? Or, should the schema look
more like the following > DTD? > > ( NonSequenceReply | SequenceReplies )+ > > rather than the current > > ( NonSequenceReply*, SequenceReplies* ) > > Yes, the
"1 or
more" part is enforced only in the
specification at the > moment... > > 3. If this is covered in an action item I missed,
please let me know! > > thanx, > doug > · Re: [wsrm] Technical issues as I go through
action items... Subject: Re: [wsrm] Technical
issues as I go through action items... * From: Tom Rutt <tom@coastin.com> * To: Doug
Bunting <Doug.Bunting@Sun.COM> * Date: Sat, I guess the receiving RMP would put multiple groups
with the same reply pattern in one response
message. That means if , say 3 groups
used callback, while 2 groups used poll, the 3 groups could be
returned together in a callback
response, while the othere 2 groups could be returned together in a
poll response. However, this needs to be clarified. I see no reason to allow changing the reply pattern
across messages in a single
group. But this needs to be clarified as
well. We need to discuss this at the Tuesday meeting as a new
technical issue, and, unless the fix
is trivial, we may have to defer the cd vote until Aug 10 if we do not have the complete solution in place by
Tuesday. Tom Rutt Doug Bunting wrote: > What restricts the content of a Response message
(or element) to > information about a
single group? > > On > >> I always thought that the reply pattern had to
be the same for every >> message sent in the
group. >> >> If it does not say that, then I agree we have
a technical issue to >> resolve. >> >> What reason would there be to send a different
reply pattern for two >> messages with the
same group ID? >> >> Tom Rutt >> >> If we clarified that all messages in a group
must have the same reply >> pattern value, this
will simplify each >> return of the
response element being from a single reply pattern >> (i.e., single reply for response reply
pattern, >> and batch of callback
responses, or a batch of poll responses. >> Tom: It is Clear that you can do a poll on any message, regardless of what reply pattern was originally requested. Doug: In response rm reply pattern we talk about first element in response, because there might be more after that. For callback and reply there is not restriction on what messages are included in a callback response element. What would work without restricting our protocol, is to remove this attribute. Tom clarify: if the sender sends callback reply pattern on request, the receiver must send information back on a Callback Response. Jacques and Doug: we agree that this is required. Sunil: I do not mind. Doug: I move to remove response@replyPattern from spec and schema, seconded by Iwasa. No opposition. ------- Second Half of email. > 2. The restrictions identified in the final
two bullets prevent sending > additional information
about other singleton (no SequenceNum) messages > when responding to a message received as part of a sequenced
group. The > SequenceReplies element must be first in this case and only additional > SequenceReplies elements are allowed according to the specification and > the schema. In the opposite case, a NonSequenceReply
element must be > first and may be followed
with additional NonSequenceReply and
/ or > SequenceReplies elements (though never mixed according to our schema). > Was this
the intent? Or, should the schema look
more like the following > DTD? > > ( NonSequenceReply | SequenceReplies )+ > > rather than the current > > ( NonSequenceReply*, SequenceReplies* ) > > Yes, the
"1 or
more" part is enforced only in the
specification at the > moment... > > 3. If this is covered in an action item I missed,
please let me know! > > thanx, > doug > Doug: Choice at lowest level, but it is a choice between two types. Doug: this is purely a schema change, there is nothing in the spec on the ordering of sequence replies. The description is one or more of the following. Doug moved to change the schema from two successive lists to one list of either element type that is one or more long, Jacques seconded. No opposition, motion passes. Action: editing team to implement this change in the schema. Tom: I noticed that Doug added Any’s to the diagrams. Doug: all are where they belong. In response RM-reply pattern we support lots of info in reply element. We restrict what has to be the first element of the response element. 5.4 Comment on the ref Schema· Minor technical issue (or two) in the
reference.xsd schema · Re: [wsrm] Minor technical issue (or two) in
the reference.xsd schema Changes were incorporated in Draft 1.07. Doug posted the following contribution explaining the changes: http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/8411/ReplyToFixes-2004-08-02.pdf Implemented in the draft 1.07. 5.5 Schema Consistency issues· Re: [wsrm]
Full agenda for WSRM TC teleconf 8/3/04 Iwasa: there are two inconsistencies between schema and specs. Iwasa : I propose to remove invalidMessageHeader from schema. Doug: I asked why this has been removed from the spec, however I now realize we no longer have the separate element. Iwasa moved to remove invalidMessageHeader fault from schema, Doug seconded. No opposition motion passed. Iwasa : notSupportedFeature, vs nonSupportedFeature Doug: I made two counter proposals, if we do not want to reopen, we should use notSupportedFeature. If we do allow renaming of the spec featureNotSupported. Doug moved to change name notSupportedFeature to featureNotSupporte in both the spec and schema. No opposition Motion passes. Action: to editing team to implement both of these schema changes. Doug: the last part of Iwasa’s email is a schema editorial change. No opposition to the editorial team handling the result of the schema mismatch concerns of Iwasa. 5.6 Doug Cleanup issuesDetailed
review of Section 2-2.5, 5.2 and related definitions Doug: another question on my email as this meeting started. A fairly low lever review of text in section 2, and other portions of the spec. I do not think we have quite addressed the multilevel question I have asked in the past. To make thinks specific, we should do this on the list. Doug: I have a lot of questions, which need discussion by the group. Try for a proposal to address these concerns by next Monday. 6 Scheduled Vote for CD (only if all comments are resolved and we are quorate)Agreed to wait till Aug 10 7 Scheduled Votes for further progression (only if CD is voted yes)This agenda item, and the following sub sections are not applicable 7.1 Vote on whether changes from CD .992 are substantive7.2 Vote to Submit to OASIS for member vote (subject to no vote on 7.1))7.3 Vote for second 30 day public review (subject to yes vote on 7.1)1 Discussion of document progression and future meeting scheduleDoug: other than the text on CF8 we are not talking about major editorial work. We could have an updated spec and schema by wed evening. Would the TC prefer the discussion of the exact wording of group abort be given to editors, alone. Editors can provide this text. Target is wed evening. Everybody provide comments on the Wed draft before the end of Monday. Discuss any comments at the meeting on Tuesday. All comments received by Monday and not controversial should incorporated by the editing time into another draft on Tuesday morning for discussion at meeting. Editors should try to do this. Alan W posted the following email for discussion: · Has anyone proposed a RM'g panel session for
Oct 6th OASIS Adoption Forum in Brussels? Subject:
Has anyone proposed a RM'g
panel session for Oct 6th OASIS Adoption Forum in * From: "Alan Weissberger"
<ajwdct@technologist.com> * To: "wsrm"
<wsrm@lists.oasis-open.org> * Date: http://www.oasis-open.org/events/adoption_forum/presentation_proposals.php -Te
agenda lists Reliable Messaging as a topic of interest, but I have not heard
about any proposal. Has one been
submitted? Is it now too late/ past
submission deadline? Do we fear another
rock throwing/ mud slinging affair with the authors of the competing spec? -Also,
there were some mails indicating are next f2f would be co-located with this
Adoption Forum, but nothing was ever scheduled.
Where and when is are next f2f? Can
we please put these two items on the agenda for tomorrow's call Thanks alan Jeff:
this is not a symposium, like Doug: an interop demo would be the best thing to do. Jeff: I am not sure a face to face is called for. Alan: I do not prefer a TC f2f since the advantage of cross meetings is not there. Alan: I would suggest having a meeting to ourselves. The
week of October 4 is good timing for the next f2f. If it could also have an interop
demo, the Call Karl to talk about what the events are planned. Jeff:
there may be another Week
of October 4 is a possibility in Bob F: if we plan to do an interop there is a lot of work needing to be done. An
interop at WS-I would be interesting in Jeff M: this would be hard to get on the Agenda. Jeff M: we need to be planning another interop event. Tom: would this be the time to have the next Face To Face. Alan: I agree we need wide exposure. The last interop was not good, since there was only 10 people. The week of the Oct 4 in Doug: I will coordinate the editing team results. Doug moved to adjourn Bob F seconded. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]