WS-RX charter clarification is effective (w attachment)

[James Bryce Clark <jamie.clark@oasis-open.org>]

Re-sending.

     This is your notification under the OASIS TC Process rules that the 
ballot entitled
"Charter clarification proposal (1 of 2: Bunting)"
     and reported at
http://www.oasis-open.org/apps/org/workgroup/ws-rx/ballot.php?id=803
      was successful, and the TC's charter has been clarified as a 
result.  The amendment  to the language is now effective.  The text we plan 
to post to the official TC charter site is attached.   This text also 
incorporates a typo noted by the TC as its action item #2 at
http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_item.php?action_item_id=939
     I will announce this to the [members] and [tc-announce] lists and post 
it tomorrow (minus the proofreading marks).
     Regards  JBC

Title: OASIS WS-RX TC Charter

            The original Call for Participation for this TC may be found
at  http://lists.oasis-open.org/archives/tc-announce/200505/msg00004.html.
            
            The charter for this TC is as follows.
            
            Name and abbreviation
            
                 OASIS Web Services Reliable Exchange 
Technical      Committee (WS-RX)
            
            Purpose
            
                 The purpose of the OASIS Web Services
 Reliable     Exchange (WS-RX) Technical Committee (TC) is to define a protocol
 for reliable    message exchanges between two Web services, through continued 
 development    of the Web Services Reliable Messaging specification [1] submitted
 to the    TC as referenced in this charter and to define a mechanism by
which   Web  services  express support for reliable messaging as well as
other related    useful parameters.  This mechanism will be based upon the
Web Services Reliable   
            Messaging Policy Assertion ("WS-RM Policy") specification [2] 
submitted      to the TC.
            
            Scope
            
                 The TC will accept as input the February 
  2005   Version  1.0 of the WS-ReliableMessaging [1] and WS-RM Policy [2] 
 specifications   (the  Input Documents) from BEA Systems, IBM, Microsoft, 
 and TIBCO Software.   Other  contributions and changes to the input documents 
 will be accepted  for consideration  without any prejudice or restrictions 
 and evaluated based  on technical merit  in so far as they conform to this 
 charter. OASIS members   with extensive experience and knowledge in these 
 areas are particularly 
            invited to participate.
            
                 The scope of the TC's work is to continue
   development    and refinement of the input documents to produce as output
   modular specifications    that standardize the concepts, WSDL documents
 and  XML schema renderings  required  to provide reliability assurances
to  message  exchanges between two parties  that conform to the specifications.
            
                 Reliable messaging systems can generally 
  be  described   using a four agent model. In this model there is an Application
    Source, a  Reliable Messaging Source that acts on behalf of the Application
    Source,  an Application Destination and a Reliable Messaging Destination
   that acts  on behalf of the Application Destination. Message Transfer
is   the function  of moving messages from a Reliable Message Source to a
Reliable    Messaging  Destination. This TC will provide protocols for the
reliable  message  transfers  that occur between Reliable Messaging Sources
and Reliable  Messaging  Destinations.  The TC will not develop additional
mechanisms by  which a Reliable  Messaging  Source captures messages from
an Application  Source or mechanisms  by which  a Reliable Messaging Destination
delivers  messages to an Application  Destination.
            
                 A reliable message transfer is one in
 which    certain   reliability assurances exist between two parties even
in the presence   of a variety of failures. There can be multiple, concurrent
 and independent  reliable  exchanges between two parties. Reliability assurances
 make statements  about  the type of reliability provided to a message exchange.
            
                 The specifications will define a set 
of  basic    concepts  required for the correct functioning of message exchanges
  with   reliability  assurances. The specifications will render these concepts
  as   a specific set  of restrictions over SOAP messages including XML schemas
   and WSDL documents.
            
                 The specific reliability assurances
in  the   scope   of the TC are:
                 --  At Least Once: Messages are 
transferred      at least one time or an error is raised on at least one of
the endpoints.      It is possible that some messages are transferred more
than once.
                 --  At Most Once: Messages are
transferred       at most one time or an error is raised on at least one
of the endpoints.      It is possible that some messages are not transferred.
                 --  Exactly Once:  Messages
 are   transferred    at least one time and at most one time or an error
