Raw scribed text from 2006-11-30 WS-RX telecom. I will clean up andre-s

Room information was updated by: Gil

toll free (US + Canada): 1-866-214-3176

others: +1-404-827-9098

*6 to mute

*7 to unmute

Mark Little: Access Code: 5212773

Room information was updated by: Matt Lovett

toll free (US + Canada): 1-866-214-3176

others: +1-404-827-9098

Access Code: 5212773

*6 to mute

*7 to unmute

Gil: oops

chris: oops?

Gil: hey we matter! http://service-architecture.blogspot.com/2006/11/rating-ws.html

Gil: chris: forgot to post the access code

Gil: gotta leave, be back in a sec

Sanjay: Gil, you there?

Dug: brb2

Gil: one sec

bob Yo!, haven't heard that since Brooklyn</B< pre>

anish jeff is in Japan, not sure if he'll dial in</B< pre>

Glen: Hi folks... just joined.

bob: scribe: bob

Glen: Could you add me to the roll, Sanjay/Paul?

bob: meeting: OASIS WS-RX Teleconference

bob: Agenda+ pr36

Jonathan: Just joined, could you add me to the roll>

bob: resolution: 2006-11-16 minutes approved without objection

anonymous: sorry, sanjay, i lost battery power on my cell

bob: topic: open action item review

Dug: this may not be a good sign if people are reluctant to even approve last call's minutes

lei: that last anonymous was me

anish: it could be apathy rather than reluctance

Dug: just too tired, eh?

 umit: or plain sleepiness.

anish: i certainly am

bob: Paul: proposes closure of Bob/Paul joint action

bob: topic: Implementation subcommittee report

bob: Dug: No activity

bob: topic: Discuss W3C Policy LC review

tomRutt: test

Glen: Sanjay or Paul - could you ack Jonathan and I having been marked present?

bob: Policy LC period ends Janary 12, please review prior to the deadline

Sanjay: Glen, Jonathan, added you to the roll

Glen: Thanks, Sanjay!

bob: Paul: Non Normative documents Guidelines for assurtion authors and Primer will be available in time

bob: Chris: Review periodis not intended for only casal personal review.  It is the time for WG formal feed-back as well.

bob: AI: Sanjay to follow up with Paul to create a review plan

bob: topic: New Issues

bob: MrGoodner: No new issues

chris: s/periodis/period is/

bob: s/assurtion/assertion

 umit: i do  not think so

bob please speak up</B< pre>

bob: i/topic:/Note that there is a new ignorable attribute

bob: topic: PR36

bob: Compliance vs Conformance

anish: http://www.oasis-open.org/archives/ws-rx/200611/msg00199.html

chris: I would note that the purpose of wsp:ignorable is to allow the consumer of policy the OPTION of excluding the assertion from consideration in the intersection

Sanjay: http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i036

chris: it is quite different than wspptional

bob: Pete: Proposes changing compliance to conformance due to te semantics of compliance

chris: +1

bob: +1

bob: bob: moves to accept Pete's proposal

bob: resolution: Pete's proposal accepted without objection

bob: topic: PR34

bob: Paul: Moves closing with no action

anish: two issues closed before the half hour mark!!

bob: resolution: PR34, close with no action

bob: topic: PR26

bob: Paul: We never explicitly state that messages should be re-sent

bob: ... since the protocol depends on it, that is strange

bob: ... I am not quite clear yet on clear wording on a protocol invariant that well describes this

jacques: "...but one of the invariants of this protocol is to resend messages until they are acknowledged.

Consequently,.." (in Sect 5)

bob plese speak up</B< pre>

 umit: dug, do you have another wish ?

PaulFremantle: While the Sequence is not closed or terminated, the RMS must retransmit

unacknowledged messages.

bob: chris: Yes, messages need to b re-transmitted, but the timing is up to the RMS

bob: s/ b / be

MrGoodner: +1 chirs

MrGoodner: I don't think this is neccessary in the invariants

bob: ... to get messages across is the point of this damn protocol

Sanjay: The RMS SHOULD retransmit unacknowledged messages

Sanjay: ??

Stefan: how can it be an invariant and say SHOULD?

bob: ... would not like to get too specific about which messages need to be re-transmitted

anish: curious, why is this a protocol invariant?

bob: s/chirs/chris

Dug: I'm wondering if an RMS MUST resend at all - what if it just doesn't want to - clearly the Sequence will have gaps but that's its choice, no?

Dug: if we're no doing inOrderDA and the RMS decides that it just doesn't care about that msg then shouldn't it be allowed to drop it?

Dug: s/no/not/

bob: Jacques: A conforming RMS must be able to re-transmit

