Thursday
Prelim Minutes WS-RX F2F meeting
RTP
March 23, 2006
8
Agenda Tuning
Sanjay presented the following draft agenda
9:00-11:00
Anonymous URI and Offer - review of the Interop
Scenario 2.4
Paul F to present issues.
11-
11:15 Acceptance of any new issues
11:15-12:00
Review and update of State Tables
13:00
- 13:45 Application
Notes discussion
13:45-14:45
Planning
Please
see note:
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200603/msg00151.html
-
Editors next steps
-
CD4
-
Ballot for PR
-
Public Review
-
Future distributed and F2F schedule
15
- 16:00 Discussion of new issues
Marc
G asked where issue 89 will be discussed.
Sanjay:
that was intended to be part of the anonymous URI and offer discussion.
Bob
F stated the state Table discussions could be put offline with a small team,
since the issues are not contentious,.
Jacques
stated the application notes discussion could be less than ½ hour.
9
Discussion of Issue 89
Description
When an AS uses an RMS to reliably send messages to an RMD, the
RMS will need to be able to resend the un-acked
messages at will. If the AS uses a target URL or wsa:To value such that the RMS can not, at its own
discretion, initiate the (re)sending of messages then the RMS would be severely
limited in its ability to complete its job. To this end the RM spec should
discourage the use of wsa:To
values that would put the RMS in this situation, like the anonymous URI. Of
course, there may be times that using the anonymous URI _and_ RM can work and
so we shouldn't totally ban the use of anonymous URI but we should make people
aware that w/o some other mechanism, a generic WSA+RM soap stack would not be
able to support this. Note, that while this is phrased in the context of wsa:To, for replies the RMD
becomes the RMS and the wsa:ReplyTo becomes the wsa:To - so it would mean that we'd, implicitly, be
discouraging the use of the anonymous URI in wsa:ReplyTo
when people would want responses sent reliably.
Paul Freemantle gave a
presentation on Anonymous URI and Offer - review of the Interop
Scenario 2.4
Paul talked about 2 scenarios:
- Scenario
1 _ reliable http request with anon reply to and non reliable http
response.
- Scenario
2 – Reliable http request with anon ReplyTo and
reliable http response using offer.
Doug D stated there is a scenario 3, non reliable request
with reliable response.
Paul stated that if a server receives a create sequence with
anon ack to and anon reply to with an offer, it could
refuse to create this sequence.
Matt: lets look at the scenario,
then discuss the marker that signals its presence.
Marc G asked how this relates to I089 restrictions.
Tom R: the presentation is about anonymous reply to with an
offer at sequence creation for a reliable response.
Paul F: for scenario 2.4 the request must be replayed to
stimulate receipt of a lost response.
Paul F : there is one issue that
you cannot terminate an offered sequence, since it is a two/way operation in
reverse.
Paul F::Another potential issue is
that the server has to echo the response for a duplicate message before it
drops delivery of the duplicate to the AD.
Paul F: this scenario involves polling for the response, and
currently the only way to do that is to replay the response.
Paul F: to replay the client must keep the request after it
is acked, so it can replay it. One way to do that is for the client to know
that this scenario is in place, knowing the mep. However this would not work for a gateway
style implementation, which does not know the mep in
use.
Paul F: another was would be for the server to change its
acknowledgement behaviour if it knows the MEP.
Anish: Is there an assumption that
a co-related request response is tied to a single http exchange.
Paul F: yes, since otherwise it would break ws-addressing.
Anish: if you constrain the lower
level protocol behaviour based on a higher layer MEP,
this seems to be problematic.
Paul F proposed an additional solution mechanism: the client
can poll rmd.either
·
Ack request with empty
body, signals resending the response in return. (a hack with several problems)
·
Special “get response” message with offerSequenceID in header
Paul F: the get message is better, because it eliminates the
need for the server to correlate messages in sequence.
Paul F: the response has two relatesTo,
one to the get message the other to the original message.
Doug:D:
the polled response is a response to the get request, and a reply to the
original message.
Bob F: the echoed message response is to the get request,
not the original message. It should not
use two relatesTo elements.
Peter N: we need two relates to. They could have different
relationship type.
Tom R: we could define our own relationship type for the
reference to original message: correlation, say wsrm:replay.
Anish: anonymous semantics for
soap http binding the response has to be sent on same response channel. But in our case there is a failure and you
never got a reply. The get message is a
new message, and its reply to can be whatever is required.
Marc G: I am concerned as to our references to ws-addressing. Does
this compose to the submitted version of ws-addressing.
Tom R: I think it is better to give two relationship types,
because the response to the get does not obey the semantics of an anonymous
reply to the original message.
5.1.2 wsa: soap binding spec quote
When
"http://www.w3.org/2005/08/addressing/anonymous" is specified for the
response endpoint and the message is the
http://www.w3.org/2003/05/soap/mep/InboundMessage property of a SOAP
request-response MEP [SOAP
1.2 Part 2: Adjuncts], then any response MUST be the
http://www.w3.org/2003/05/soap/mep/OutboundMessage property of the same
instance of the SOAP request-response MEP [SOAP
1.2 Part 2: Adjuncts].
Gil: but it would be better to have the infrastructure see
the message as a response to both the original message and the get message.
Anish: since there was a failure this
text does not apply. I could live with a new relationship type URI, but do not
think it is necessary. If there is a
failure nothing stops me from doing extra things with that response message.
Glen D: this perceived restriction is at soap mep level.. Application mep
semantics can add extra things. The use
of WS-RM can add additional paths for the reply channel.
Umit: I agree there may be a
loophole in wsa which we can exploit. However, I really do not like changing
semantics without minting a new URI. Introducing
polling semantics with anonymous uri needs to be
adequately defined.
Paul F: we need to take straw poll on preferred
approach. Is there support for the get
message approach without minting new URIs. The replay should
be able to keep the original relationship element as the original response.
Glen D: do you mean both requests use anonymous replyTo, and the replay response will have two relationship
elements with the relationship type WSA: reply.
Paul F: yes that is the question for the Straw poll. Who thinks this does not break WS addressing.
Does not break: 7
Do not know: 7
Does break: 2
Chris F: this case does not break ws
addressing. However that is the wrong
question. I think it is legitimate, if
you attempt to respond anonymously and fail, to
replay. However I still see a valid
requirement for a new URI for the original reply to (this should be change to “multipleRetry” anonymous.
Tom: if we had this we do not need a separate get message,
since the client knows it is playing the game, and can buffer the original
request until it gets the response. It
can use the replay of the message itself as the poll for the response replay.
Chris F: the application does not know anything about wsrm specifics, and URIs.
Paulf F: straw poll three options
0)
do nothing
1)
forbid anonymous reply to with offered sequences
(don’t support scenario 2)
2)
Fix Replay model without adding get message
3)
Support replay using get message.
Option 0 – none
Option 1 - 1
Option 2 – 4
Option 3 – 11
Ø
Action: Paul F will produce a detailed proposal for
i089 with usage of Get Message.
Ø
Action: Marc G will produce a detailed proposal for
i089 by fixing normal replay mechanism.
10
New issues raised since yesterday
10.1Bob F new
issue
Bob F raise new issue: http://lists.oasis-open.org/archives/ws-rx/200603/msg00185.html
Description
Modify definition of SequenceAcknowledgement:Final to
reflect accurate ending delivery capability status.
Justification
The protocol defines the SequenceAcknowledgement:Final
element which contains the final summary of message acknowledgements at the
closure of a sequence. It is assumed that the RMD has taken responsibility for
all messages that have been acknowledged.
Depending upon the operation of the RMD and its interface with the
application, Messages that have been previously acknowledged as received by the
RMD, may never be deliverable. One such
case of note that comes to mind is the situation of a message sequence that is
being delivered in-order to an application which is closed at the time when one
or more gaps that may exist in the sequence.
If this situation occurs, the RMS will have incorrect information
concerning exactly which messages have been or will be deliverable at the
conclusion of a sequence.
Note that there is nothing in the
spec that states what the RMS is to do with the information contained in SequenceAcknowledgement:Final. This proposal does not add any such
statement, but it does permit the information to be potentially interpretable.
Target: core
Proposal:
Reference Core Spec CD03
insert
after line 613:
SequenceAcknowledgemnt:Final shall identify only those messages that have
been delivered or which the RMD has taken responsibility for delivery without
regard to the previous acknowledgement status of any message.
State Table impact: None
Doug D: this is reopening the issue of DA. This is regarding delivery beyond RMD.
No objection to accept as a new issue.
10.2Semantics of Nack
http://lists.oasis-open.org/archives/ws-rx/200603/msg00193.html
Description:
The description of Nack implies but does not clearly state that a Nack acknowledges messages received of a lower sequence
number.
Justification:
Clarity
Proposal:
Ref spec CD03
Insert in line 621 after “by the Nack.”
Receipt of a NACK by the RMS
implicitly acknowledges all messages of sequence numbers lower than the lowest
sequence number contained in the Nack or Nacks.
State table impact: none
No objection to raise as new issue.
10.3Misplaced
Guidance on Fault Handling
http://lists.oasis-open.org/archives/ws-rx/200603/msg00201.html
Title: Misplaced guidance on fault
handling
Description:
Line 566 CD3 WS-RM spec (SeqAck section 3.6) reads:
If a non-mustUnderstand
fault occurs when processing an RM Header that was piggy-backed on
another
message, a fault MUST be generated, but the processing of the original
message
MUST NOT be affected.
First point, this text isn't very
clear. Second, it is IMO misplaced. It really should be called out separately
as it
applies to more than just SequenceAcks.
Justification:
This guidance is in the SeqAck section and really deserves to stand on its own as
it applies to any
RM header block that is piggy-backed
on a message unrelated to the Sequence.
Target: core
Proposal:
Strike sentence
beginning on line 566, through line 568.
Insert, after line 232:
When processing of an RM protocol
element generates a fault and that RM protocol element
pertains
to a Sequence that is otherwise unrelated to the message in which the protocol
element is contained,
(i.e. the
RM protocol element is a SequenceAcknowledgement or AcksRequested element) the receiving endpoint MUST continue
normal
processing the message unless the generated fault is a SOAP MustUnderstand
fault.
After matter:
Note that this says nothing about
transmission of the generated fault. I personally believe that we
should
leave well enough alone, however, I recognize that this MAY present
interoperability
issues,
especially in the case where both the [reply] endpoint and the [fault] endpoint
are
anonymous.
I COULD see adding guidance that says that when the above criteria are met
that the
endpoint MUST NOT transmit the fault to the anon endpoint UNLESS there is
no
response message to be transmitted
No objection to raising as a new
issue.
10.4Description of
sequence element
http://lists.oasis-open.org/archives/ws-rx/200603/msg00205.html
Title: The description of the
<Sequence/> element could use some wordsmithing.
Description: The description of the
Sequence element could use some wordsmithing.
Justification: It currently says
nothing of substantive meaning.
Target: core (CD3)
Proposal:
Change line 504 from:
This is the element containing
Sequence information for WS-ReliableMessaging.
to:
This protocol element associates
the message in which it is contained with a previously established RM Sequence.
It contains
the
Sequence's unique identifier and the containing message's ordinal position
within that Sequence.
No objection to raising as new
issue.
10.5Chris Miscelaneous
http://lists.oasis-open.org/archives/ws-rx/200603/msg00206.html
Title: editorial tweaks
Description:
suggested
editorial tweaks
Target: core (CD3 WS-RM)
Proposal:
change
line 141 from:
The protocol supports reliability
features which include ordered delivery, duplicate elimination, ...
to:
The protocol supports reliability
features that enable ordered delivery, duplicate elimination,
...
Change line 143:
In any case the wire protocol does
not change.
to:
Regardless of which of the
reliability features are employed, the wire protocol does not change.
Change line 218 from:
associated
acknowledgement may have been lost.
to:
associated
acknowledgement might have been lost.
Line 337: text is BLUE, should be
black.
Change line 370 from:
If the RM Source wishes to close
the Sequence then it sends a
to:
If the RM Source wishes to close
the Sequence, then it sends a
There are numerous places
throughout the specification where the term "Sequence"
uses
lower-case "S". I believe that all uses of the term Sequence should
be typographically
consistent
and use a capital "S".
s/sequence/Sequence/g
where the term is used as a noun.
I also spotted a couple of
instances where the term RM Source used a lower-case "s".
s/RM
source/RM Source/g
s/RM
destination/RM Destination/g
Change line 534 from:
The RM Source may request an
acknowledgement
to:
The RM Source MAY request an
acknowledgement
No objection to adding as new issue.
11
Plan for progressing State Table changes
Bob F: Matt gave a contribution to fix and clarify the state
tables. Matt, myself, and Tom Rutt will work on a more complete proposal for the amended
state tables.
Matt: we could have a contribution ready by the next teleconf call, on April 6.
Ø
Action: Matt, Bob, and Tom will provide an
amended state table before the April 6 teleconference.
12
Interop SC report
Paul F: I believe the interop SC should
provide a report.
Bob: have corner cases been exercised?
Stefan: we have just done the easy things to date.
Doug D: the report should show who participated, but the
result details should be anonymized.
There was no objection to the Interop
SC providing a report.
13
Issue 42 resolution
Issue 042 which ws-addressing
version
Bob WS-Addressing has achieved Proposed Recommendation
status, with the AC comment period ending April 18.
Proposal;
On or before April 20, update the ws-rm specification to refer to the W3C's current
WS-Addressing version.
It would be good to have the next interop event on the new spec since there is diminishing
doubt of its near-term acceptance.
Paul C: Perhaps rm could refer to
the input spec as well as the W3C output spec of ws
addressing. This could be the same as
referencing both versions of SOAP.
Jeff M; why would be want to do what Paul C suggests. There are big differences in PR version from
input version.
Paul C:where
are there differences.
Tom R: The epr format is
different.
Paul C: we should not orphan customers currently using the
input version of ws-addressing.
Anish: One main difference is the
semantics of anonymous URI. In the input
version the anon URI is meant to allow pointing at devices behind a NAT. Now anonymous is defined by the binding and
not the core.
Chris F: We should
not prohibit compositions with other versions of addressing. In the spec, where a normative reference is
required, we should use the new version (e.g., epr
schema type used in our message schema).
Dave O: While I can see a reason to support both versions, I
realize that this can make people slow in moving the the
new spec. This is now occurring with
Soap 1.2. At some point the industry
needs to make a decision to support just the w3c version. This provides an opportunity to show
commitment to moving forward, and people should consider this as a rationale
for supporting just the new ws-addressing spec.
Umit: Is Paul C suggesting use of
both ws-addressing specs at same time, or just to
support transition from old version to new.
Is the old version to be a normative reference.
Paul C: RM can reference both ws
addressing specs. I think profiles can
deal with the details of supporting only one version. I prefer to leave the option in the OASIS
spec.
Umit: I cannot agree with
requiring support for both versions of ws-addressing.
Paul C: we intend to support both implementations of
addressing with ws-rm. I would like to have the spec facilitate both.
Paul F: I believe non of the interop participants had problems with using 2004 version.
Doug D: we agreed to do that, it is not that we had no
problems.
Paul F: I believe it is ok to refer normatively to both
specs.
Tom Rutt: Companies can do
anything they want to support migration for their customers. However I see no way to allow two epr formats supported as normative conformance to this
spec.
Bob F: I move we reference the new w3c spec, leaving
reference to the prior specification, but deprecate its use. This allows continued claims of conformance
for the old spec.
Failed for lack of a second.
Paul C: with respect to Tom Rutt’s
concern, we would have to go to extreme cases to support one or the other. Supporting both namespaces will make life
difficult for implementers. I am
changing my position, and recommend that we substitute the w3c namespace for WSaddressing.
Paul F moved that the namespace be changed to the new w3c ws addressing spec.
Tom Rutt seconded.
§
No objections issue 042 closed by changing reference
to the PR w3c namespace and to refer to the new spec.
14 Discussion of Application Notes
Document
Jacques presented the latest version of the draft
application notes document, posted as:
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/17345/AppNotes-061-WSRM.doc
Jacques stated that he wants to separate discussion of the
detailed contents of the document (which is preliminary) from discussion of the
need for the document itself.
Jacques pointed to the ws-rf TC
application notes document.
Such a document can aid people in the understanding of the
base specification, and can include material which is considered out of scope
of the spec.
Paul F asked how much work was done in the WS-RF tc on this document.
Doug B: in the wsrf case three
editors did most of the work. The TC was
involved in the review.
Paul F: as member I have no problem, but as chair I have
concerns that this may take too much time.
Tom R: if the examples raise controversy, then the time
should be taken to discuss them. If the spec is stable and complete there
should be no great effort to review it.
Paul F: I would like to ensure that this document does not
delay progression of the Base specification.
Jacques: if it takes too long, the TC can postpone or delay
it. It does not have to be put on a
critical path.
Sanjay: we could initate a
subcommittee to produce such a document.
Paul F: If it is just an effort done by some members, with a
goal to produce a draft CD for vote by the TC. I do not want a schedule associated with this
document. It would be incumbent on the proposers to produce a document which can be voted as CD.
Doug D: from a quick reading, I have a concern that this
states things that are obvious from reading ws
addressing. If it is merely repeat of what ws addressing already
says, rather than a set of guidance to document things which had controversy in
the TC, I cannot support it. If it profides guidance on things this TC has grappled with (like
use of anonymous with offer) then I could accept it.
Jacques gave a summary on the contents. The focus is on how to identify different
ways the message patterns may be used. They
involve bindings to underlying protocol in ways that might be constrained (e.g.
case where the client can only initiate connections).
Marc G: I share some concerns with Doug D on content. I do not think delivering it on a separate
non CS track warrants the same level of review as the core spec. I am concerned about the scheduling impact
this will have on the spec. I do not
want to be here another year. We should
be able to stop once we reach CS on the base spec.
Jacques: we can get some experience information from WS-RF
on how much work this entailed. It does
not have to take a long time.
Paul F: I agree with Marc G that we delay the progression of
the spec. I think a Primer might be a
better document. Perhaps we can take the
interop scenarios, clean them up and document what we
learned during interop exercise, as an alternative
approach.
Paul C: I cannot discuss this without the content. But I see it talking about binding examples. Is the problem that the spec is not clear how
to do the bindings. If it gives general advice to do things
different that our product, that will impact interop
with our implementation.
Tom: what if one implementation only supports synchronous
reliable request response, while another only supports asynch
one way. Can they interoperate.
Paul C: my concern is that making these bindings visible,
may make some think that is the preferred way to do things.
Gil: one example is the deadlock problem found during the interop..It would be a shame if
that knowledge disappeared after this meeting.
Having a place to allow people to read and benefit from our experience
is usefule.
Paul F: the benefit to focus this on the interop
document is that it is focused on our tc
process. The schedule for this would be
tied to the interop work. The only thing to add for CD is to add the
additional notes to give guidance to people, on this.
Doug D: without a document to look at we are talking about
nothing. In order to move this along,
concerns have been express already. It
should be up to them to see if they can cross the threshold to make this a
useful document.
Tom: do the interop scenarios
cover both cases of using ack requested for
stimulating acks, vs having
the rmd send acks at normal
intervals. In general I think Paul F
idea is good, to have the application notes reflect what is learned in the inteorp scenarios.
Paul F: the scenarios make no such prescriptions,
the idea is to test if different assumptions made by the implementations can
cause interop problems.
Tom R: can the interop SC post in
an accessible place the interop scenario document.
Ø
Action: Paul F will post a version of interop Scenario document on Kavi
for access by entire TC.
Sanjay: straw poll, should this be pursued further with a
second example.
Yes: 7
No 0
Paul C: I do not know what my position is. I do not know
whether it would affect interop. I do not think the
TC has stated it is for it yet. All I
can conclude is that perspective authors can come up with a new version to let
us decide.
Tom: once Paul F posts an accessible version of the interop scenarios Fujitsu can try to make the application
notes more related to those scenarios.
15
Planning Disussion
Paul F posted the following timeline:
March 31st Next WD ready for review
April 6th Ballot for CD/PR
April 14th PR begins
June 13th = PR ends
June 19th = Final pre-CS draft
ready for review (with non-substantive
changes)
June 29 = CS ballot starts
July 6th = CS ballot ends
Chairs to run around
July 14 Submission to OASIS
Paul C: are we going to public review before we resolve all
our our own issues?
Peter N: the first public review is 60 days,
however the subsequent ones are allowed to be much shorter.
Chris F: If we do not have 89 done, we should not go to
public review. Other, non consequential
issues may not be as important.
Paul C: If we are going to the public for review, it is not
good to do that with outstanding issues, (with perhaps a note to not comment on
them because they are being worked). To
avoid excessive effort to track public comments, the editorial issues should already
be resolved.
Marc G: I thought that the goal of this meeting was to
resolve all issues so we could go to public review. I always thought we would resolve all issues
before putting out for public review.
Chris F: we need to make sure we address all the technical
issues, and in preference to resolve the editorial issues. If we scheduled a
vote for cd in a week, which prompts a slew of
editorial comments, then we are probably not ready.
Jeff M: I hear agreement on the pre conditions for public
review.
Chris F: want deadline for TC member comments to be first.
Timeline after discussion
·
N All
issues closed
·
N+1 Next
WD x ready for review
·
N+2 Deadline
for TC member comment
·
N+4 New
WD y
·
N+5 Ballot
closed CD / WD y, (with conditional Public review ballot)
·
N+5.14 PR
begins
·
M = N+14 PR ends (interop 2
during back end or PR)
·
M+1 Final
pre-CS draft ready for review (with non-substantive changes)
·
M+2 CS
ballot starts
·
M+3 CS
ballot ends, Chairs to run around
·
August 14 Submission to OASIS
Chris F: we might consider a Face To Face in the May time
frame (perhaps with the OASIS symposium).
Paul C: does this schedule give the interop
SC enough time for the next interop?
Paul F: from a spec perspective the Interop
SC has sufficient flexibility.
Paul F: due to change to adopt w3c addressing, I move we
change the namespace for schema in our next CD, seconded by Chris F.
Chris F: we can now pick a namespace for the next CD, and
keep it stable until it changes.
§
No objections, motion to change namespace passed.
Ø
Action: have editors get a new namespace for
next CD, given the use of ws addressing PR
Anish: there is a possibility for
change in w3c from PR to rec.
Jeff M : lets not worry until it
occurs, the worst that will happen it we have to change the namespace.
Tom: When will the next F2F be?
Paul F: it should be just before the Public Review. We cannot set the date at this time.
Paul C: it is possible to get thru to CS without another
Face To Face meeting. This would require
action items for each issue to ensure we have proposals for discussion on
conference calls.
16
Discussion of issues Resumed
I089
I104
Mixing Soap.
I105 Seq acks
after close
I106 Final Deliverable
I107 Acks Nacks
Nacks Acks
I108 guidance on fault handling
I109 Description of sequence
I110 Chris Editorial Rant part 1.
16.1I109
Description of sequence
http://lists.oasis-open.org/archives/ws-rx/200603/msg00205.html
Chris moved, Anish
seconded to accept proposal Proposal:
Change line 504 from:
This is the element containing Sequence information for WS-ReliableMessaging.
to:
This protocol element associates the message in which it is
contained with a previously established RM Sequence. It contains
the Sequence's unique identifier
and the containing message's ordinal position within that Sequence.
§
No opposition, issue 109 closed by accepting
proposal.
16.2I107 Acks Nacks Nacks
Acks
http://lists.oasis-open.org/archives/ws-rx/200603/msg00193.html
Amended proposal after discussion
and wordsmithing
Ref spec CD03
Insert in line 621 after “by the Nack.”
“Receipt of a Nack by the RMS implicitly acknowledges all message numbers within the sequence lower than the lowest message number contained in the Nack or Nacks.”
Doug B: I am concerned that the RMD can only use the NACK if
there is a single gap.
Chris F: the spec allows multiple nack
elements.
Doug B: the schema seems to disagree.
Doug D: the schema says max occurs = unbounded.
Doug B: the schema in the PDF version is wrong.
Doug D: the “unbounded” decoration is on the next line,
since it wraped.
Sanjay: why cannot nack 2 and nack 4 mean receipt of 1 and 3.
Gil: we were motivated by the rms
being able to get a snapshot of the entire sequence, which was resolved by not
using Nack. It
seems we might have removed the motiviation for
changing the semantics of Nack as already stated. I think we should close with no changes.
Chris F: I still think there is value in understanding that
a Nack explicitly resolves the earlier message
numbers. I am happy with the proposed
text above. I could also see a use case
for stating that all non nack messages lower than the
highest in the nack list are received.
Paul F: with the ack requested
agreement yesterday, I agree with Gil we do not need to constrain the semantics
of Nack in this way.
Anish: I agree with Gil. A nack just a nack, and should not be constituted as implying receipt of
other messages. This new requirement
will cause more complex implementation, in that it takes a freedom away from
the RMD.
Bob F: When I read the Nack text
it states it allows the rms to do gap analysis. In the way that it is written, the other
messages have been received. An alternative
to the text above, would be to clarify the nack text by removing all words about gap analysis. Just state that it stimulates the
retransmission of the request. It should
not be closed without action.
Paul F: striking the seconde sentence (lines 616
to 618) does the job.
Anish moved (seconded by Matt) to
strike second sentence (lines 616 618 in CD 3) “This element … in certain
environments”.
§ No objection to closing issue 107 with
proposal to strike sentence on lines 616 thru 618.
16.3Issue I108 Misplaced guidance on
fault handling
http://lists.oasis-open.org/archives/ws-rx/200603/msg00212.html
>
Strike sentence beginning on line 566, through line 568.
>
> Insert, after line 232:
>
> When processing of an RM protocol element generates a fault and that
RM protocol element pertains to a Sequence that is otherwise unrelated to the
message in which the protocol element is contained, (i.e. the RM
protocol element is a SequenceAcknowledgement or AcksRequested
element) the receiving endpoint MUST continue normal processing the message
unless the generated fault is a SOAP MustUnderstand fault.
DougD pointed out that the same text
is present under Request Acks section.
I would therefore amend my proposal to add:
Strike sentence beginning on
line 537 and continuing through 539.
There was
considerable discussion on the new proposed text.
Ø
Action:
Chris F and Anish will propose appropriate text for resolution
of I108.
16.4I 110 Chris F Editorials.
Line 141 change agreed
as Editorial.
Line 143 change
agreed as Editorial
Line 218 change
agreed as Editorial
Line 337 change
agreed as Editorial.
Line 370 change
agreed as Editorial
Agreed to consitently use “S” in word sequence when used as noun.
Agreed to change on
RM source to RM Source
Agree on Line 534
issue as editorial.
Paul C moved to
accept all proposed changes for I104 as proposed by Chris F, seconded by Bob.
No objection issue
104 closed with proposed change.
16.5Issue 104 mixing soap and/or wsa versions
http://lists.oasis-open.org/archives/ws-rx/200603/msg00174.html
Title: Mixing SOAP and/or WS-A versions
Description:
You may end up with both SOAP 1.1 and SOAP 1.2 across a sequence. The
same applies to WS-A versions.
Justification:
Suppose the RMS starts a sequence in SOAP 1.2. The RMD may initiate
messages (e.g. SequenceAcknowledgement). Those could
be in SOAP 1.1.
Should we allow mixing SOAP types? Probably not.
We could recommend that the SOAP style in place for the CS should used for the rest of the sequence.
Target: core
Type: design
Proposal:
From CD-3.
between lines 241-2 insert new para:
The SOAP and WS-Addressing versions used for the CreateSequence
message SHOULD remain in place for all future interactions between the RMS and
RMD, including messages initiated by the RMD (e.g. <wsrm:SequenceAcknowledgement>
and faults).
Related issues: None
Paul F stated he is
not happy with the exact wording of his proposal above.
Chris F: soap 1.2
has a clearly defined fault for this case. It would be good to nail down what soap
version is used for our protocol elements. However we should strongly discourage
supporting multiple soap versions on the same sequence..
Doug D: Since
sequence can span multiple client endpoints, there is a use case for multiple
soap versions on a sequence. In a
gateway implementation, an rm manager should not have
to change soap version for reliable messages its receives
and adds rm headers for.
Paul F: I prefer
separate sequences for each soap version in this use case. Do not mix soap
versions within a sequence.
Paul C: I propose
that all messages in a sequence SHOULD use the same soap version as the create
sequence.
Anish: both soap 1.1 and soap 1.2 have version
mismatch faults.
Chris F: I prefer
to keep a single version of soap for an entire sequence.
"The SOAP version used for the CreateSequence message SHOULD be used for all subsequent messages in and for that Sequence, send by either the RMS or the RMD.”
Tom: why is it a
SHOULD rather than a MUST.
Doug D: I want
SHOULD, to enable some specific use cases I have in mind.
Considerable
discussion ensued on the rationale for SHOULD in the requirement.
Doug D moved, Matt seconded to add
new parat: "The SOAP version used for the CreateSequence message SHOULD be used for all subsequent
messages in and for that Sequence, send by either the RMS or the RMD.” between lines
241 and 242.
§
No objection motion to close 104 with proposed
change approved.
Chair moved to thank IBM, with special recognition to Marc
Comer, seconded by Paul C.
§ Unanimous consent to thank IBM for excellent
hosting arrangements.
16.6I105 – Sequence acks after close.
http://lists.oasis-open.org/archives/ws-rx/200603/msg00179.html
Proposal:
From CD-3.
At lines 373-377 replace the above text with:
"Upon receipt of this message, or subsequent to the RM Destination
closing the Sequence of its own volition, the RM Destination MUST include a
final SequenceAcknowledgement (that MUST include the
<wsrm:Final> element) header block on any
messages *associated with the Sequence* destined to the RM Source, including the
CloseSequenceResponse message *or* on any Sequence
Fault transmitted to the RMS."
The added/modified text is within * *.
Chris F moved to accept proposal above to close i105,
seconded by Gil.
§
No objection i105 being closed with proposed
change.
16.7Owners for proposals on
open issues.
I 89 (Paul F, Marc
G) next call,
I 96 – (Matt Lovett)
next call
I105 – seq acks after close.(proposal already formulated)
I106 – final Ack (Bob)
I108 Guidance on
Fault handling (Chris ) next call.
Meeting adjourned
at 4:00 PM.