[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: full agenda for may 04 teleconf
the full agenda with links is attached. -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133Title: Draft Agenda to WSRM TC Conference Call – May 06, 2003
Full Agenda of WSRM TC Conference Call –
The meeting of the WSRM TC took place by teleconference
(UTC - 5)
1
Draft
Agenda:
Draft Agenda to WSRM TC Conference Call 1 Roll Call 2 Minutes Discussion 2.1 Appointment of Minute Taker 2.2 Approval of previous meeting minutes – 3 Action Item Status Review 4 Discussions of unresolved editorial comments 5 Discussion of Document progression 6 Discussion of FAQ / Presentation for WS-Reliability 2
Roll
Call
Attendance: Meeting ?? quorate. 3
Minutes
Discussion
3.1 Appointment of Minute TakerTom Rutt will take minutes. Minutes will serve to record issue resolutions. 3.2 Approval of previous meeting minutes
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/6614/MinutesNewOrleansF2F.htm
xx moved to approve f2f minutes. YY seconded. ?? Opposition, Minutes ?? approved 4 Status of Action Items
4.1 Action editors-1 – (Marc and Doug) Pending
Marc G and Doug B to updated issues list to reflect agreements in CD .992. - open
4.2 Action 042004-1 – (Jacques) Pending
Action: Jacques will propose the text changes to the document to remove retry parameters Changes for the agreements section text in .996, still listed in table Iwasa added to section 3 and in the annex
New action for Iwasa needed to remove retry parameters from table in section 3 and from annex A.
4.3 Action 042904-1 – (Tom and Iwasa) needs discussionAction: Iwasa and Tom will provide text for the new fault code and the reference to it in the section of text Alan cites. Added GroupAborted error code to draft .996, however the paragraph which was cited to add the MUST return sentence was deleted. Did not add a sentence. Could add the following sentence somewhere: ““When group
processing is aborted, the Receving RMP MUST return GroupAborted fault for all non-delivered messages which
have not had an RM reply sent.” 4.4 Action 042904-2 – (Sunil) completedAction: Sunil will update schema for new fault code in the message processing failures sector. Done 4.5 Action 042904-3 – (Jacques) PendingJacques took an action item to propose this new subsection on special considerations for wsdl request/response operations. 4.6 Action 042904-4 – (Jacques) PendingJacques took action item to add appropriate text to also clarify that an RM-Fault must be returned if the message cannot be delivered because the requested reply pattern is not supported 4.7 Action 042904-5 – (Jacques) completedJacques took an action on where to move the current section 3.4, with perhaps a re-title of section 3. Jacques will also propose a new document structure to accommodate this and other problems he encounters Completed 4.8 Action 042904-6 – (Jacques) completedJacques took action item to propose appropriate change to using word application (perhaps producer/consumer). Completed in .996, however figures need to be updated to change “application layer” to “producer” or “consumer”. New action to Iwasa required to make figure changes. 4.9 Action 042904-7 – (Iwasa) needs discussionAction: Iwasa to apply all editorial changes from Tony’s mail, except for those he considers in need of discussion. Completed on 4/30, there are a few comments that require further discussion at May 4 TC teleconf. 4.10Action 042904-8 – (Tom) completedAction: Tom should put out a call for IPR claims. Done 4.11Action 042904-9 – (Jacques) completedAction on Jacques: incorporate his new Agreement section while doing the document restructure. Done 4.12Action 042904-10 – (Bob F) PendingBob F took action to lead a team to provide an initial draft of the comparison paper of WS-Reliability/WS-ReliableMessaging, for review by the TC. Sunil and Jacques joined the team. 4.13Action 042904-11 – (Jacques) PendingAction: Jacques will lead a team to ensure the terminology used in the spec is consistent with normative terms in the soap spec. Pete W will work with Jacques to provide a proposal to resolve this. 5
Discussion
of Issues and editorial Comments
The following table includes items which need further discussion: also, to be discussed with this: Mail from Tony Graham: >Some of Tony Graham's editorial comments are
in this category. >> Please look this over to see if any of
your items need further discussion. 1. Line 178: example.org
example.org (and example.net and example.com)
are reserved for examples and documentation.
See http://www.rfc-editor.org/rfc/rfc2606.txt for the explanation. Using
example.org makes it obvious that it is an example and avoids any conflict with a domain name that is in use or will one
day be in use. 2. Line 288, 304: Why must the time be
identifiable? I would
like this to be explained to me. 3. Line 329: Reliable Messaging Fault Indication
for failure to receive a message Another
thing that I would like explained to me. 4. Line 366 My
comment had to do with the sentence construction. Looking at the comment in the preliminary minutes, it seems likely that
the sentence will change anyway. 5. Line 388, 390, 392 My braino. It should be "Change 'details' to
'details.'." but I was thinking too much about periods so the wrong word came
out. Regards, Tony Graham 5.1 Syntax of replyTo attributeNew email from Anish: For
the poll and callback pattern WS-R has an attribute 'replyTo'
of type xs:anyURI. The value
of this attribute in the request message specifies the poll/callback location.
This is problematic for the following reasons: 1)
A URI does not represent a Web service -- a WS is much more than a URI and a
reference to a WS has to be more than a URI. A URI is certainly part of the WS
reference. URI is necessary but not complete. For example, the URI does not say
what the operation/interfaces/binding/policy/f&P/capability/etc
are. One cannot even specify the value for the "SOAPAction"
HTTP header (which is part of the binding). Although WS-R is not WSDL-centric
(and the callback location and poll location does not necessarily have an
associated WSDL), the replyTo attribute makes the
scope of WS-R very limited. 2)
As corollary to (1) above, the binding/interface of the URI has to be known
before hand and cannot be changed. I.e., the SOAP node which is being polled or
called-back on has to be assumed to use SOAP HTTP binding. One of the big
reasons for using callback/poll is the underlying protocol itself is
asynchronous (HTTP is synchronous) -- other reason is that the operation takes
a looong time. Effectively, WS-R cannot be used with
non-HTTP/non-SOAP-binding. For example, one cannot use SMTP/MOM-proprietary asynch protocols. 3)
Another corollary to (1) is that one cannot send a message using protocol A and
poll/callback using protocol B. E.g., a node which is behind a firewall sends a
message using HTTP (so that it knows that the message has been received but not
necessarily delivered) and have the receiving node send an ack
using SMTP. 4)
An attribute of type URI is not enuf to represent all
kinds of protocol bindings (such as queuing systems). This means that newer
versions of WS-R spec (which hopefully will support various protocols) cannot
use an attribute of type URI -- for two reasons -- the type is restricted to
URI and it is an attribute (which means it can only be simple type). I.e., the
current schema for WS-R lacks extensibility for the addressing feature of
callback/poll. Not very friendly for future versioning. I
do realize that this issue is being brought up at the 11th hour, but did not
realize that there was an issue till now. Thanks. -Anish -- 5.2 Clarification of http binding· · Re: [wsrm]
Clarification needed on our http binding Tom Rutt wrote: > We need to clarifiy
that the mandatory binding in the spec is to use > htttp
post. > I think the spec needs to be clearer than that.
It should probably say SOAP HTTP binding defined by WSDL 1.1 section 3
(OR SOAP 1.1 section 6 binding, minus the HTTP
Extension framework) > This is not stated clearly. > > In fact we need to clarify the exsting lines 1310, 1311, 1312 > " > (3) The Acknowledgment Message is sent with
another HTTP connection from > the Receiving > RMP to the Sending RMP. Example 15 is an
example of this message. > (4) The HTTP response for (3) has no HTTP
message body. Example 14 is an > example for this > HTTP Response. > " > to require an http
post request. > > This clarification is needed, for
interoperability, to avoid the use of > http get when http
post is expected. > > Tom Rutt > > 6 Discussion of Document Progression.7 Frequently Asked Questions / Presentation rebuttalKarl F. Best wrote: Tom: |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]