OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx-editors message

[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


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
> 
> 

smime.p7s



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]