is  raised   on at least   one of the endpoints.     
                 --  Ordered: Messages are transferred 
   in  the  order in which they are sent.
            
                 These reliability assurances can be
combined     and  certain combinations are of particular interest due to
their widespread      application:   Exactly Once and Ordered (also
referred to as Exactly      Once Ordered).
            
                 The specifications developed by the
WS-RX    TC  will  define mechanisms that support and allow the implementation
and    expression    of reliability assurances, at most once, at least once,
exactly    once, ordered,    and will not define mechanisms for applications
to manifest    reliability  assurances.
            
                 The specifications developed by the
WS-RX    TC  will  define elements and relationships among elements that
enable the   implementation    of the following functions which support the
reliability    assurances in the   scope of the TC:
                 --  Reliable establishment and
teardown     of  one or more independent shared contexts between two parties
within  which   reliability assurances apply to one-way or two-way messaging.
                 --  A mechanism which two parties 
 can   use   to perform one-way or two-way reliable messaging within a reliable 
  context.
                 --  Ensures timely destination
amnesia     detection.   Destination amnesia is the condition resulting from
catastrophic     failure  in which a Destination loses the shared context
required by reliability     assurances.
                 --  At Most Once reliability assurances 
    even  in the case of Destination amnesia.
                 --  Efficient message retransmission
   and   acknowledgment.
                 --  Duplicate message detection.
                 --  Detection of out-of-order messages
    and   discovery of the correct order of messages.
                 --  Unique identification of messages 
   within   a reliable context
                 --  Acknowledgement of all messages 
  within    a reliable context
                 --  RM protocol violation detection 
  and   the  raising and transmission of related fault information.
                 --  Efficient preservation of the 
 integrity     of reliable contexts by composition with WS-Security or other 
 SOAP security     mechanisms.
                 --  Expression of support for the 
 specifications     using the WS-Policy Framework [9] and binding of that 
policy to a WSDL  port.
                 --  A binding of the reliable messaging 
    protocol  elements to SOAP 1.1 and SOAP 1.2.
            
                 The specifications will uphold the basic 
  principles    of other Web services specifications of independence and composition
  and   must be composable with the other specifications in the Web services
  architecture,    such as WS-Security [3], WS-Trust [4], WS-SecureConversation 
  [5], WS-Addressing    [6], SOAP 1.1 [7], SOAP 1.2 [8], bindings of SOAP 
1.1/1.2  to HTTP, WS-Policy    [9], WSDL 1.1 [10] and WSDL 2.0 [11].  
The TC will also take into consideration   applicable work, such as the WS-I 
Basic Profile [12].  The "Secure, Reliable,    Transacted Web Services: 
Architecture  & Composition" white paper [13] published    in 2003 provides 
information  on the Web services architecture.
            
                 If an above specification is outside 
of  a  standardization    process at the time this TC moves to ratify its 
deliverables,   or is not  far  enough along in the standardization process, 
any normative   references  to it in the TC output will be expressed in an 
abstract manner,   and the incarnation    will be left at that time as an 
exercise in interoperability.
            
                 While composition with other specifications
    is  a goal of the TC, it is also a goal to leave the specifics of how
that    composition is achieved outside the scope of this TC.

Add "this TC" and delete "the RM specifications"

                        Each of the protocol elements 
will   use  implementation and language neutral XML formats defined in XML 
Schema   [14].
            
                 Out of Scope: The following is a non-exhaustive
      list. It is provided only for the sake of clarity. If some function,
 mechanism     or feature is not mentioned here, and it is not mentioned
in  the Scope  of   Work section either, then it will be deemed to be out
of scope.
            
                 The TC will not define a mapping of
the   functions     and elements described in the specifications to any programming
  language,     to any 
            particular messaging middleware, nor to specific network transports.
            
                 The elements and/or mechanisms the TC
 defines     must  be independent of issues and considerations that do not
 affect an   interoperable   reliable messaging protocol.
            
                Specifically: the TC is not concerned with 
binding     the  specifications to specific underlying transports.
            
                 The TC and the specifications that it
 produces do not address considerations, such as durability related
to Sources' and/or Destinations' ability to satisfy reliability assurances.

Corrected: "producesdo" -> "produces do"

                  Except for the elements directly related 
  to  the   functions in the scope of the specifications, the TC will not 
