[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx-editors] First draft of the submission package
Yes its an alternate spelling. I think I've used American spelling elsewhere (optimized?) so I'm happy to make it more focused on US English. Gilbert Pilz wrote: > Looks good to me. I'm curious though, is 'focusses' the English way of > spelling 'focuses'? > > - gp > >> -----Original Message----- >> From: Paul Fremantle [mailto:paul@wso2.com] >> Sent: Friday, March 02, 2007 1:33 AM >> To: ws-rx-editors@lists.oasis-open.org >> 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 >> paul@wso2.com >> (646) 290 8050 >> >> "Oxygenating the Web Service Platform", www.wso2.com >> >> -- Paul Fremantle VP/Technology and Partnerships, WSO2 OASIS WS-RX TC Co-chair http://bloglines.com/blog/paulfremantle paul@wso2.com (646) 290 8050 "Oxygenating the Web Service Platform", www.wso2.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]