Preliminary Minutes WSRX TC Teleconf
October 27, 2005
Tom Rutt agreed to take the
minutes.
From Kavi,
Meeting is
Quorate
2
Review and approve of Agenda
1) Roll Call
2) Review and approval of the
agenda
3) Approval of the Oct 20, 2005
meeting minutes
http://www.oasis-open.org/committees/download.php/15061/MinutesWSRX-102005.htm
4) Administrative Issues
a> Review the CD I ballot result
b> Reminder for the Sunnyvale
F2F ballot (closes on 10/31)
5) AI Review
6) Whether this TC should use wsrx or wsrm as the [product]
token in the namespace pattern http://docs.oasis-open.org/[product]/yyyymm/
Jamie Clark to describe on the call
7) New issues since last conf-call
8) Issue Discussion:
a> i010: Sequence port spanning
b> i042: Which version of
WS-Addressing spec?
c> i053: Which occurances within the specs, if any, of the term
"URI" need to be replaced with "IRI"?
d> i050: spec talks about
delivery assurances but does not clearly relate them to the protocol
e> i002: AckTo
EPR and seq lifetime
f> i022: RM Policy Assertion
Model's Base Retransmission Interval Clarification Needed
g> i023: Robust recovery from
low-resource conditions
9) Any other business
Marc G suggested moving issue 50 to discussion at end, since
there is no agreed proposal yet.
No objection, Issue 50 moved to end.
Bob F stated to discuss issue 22 near the front.
Sanjay asked that it be kept the same, since protocol issues
should be discussed first before policy issues.
Anish: I need to start discussion
on issue 002. I would like to have this
be deferred to next call.
Agreed to move Issue 002 out of discussion
for this meeting.
3
Approval of Oct 20 meeting minutes
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/15061/MinutesWSRX-102005.htm
Tom R moved, Charlton B seconded to approve the Minutes of
Oct 20 meeting.
§
No
objection, Minutes of Oct 20 meeting Approved.
4
Administrative Issues
Ballot for WSRMP wd as CD 41 yes votes, 1 abstain, 72 % yes votes.
Ballot for WSRM wd as CD 42 yes, 78% yes, votes.
Both WDs are now approved Committee Drafts.
Sanjay:: the drafts need to be edited to change the status on the
cover page:
There were no
objections to updating the status on the cover page.
Paul C suggested
posting links on the home page to the CDs.
Agreed
that the links to CD will be put on home page.
Tom R stated he
would help Anish decide how to update the web site
with CDs.
Doug D will make a
new WD which restructures the text from the CD.
Doug D stated that
the future working drafts will proceed before we have a next CD ballot.
4.2 Reminder
for the Sunnyvale
F2F ballot (closes on 10/31)
Sanjay asked that
all members post their vote on this ballot before the end of the month.
Jacques stated he
needs to know how many people will be attending.
5
AI Review
http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php
#0012: Chair took an action item to get a ruling from Jamie
on CVS repository usage.
Owner: Paul Fremantle
Status: Keep Open
Assigned: 2005-07-17
Due: ---
#0031: Open two issues around cancel / fill proposal and use
cases
Owner: Stefan Batres
Status: Keep Open
Assigned: 2005-09-21
Due: 2005-09-29
#0034: Abbie to raise new issue to
have state diagram in the spec.
Owner: Abbie Barbir
Status: Closed
Assigned: 2005-09-27
Due: ---
#0040: Ashok to write proposed
clarification text on meaning of observed in this spec.
Owner: Ashok Malhotra
Status: Closed
Assigned: 2005-09-27
Due: ---
#0041: Doug D will write new issue to characterize the
piggybacking of acks when using an anonymous AcksTo
Owner: Doug Davis
Status: Closed
Assigned: 2005-09-27
Due: ---
#0050: Jacques will raise new issue on the nature of
reliable message endpoints
Owner: Jacques Durand
Status: Closed
Assigned: 2005-10-25
Due: ---
6
Product token discussion
Whether this TC should use wsrx
or wsrm as the [product] token in the namespace
pattern http://docs.oasis-open.org/[product]/yyyymm/
Jamie Clark : OASIS Staff:
We are trying to regularize our naming of documents. TAB and staff have been articulating a more
detailed set of rules, which are coming.
However filenames and uri values are of
particular interest.
A normative production rule based naming scheme concept is
not likely from OASIS. Different TCs have different ways of carving the universe.
The TC short name is used in the namespace scheme for
documents. We rely on that token for the
TC name. All of our work is available
only on terms bound to TC in question.
This TC needs to use ws-rx in the
namespaces for our documents.
Sanjay: currently we have namespace uri
which uses wsrm.
The token should be WS-RX in the tc
position.
Paul C: the wsrm could
remain.
Jamie: there is already a wsrm TC , so we need to avoid confusion with work of that
TC. We have not yet faced the issue of
whether wsrm as token creates problems.
Tom: the wsrm TC produce is
WS-reliability, so there is no problem with this ws-rx
to use a product name.
Paul C: is it ws-rx or wsrx.
Jamie: it is ws-rx.
Paul C: I suggest we insert ws-rx after .org/ in our namespaces to
distinguish the TC.
Jamie: that solves most of our problems. There might also be an issue regarding the
name ws-rm.
Tom: Jamie should raise this with the WSrm
tc. They can answer your question.
Tom: Does it matter for the CD posting if the documents are
named appropriately.
Sanjay: it is up to the TC at this time.
Add Issue in the document identifiers in the document, and
get documented.
Jamie : do it in the next pass.
Umit: we would like to defer to
the next one.
Tom: Document Id on the cover page might be the only change
for now.
Ψ
Action: Sanjay will work with editors to propose
a new issue on the topic of using TC name in all document namespaces.
.
7
New Issues since last con call
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200510/msg00258.html
7.1
Proposed-01
From Abbie:
Title: State Transition Table
Description:
The current specification has an example of message exchange
between two ends. The example represents a subset of possible states that the
protocol can transition to. It is left to the reader/implementor
to verify all the possible states of the protocol.
Justification:
A full state transition table is needed in order to ensure
proper design of the reliable protocol.
Proposal:
To produce such a table.
No comments.
No objection to accept as TC issue.
Agreed to accept as new TC issue, with Tom
R as owner.
7.2
Proposed-02
From Bob F:
Title: Retransmission
behavior
Description:
The Core specification depends on message retransmission by
the RMS of unacknowledged messages in order for a reliable exchange to be
accomplished, yet does not describe this behavior in any way. Discuss and
conclude the manner and the location for such an exposition in the core
specification.
No comments.
No objections.
Agreed to accept proposed 02 as new issue,
Bob F as owner.
7.3
Proposed-03
From Jacques:
Title: Definition for "Reliable Message"
Description: there are several references to "reliable
message" (section 1, 2 intro, 2.1, 2.3) that are not backed by a clear
definition.
Justification: Terminology section is defining key concepts,
yet does not explain what a reliable message is (and now other definitions are
also referencing "reliable message"). The main requirement of
inclusion of a wsrm:Sequence
element which could back an intuitive definition, is not currently related to
this expression at all, (related to DA instead) which is confusing.
Target: core
Type: editorial
Proposal:
1- Add a terminology entry. It could be:
Reliable message: a message submitted by the Application
Source to an RM Source via the "Send" operation,
for transmission over the protocol
defined in this specification.
2- In 3.1:
associate the main protocol requirement (Sequence element) with the definition
of "reliable message" instead of with a vague requirement of being
subject to some DA:
Replace:
"Messages for which the delivery assurance applies MUST
contain a <wsrm:Sequence>
header block."
With:
"Reliable Messages MUST contain a <wsrm:Sequence> header
block."
(DA and protocol being in fact separately defined, DA should
now more abstractly mandate the use of "reliable messages" if we
still want to pre-req one to the other.)
No objections to accept.
Agreed to accept Proposed 03 as new issue,
owner Jacques.
Chris F: I would like to point out some other new issues
which missed the cutoff.
7.4
Other new issues
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200510/msg00267.html
Agreed to accept msg00268 as new issue for TC, with Doug D as
owner.
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200510/msg00268.html
Agreed to accept with Doug D as owner.
8
Issue Discussion:
8.1
a> i010:
Sequence port spanning
http://www.oasis-open.org/committees/download.php/15045/ReliableMessagingIssues.xml#i010
Proposal from Doug D: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200510/msg00266.html
Doug D summarized the proposal.
Doug D moved to accepts mesg 266
to resolve issue i010, anish seconded.
§
No objection, motion to resolve i010 with msg 266 passed.
Issue to be marked as pending.
8.2
b> i042:
Which version of WS-Addressing spec?
http://www.oasis-open.org/committees/download.php/15045/ReliableMessagingIssues.xml#i042
Marc G stated to defer updating this spec to later, and
defer this issue.
Motion to accept Marc proposal http://lists.oasis-open.org/archives/ws-rx/200510/msg00208.html ,Paul C
Motion: Defer updating references to WS-A at this time. We
should reopen this issue after WS-A progresses to Proposed Recommendation with
the intention of updating the reference when WS-A reaches REC status.
Anish msg
264 as amendment , seconded by Marc G.
I would like to support this motion with but with an important
caveat/friendly amendment:
Given the importance of the version of WS-Addressing for interop, in
deferring this issue I would like to record the sense of the TC (if
TC agrees to do so) that for the Implementation SC and interop
events/efforts, the TC will be cognizant of the changes that have been
made to the WS-Addressing spec by the WS-Addressing WG. For example,
Reference Properties have been removed, the syntactic structure of an
EPR has changed, the default Action value for faults, default Action
algorithm for WSDL, defaulting of wsa:To has changed. Wherever possible
the interop effort will adopt the recent changes that have been made to
WS-Addressing.
Ammendment passed.
No objection to amended motion, so it passes. Issue 42 will be marked as Deferred
8.3
c> i053:
Which occurances within the specs,
if any, of the term "URI"
need to be replaced with
"IRI"?
http://www.oasis-open.org/committees/download.php/15045/ReliableMessagingIssues.xml#i053
http://lists.oasis-open.org/archives/ws-rx/200510/msg00216.html
Here are the
references to URI that should and should not be updated to IRI for the CD draft
of WS-RM [1]:
111: keep URI
122: IRI
123: IRI
124: keep URI
291: IRI (this
one appears to be a substantial change.)
321: keep URI
357: IRI
(following line 291)
451: IRI
(following line 291)
511: IRI
(following line 291)
556: IRI
(following line 291)
613: IRI
(following line 291)
656: IRI
(following line 291)
695: IRI
Plus of course
add the reference to the IRI spec.
Motion by Marc G, seconded by Rebecca to accept proposal in
msg216 to resolve i053..
Umit: Will this
hurt existing implementations?
Doug B: this is also affecting the infrastructure that one
uses.
Chris F: first way is to adopt sense of group, defer and
resolve when we adopte ws addr. Second way is
to just do it now. I would be inclined
to do it now. When we adopt ws-addr we will have to do it then. A profile could constrain use. We should not subset ws-addressing
arbitrarily.
Paul C: To send rm to people who
have uris in iri format then we have to do this. If adoption of this might impact someones use of this spec, means we should do it now rather
than later. I would like to make this
change now.
Jonathan: there are two types of changes, referencing things
from other specs, and the other is about the types defined as anyURI for out protocol.
I suggest we make anyURI to state in the prose
that is it IRI. The schema is ambiguous already, the way w3c resolves this is to state in text that
they are IRIs.
Dave O: The situations will be movement of entire
stacks. Our new spec could go in lock
step with the new ws-addressing. Do the changes in lock step with ws-addr.
Umit: I would like to defer this
to later, making this change does an impact.
Use IRI for things we refer to.
Anish: I do not understand what is
difference between Marc G email above and what we are
talking about now?
Paul C: The schema defined for contributed version , if it has anyURI you can
already us IRI for that.
Anish::
there is a constraint with the schema in prose whenever we have anyURI that it must be a absolute URI value.
Paul C: You are saying that the proposed text in our spec
subtypes anyURI so it does not permit all values that
the schema type permits.
Anish: Yes.
Jonathan: we do restrict the types to absolute, with ascii chars. It has to be pre escaped when you put URI in
the attribute.
Jonathan: I do advocate adopting the entire proposal now.
Gil: Is Umit proposing an amendment.
Umit: I do not think it is an amendment. It would be a separate proposal.
Chris F: I speak for the motion.
Umit: I would like to defer the
resolution of this vote to some later time.
Sanjay: should we really do that.
Sanjay: are vendors ready to adopt IRIs
is a major question.
Chris F: We should not disenfranchise the portion of the
globe which chooses to use IRIs.
Jonathan: one of the reasons IRIs are interesting, beyond I18N, is that people were putting in
chars that are not ascii chars. There is an issue as to whether the
infrastructure has to deal with this correctly. Most platforms deal with these
characters and to the % escaping. IRI
spec states how to do the % excaping.
Sanjay asked if there would be a no vote on this motion.
Umit: I would like to investigate
a possible alternative.
Anish: I would like to understand
what would be the alternative.
Umit: I would like to have the
ones we define be URIs and the ones we refer to
externally as IRIs.
Paul C: I would like to see if I can generate support for
her idea.
Chris F: moved to table, Paul C seconded.
§
No objections motion tabled.
8.4
d> i050:
spec talks about delivery
assurances but does not clearly
relate them to the protocol
http://www.oasis-open.org/committees/download.php/15045/ReliableMessagingIssues.xml#i050
no time
8.5
e> i002:
AckTo EPR and seq
lifetime
http://www.oasis-open.org/committees/download.php/15045/ReliableMessagingIssues.xml#i002
no time
8.6
f> i022:
RM Policy Assertion Model's Base Retransmission Interval
Clarification Needed
http://www.oasis-open.org/committees/download.php/15045/ReliableMessagingIssues.xml#i022
no time
8.1
g> i023:
Robust recovery from low-resource conditions
http://www.oasis-open.org/committees/download.php/15045/ReliableMessagingIssues.xml#i023
no time
9
Any other business