prescribe   the  format of messages that are transferred reliably according 
to the specifications.
            
                 The TC will make no assumptions about
 the   location    of Application Sources relative to RM Sources and Application
   Destinations    relative to RM Destinations.
            
                The TC will not attempt to define concepts 
or  renderings     for functions that are of wider applicability including 
but  not limited   to:
                 --  Security (Encryption, Integrity 
  and   Authentication)
                 --  Addressing
                 --  Policy languages and frameworks
                 --  Routing
                 --  Transactions and Compensation
            
                 Where required these functions are achieved
    by  composition with other Web services specifications.
            
                 The TC will not attempt to define functionality
      duplicating that of any normatively referenced specification in the
input      WS-ReliableMessaging or WS-RM Policy specifications. If the referenced
   specification   is outside of a standardization process at the time this
  TC moves to ratify   its deliverables, or is not far along enough in the
 standardization process,   any normative references to it in the TC output
 will be expressed in an abstract  manner, and the incarnation will be left
 at that time as an exercise in interoperability.
            
            Deliverables
            
                 The TC has the following set of deliverables.
                 --  A revised Web Services Reliable 
  Messaging    Protocol specification.  Committee Specifications are 
scheduled  for   completion 
            within one year of the first TC meeting.
                 --  A revised Web Services Reliable 
  Messaging    Policy Assertion specification.  Committee Specifications 
  are scheduled    for completion within one year of the first TC meeting.
            
                 These specifications will reflect refinements, 
     corrections or material technological improvements with respect to the 
  input   documents and in accordance with this charter.
            
                 Ratification of the above specifications 
  as  OASIS   Standards, including a brief period to address any errata, will
  mark  the  end of the TC's lifecycle.
            
                 The TC may choose to vary the number 
of  the   specification   documents and their titles.
            
            IPR Mode
            
                 This TC will operate under the "RF (Royalty
    Free)   on RAND Terms" IPR mode as defined in the OASIS Intellectual
Property     Rights   (IPR) Policy, effective 15 April 2005.
            
            Audience
            
                 The anticipated audience for this work 
 includes:
                 --  Vendors offering Web services 
 products;
                 --  Other specification authors 
that   need   reliable message delivery for Web services;
                 --  Software architects and programmers,
     who  design, write or integrate applications for Web services; and
                 --  End users implementing Web
services-based       solutions that require an interoperable, composable
reliable messaging    solution.
            
            Language
            
                 TC business will be conducted in English.
            
            References
            
            [1] WS-ReliableMessaging
            http://schemas.xmlsoap.org/ws/2005/02/rm
            
            [2] WS-RM Policy
            http://schemas.xmlsoap.org/ws/2005/02/rm/policy
            
            [3] WS-Security
            http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf
            
            [4] WS-Trust
            http://schemas.xmlsoap.org/ws/2005/02/trust
            
            [5] WS-SecureConversation
            http://schemas.xmlsoap.org.ws/2005/02/sc
            
            [6] WS-Addressing
            http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/
            
            [7] SOAP 1.1
            http://www.w3.org/TR/2000/NOTE-SOAP-20000508/
            
            [8] SOAP 1.2
            http://www.w3.org/TR/soap12-part1/
            http://www.w3.org/TR/soap12-part2/
            
            [9] WS-Policy
            http://schemas.xmlsoap.org/ws/2004/09/policy
            
            [10] WSDL 1.1
            http://www.w3.org/TR/2001/NOTE-wsdl-20010315
            
            [11] WSDL 2.0
            http://www.w3.org/TR/wsdl20-extensions
            http://www.w3.org/TR/2004/WD-wsdl20-bindings-20040803
            
            [12] WS-I Basic Profile
            http://www.ws-i.org/deliverables/workinggroup.aspx?wg=basicprofile
            
            [13] Secure, Reliable, Transacted Web Services: Architecture
&    Composition
            http://msdn.microsoft.com/webservices/understanding/advancedwebservices/default.aspx?pull=/library/en-us/dnwebsrv/html/wsoverview.asp
      
            http://www-128.ibm.com/developerworks/webservices/library/ws-securtrans/index.html
            
            [14] XML Schema
            http://www.w3.org/TR/xmlschema-1/
            http://www.w3.org/TR/xmlschema-2/