Stefan: or the RMS-RMD might be using some custom addition to the protocol that enables gaps to be filled, this would preclude that.

Dug: yup

Glen: technically I think you're correct Dug.  There might be interesting edge cases where you want to deliver a numbered sequence of events and know what the gaps are but not use retransmission (data goes stale after 1 sec, for instance).

Stefan: i don't think we should say anything at all

bob: Paul: This ought to be part of the invariants since invariants and preconditions represent the axioms that proove the reliability of the protocol

bob: s/proove/prove

PaulFremantle: 1. this is an invariant because the invariant and preconditions are the place we define how the spec actually works. 2. Saying MUST doesn't imply anything about timing so allows any heuristic.

bob: Dug: There may be some use cases where the RMS may not want to re-transmit after all

bob: ... for example, perhaps the RMS decides that the message is too stale

DaveO: then why should it be in an RM protocol?

bob: ... the RMS may be perfectly happy with there being gaps

bob anish I can't hear you</B< pre>

chris now I'm going deaf!</B< pre>

Dug: DaveO: its really up to the RMS - it could be time dependent - perhaps it will try to resend 5 times and then give up on that one message since after 5 minutes the message is stale.

bob: Anish: Protocol invariants in the spec are to insure correctness of the protocol

bob: ... thus it does not belong in the invariants section

bob: ... I don't have a problem with a descriptive statement somewhere but do not agree with a MUST

Glen: Yep, I think I agree with Dug here.  It might be that sequence setup and teardown are very expensive, so you don't want to drop it if gaps are OK in certain circumstances.

Dug: +1 stefan

Sanjay: adding Chouthri to the roll

bob: Stefan: Perhaps simply pious advice might be enough

Chouthri Palanisamy: Thanks Sanjay

Glen: It's not going to really guarantee reliability anyway, depending on the underlying network and lots of other factors.

bob: Chris: Aggress with Anish that this is NOTan invariant

bob: s/Aggress/Agrees

Dug: I get very bothered when we try to restrict the protocol for no reason - such a base spec/protocol really should be as flexible as possible - within reason of course.

bob: ... purpose of the protocol is that the RMS can know the state of messages that have been received by the RMD

DaveO: Maybe this shouldn't be the "reliable messaging" protocol, but the "RMD/RMS State sharing" protocol

Dug: daveO: not much of diff

anish: given that the protocol is at-least-once, wouldn't you want the RMS to retransmit for a successful closing of the sequence?

 umit: +1 to Anish.

Dug: in general sure - but its not a hard requirement - its up the RMS to decide when its happy (to close) or when it wants to retransmit.

bob: ... Depending on the agreement between RMD and RMD there may be situations that indicate that re-transmission is not required

Dug: (if at all)

Glen: jeez -  don't take this tooooo far, people.  Reliability certainly is what we want here.   We just don't want to make it impossible for people to use the protocol in novel ways.

Dug: +1 glen

DaveO: Gee, PaulF joined the reliable messaging TC and got the "Message Delivery State Transfer" TC

Glen: Retransmission is going to happen in any usual implementation, no question.

bob DaveO yup</B< pre>

Dug: clearly we think most people will retransmit but that's not the same thing as banning uses of it that may not require it all the time for _all_ cases.

Glen: Yuppers.

Dug: I think the most we should say is something like 'If and RMS wants an Ack for a msg then it should retransmit it at a time it deems necessary'

Dug: s/and/an/

DaveO: Would be interesting to have a straw poll on who cares about the cases where retransmission will not occur, that is how wants reliable delivery vs message delivery state transfer.

bob: Anish: I think that it makes sense to say somewhere that re-transmission is used when it is desired that a message actually be reliably delivered

Dug: given the text that Sanjay just read is already in the spec - do we need anything else?

bob: Sanjay point to existing text that indicates that a message be tr-transmitted in an ack is not received

Gil: it seems like the purity of the protocol is taking a back seat to the desire to provide guaranteed delivery

Gil: wups

Gil: strike that, reverse it

Dug: willy wonka

bob spuw</B< pre>

bob: Jacques: Line 268 indicates that a message must be re-transmitted and elsewhere talks about re-sending.

bob: ... Re-transmission should at least be defined

MrGoodner: +1 Dug

bob: ... just because re-transmission is not a requirement, it definition must be clear

DaveO: So how does an RMD advertise that it wants an RMS that will retransmit?

 umit: < pleaseRetransmit wsp:ignorable="true"/> just kidding.

MrGoodner: 2.4 Example Message Exchange

Glen: Retransmission should be the expected default

Glen: we don't talk about delivery either, right?

MrGoodner: "Should an Acknowledgement not be

Received in a timely fashion, the RM Source MUST re-transmit the message since either the message or

