FW: SWAP Working Group Charter -- Any comments/suggestions

-----Original Message-----
From: Grimes, Jack [mailto:jgrimes@visa.com]
Sent: Monday, September 28, 1998 6:02 PM
To: 'Surendra Reddy'
Subject: RE: SWAP Working Group Charter -- Any comments/suggestions


Charter looks great.  Good job.
--jack grimes
> ----------
> From: 	Surendra Reddy[SMTP:skreddy@us.oracle.com]
> Sent: 	Thursday, September 24, 1998 11:33 PM
> To: 	swap-wg@netscape.com
> Cc: 	moore+swap@cs.utk.edu
> Subject: 	SWAP Working Group Charter -- Any comments/suggestions
>
>
> I have posted an updated SWAP WG charter to this list couple of days back
> and not seen any feedback on the charter yet. It is important to agree on
> the charter so that we can send the updated charter to Area Director for
> consideration of SWAP as an official working group.
> I would really appreciate if you can take sometime and review the charter:
> If you agree with this charter or any suggestions/comments, please post
> them to the list.
>
> --Surendra
>
> SWAP -- Simple Workflow Access Protocol Working Group
>
> Chair(s)
>
>    * Surendra Reddy (skreddy@us.oracle.com)
>
> Applications Area Director(s):
>
>    * Keith Moore <moore+swap@cs.utk.edu>
>    * Patrik Faltstrom <paf@swip.net>
>
> Area Advisor
>
>    * TBD
>
> Mailing List Information
>
>    * General Discussion: ietf-swap@imc.org
>    * To Subscribe: send msg to ietf-swap-request@imc.org with "subscribe"
>      in subject
>    * Archive:http://www.imc.org/ietf-swap/
>    * Documents: http://www.ics.uci.edu/pub/ietf/swap/
>
> Problem Statement
>
> Currently all services or processes on the Internet are well suited for
> short
> lived interactions between users and systems that provide information and
> services. There is no standard way to support long running interactions
> on the Internet. A standard protocol is needed to integrate work providers
> and
> asynchronous services across the Internet and provide for creating the
> work,
> setting up the work, starting the work, stopping the work, being informed
> of
> exceptions, being informed of the completion of the work, getting the
> results
> of the work, checking on the current status of the work and getting a
> history
> of the execution of the work.
>
> Workflow service is a good example of a generic service which when invoked
>
> can take anywhere from minutes to months to complete, so this protocol can
> be
> used to initiate workflows without being concerned with how the workflow
> system
> accomplishes it.  Secondly, workflow services are used to invoke and
> coordinate
> external asynchronous services, and this protocol allows a standard way to
> plug
> generic services from anywhere on the Internet into a workflow process.
>
> Description of Working Group
>
> The purpose of this working group is to provide a simple protocol to
> invoke,
> monitor, control, and be informed about a generic asynchronous service.
>
> An ad-hoc group has analyzed the functional needs of several
> organizations,
> and has developed requirements for Simple Workflow Access Protocol.
> These requirements encompass the following capabilities, which SHALL BE
> considered by this working group:
>
> IN-SCOPE GOALS:
>
>    * a standard way to start, stop and monitor a generic service
>    * query the status of the service,
>    * pass data values to the service
>    * pause or resume the service,
>    * retrieve preliminary results of the service,
>    * subscribe and receive events from the service.
>    * basic auditing functions
>    * internationalization
>    * security considerations
>
> NOT IN SCOPE:
>
> Many decisions have been made to reduce the scope of this working group.
> This working group will limit its scope to the IN-SCOPE goals and will
> not address the following issues, unless they are critical for successful
> completion of the IN-SCOPE goals:
>
>     * exchange of process definition
>     * transactions
>     * statistics gathering or monitoring of processes other than
> retrieving
>       the status of the specific instance of a service.
>     * administration functions such as installation or general
>       management of a service
>     * presentation of data to humans in HTML or other types of form
> layout.
>
> Deliverables
>
> The final output of this working group is expected to be three documents:
>
> 1. A requirements document, which describes the high-level functional
>    requirements for Simple Workflow Access Protocol, including rationale.
>
> 2. A scenarios document, a description of how this protocol can be used
>    effectively.
>
> 3. A protocol specification, which describes methods, request bodies, and
>    response bodies, to implement the  Simple Workflow Access Protocol
>    requirements.
>
> Goals and Milestones
>
>  DONE    Hold the first meeting on May 4 & 5, '98 of the ad-hoc
>          group. Review the initial version of the specification document.
>          Review the charter for the working group, and decide on a final
>          form to be used to propose the formation of the working group.
>
>  DONE    (Aug '98) Submit initial version of the requirements document
> 	 as an I-D.
>
>  Aug 98  Initial version of the scenarios document distributed for review
>          within the working group.
>
>  Nov 98  Submit revised versions of all  Requirements, Scenarios and
>          Protocol documents as Internet-Drafts.
>
>  Dec 98  Meet in 43rd IETF in Orlando, review requirements and Scenarios
> 	 documents.
>
>  Jan 99  Submit all Requirements and Scenario drafts as Informational RFCs
>
>  Feb 99	 Issue WG last call for protocol specification
>
>  Mar 99	 Meet in 44th IETF, and review the final specification
>
>  Apr 99  Submit SWAP specification as a proposed standard
>
> Current Internet-Drafts
>
> 	Requirements for Simple Workflow Access Protocol(http://
> 	www.ietf.org/internet-drafts/draft-sreddy-swap-requirements-01.txt)
>
> 	SWAP Specification(strawman) ( http://www.ietf.org/internet-drafts/
> 	draft-swenson-swap-prot-00.txt).
>
> No Request For Comments
>
>
>
>
>
>

Received on Monday, 28 September 1998 13:30:24 UTC