Preliminary Minutes of WS-RX TC Weekly Conference Call
Date: Thursday, 01 September 2005
Time: 01:00pm - 02:30pm PT
1
Roll Call
<recorded in Kavi>
Meeting is Quorate.
2
Review and approval of the agenda
Agenda:
1) Roll Call
2) Review and approval of the agenda
3) Approval of the Aug 25, 2005 meeting minutes
http://www.oasis-open.org/committees/download.php/14226/Minutes-wsrx-082505.htm
4) Administrative Issues
a> Volunteers for sponsoring dial-in facility for future calls
5) AI Review
http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php
6) Pending business from mailing list
a) Motion to form an implementation subcommittee
http://lists.oasis-open.org/archives/ws-rx/200508/msg00252.html
7) New issues since last conf-call
http://lists.oasis-open.org/archives/ws-rx/200508/msg00326.html
8) Issue Discussion: Assign owner and discuss resolution
a> i004 wsa:messageID uniqueness requirments for retransmission
http://www.oasis-open.org/committees/download.php/14147/ReliableMessagingIssues.xml#i004
b> i001 Bilateral sequence negotiation
http://www.oasis-open.org/committees/download.php/14147/ReliableMessagingIssues.xml#i001
c> i019 Sequence termination on Fault
http://www.oasis-open.org/committees/download.php/14147/ReliableMessagingIssues.xml#i019
d> i028 Accurate final acknowledgement of a Sequence with gaps when RMS decides to stop using it
http://www.oasis-open.org/committees/download.php/14147/ReliableMessagingIssues.xml#i028
e> i005 Source resend of nacks messages when ack already received
http://www.oasis-open.org/committees/download.php/14147/ReliableMessagingIssues.xml#i005
f> i012 Anonymous acksTo
http://www.oasis-open.org/committees/download.php/14147/ReliableMessagingIssues.xml#i012
9) Any other business
No suggested changes.
Marc G asked that we limit debate, to allow time to get thru all issues.
3
Approval of the Aug 25, 2005 meeting minutes
http://www.oasis-open.org/committees/download.php/14226/Minutes-wsrx-082505.htm
Tom Rutt moved to approve the minutes, Anish seconded.
No opposition, minutes approved.
4
Administrative Issues
a> Volunteers for sponsoring dial-in facility for future calls
TC members are requested to volunteer for the calls. Members should send mail to either of the co chairs.
5
AI Review
http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php
#0002: OASIS Staff should fix typographical error in charter of missing space between “produces” and “do” the next time the charter is updated.
Owner: James Bryce Clark
Status: Open – no fixed yet.
Assigned: 2005-07-06
Due: 2005-07-08
#0012: Chair took an action item to get a ruling from Jamie on CVS repository usage.
Owner: Paul Fremantle
Status: Open – still waiting for OASIS timetable for CVS. No updated yet from Chris Kurt.
Assigned: 2005-07-17
Due: ---
#0013: Chairs will propose a mechanism to manage the Queue on the conference calls.
Owner: Sanjay Patil
Status: Closed – Use Doug Davis chat room
Assigned: 2005-07-17
Due: ---
Glen D asked for the feasibility of using the chat room log as a means for taking minutes. Tom Rutt suggested it be put on the agenda, for he would like to explain the efficiencies of working on off a template prepared before the meeting.
#0024: Provide concrete proposal for issue "InOrder delivery assurance spanning multiple sequences"
Owner: Andreas Bjarlestam
Status: Open
Assigned: 2005-08-12
Due: 2005-08-25
#0025: Propose a "namespace change policy" for the schemas produced by the TC
Owner: Christopher Ferris
Status: Open
Assigned: 2005-08-23
Due: ---
#0026: Propose new resolution to I005, reflecting TC discussion
Owner: Steve Winkler
Status: Open
Assigned: 2005-08-29
Due: ---
#0027: Propose resolution for both I0019 and i0028
Owner: Doug Davis
Status: Closed
Assigned: 2005-08-29
Due: ---
6
Pending business from mailing list
a) Motion to form an implementation subcommittee
http://lists.oasis-open.org/archives/ws-rx/200508/msg00252.html
Motion text from Marc G, seconded by Chris Ferris on list:
For the RX TC to produce WS-RM as an OASIS Standard it must per the OASIS TC Process rule 3.4.f [1] certify that at least three member organizations are successfully using the specification. The RX TC should establish an implementation subcommittee that will update the contributed interop scenarios documents [2] (starting with the most recent) against the WS-RM specification output by the committee. The final scenarios should cover major WS-RM features and need not exhaustively document corner cases. Participants in the subcommittee and other TC members are encouraged to implement the scenarios as they are refined. The subcommittee should keep records of successful use of the scenarios to have documented proof to meet the above cited OASIS requirement.
1 OASIS TC Process Section 3.4 [
http://www.oasis-0pen.org/committees/process.php#3.4 ]
2 Contributed interop scenarios [
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/13478/www.oasis-open.orgappsorgworkgroupws-rxemailarchives200507zip00000.zip ]
Sanjay asked if there are any specific deliverables in the charter.
Tom Rutt stated that a SC can only make proposals to the TC, which must make all decisions regarding any SC output.
Sanjay asked for any opposition. There was none.
Action: chairs will set up SC with OASIS Staff, and make announcement to TC when it is set up.
Interested members should join this SC using the Kavi website.
7
New issues since last conf-call
http://lists.oasis-open.org/archives/ws-rx/200508/msg00326.html
7.1
proposed-01
Chris Ferris presented the following email. Discussion from the meeting is not indented.
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200508/msg00251.html
Title: What are the obligations on RMD for use (or not) of Offered Sequence?
Description: When an RMD accepts an offer of a bilateral Sequence, is it Obligated to use that Sequence for response messages to the endpoint that requested creation of the Sequence in which the offer was made?
Justification: The text in section 3.4 makes no mention of the obligations, if any that the RMD has in accepting a CreateSequence with an Offer. The text at 480(pdf) reads:
/wsrm:CreateSequence/wsrm:Offer
This element, if present, enables an RM Source to offer a corresponding Sequence for the reliable exchange of messages transmitted from RM Destination to RM Source.
Target: core
Type: design
Proposal: As the wsrm:Offer is intended as an optimization, I believe that the RMD should be under no obligation to actually use the offered Sequence. Similarly, I believe that it should be made clear in the spec that the RMS MUST NOT presume that the offered Sequence will actually be used to ensure that there are no interop issues that might arise from one implementation making such an assumption and another that chooses not to use the offered Sequence (for what ever reason). I suppose that we *could* devise a wsrm:Decline child of wsrm:CreateSequence as a courtesy to the RMS that made the offer so that it could reclaim the associated resources rather than having to wait until the offered (but unused) Sequence expired. That would make it abundantly clear that there was no association. If we pursued the wsrm:Decline, then the text around lines 536-566 will need to be fixed accordingly.
Anish stated that there is no way for the RMD to indicate to sender that it will accept sequence, but reject the offer.
Chris F: That is correct, as part of the proposal we could add a decline mechanism
Sanjay: we can fix that in the resolution of this issue.
No objection to adding this as an issue for the TC.
7.2
proposed-02
Chris Ferris presented the following email: Meeting discussion is shown as not indented.
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200508/msg00285.html
Title: Inconsistency between spec and schema (AckRequested)
Description: There is an inconsistency between the spec and the schema for the child element of the <AckRequested> directive. Is the child element wsrm:MaxMessageNumberUsed (as per the schema) or is it wsrm:MessageNumber as per the spec?
Here’s the prose from line 427 (pdf) of the wsrm spec:
/wsrm:AckRequested/wsrm:MessageNumber
This optional element, if present, MUST contain an xs:unsignedLong representing the highest
<MessageNumber> sent by the RM Source within a Sequence. If present, it MAY be treated as a
hint to the RM Destination as an optimization to the process of preparing to transmit a
<SequenceAcknowledgement>.
Here’s the relevant fragment from the schema:
<xs:complexType name=”AckRequestedType”>
<xs:sequence>
<xs:element ref=”wsrm:Identifier”/>
<xs:element name=”MaxMessageNumberUsed” type=”xs:unsignedLong”
minOccurs=”0”/>
<xs:any namespace=”##other” processContents=”lax” minOccurs=”0”
maxOccurs=”unbounded”/>
</xs:sequence>
<xs:anyAttribute namespace=”##other” processContents=”lax”/>
</xs:complexType>
Justification: there is a clear discrepancy between the spec and the schema
Target: core, schema
Type: editorial
Proposal: I believe the intent was to have the element named as per the schema. Change the text at line 427 as follows:
/wsrm:AckRequested/wsrm:MaxMessageNumberUsed
This optional element, if present, MUST contain an xs:unsignedLong representing the highest
<MessageNumber> sent by the RM Source within a Sequence. If present, it MAY be treated as a
hint to the RM Destination as an optimization to the process of preparing to transmit a
<SequenceAcknowledgement>.
No objections to TC acceptance as an issue. Issue will be added to the issues list.
7.3
Proposed-03
Chris F presented the following email. Discussion from meeting is shown as non indented.
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200508/msg00299.html
Title: protocol serialization optimization proposal
Description:
I’ve been thinking a bit about how we might optimize the serialization of the elements in the protocol; doing so without actually changing the abstract properties of the protocol itself.
Here’s what we have today:
<wsrm:Sequence xmlns:wsrm=”http://docs.oasis-open.org/wsrx/@@@”;>
<wsrm:Identifier>http://example.org/mysequence/1234</wsrm:Identifier>
<wsrm:MessageNumber>1</wsrm:MessageNumber>
<wsrm:LastMessage/>
</wsrm:Sequence>
I think that if the properties were serialized as attributes, we would have a much more compact serialization:
<wsrm:Sequence xmlns:wsrm=”http://docs.oasis-open.org/wsrx/@@@”;
seqID=”http://example.org/mysequence/1234”; msgNum=”1”
last=”true”/>
The ooleanation savings for a Sequence element is 91 bytes per message.
For the SequenceAcknowledgement, we could collapse the acknowledgement range elements into a single attribute value that was a sequence of integers. E.g in the simplest case, here would be an example SeqAck:
<wsrm:SequenceAcknowledgement
xmlns:wsrm=”http://docs.oasis-open.org/wsrx/@@@”;
seqID=”http://example.org/mysequence/1234”; ranges=”1 1 3 10”>
where the @ranges attribute is a list of unsignedLongs. E.g.
<xs:simpleType name=’rangeType’>
<xs:list itemType=’xs:unsignedLong’/>
</xs:simpleType>
The ranges are expressed as “low hi low hi low hi …”
In the example above, message #2, 3 and 4 are missing. Here’s an example of a nack:
<wsrm:SequenceAcknowledgement
xmlns:wsrm=”http://docs.oasis-open.org/wsrx/@@@”;
seqID=”http://example.org/mysequence/1234”; nack=”2 3 4”>
The savings on the SequenceAcknowledgement are 99 bytes/message using the optimized serialization for a SequenceAcknowledgement with no gaps, 148 bytes for one with one gap, 195 bytes for one with two gaps, and 242 for one with three. Basically, it boils down to an additional 47 bytes per gap (in this case using namespace prefix of wsrm) or 42 bytes using the default namespace.
Justification:
The point of this proposal is not limited to byte savings of serialization.
Rather, it has more to do with the efficiency with which the protocol properties can be serialized and deserialized. Especially with the @range attribute, there are far fewer nodes involved.
In terms of creation/serialization performance, I found an average savings in serialization (using java) of:
Sequence - .0478 ms
SequenceAcknowledgement (with 2 gaps) - .19765 ms
I haven’t had a chance to assess parsing performance benefits yet, but I have to imagine that there would be some benefit.
Sure, scoff if you will, but in the context of an server implementation processing a gazillion messages, the performance savings are non-trivial.
Think about providing RM support for a customer such as a Ford or FedEx.
The sheer volume of messages that they expect to be able to process daily is mind-boggling.
Of course, in the context of a message with a WS-Security header, the RM performance and bandwidth overhead pales in comparison for the processing of the overall message, but IMO, there’s no reason that RM should exacerbate the issue. If there is a performance and bandwidth optimization that we could effect without actually changing the protocol, I think we should give it serious consideration.
As for extensibility, we could still have the Sequence and SequenceAcknowledgement elements extensible via both attributes and elements. There’s no reason to change that.
Target: core, schema
Type: design
Proposal: This isn’t fully fleshed out in terms of line numbers and prose, etc. However, the gist would be to have the protocol elements be as follows:
<wsrm:Sequence seqID=”[xs:anyURI]”
msgNum=”[xs:unsignedLong]”
last=”[xs:oolean]”? …/>
<xs:simpleType name=’rangeType’>
<xs:list itemType=’xs:unsignedLong’/>
</xs:simpleType>
<!—The ranges are expressed as “low hi low hi low hi …” à
<wsrm:SequenceAcknowledgement seqID=”[xs:anyURI]”
[ranges=”[wsrm:rangeType]”|nack=”[wsrm:rangeType]”] …/>
<wsrm:AckRequested seqID=”[xs:anyURI]”
msgNum=”[xs:unsignedLong]”? …/>
Tom Rutt asked if any tools have limits on list sizes, which would impact the use of attribute for ranges.
Chris F stated he knew of no problems.
No objection to accepting this as a new issue.
----------------------------------------------------------------------------------------------------------
7.4
Use Case Issues
I have no idea how the use cases that were sent in are expected to be logged, for reference here they are.
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200508/msg00277.html
Broker Interface
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200508/msg00278.html
Commodity Quotes Service
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200508/msg00279.html
Smartphone Subscribes to Service
Sanjay prposed that TC members go over these use cases, and we should spend some time at each meeting to discuss each use case as to its acceptability.
Tom Suggested people respond on the mailing list if there are any concerns on the use cases.
Doug B stated we should assign owners to the newly accepted
issues.
Proposed 01 – Chris F agreed to be owner
Proposed 02 – Assign to editing team to propose resolution
Proposed 03 – Chris F agreed to be owner
Action: Editors to propose a resolution to proposed 02 for voting at the next meeting.
8
Issue Discussion: Assign owner and discuss
resolution
Sanjay asked if there was any discussion on this order of
discussing issues. None was asserted
8.1
a>
i004 wsa:messageID uniqueness requirements
for retransmission
http://www.oasis-open.org/committees/download.php/14147/ReliableMessagingIssues.xml#i004
Sanjay noted that there has been considerable discussion on the email list for this issue. Some members suggested communication to the wsa group about the usage of MessageId.
Anish: He sent a recent email on this. WSA group had considerable discussion on this, and came up with the current wording. They wanted other specs to make any required constraints. However, he stated it is not important to distinguish message ID from any other header of body element. We do not currently state in the spec that the seqID/messageNO an be used to detect duplicates, and is allowed to ignore them, dependent on DA. This requires a contract on wsrm side, which does not allow change to message content, otherwise things that rely on wsrm might break. Even a note would be sufficient. He does not see a need to tie us into a knot, we should just say what wsrm should do.
Sanjay: are you stating there is a need to clarify the spec with this issue.
Anish: the fundamental issue is that messageID is no different than any other soap header element of body element. The wsrm layer should not change things in the message.
Marc G: we should close this issue and move on, there is no specific dependency on wsa:messageID. If someone wants to ask wsa group to change, they must realize it as at CR level and will be hard to change.
Jacques: there are two things mixed, The semantics of retransmission itself is broader than this issue. The term retransmission as it stands is vague and could be clarified, but that could be another issue. There is a consensus that wsa WG did not take a position on retransmission. I see issue i004 as a composability issue with ws addressing, and the issue is more within the ws addressing spec. They should make it clear that if messageID changes it can cause problems in other specs. I propose that the wsrx spec does not need to say anything, but that the tc should send a request for clarification to ws addressing.
Jonathan: I am on the wsa WG. The only place that retransmission is discussed is in the security section. Otherwise it states nothing about retransmission. What the wsa spec does state that the messageID uniquely identifies the message.. WSA spec does not want to deal with retransmission, the same message on five walls should have the same message ID. The wsa could not agree on scope of comparison of uniqueness for the Receiver to detect re-use of same messageID>
Jacques: Has the text from the input document to wsa been changed.
Jonathan: the current text no longer talks about retransmission in the section on message ID.
Giovanni: There are a variety of message contents that should not change in retransmission. The earlier discussion was on whether we need explicit clarification on message ID. Many elements being changed would cause a problem I would prefer a generic explanation of what retransmission means. I believer we could close this issue with no change.
Chris F: I agree with Giovanni. The security guys might want the timestamp to change in the retransmission. The RM spec should not be concerned about the details of other spec’s headers. The seqID/messageNo has to be the same on a retransmission, that is all the wsrm spec needs to say.
Bob Freund: I was part of the wSA WG discussion. There are use cases where a receiver may want to do something other than throw away on receipt of a duplicate. WSA did not want to specify behaviour on receipt of a duplicate Message ID>
Sanjay: there seems to be consensus that this issue can be closed with no change.
Jacques: I understand we cannot be too proscriptive here. However, WSA:messageID could cause specific problems.
Tom Rutt: this issue was actually raised in our TC before the wsa group resolved their own issue on messageID. I believe the current text in ws addressing has fixed any problem.
Jacques: I can live with the resolution.
Sanjay asked if there was any objection to closing this issue with no change required.
Doug B asked if we were accepting the proposed text from Marc.
Tom Rutt stated that the proposed resolution is to close issue with no change required to text.
There was No objection to closing this issue with no change required.
8.2
b>
i001 Bilateral sequence negotiation
http://www.oasis-open.org/committees/download.php/14147/ReliableMessagingIssues.xml#i001
Chris F: there was a proposal by Lei to delete 221 until 226 in WS-RM spec on the web site.
Marc G: with the new issue that Chris raised today on “offer” in the core spec, I would rather defer resolution of this issue until after resolving that one.
Chris F: I do not think that one is really dependent on the other.
Marc G: that depends on what clarification are made regarding the “offer”.
Chris F: Suppose RMD has no obligation, however there might be an obligation for RMS to provide the offer if it is in the WSDL.
Doug D: This text should be removed, the other issue is a standalone issue.
Anish: From my memory, these lines to be removed are about when two way sequences are established. I do not see how this relates to the new issue from Chris F.
Marc G: These lines could be changed rather than removed by the new issue. We need to discuss them at the same time.
Sanjay: there is the ability to add new text resulting from the resolution of the new issue. I would suggest we hold this i001 as standalone.
Marc G: I express a concern in the context of the new issue. I prefer we hold off to discuss this after the resolution of the new issue.
Chris F: I am concerned about our not being able to discuss issues in sequence, because some other issue potentially might change the text in another way. These issues are orthogonal, closing i001 does not affect the resolution of the other. One is for RMD other is RMS.
Chris F moved to close issue with accept resolution from Lei, Tom Seconded.
Sanjay: there is a motion to strike specific line numbers from the doc. We need to make a vote on this.
< roll call vote by Sanjay >
25 yes, some abstains, no objections.
Motion passes, issue i001 moved to pending with removal of lines.
8.3
c>
i019 Sequence termination on Fault
http://www.oasis-open.org/committees/download.php/14147/ReliableMessagingIssues.xml#i019
8.4
d>
i028 Accurate final acknowledgement of a
Sequence with gaps when RMS decides to stop using it
http://www.oasis-open.org/committees/download.php/14147/ReliableMessagingIssues.xml#i028
8.5
e>
i005 Source resend of nacks messages
when ack already received
http://www.oasis-open.org/committees/download.php/14147/ReliableMessagingIssues.xml#i005
8.6
f> i012
Anonymous acksTo
http://www.oasis-open.org/committees/download.php/14147/ReliableMessagingIssues.xml#i012
9
9) Any
other business
Tom Asked if there was any need to reaffirm the co chair,
Paul F, who recently changed companies..
Paul F stated that Jamie Clark told him that unless the
oasis membership of a chair lapses, there is no problem with that person remaining
co-chair.
Chris K: If there was a period of time when our co-chair
would not have been able to participate, there might have been a problem.. If the majority of group wanted to make a
change we could do so. However, I agree
that an implicit decision to take no action has the same affect.
Paul F: I was on leave of absence while on vacation. The
rules allow a small grace period.
Chris K : I just
wanted to clarify that the TC always has a choice of a chair.
Tom: It seems clear if we do nothing official, Paul remains
co-chair.
Bob F: I move we adjourn the meeting.
Tom Rutt seconded.
Meeting adjourned.