[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Prelim minutes of wsrx tc meeting 7/14/2005
Prelim minutes are attached. Please post any correctinos before the end of the week. I will post the minutes on the server on monday. Tom Rutt -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133Title: Preliminary Minutes OASIS (WS-RX) TC formation meeting
|
Preliminary Minutes OASIS WS-RX TC Weekly Conference Call Date: Thursday, 14 July 2005 Time: 01:00pm - 02:30pm PT Draft Agenda: PASSCODE: 27894 0 ConventionsMinutes Style Conventions Motion text § Motion Resolution text Ø Action item text Ø Potential new issue Text: Tom Rutt agreed to take the minutes. 1 Roll callRoll Call:
79% voting members, achieved quorum. 2 Review and Approval of AgendaAgenda Agenda
for this weeks call 1. Roll Call & Quorum 2. Review and approval of Agenda 3. Approval of the minutes of Prior
meetings 4. Call in numbers for future calls. 5. Update on next F2F http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00065.html 6. Update from editors team 7. Update on the issues list http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/13598/ReliableMessagingIssues.xml a) accept new issues b) review of issues list c) discussion of issue prioritization 8. Action Item review http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php 9. Discussion of the following four
issues: Ø Potential issue a> Source
based delivery QoS policy assertion http://lists.oasis-open.org/archives/ws-rx/200506/msg00055.html Ø Potential issue b> Destination
to declare delivery QoS policies http://lists.oasis-open.org/archives/ws-rx/200506/msg00046.html Ø Potential Issue c> Granularity
(per operation vs. per portType) of delivery QoS policies http://lists.oasis-open.org/archives/ws-rx/200506/msg00053.html Ø Potential Issue d> Single
sequence to span multiple ports http://lists.oasis-open.org/archives/ws-rx/200506/msg00059.html 10. Any other business. Paul C wanted to report on the
arrangements for the F2F in 0 Approval of the minutes of Face to Face and Teleconf 7/7/05Minutes of Face to Face meeting: http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/13388/MinutesWSRXFormation.htm Tom Rutt moved, Paul Knight seconded to approve face to face minutes. § No object face to face minutes approved. Minutes of 7/7/2005 Teleconference: http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/13536/MinutesWSRX070705-b.htm
Chris F moved to approve, Anish seconded. §
No objection ,minutes
of teleconf 7/705 approved. 1
Call in numbers for future calls.
Novel will host next two calls. July 21 and 28. Adobe will host afterwards. 2
Update on next F2F
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00065.html waited for Paul Cotton to arrive. Paul asked the chairs to have a KAVI ballot to determine who will come. Ø Actioin: Chairs should start a KAVI ballot asking members if they will attend the Face to Face meeting, either in person or by teleconference. Paul Stated there will be a conference phone in the room. He can provide a conference phone. 3
Update from editors team
Gil stated that the editors went thru the editorial issues, and posted a resulting set of editorial issues to the list. Jeff had question about the repository. Does the oasis policy apply. Duane Nicol: they do not have such a facility yet. Jeff: we need to be sure we do things according to the rules. Marc G: the BPEL repository was set up by IBM, and transferred to source forge. The just use it as a cvs repository. Anything released is thru the oasis document store. Jeff M: it is a little more complicated. BPEL is under different IPR policy than ws-rx TC. Ø Paul F: Chair took an action item to get a ruling from Jamie on CVS repository usage. Steve W: we wanted a cvs repository to track the changes between versions. Marc G: there are some problems with having everyone on TC to access the source forge CVS repository. Peter F: members of BPEL have access to the repository. Chris K: I would propose to ask the chairs to look into this and not spend time on it in the TC meeting. Jeff M and I can work with OASIS staff to expedite the discussion. 4
Update on the issues list
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/13598/ReliableMessagingIssues.xml
Sanjip ran the discussion: He asked Marc G to review the issues list. Doug B expressed a concern that the document was not posted with the correct attributes. Tom Rutt stated he did not get an html rendering in Firefox. 4.1 a) accept new issuesMarc G stated the new issues which came up this week were editorial, including the Editor’s issues. Below are the new issues raised since the July 7th
TC call and the July 14th TC call. 4.1.1
Title:
typo in expires P0S
Description: per the schema spec a zero second duration needs to have the
"T" designator - so it should be PT0S not P0S. http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00046.html
§ No opposition to accepting as new issue 4.1.2
Title:
typo in Interop scenario 3.2 example
Clarification - the document is Interop
Scenario 3, not the main spec. The section is at the end of 3.2 This one is an easy fix - the first example of a
message had one visible error - an extra white space after the two
"--" of the comment. |<!-- BEGIN: 128-bit
key K encrypted using public key of SERVICE -- >| http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00061.html
Concern expressed that this document is not a deliverable.
Do not accept at this time as new issue. 4.1.3
Title:
anonymous acksTo
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00066.html
§ No objection to accepting anonymous acksTo as new issue 4.1.4
Title:
Max message number in policy
Description: define a policy assertion that defines the highest message number the
RM destination will accept. http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00073.html
Doug B: I would like to have this issue deal with
whether a system has to support unsigned long. Chris F: I
would like to have a separate issue “Can implementation support less than
unsigned long?” Shivagy:: There
could be another issue regarding support of types as a more general issue. Chris
F: the issues should be relevant to deliverables of TC. We need to discuss at this level whether the
issue is understandable. § Agreed to add this as an issue. Shivagy: : can
raise a newer issue which raises his thoughts. Doug B: some issues
can be made irrelevant by resolutions of other issues. I agree to move ahead with this issue. Doug
B can capture his issue. 4.1.5
Title:
Document Names
Description: Should the “names” of the normative documents remain the same as the
submission documents or should they be changed? This issue applies to both WS-ReliableMessaging and WS-RM Policy. Justification: The “name” of a document effects a number of
things such as the document identifier, URIs etc. Target: core, policy Type: editorial Proposal: Preserve the name of the documents as submitted. Changing the names
would increase confusion (already at a high level) around “OASIS and RM” and
result in extra effort. There does not seem to be any reasons for changing the
names forcefull enough to override these concerns.
Therefore the names of the normative documents should be “Web Services Reliable
Messaging Protocol (WS-ReliableMessaging)” and “Web
Services Reliable Messaging Policy Assertion (WS-RM Policy)” http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00090.html
§ No objection to adding as an issue. 4.1.6
Title:
Required Artifact Metadata
Description: OASIS guidelines (http://www.oasis-open.org/committees/download.php/13344/ArtifactIdentificationRequirements-v1.0-wd-15.pdf)
require that the artifacts (documents, schemas, etc.) produced by a TC should
have a minimum set of of metadata that describes
these artifacts. Justification: OASIS requirement. Target: core, policy Type: editorial Proposal: We propose the following values for each specification: WS-ReliableMessaging: artifactName: TBD tc: TBD product: wsreliablemessaging productVersion: 01 artifactType: spec stage: wd descriptiveName: Web Services Reliable Messaging Protocol
Specification WS-RM Policy: artifactName: TBD tc: TBD product: wsrmpolicy productVersion: 01 artifactType: spec stage: wd descriptiveName: Web Services Reliable Messaging Policy Assertion
Specification Note that the “product names” of these two
artifacts differ. http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00091.html
§ Agreed to add as an issue 4.1.7
Title:
Document Identifiers
Description: The artifacts (documents, schemas, etc.) produced by the WS-RX must be
uniquely identified. We need to decide on the identifiers for WS-ReliableMessaging and WS-RM Policy. Justification: Self-evident. Target: core, policy Type: editorial Proposal: According to the OASIS guidelines and in light of the proposed
artifact metadata, the documents should currently be identified as: wsreliablemessaging-01-spec-wd-01.* wsrmpolicy-01-spec-wd-01.* Note that some identifiers may have the final
sub-version removed. The “*” indicates that these documents may be formatted in
either HTML (.html) or PDF (.pdf). http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00092.html
§ Agreed to add as a new issue. 4.1.8
Title:
XML Namespace URIs
Description: We need to decide upon the normative XML namespace URIs
that must be used by implementations of these specifications. Justification: Self-evident. Target: all Type: editorial Proposal: The namespace URIs for WS-RX-defined schemas
should be URLs that resolve to RDDL documents that provide information about
the schema as well as links to the corresponding specification(s). Per OASIS
guidelines, the RDDL documents must be hosted by OASIS. Therefore the exact URL
values will need to be co-ordinated with OASIS but,
in general, they should look something like the following: xmlns:wsrm=”http://www.oasis-open.org/committees/ws-rx/wsreliablemessaging-200507.html” xmlns:wsrmp=”http://www.oasis-open.org/committees/ws-rx/wsrmpolicy-200507.html” Note that the “200507” in the URL is represents the
schema version as a date (July, 2005). http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00093.html
§ Agreed to add as a new issue. 4.2 b) review of issues listThe issue list was corrected so it renders in Firefox. 4.3 c) discussion of issue prioritizationMarc G: we might want to spend some time to decide which issues can be tackled first. I have not attempted to do this yet. Gil: I have a preferred approach to put requirements issues at the top of the priority. This can save a lot of future effort if a requirement is not accepted. Sanjip: we should give more time to come up with high level areas which pertain to the issues. At future calls we can look at all the issues. Paul F: at this time our main point is to capture as many issues as possible. Sanjip I encourage TC members to bring their major issue to the table very soon. Paul F: I suggest we work by email to prioritize the issues list. Members should have email discussion, terminating on Monday morning, regarding which issues they want to discuss at the next call. Bob F: we need to have short discussions to assign owners to each Issue. The owner can lead the email discussions. Paul F: I urge TC members to address their issue priorities to the list before Monday morning. Paul F: the chairs will post issues to be Sanjip: TC members should send their issue priority discussion before Monday morning, and the chairs will 5
Action Item review
http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php Paul F pointed out that the two KAVI ballots on proposed
charger changes were initiated by OASIS Staff. #0010: Add Four new issues a thru c
from TC meeting 7/7/05 Owner: Marc Goodner Status: Closed Assigned: 2005-07-08 Due: 2005-07-14 #0009: Suggest Email Template for Proposed Issues Owner: Marc Goodner Status: Closed Assigned: 2005-07-08 Due: 2005-07-14 #0008: Prepare First TC Issues List Owner: Marc Goodner Status: Closed Assigned: 2005-07-08 Due: 2005-07-14 #0007: Sanjay to set up editing team Subcommittee or mailing
list Owner: Sanjay Patil Status: Still Open Assigned: 2005-07-08 Due: 2005-07-14 #0002: OASIS Staff should fix typographical error in charter
of missing space between “produces” and “to” the next time the charter is
updated. Owner: James Bryce Clark Status: Still Open Assigned: 2005-07-06 Due: 2005-07-08 6
Discussion of the following four issues:
6.1
Issue 6 Source based delivery QoS policy assertion
http://lists.oasis-open.org/archives/ws-rx/200506/msg00055.html Tom Rutt posted a new email to open discussion on this issue, as: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00108.html Tom Rutt was assigned as owner of the issue. Tom Rutt gave an overview of the email discussion. Here is a more precise statement
about the real issue at the core of i006
"How does the RM Destination
know which level of Delivery assurance to associate with a received
message?" We can't just discard this question
as only relevant to the implementation space, especially if the assumptions
below are valid: - I expect an RM Destination to
handle concurrently several sequences associated with different delivery
assurances (DA) (driven by different WS operation requirements, e.g. InOrder or not, but also by - Even if we assume that some DA is
statically assigned to an endpoint, a layered implementation (see discussion
below) of the RM destination component should not have to peak inside the
message body or other headers to figure the DA. RM Header data such as Sequence
ID should be sufficient. - Assuming all messages within a sequence as associated with the same delivery assurance (DA) (assumed in WS-RM Policy), it is not clear how the RM Destination associates a new sequence ID with a DA, when answering a SequenceCreation request from the Source. Chris F: currently RM granularity applies to a port. Currently there is no way to have different qos per port. Chrif F : there will be a single sequence at a time per port typically. But the spec is designed around the concept of one for one with port. Chris F: the endpoint can implement a given level of delivery assurance. Tom R: Even with qos per endpoint – there might be a need to have the reliable source and destination communicate their level of qos. That is the point of the second bullet in the summary above. Gill: there are runtime tradeoffs which the source may want to take away ordered delivery. I do not see a real win with adding duplicate elimination. Tom R: with the current ws-rm protocol you are correct that duplicate elimination adds no cost over guaranteed deliver, since it has to hold the entire history of which sequence numbers were already delivered. However, ordered delivery requires message buffering. Jeff M: Do we know what an endpoint is. Is it that identified by EPR. Paul F: this is another complex point. Paul F: we have ran out of time, lets take this discussion to the email list. Umit: we need to have a better way to determine the meeting speaker queue. Not everyone is on irc. Ø
Action: Chairs will propose a mechanism to
manage the Queue on the conference calls. 6.2
Issue 9 Destination
to declare delivery QoS policies
http://lists.oasis-open.org/archives/ws-rx/200506/msg00046.html No time to discuss 6.3
Issue 8> Granularity (per operation vs.
per portType) of delivery QoS
policies
http://lists.oasis-open.org/archives/ws-rx/200506/msg00053.html No time to discuss 6.4
Issue 10> Single sequence to span multiple
ports
http://lists.oasis-open.org/archives/ws-rx/200506/msg00059.html No time to discuss 7 Any other business.Meeting adjourned at 2:30 pacific time. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]