OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: preliminary minutes



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]