Minutes
<Glen>
Could you add me to the roll, Sanjay/Paul?
<Jonathan>
Just joined, could you add me to the roll>
Resolution: 2006-11-16 minutes approved without objection
open action item review
Paul:
proposes closure of Bob/Paul joint action
Implementation subcommittee report
Discuss W3C Policy LC review
<Glen>
Sanjay or Paul - could you ack Jonathan and I having been marked present?
Policy LC period ends Janary 12, please review prior to the deadline
Paul:
Non Normative documents Guidelines for assertion authors and Primer will be available in time
Chris:
Review period is/ not intended for only casal personal review. It is the time for WG formal feed-back as well.
Action: Sanjay to follow up with Paul to create a review planNote that there is a new ignorable attribute
New Issues
PR36 - Compliance vs Conformance
<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
<chris>
it is quite different than wspptional
Pete:
Proposes changing compliance to conformance due to te semantics of compliance
Resolution: Pete's proposal accepted without objection
PR34 - Define Gap
Paul:
Moves closing with no action
<anish>
two issues closed before the half hour mark!!
Resolution: PR34, close with no action without objection
PR26 - Retransmission
Paul:
We never explicitly state that messages should be re-sent
... since the protocol depends on it, that is strange
... 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
<umit>
dug, do you have another wish ?
<PaulFremantle>
While the Sequence is not closed or terminated, the RMS must retransmit
unacknowledged messages.
chris:
Yes, messages need to be re-transmitted, but the timing is up to the RMS
<MrGoodner>
I don't think this is neccessary in the invariants
... to get messages across is the point of this damn protocol
<Sanjay>
The RMS SHOULD retransmit unacknowledged messages
<Stefan>
how can it be an invariant and say SHOULD?
... would not like to get too specific about which messages need to be re-transmitted
<anish>
curious, why is this a protocol invariant?
<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 not/ doing inOrderDA and the RMS decides that it just doesn't care about that msg then shouldn't it be allowed to
drop it?
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.
<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
Paul:
This ought to be part of the invariants since invariants and preconditions represent the axioms that prove the reliability
of the protocol
<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.
Dug:
There may be some use cases where the RMS may not want to re-transmit after all
... for example, perhaps the RMS decides that the message is too stale
<DaveO>
then why should it be in an RM protocol?
... the RMS may be perfectly happy with there being gaps
<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.
Anish:
Protocol invariants in the spec are to insure correctness of the protocol
... thus it does not belong in the invariants section
... 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.
<Sanjay>
adding Chouthri to the roll
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.
Chris:
Agrees with Anish that this is NOTan invariant
<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.
... 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?
<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.
... Depending on the agreement between RMD and RMD there may be situations that indicate that re-transmission is not required
<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.
<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
<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.
<Dug>
I think the most we should say is something like 'If an/ RMS wants an Ack for a msg then it should retransmit it at a time
it deems necessary'
<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.
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?
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>
strike that, reverse it
Jacques:
Line 268 indicates that a message must be re-transmitted and elsewhere talks about re-sending.
... Re-transmission should at least be defined
... 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."
Tom:
The statement that the protocol that it is at least once has been removed long ago, but there 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"/>
<Dug>
atLeastOnce != Until Acked does it?
anish:
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
... that was one of the reasons we used to get rid of DAs
<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?
Gil:
regardless of delivery assurances that one might want, the protocol on the wire remains the same
<umit>
yes, and we were all educated about this point on the first f2f when Chris gave his presentation
... allowing for the point that the RMS does not need to re-transmit undoes a lot of the discussion that supported removal of
DAs
<PaulFremantle>
except i dont agree we can resolve in the primer
<Sanjay>
I think the descroption of reliable messaging model in section 2 could have some text for retransmission.
<Gil>
Dug, sounds like an interop problem waiting to happen
dug:
Most will re-transmit unacknowledged messages, but it does not make sense to preclude those
... situations where the RMS choses not to
... leaving the option open is important. That is why I am objecting to the MUST
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/ claim we know why it doesn't choose to not retransmit
<Dug>
sanjay - I like the "is expected" way of saying it
Sanjay:
It seems the sense of the meeting is that this should not be a protocol invariant
<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?
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
... 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
Tom:
Suppose that the sender loses state?
<chris>
clearly, the protocol enables reliable delivery
<chris>
the question is how the protocol is implemented
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
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
... it does, but there are implications in the implementation
... 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
... 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.
... 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
... 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.
... The responsibility of the function is devided between the protocol and the implementation
<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?
<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?
<anish>
Dug -- that's sacrilage, isn't it?
<MrGoodner>
just change the MUST to "is expected to"?
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
<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.
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"
... People want this protocol for the purpose of reliable messaging
<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?
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 message was/ not received.
<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
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
Action: Paul to talk to some of the people and find a middle ground proposal for PR26
<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.
PR17 - What is the purpose of the WSDL?
<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.
Jonathan:
Discussion of a few months ago concerning makeConnection and WSDL
... It got me to thinking about why one would use WDSL rather than policy concerning the message flow
Dug:
In general i am ok with this text, but there are proposals for pr7 that might impact this
Gil:
I think that the first sentance is good.
<Stefan>
does anyone actually find the WSDL useful?
... 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
... 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.
Gil:
There might be distinct RMS and RMD WSDLs. There are different philosophies concerning how a service might be described
in WSDL
Jonathan:
This WSDL is for human consumption for folks to understand the message flow
Anish:
Do we at least document all of the message types at least in the schema portion of WSDL?
... I would be happy to accept this proposal as is and deal with R7 later
<Jonathan>
+1 to keeping the WSDL as complete as possible WRT issue 7...
Resolution: to accept Jonathan's proposal without objection
Schreiber diagnostics output
[Delete this section before publishing the minutes]
statistics: Schreiber found 260 input lines
edits: Schreiber found the following text-edit commands:
edits: Line 39: chris: s/periodis/period is/
edits: Line 41: bob: s/assurtion/assertion
edits: Line 45: bob: i/topic:/Note that there is a new ignorable attribute
edits: Line 95: bob: s/ b / be
edits: Line 113: bob: s/chirs/chris
edits: Line 119: Dug: s/no/not/
edits: Line 133: bob: s/proove/prove
edits: Line 167: bob: s/Aggress/Agrees
edits: Line 203: Dug: s/and/an/
edits: Line 249: bob: s/tere/there
edits: Line 275: bob: s/removl/removal
edits: Line 303: Dug: s/can do/can/
edits: Line 451: bob: s/Pal/Paul
edits: Line 455: tomRutt: s/messages was/message was/
edits: Line 504: bob: s/lest/least
edits: Line 508: bob: s/lter/later
command-scribe: Line 3: bob is a nick for Bob Freund who will be named as scribe
command-scribe: Schreiber detected that this section was scribed online
edit-substitute: command on line 41 succeeded, changed line 29 from 'assurtion' to 'assertion'
edit-substitute: command on line 39 succeeded, changed line 31 from 'periodis' to 'period is/'
edit-insert: i/ command line 34.1 inserted before source line
edit-delete: Line 39 was deleted
edit-delete: Line 41 was deleted
edit-delete: Line 45 was deleted
edit-substitute: command on line 95 succeeded, changed line 93 from ' b ' to ' be '
edit-delete: Line 95 was deleted
edit-substitute: command on line 113 succeeded, changed line 97 from 'chirs' to 'chris'
edit-delete: Line 113 was deleted
edit-substitute: command on line 119 succeeded, changed line 117 from 'no' to 'not/'
edit-delete: Line 119 was deleted
edit-substitute: command on line 133 succeeded, changed line 131 from 'proove' to 'prove'
edit-delete: Line 133 was deleted
edit-substitute: command on line 167 succeeded, changed line 165 from 'Aggress' to 'Agrees'
edit-delete: Line 167 was deleted
edit-substitute: command on line 203 succeeded, changed line 201 from 'and' to 'an/'
edit-delete: Line 203 was deleted
edit-substitute: command on line 249 succeeded, changed line 243 from 'tere' to 'there'
edit-delete: Line 249 was deleted
edit-substitute: command on line 275 succeeded, changed line 271 from 'removl' to 'removal'
edit-delete: Line 275 was deleted
edit-substitute: command on line 303 succeeded, changed line 301 from 'can do' to 'can/'
edit-delete: Line 303 was deleted
edit-substitute: command on line 455 succeeded, changed line 427 from 'messages was' to 'message was/'
edit-substitute: command on line 451 succeeded, changed line 447 from 'Pal' to 'Paul'
edit-delete: Line 451 was deleted
edit-delete: Line 455 was deleted
edit-substitute: command on line 504 succeeded, changed line 502 from 'lest' to 'least'
edit-delete: Line 504 was deleted
edit-substitute: command on line 508 succeeded, changed line 506 from 'lter' to 'later'
edit-delete: Line 508 was deleted
system: Transformer: SAXON SA 8.8
[End of Schreiber diagnostic output]