Minutes WSRM TC Final Conference Call Apr 10, 2007
Textual Conventions
Ψ Action Item
Motion
§ Resolution
5
Consider Progression Draft Deployment Profile
for Intelligent appliances
6
Discusssion mechanics
of committee future
Attendance:
|
First Name |
Last Name |
Role |
Company |
|
Jacques |
Durand |
Secretary |
Fujitsu Limited* |
|
Kazunori |
Iwasa |
Voting Member |
Fujitsu Limited* |
|
Tom |
Rutt |
Chair |
Fujitsu Limited* |
|
Robert |
Freund |
Voting Member |
Hitachi, Ltd. |
|
Eisaku |
Nishiyama |
Voting Member |
Hitachi, Ltd. |
|
Nobuyuki |
Yamamoto |
Voting Member |
Hitachi, Ltd. |
|
Pete |
Wenzel |
Voting Member |
Sun Microsystems |
Meeting is quorate
The minutes of the April 3 teleconference meeting (with Iwasa correction) are posted at: http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/23451/MinutesWsrmTC-040307R1.htm
Bob
F moved to
approve the April 3 minutes, Iwas seconded.
No opposition April 3 minutes are approved
Action 1: Jacques to arrange for OASIS staff to post CD 01 for application notes correct OASIS url. done
available
here:
http://docs.oasis-open.org/wsrm/ws-reliability/v1.1/cd01/application-notes-cd-01.pdf
http://docs.oasis-open.org/wsrm/ws-reliability/v1.1/cd01/application-notes-cd-01.doc
http://docs.oasis-open.org/wsrm/ws-reliability/v1.1/cd01/application-notes-cd-01.html
as
well as here:
http://docs.oasis-open.org/wsrm/ws-reliability/v1.1/application-notes.pdf
http://docs.oasis-open.org/wsrm/ws-reliability/v1.1/application-notes.doc
http://docs.oasis-open.org/wsrm/ws-reliability/v1.1/application-notes.html
Action 2 on Tom is update public site to ensure it has up to date links.open.
Added links to errata, app notes, and Intap external reference link for profile for information appliances
This gives a Japanese Language pages.
Iwasa they may add an English link on that page
Closed.
Action: Jacques and Iwsasa to consult OASIS staff about IPR discussion. Iwasa will distribute mail from OASIS staff. done
http://www.oasis-open.org/apps/org/workgroup/wsrm/email/archives/200704/msg00017.html
All,
I had the following action item today's telecon:
> Action: Jacques to consult OASIS staff about IPR discussion. - Open Iwasa
will distribute mail from OASIS staff.
Here is the e-mail from Jamie.
I believe the concern is resolved.
Thanks,
Iwasa
----- Original Message -----
From: "James Bryce Clark" <jamie.clark@oasis-open.org>
To: "Durand, Jacques R." <JDurand@us.fujitsu.com>
Cc: <mary.mcrae@oasis-open.org>; <tom@coastin.com>;
"iwasa"
<kiwasa@jp.fujitsu.com>
Sent: Thursday, March 29, 2007 2:47 AM
Subject: Re: Process questions for WSRM TC
> Hello Jacques. I am in
> correspondence. Under the 1999 OASIS IPR Policy, which I believe
> applies to that TC, an OASIS member is welcome to contribute work
> from others, as long as it (the contributing OASIS member)
> understands that it is, itself, making the assurance under our
> policy that the work is available for use, in the manner our rules
> require and with any necessary disclosures. (There are quite a few
> examples, including , BPEL4WS v1.1 and some Liberty Alliance work,
> that were originated *from* a group of entities not all being OASIS
> members .... This was no problem, because in each case the OASIS
> members who made the contribution were responsible for assuring that
> the contribution satisfied all OASIS input rules.
> So, by posting this to the TC, Fujitsu is offering its assurance
> that (a) the contribution is permitted by INTAP and its various
> originators/owners, and (b) it will be available to OASIS and
> implementers on the terms required by OASIS' 1999 Policy; and (c)
> any required disclosures of claim are made (if indeed any are
> necessary).
> As to (c), please note that (as we've discussed) it's been
> acceptable to OASIS in the past to carry forward the pre-existing
> copyright notices of other organizations. See, for example,
> copyright notices in the OASIS UDDI v3.x standards. You noted to me
> that INTAP retains no claim in the work to be contributed: but it
> certainly could retain its own copyright notice if it wishes,
> without undermining the rights OASIS acquires to
> reuse/reprint/derive from it under our policy.
>
> Please feel free to inquire further if needed. It's our
> assumption that Fujitsu (and INTAP) are aware of and satisfied with
> the effects of our policy.
> Of course, the TC's decision thereafter, to approve it or use it
> in any way, is entirely a question for the TC.
> Regards JBC
>
> ~ James Bryce Clark
> ~ Director of Standards Development, OASIS
> ~ jamie.clark@oasis-open.org
>
> Durand, Jacques R. wrote:
> > Just a reminder we would like to double-check with you that the
> > WSRM TC can accept this contribution from an org (INTAP) that is
> > not OASIS member, without problem.
> > - The goal is to reuse material from this INTAP contribution in a
> > coming Committee draft.
> > ***
> > Here is a copy of the letter from INTAP rep, to WSRM TC chair: ***
>
Iwasa
posted an issues list at:
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/23358/IssueListForProfiles0.1.pdf
The
base Template Candidate CD refered to in the
"T" issues in the list is:
The
base Proposed CD for Information appliance profile, referred to in
the "P" issues
in the list is:
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/23275/wsr-profile-ias02.pdf
Proposed issue resolutions and modified documents posted by Iwasa as:
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/23436/wsr-profiles-20070409.zip
Title (if any) 4.1.1 Profile Item (b) (resending) seems too much.
Raised by Bob Freund,
Target document Deployment Profile Template Version1.0 for WS-Reliability1.1
2 April 2007
Issue Description line 101: (in 4.1.1 Profile Element: Usage of At-Least-Once)
"Profile Item (b) (resending)" seems too much.
Propose Resolution Proposal 1) Iwasa:
Remove the Profile Item (b) column in 101 and the texts inside the column.
And add the following text to the right column of "Notes" in the table in Line101 at 4.1.1:
"You may describe if there is any other requirement (e.g., Number of retries, Interval between retries, and others)."
Proposal 2) Tom:
Delete the entire row for profile item (b) in section 4.1.1 and its columns. Add the following statement to the right column of Notes in section 4.1.1:
"Describe any mechanisms whereby the user of the deployed implementation may exercise control of resending behavior."
The proposal 2) will be the resolution in the new specs.
Resolution Proposed Resolution 2) is incorporated in the new specs.
Status Updated specs are on the table for CD voting.
Jacques: some rosettanet users want guidance on such things
Bob: proposal 2 goes beyond the specification of a wire profile or the spec itself. It talks about feature that may or may not be present in api.
Tom: this is for the implementation to record such an implementation.
Bob: Its not necessary, but is is useful at all.
Jacqeus: this is a compliance document, allowing all possible entries they might want to agree on. Some implementations may want to get agreement on resending parameters. It does not cover everything, but only things which relate to spec. Resending is assumed by the spec.
Jacqeus we could Ignore it if there are concerns.
Bob I am willing to stand aside to consensus.
Tom: anyone could not accept proposal 2.
Iwase moves to accept proposal 2, Jacques seconded.
No opposition, proposal 2 accepted.
Title (if any) I cannot understand the intention of "Profile Item (b)" in 105.
Raised by Bob
Freund,
Target document Deployment Profile Template Version1.0 for WS-Reliability1.1
2 April 2007
Issue Description line 105: (in 4.1.3 Profile Element: Usage of At-Most-Once)
I cannot understand the intention of "Profile Item (b)". It could be reliable request-response MEP because it mentioned "cached response", but it is unclear.
Propose Resolution Proposal 1) Iwasa:
Remove the Profile Item (b) column in 105 and the texts inside the column.
Proposal 2) Tom:
Change the second column of profile item b) row in Section 4.1.3 from:
"What is the behavior of a receiving RMP when a duplicate request is received, for which a response had already been previously sent? (is a Fault be sent back? Or a duplicate of the cached response?)
RECOMMENDED / REQUIRED"
to:
"Which of the following statements describes the behavior of the
implementation of a receiving RMP when a duplicate request message, which requires a response, is received:
1) an application fault is always sent as response to the duplicate message
2) a limited cache of sent responses is used to allow resend of the prior response, when this cache is exhausted, an application fault is sent in response to duplicate message
3) all sent responses are cached until the expiry time for the original request message
4) other - please describe an alternative behavior regarding the response sent after receipt of duplicate response"
The proposal 2) will be the resolution in the new specs.
Resolution Proposed Resolution 2) is incorporated in the new specs.
Status Updated specs are on the table for CD voting.
Tom: Any questions or concerns on Proposal 2.
Bob: a minor one. This document has to be prefaced by clarification that all are valid options. This may give user indication that there might be interop issues. This is a minor concern.
Tom: it does not affect interop, but it affects the quality of what one gets.
Tom: is there anyone that cannot live with proposal 2.
Iwasa moved to accept proposal 2, no second Motion Fails.
Bob moved to delete the entire row, Iwasa seconded.
No opposition, agreed to delete entire row.
Title (if any) There are blank row in line 131: (in 5 Operational Aspect of the Profile)
Raised by Bob
Freund,
Target document Deployment Profile Template Version1.0 for WS-Reliability1.1
2 April 2007
Issue Description line 131: (in 5 Operational Aspect of the Profile)
In some tables, the last row is blank
Propose Resolution Iwasa: Remove the blank column in section 5.3, 5.4, and 5.5
Resolution Proposed Resolution is incorporated in the new specs.
Status Updated specs are on the table for CD voting.
Title (if any) Explanation of SPIA Forum
Raised by Bob
Freund,
Target document Deployment Profile of Information Appliances Services for WS-Reliability1.1 Version1.0, 2 April 2007
Issue Description line 62: (in 2 Overview of the Profile)
Since the phrase "SPIA Forum" is not defined nor described, the audience of this document could not recognize what was "SPIA Forum".
Propose Resolution Iwasa: Add the following sentence just after the sentence mentioning SPIA Forum first (line 62 just after "in SPIA Forum."):
"SPIA Forum is a not-for-profit forum to standardize Service Platform for Information Appliances."
Resolution Proposed Resolution is incorporated in the new specs.
Status Updated specs are on the table for CD voting.
Title (if any) Figure number is incorrect
Raised by Bob
Freund,
Target document Deployment Profile of Information Appliances Services for WS-Reliability1.1 Version1.0, 2 April 2007
Issue Description line 79: (in 2.1 General Objectives)
Figure number is incorrect.
Propose Resolution Iwasa: Replace the following sentence in 79:
"Figure 1.1 shows the Use case of Reliable Web Services Messaging."
To:
"The following figure shows the Use case of Reliable Web Services Messaging."
Resolution Proposed Resolution is incorporated in the new specs.
Status Updated specs are on the table for CD voting.
Title (if any) The "(*) One-WAY:" seems a footnote for the following Chart 3.
Raised by Bob
Freund,
Target document Deployment Profile of Information Appliances Services for WS-Reliability1.1 Version1.0, 2 April 2007
Issue Description line 136: (in 2.3.2 Use case：Registration and Operation ...
just before Chart 3)
The "(*) One-WAY:" seems a footnote
for the following Chart 3.
Propose Resolution Iwasa: Move the sentence just after the Chart3.
Resolution Proposed Resolution is incorporated in the new specs.
Status Updated specs are on the table for CD voting.
Title (if any) Figure number is incorrect.
Raised by Bob
Freund,
Target document Deployment Profile of Information Appliances Services for WS-Reliability1.1 Version1.0, 2 April 2007
Issue Description line 218: (in 2.5 The Scope of this profile)
Figure number is incorrect.
Propose Resolution Iwasa: Replace the following sentence in 218:
"The scope of this profile is described in Figure1.5."
To:
"The scope of this profile is described in following figure."
Resolution Proposed Resolution is incorporated in the new specs.
Status Updated specs are on the table for CD voting.
Title (if any) A pair of N/A in the table seems no sense.
Raised by Bob
Freund,
Target document Deployment Profile of Information Appliances Services for WS-Reliability1.1 Version1.0, 2 April 2007
Issue Description line 345: (in 5.4 Profile Management)
A pair of N/A in the table seems no sense.
Propose Resolution Iwasa: Remove the two N/As and those columns from the table in section5.4. And add "N/A" to the right column just after "Recommended or required practices."
Resolution Proposed Resolution is incorporated in the new specs.
Status Updated specs are on the table for CD voting.
Title (if any) The reason to refer ebMSGuide is unclear.
Raised by Bob
Freund,
Target document Deployment Profile of Information Appliances Services for WS-Reliability1.1 Version1.0, 2 April 2007
Issue Description line 358: (in 6.2 Non-Normative References)
ebMSGuide is not mentioned at all in this document.
The reason to refer ebMSGuide is unclear.
Propose Resolution Iwasa: Remove the entire 6.2 section.
Resolution Proposed Resolution is incorporated in the new specs.
Status Updated specs are on the table for CD voting.
Title (if any) Reference to [RFC2119] is missing in line25.
Raised by Kazunori Iwasa, Fujitsu
Target document Deployment Profile of Information Appliances Services for WS-Reliability1.1 Version1.0, 2 April 2007
Issue Description Line 25 is missing a reference to [RFC2119].
Propose Resolution Iwasa: Add "[RFC2119]." at the end of line 25.
Resolution Proposed Resolution is incorporated in the new specs.
Status Updated specs are on the table for CD voting.
Tom: is there any objection to accepting the rest of the issue resolutions.
No objection to accepting rest of issues t3 thru P7 as editorial.
Pete there is still Japanese character set resolutions in the text. Some figures I cannot change.
They show up in PDF incorrectly. They show up OK in the word, the font is MS-Minchau.
Figure 5 and chart 5 cannot be corrected from the Word. They use a font not available in PDF.
We should only approve the word document.
Need to apply issue resolution T2 to the proposed draft from iwasa zip file to remove the
Line 5b)
Bob: I would want to clarify that this is independent judgment on keeping link to INTAP profile.
Tom: that link is there from previous agreement, and unless a motion is made to remove it will stay.
Iwasa I move to make template doc to cd with resolution to T2 applied , Seconded by Pete.
Jacques: yes
Iwasa: yes
Tom: Yes
Bob: Abstain
Nishiama: Yes
Yamamoty Yes
Wenzel Yes.
Motion passes. 6 of 8 voting members yes
Need to apply issue resolution T2 to the actual proles.
No comments.
Iwasa moved to make CD with update to resolution T2, Jacques Seconded.
Jacques; yes
Iwasa: yes
Tom: yes
Bob: Abstain
Nishaima Yes
Yamamoty Yes
Wenzel Abstain
motion passes.5 of 8 voting members yes
Action: Iwasa to Update these two CD documents to post on the CD site.
Action: Tom to update site to point to new CDs.
Agreed to Allow Two days to register objection by email.
Deadline is Friday 5: PM EDT.
Tom will state in minutes.