the associated Acknowledgement might have been lost."

Dug: umit LOL

bob: Tom: The statement that the protocol that it is at least once has been removed long ago, but tere are still artifacts in the spec that need to be cleaned up

Stefan: tom: it seems we agreed with this current position a long time ago

Glen: umit: Just like <secure:isEncypted mustUnderstand="0"/>

bob: s/tere/there

PaulFremantle: +1 Anish

 umit: +1 to Anish

Dug: atLeastOnce != Until Acked  does it?

DaveO: can anish's point be minuted?

bob anish can you scribe your point, I got behind</B< pre>

 umit: The agreed protocol the spec specifies is at least once on the wire.

Dug: right - and sending it 2+ times is up to the RMS to decide, right?

anish: what I was saying on the call was: the protocol is at-least-once on the wire. DAs are a layer above. The protocol enables DAs (like at-least-once), but the protocol is at-least-once

bob: Gil: regardless of delivery assurances that one might want, the protocol on the wire remains the same

anish: ... that was one of the reasons we used to get rid of DAs

 umit: yes, and we were all educated about this point on the first f2f when Chris gave his presentation

PaulFremantle: +1 gil

bob: ... allowing for the point that the RMS does not need to re-transmit undoes a lot of the discussion that supported removl of DAs

PaulFremantle: except i dont agree we can resolve in the primer

bob: s/removl/removal

Sanjay: I think the descroption of reliable messaging model in section 2 could have some text for retransmission.

 umit: +1

Gil: Dug, sounds like an interop problem waiting to happen

bob: dug: Most will re-transmit unacknowledged messages, but it does not make sense to preclude those

bob: ... situations where the RMS choses not to

bob: ... leaving the option open is important.  That is why I am objecting to the MUST

bob: jacques: An improvement might be to say that a conforming imlemention MUST be able to re-transmit mssages

Dug: must be able to retransmit is just as bad since if the RMS doesn't plan on retransmitting then it violates it.

Sanjay: RMS *is expected* to retransmit unacknoweldged messages!

Dug: sanjay ... if it wants acks for those messages.  yes

Stefan: dug - dunno, im able to retransmit but i just don't choose to do so.

Dug: stefan - it can yes, but perhaps it can't and doesn't need/want to

Dug: how can do claim we know why it doesn't choose to not retransmit

Dug: s/can do/can/

Dug: sanjay - I like the "is expected" way of saying it

bob: Sanjay: It seems the sense of the meeting is that this should not be a protocol invariant

Stefan: +1

tomRutt: If we take the MUST retransmit branch, Is there a time limit on how long the sender has to wait to terminate the sequence when it has lost its own buffer for a non acked message?

bob: Paul: The support of guaranteed delivery depends on message re-transmission.

Gil: I think re-transmission should be a protocol invariant

chris: sorry, but I simply don't agree with paul's statement

anish: tom: we don't talk about time limits

bob: ... It is ok that an incomplete sequence be closed, but that is a failure to deliver a sequence

Dug: saying that someone MUST close a sequence just to fill a gap is way too harsh

bob: Tom: Suppose that the sender loses state?

chris: clearly, the protocol enables reliable delivery

chris: the question is how the protocol is implemented

bob: Paul: The proposed text has no timing statement

anish: dug -- such a requirement is not testable anyway. But it clearly says what an RMS must do

Sanjay: How about we update lines 186-197 to say: RMS transmits a message one or more times until it receives an Acknwoledgement

Sanjay: 186-187

bob: Chris: I diagree with the statement that the prtocol as it stands does not nable reliable delivery.

Dug: it doesn't say that it must close it to fill a gap - it says it should close it if it wants to for whatever reason

bob: ... it does, but there are implications in the implementation

bob: ... the protocol supports reliable delivey, but the responsbility for that function depends on the implementation

anish: i agree with chris on the the correctness issue

anish: but i would be ok with adding a must somewhere else

bob: ...  Invariants are to make sure that the protocol does not get screwed up

Stefan: +1 chris. the protocol certainly supprts reliable transfer, to expect the base spec to say how to do it for all usages of the protocol is a bad idea.

bob: ... Clearly it is necessary that the RMS re-transmit messages to achieve relible delivery, but it is a separate function from the wire protocol itself

anish: does "really really really really good idea" == SHOULD ?

tomRutt: HOw about" If the rms wants to assure guaranteed delivery, it MUST retransmit non acked messages"

Dug: at least its not a MUST

bob: ... The function of the protocol is to insure that both sides have an understanding of the state of a sequence

 umit: I have exactly the same problem that Gil has.

bob: ... The responsibility of the function is devided between the protocol and the implementation

Gil: queue!!

