Looks good to me. I'm curious though, is 'focusses' the English way of
spelling 'focuses'?
- gp
> -----Original Message-----
> From: Paul Fremantle [mailto:]
> Sent: Friday, March 02, 2007 1:33 AM
> To:
> Subject: [ws-rx-editors] First draft of the submission package
>
> Comments please!
>
> (a) Links to the approved Committee Specification in the TC's
> document repository, and any appropriate supplemental
> documentation for the specification, both of which must be
> written using the OASIS templates.
> The specification may not have been changed between its
> approval as a Committee Specification and its submission to
> OASIS for consideration as an OASIS Standard, except for the
> changes on the title page and running footer noting the
> approval status and date.
>
> [CSM* please can you provide this?]
>
> (b) The editable version of all files that are part of the
> Committee Specification;
>
> [CSM please can you provide this?]
>
> (c) Certification by the TC that all schema and XML instances
> included in the specification, whether by inclusion or
> reference, including fragments of such, are well formed, and
> that all expressions are valid;
>
> All schema and XML instances included in the specification
> are well formed and all expressions are valid.
>
> (d) A clear English-language summary of the specification;
>
> The WS-ReliableMessaging 1.1 specification defines a protocol
> for reliable message exchange between two Web services, even
> in the presence of network or system failures. For example,
> the protocol can ensure the resending of messages that have
> been lost, and can ensure that duplicate messages are not
> delivered. The protocol allows Web service nodes to implement
> a variety of delivery assurances, including at most once, at
> least once, exactly once and in-order delivery of messages.
> The protocol fundamentally defines a one-way reliable channel
> (known as a Sequence), but also includes mechanisms to
> optimize the creation of two-way reliable exchanges.
> The protocol is designed to compose with other relevant
> standards such as WS-Security and WS-SecureConversation. The
> protocol allows developers to add reliable delivery of
> messages to their applications on a variety of platforms,
> including Java and .NET.
>
> The WS-ReliableMessaging Policy 1.1 specification defines an
> XML policy language that enables Web services to advertise
> their support for the WS-ReliableMessaging specification. The
> specification is designed for use with the WS-Policy
> Framework. The language aids the interoperability of nodes
> that support WS-ReliableMessaging by publishing their support
> and requirements. For example, an endpoint may use this
> specification to indicate that it requires that the reliable
> message protocol to be secured using transport level
> security. WS-ReliableMessaging Policy is designed to be used
> with other policy languages, such as WS-Security Policy, in
> the scope of the WS-Policy Framework.
>
> The WS-MakeConnection 1.0 specification defines a protocol
> that can be used to allow two-way communications when only a
> transport specific back-channel (such as the HTTP response
> mechanism) is available. For example, when used with the
> WS-ReliableMessaging protocol, WS-MakeConnection allows a
> client to establish a two-way reliable message exchange even
> in the presence of firewalls and network address translation
> that would prevent the server from initiating connections to
> the client. WS-MakeConnection can be bound to a specific
> WS-ReliableMessaging sequence, or use a generic URI syntax to
> define the logical set of messages that should be transferred.
>
> (e) A statement regarding the relationship of this
> specification to similar work of other OASIS TCs or other
> standards developing organizations;
>
> -- The OASIS WS-Reliable Messaging (WSRM) TC also defines a
> reliable messaging specification for Web services. The WS-RX
> TC and WS-ReliableMessaging specification focusses on
> creating a specification which composes with other
> specifications, in particular the WS-Addressing, WS-Security
> and WS-SecureConversation, and WS-Policy Framework specifications.
>
> (f) Certification by at least three OASIS member
> organizations that they are successfully using the specification;
>
> http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archi
ves/200702/msg00068.html
> http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archi
ves/200702/msg00069.html
> http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archi
ves/200703/msg00000.html
> http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archi
ves/200703/msg00017.html
>
> (g) The beginning and ending dates of the public review(s), a
> pointer to the announcement of the public review(s), and a
> pointer to an account of each of the comments/issues raised
> during the public review period(s), along with its resolution;
>
> First Public Review: 24 August 2006 to 21 October 2006 Second
> Public Review: 12 February 2007 to 27 February 2007
>
> Announcement of the first Public Review of the
> WS-ReliableMessaging 1.1 and WS-ReliableMessaging Policy 1.1
> specifications:
> http://lists.oasis-open.org/archives/tc-announce/200608/msg00005.html
>
> Announcement of the Public Review of the WS-ReliableMessaging
> 1.1, WS-ReliableMessaging Policy 1.1 and WS-MakeConnection
> 1.0 specifications:
> http://lists.oasis-open.org/archives/tc-announce/200702/msg00004.html
>
> Public Review Issue and Resolution Log:
> http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml
>
> (h) An account of and results of the voting to approve the
> specification as a Committee Specification, including the
> date of the ballot and a pointer to the ballot; TBD
>
> (i) An account of or pointer to votes and comments received
> in any earlier attempts to standardize substantially the same
> specification, together with the originating TC's response to
> each comment;
>
> This is the first submission to the OASIS membership
>
> (j) A pointer to the publicly visible comments archive for
> the originating TC;
> http://lists.oasis-open.org/archives/ws-rx-comment/
>
>
> (k) A pointer to any minority reports submitted by one or
> more Members
> who did not vote in favor of approving the Committee Specification,
> which report may include statements regarding why the member voted
> against the specification or that the member believes that
> Substantive
> Changes were made which have not gone through public review; or
> certification by the Chair that no minority reports exist.
>
> There are no minority reports.
>
> [CSM = Chief Spec Monkey :-) ]
>
>
>
> --
> Paul Fremantle
> VP/Technology and Partnerships, WSO2
> OASIS WS-RX TC Co-chair
>
> http://bloglines.com/blog/paulfremantle
>
> (646) 290 8050
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
>
