ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: preliminary minutes
- From: Christopher B Ferris <chrisfer@us.ibm.com>
- To: sanjay.patil@sap.com, ws-rx@lists.oasis-open.org
- Date: Thu, 29 Jun 2006 17:38:14 -0400
Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295
__________________
WS-RX TC Weekly Meeting has been modified by Mr Sanjay
Patil
Date: Thursday, 29 June 2006
Time: 01:00pm - 02:30pm PT
Event Description:
Dial-in details (thanks to Microsoft):
1(866) 500-6738
PC: 2365501
*6 Self Mute/Un-mute
IRC/Q Mgmt(thanks to DougD): http://webconf.soaphub.org/conf/room/wsrx
Agenda:
1) Roll Call
sanjay: 31/40 we are quorate
2) Review and approval of the agenda
sanjay: received proposals to NOT consider 121-124
on this call. Fine with me... please send update on what the plans are,
and when we might be prepared to finally deal with these issues.
3) Approval of the Jun 22, 2006 meeting minutes
http://www.oasis-open.org/committees/download.php/18932/MinutesWSRX-062206.html
asir: was present but not noted
andre: also omitted from roll
chris moves as amended, dougD seconds
sanjay: no objections, minutes are approved
4) AI Review
http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php
sanjay: ai100 (CLOSED)
paulc: bob, you haven't dealt with the polling concerns,
right?
bobf: correct
paulc: you are attempting to close this action item,
but I do not think that this
work is complete
bobf: ok, suggest we close this one and open a separate
AI
paulc: thanks, I'll agree to close the original if
bob will accept the new one
ACTION: Bob address polling in the state tables (once
the first round of state table changes are stablized)
sanjay: ai102 (pending)
5) New issues since last conf-call
Watch for Marcs email
http://lists.oasis-open.org/archives/ws-rx/200606/msg00270.html
sanjay: marc, please review
marc: proposed-01 editorial, add headings to fault
descriptions (bob)
bob: really irritated working through the state tables,
irregular/extended description of
faults and circumstances
under which they arise... completely described in sect 4 faults.
like to improve
the evenness and coverage of the faults, move the discussion to fault description
to facilitate
maintenance.
sanjay: no objections, accepted as new issue. bob,
no accompanying proposal?
bob: no, perhaps, when I get time I could do an exemplar
to describe a single fault
sanjay: would you need help for a complete proposal?
bob: would need a more complete description of each
fault
sanjay: would like to assign AIs
bob: would be willing to work with one of the editors
sanjay: and take the AI
bob: with an editor
anish: i'll help
ACTION: Bob and Anish to develop proposal for i140
resolution
marc: proposed-02 Editorial,Sec
3.3 fault response to TerminateSequenceRequest is not specified.
bob: unclear exactly what fault was meant
sanjay: no objectsions, proposed-02 is i141
chris moves to accept proposal
marc seconds
sanjay: no objections, proposed resolution is accepted
to close this issue (i141)
marc: proposed-03 Editorial,
Sec 3.5 Request Acknowledgement text assumes Sequence is known
bob: chris had suggested some text that others liked
better than my proposal (looks for message)
marc: finds email http://lists.oasis-open.org/archives/ws-rx/200606/msg00202.html
sanjay: no objections to accepting new issue
dougb: moves to accept proposal from Chris
marc: seconds
gil: little bothered by the fact that you are required
to send a sequence fault
in security, you always leave things out to say you
probably should generate a fault,
but if concerned someone is fishging for seq id, you
don't have to
anish: difference between generate and transmit.
chris: I am confused
anish: if there is a problem processing a particular
header, it shoud not affect processing
of body and other headers. if I get ackrequested for
seq foo and a message for bar, I should
generate a fault for foo but do the right thing for
bar.
chris: does the propsed resolution need to be changed?
anish: I wanted to verify whether the text in the
spec covers this situation. If it doesn't,
we need to add that.
sanjay: my understanding is that it does cover, but
if anyone feels otherwise, raise a new
issue
bob: the general statement about unknownSeq fault
is described in 4.3, and ackrequested
to get these into synch. not sure that making it optional
would be a good thing
dougd: given that you raise the concern, someone could
interpret that incorrectly. get somewhat
worried about the current propsal that it not be confusing
to readers
marc: disagree, we just adopted another proposal that
used generate. don't believe is impacted by
this proposal. suggest that they RTFM.
anish: reads text from spec (line 604-606 sect 3.5)
that covers the concern I had, doug, if you are still concerned,
we could add a pointer to this section
dougd: no longer concerned
sanjay: no objections to unanimous consent, motion
passes, resolution is adopted, closes i142
marc: proposed-04 Editorial
messages have to be received for them to beexamined: with new highlighting
bob: reading section on closure, glossary definition
of received means receive something
off network interface, seems that we need another
word like accepted or cannot be acknowledged
if closed but must be received
sanjay: no objections to accepting as new issue (i143)
sanjay: anyone want to close on this call
marc: not ready yet
marc: proposed-05 Editorial
(maybe) RMS MessageNumberRollover behavior unclear
bob: go-around related to incorporation of ??? in
certain state tables, the spec states that the
rms and rmd may generate a MessageNumberRollover fault,
unclear what the actions on each side need to be
it was stated that upon the rollover detection, the
rmd must still receive messages, etc. not clear what
the rms needs to do, should it transmit a fault, etc.
needs clarification
dougb: thought that we dealt with a propsed issue
from jacques that sounds exactly like this one. can't
find that in the most recent issues list
bob: thought it was i111
dougb: cites heading
bob: that was the issue I rescinded. this issue replaces
the previous one I rescinded
sanja: no objections, issue is accepted (i144)
marc: I am not convinced that this is an issue, more
inclined to close with no action
or discuss on the list
bob: if closed with no action, I can strike sections
from state tables
sanjay: let's make progress on the list
proposed-06 design: Implications
of Sequence Expiration not specified
bob: there is an expiry in a number of places, actions
to be taken are not specified when expiration
occurs. also not clear what event from which expiry
is computed.
sanjay: no objections, issue is accepted (i145)
matt: prefer we defer consideration of this issue
sanjay: ok
proposed-7 Editorial Examples in Apx C lack CloseSequence
bob: close not represented in examples
dougd: proposal to change figure 2 too?
bob: could do that too
matt: about updating figure 2, no reason for RMS to
close before
terminating it... keep as simple as possible, not
confuse people
marc: going to say roughly the same thing, concerned
we are not bringing
things to closure. don't know how much additional
value this provides
sanjay: we are now talking about resolution
dougd: moves to accept as new issue. not a lot of
editorial work
sanjay: no objections, issue is accepted (i146)
chris: move to close with no action
marc: seconds
no discussion
sanjay: no objection to unanimous consent, motion
passed, issue closed with no action
Proposed-8 Extensibility (or not) of the Protocol Elements
matt: seems an underlying current of consistency with
wildcards, but wasn't quite
consistent... tried to work through sect 3 seeing
whether it had element or attribute
wildcards... that went to the list a while ago. Also
fault has inconsistent extensibility.
fine detail here. if people haven't had time to review
the propsal fine, but hopes we
can accept new issue.
marc: need more time to review, suggest we accept
dougb: +1 generally don't see the need to have attr
and element extensibility everywhere
need more time to review this and map that to these
elements
sanjay: no objections, issue accepted (i147)
paulc: not sure I understand dougb's thesis
sanjay: dougb?
dougb: yeah
ACTION: Doug to send note describing his thoughts
on the extensibility
Proposed-9 Reword the Abstract
matt: repetition of word "protocol" anish
had useful suggestion to replace
protocol with requirements and scenarios
sanjay: no objections, issue accepted (i148)
dougd: move to accept proposal
marc: seconds
sanjay: no objections to unanimous consent, motion
passes i148 closed
Proposed-10 Editorial namespace URI is incorrect
bob: no content at the URL endpoint
dougd: not supposed to be yet
bob: wanted to go check wsdl... found nothing
dougd: understand
sanjay: any objections?
dougd: objects
marc: seconds that objection... covers that process.
bob: if I am reading a particular wd and generating
comments, which schema
and wsdl do I use
dougd: can use the schema in the document, that should
be up to date
bob: ok
sanjay: new issue not accepted
Proposed-11 Define the syntax used to refer to elements
and attributes
peter: we don't use pure xpath for notation to refer
to extensibility points
propse we add description to section 1.1 to say what
we are doing, explain the {any}
and @{any}
sanjay: no objections, issue accepted (i149)
chris: moves to accept propsal
marc: seconds
dougb: verbosly saying subject to constraints and
... don't normally just refer to xml schema
and not provide any text in the spec itself. Aren't
constraints in the schema consistent?
peter: our spec states every time (can't really hear).
need to be precise or people will think
the schema is wrong.
dougb: worried about the verbosity
peter: we could define any to be equivalent to any
##other
sanjay: are we doing an amendment?
peter: amended proposal:
An element extensibility point is referred to using
{any} in place of the
element name. This indicates that any element
name can be used, from any namespace other than the wsrm:
namespace (likewise for @(any}
paulc: propose friendly amendment, no normative reference
to xpath 1.0
peter: agree to add [XPATH10] reference in the obvious
place
doug: like to vote on accepting all of these rather
than going through
three step process
sanjay: updated proposal with "friendly"
amendments applied
no objections to unanimous consent to accepting amended
proposal to
close i149
proposed-12 Editorial
nits in Section 4 wrt using fault names in wsrm spec
umit: references to the faults we describe and fauls
all have spaces in them
change to reflect the fault names in faults subsection.
editorial nit
sanjay: no objections, issue accepted (i150)
umit: move we close with a)
marc: specifcally first alternative
umit: yes
marc: seconds
sanjay: no objection to unanimous consent to closing
i150 with option a)
marc: not sure if I got all the issues
bob: you got all of mine
6) Discussion of comments that are not covered by
the new issues
sanjay: make sure that all comments have been addressed
dougd: ballot closed and some either forgot or did
not get a chance to vote, could
we open the ballot for a few more days to let everyone
vote?
umit: seconds
marc: how are you going to deal with duplicates?
dougd: that is why I want to reopen the ballot
sanjay: will investigate
sanjay: any further comments they would like to discuss?
7) Issue Discussion:
a> New issue from 6/22 conf-call: Inappropriate
Fault destination
http://lists.oasis-open.org/archives/ws-rx/200606/msg00132.html
marc: i139 http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i139
sanjay: raised by jacques, who is not on the call
marc: cannot support that, think that the current
text is clearer than the proposed text
could accept a part but not b part.
sanjay: think we should postpone to another call
dougb: we are quorate
daveo: common courtesy suggests we should have jacques
around for this
dougd: +1
sanjay: I would prefer we wait a week
matt: support deferral. put a proposal in the chat
which would be a better
phrase for the second part of the proposal.
[17:10] Matt Lovett For the minutes how about:
RM Destinations that generate Sequence faults SHOULD send those faults
to the same [destination] as <wsrm:SequenceAcknowledgement> messages.
marc: we are quorate, if jacques wanted the issue
deferred, he should have let the chairs
know.
sanjay: okay, let's move on
ian: jacques is on vacation and won't be available
next week either
sanjay: tom? will jacques be on the call?
jeff: many americans living in the states will likely
be on vacation
daveo: my suggestion is that a meeting next week is
very much in doubt
deferring for two weeks is the right thing to do
f> i113 Tightening
up the state tables
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i113
bob: went through the state tables, relating back
to text in the spec. (lengthy description)
back and forth marc and bob regarding incorporation
of polling in this revison or the next
bob: will have to review isue resolutions
sanjay: we won't close today, but on the next call
should we have a call next week? straw poll?
paulc: ready and willing
jeffm: requests addition to roll, martin will be on
vacation
sanjay: 18 yes, 6 no... think we should have a call
paulc: quorum is 20
sanjay: less than quorate, ...
paulc: but there are 16 unknowns
chris: let's make some progress
jeff: let people request to defer issues that concern
them
sanjay: we will have a meeting next week
folk working on 121-124, please post your plans
adjourned
8) Any other business
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]