MrGoodner: +1 Gil

chris: anish, I have to leave, you have a ? for me, please type it in

chris: I have to leave now

anish: would you be opposed to a SHOULD in a section other than the Protocol Invariance section?

chris: not at all

 umit: Yes, Gil good going. what is the capability we are enabling...

anish: Paul -- would be happy with such a SHOULD?

Dug: anish - I think most of those in the other camp could live with something like that - as long as its not a MUST

Dug: lets let the editors take a stab at it

anish: I would be happy with a SHOULD in some section other than the invariance section

MrGoodner: Dug, do we need to just change the text in section 2.4 Sanjay identified?

Dug: that might do it

anish: Dug -- that's sacrilage, isn't it?

Dug: http://money.cnn.com/2003/09/04/pf/saving/pepsi_monkey_game/monkey.03.jpg

Dug: anish - probably

MrGoodner: just change the MUST to "is expected to"?

bob: Gil: It is necessary that the RMS to re-transmit messages in order to fulfill the reliable delivery function

PaulFremantle: can we take a straw poll

bob I think that we should go back to the list for a new proposal</B< pre>

anish: lol

tomRutt: my phone card is about to run out, please ask for any votes on the chat

jacques: "MUST be able to retransmit" is much better than "MUST retransmit" as we have today in the draft.

bob: Paul: I agree that what chris is describing is a valid protocol, I just don't think that it is the protocol that anyone wants

tomRutt: I am off the phone, my only point was a conditional statment "if the rms wants to assure guranteed delivery it MUST retransmit non acked messages"

bob: ... People want this protocol for the purpose of reliable messaging

Dug: +1 to bob

PaulFremantle: i'm just glad that chris didnt define MQseries because IBM would be short about $500m this year

Stefan: Paul: why would that be bad?

bob: Umit: By not making clear statements concerning re-transmission we are confusing expections about this protocol.

tomRutt: There are use cases for a lightweight rms that merely notifies its application sender that the messages was not received.

 umit: thanks Bob

PaulFremantle: stefan now im laughing

PaulFremantle: but i have shares in IBM

 umit: i guess I do not count

DaveO: umit, it's selective hearing.

 umit: yes, Marc is a master

Dug: I'd like to see a new proposal from Paul that tries to take all of this discussion into account

bob: Paul: I think that it should be one of the invariants and SHOULD be a MUST

Dug: but clearly enough people differ - so please try to find some middle ground

bob: AI: Pal to talk to some of the people and fina a middle grouund

Stefan: i think the disagreement is not in what the protocol is for or enables but rather on how far we want to go prescribing how the mechanisms the protocol defines should (or must) be used.

bob: s/Pal/Paul

bob: topic: PR17

tomRutt: s/messages was/message was/

bob: /ms Addressing cr33 is also straightforward

Sanjay: http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i017

Dug: http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i017

anish: Jonathan's proposal:

anish:

        fix this editorially by adding the following explanatory text to "Appendix B.  WSDL":

        This WSDL describes the RM protocol from the point of view of an RM Destination.  In the case where an endpoint acts both as an RM Destination and an RM Source, note that additional messages may be present in exchanges with that endpoint.

        Also note that this WSDL is intended to describe the internal structure of the RM protocol, and will not generally to appear in a description of an RM-capable Web service.  See RM-Policy [ref] for a higher-level mechanism to indicate that RM is engaged.

bob: Jonathan: Discussion of a few months ago concerning makeConnection and WSDL

anish: +1 from me

bob: ... It got me to thinking about why one would use WDSL rather than policy concerning the message flow

bob: Dug: In general i am ok with this text, but there are proposals for pr7 that might impact this

bob: Gil: I think that the first sentance is good.

Stefan: does anyone actually find the WSDL useful?

bob no</B< pre>

Stefan: i sure don't

bob: ... PR7 might add a message flow from the RMD to the RMS.

 umit: I like Jonathan's proposal

tomRutt: The wsdl can be used to implement the createSequence exchange with a tool

bob: ... the fist sentance indicates the messages that the RMD accepts and is not from the point of view of the RMS

 umit: Wire description language or service description language? the old debate.

bob: Gil: There might be distinct RMS and RMD WSDLs.  There are different philosophies concerning how a service might be described in WSDL

bob: Jonathan: This WSDL is for human consumption for folks to understand the message flow

bob: Anish: Do we at lest document all of the message types at least in the schema portion of WSDL?

bob: s/lest/least

bob: ... I would be happy to accept this proposal as is and deal with R7 lter

bob: s/lter/later

Jonathan1: +1 to keeping the WSDL as complete as possible WRT issue 7...

bob: resolution: to accept Jonathan's proposal without objection

ws-rx message