2.1.19 Simple Workflow Access Protocol (swap) bof

Current Meeting Report

Simple Workflow Access Protocol(SWAP) BoF
Tuesday 8th, December 1998

Meeting Summary:

The Simple Workflow Access Protocol BoF was held at the Orlando IETF, on Tuesday, December 8th, 1998, from 10:15AM-11:15Am. There were 70 people in attendance.

The meeting was chaired by Surendra Reddy , and minutes were taken by Mr. Rohit Khare. Surendra Reddy began the BOF with an introduction. Next, Arthur Hitomi, UC Irvine presented goals/requirements for SWAP. In the final 25 minutes of the BOF, the microphone was opened up for discussion from the participants. Several participants noted that the problem to be solved is not well defined. One participant felt that IETF has RPC and process control should be IETF problem and If it can solve workflow problem that would be good. IAB has expressed concerns over using HTTP protocol for SWAP transport. There has been lot of discussion on the clarity of the problem to be solved and its relation to other work in IETF like EDI, RPC etc. Applications Area Director, Keith Moore recommended participants to understand the problem and discuss it in terms that IETF community can understand the problem. At the end of the meeting, a straw poll of the audience asked whether the IETF should continue to work in this area to, with an eventual view toward forming an IETF working group. Majority of the participants felt the problem is not defined well and once the problem is clearly defined, there seems to be interest in moving forward.

Here is the minutes from the SWAP BoF:
(Minutes taken by Rohit Khare, UCI)

Bob Moskowitz: re: using other groups' work.
1) just define a mime object, per EDI-INT/EDIFACT.
2) how can we distinguish this from the standard on port 80, so that firewall administrators can protect differently. IPP went that route and it's basically not acceptable. 3) you must be able to upgrade to TLS within a clear connection to conserve port numbers
- There is much contention over use of HTTP, and reuse of port 80 for other protocols. Have to be careful what lessons you take home from IPP experiences.

Mark Day:
- Schedule seems really unrealistic given that you don't even know what transport is being used.it's going to solve all kinds of things and be done in 12 months. It seems contradictory.

Frank Dawson:
There are lots of different communities with different definitions and models; we don't want to spend the years WfMC did, but we do need an IETF term base. Second, you seem to be bringing a solution to the IETF to be endorsed, in part.
- five interfaces to work on: process definition, UIs, invoked apps, engine-to-engine, administration. WfMC already did MIME bindings for the fourth. SWAP will address IF4, the fourth interface.
- Some concern that a body was bringing work to the IETF for endorsement, rather than bringing a work area before the IETF so the IETF can work on it.

Surendra: Going to implement interface 4 in the WfMC reference model. Keith Moore: This sounds a bit like a blanket statement. The IETF doesn't just bless other group's work. This is not the ADs view -- this is a choice the working group can make.

- With IPP, to solve the firewall problem, we introduced a new port for the IPP protocol. Feels that the IPP design of encapsulating the semantics of the protocol inside a MIME type was a smart decision. Keith: that sounds broad; the goal of a BOF is to scope out what everyone wants to work on. We will not approve a working group to bless the WfMC work. The goal of IF4 is being stated as a goal of the working group; that's for the group to decide, not to decide in the charter. Not just a server-server protocol, I hope.

Carl Uno: in IPP we ended up using a different basic port for printing service; you may want to as well. 2) a MIME object which can cross several transports makes sense. Nick: but just server-server deems the FedEx class of example out-of-scope.

Mark Day: the charter shouldn't have to reference another document for its goals.
- just like the calendaring group, you may find a model/terminology document deliverable to be useful

Keith: the draft requirements are just that, individual contributions.

Dave Crocker: I'm fascinated to see that there will be draft requirements a month before draft protocol in the milestones. A Charter is a contract: the very first paragraph alone should state what will and won't be done.

Keith state again the scope:define a protocols to start stop monitor the data of a process instance, and facilitate the exchange of data between servers. Informal poll: who wants to work on that (very few); something else (slightly more); Lisa Li asked if everyone else here was to prevent a WG forming (larger still, but still a minority).

[??] first thing you have to do is define data interoperability. Second, if it's process-to-process, rather than human, there are a lot better ways than HTTP. Mark Day: the answers you're giving here in person are not in the charter. It's about Interface 4, it's about transport, etc are not words in the charter.

Frank Dawson:
- Charter needs some work. Where is mailing list?
- It would be helpful to have a model document which specs. out the model domain, and lists terms, as a deliverable. Many people have a notion of workflow, and some of these views are contradictory. Am concerned that the requirements document has been stated as being already done.

Keith Moore:
- Requirements are *not* done. Work performed before the start of the working group are sugestions/contributions.

Dave Crocker: technologists often don't have a market story for their gadget; the reverse in this case. "The problem to address here is not workflow" -- IETF passed an RPC protocol. The transfer of control, marshalled data already exists. As a consequence, a generic problem *in* bounds, is to talk about process control in a distributed environment. The fact it includes some workflow needs in the process is nice, but this is a simpler proposition, technically understood, and may recruit more people.

Daniel PINKAS: this should not be about a protocol (as the group is titled), but about data format. Sync vs. async transport are both good, but still second level of importance.

Mike Spreitzer: Further, the abstract definition of the data is even more important than the data (so you can use different encoders, like XDR, etc)?
- what's your payload?
- process attributes: time used, input arguments, data generated.
- lavender polo shirt: what you just described sounds like a MIB. SNMP does have these goals, too. It's just not clear what problem we're solving.
- scenario: buying a PC triggers all kinds of work processes with subcontractors.

Dave Crocker: an exercise I do when a project remains fuzzy is to go through at least three very concrete scenarios of that nature. An I-D ought to be submitted illuminating what real, mechanical probelms are to be solved. Try to define this in computer science stuff rather than marketing stuff. control hypothesis: I'd do your scenario with EDI+small bits of workflow task info so that I can track it. Thus the payload is the EDI; the workflow stuff is the metadata in the control channel. Surendra: that's right Dave Crocker: I think that's not right. That's too coarse-grained. I thought this was to actually get the work done, to mandate a series of actions. EDI is at the most significant interface point, very coarse. Is it an external request-and-monitoring interface or an internal instantiation bit?
- This is the former. We watch the entry point of the process (its URL) and monitor that.
- is this (merely) something more interactive than EDI?
- SWAP gives an entry point for two workflow engines to interact.

Keith: What I need to see: a few of the people in the audience to be convinced there's a core problem that diverse people want to work on. I suspect there may be one; but there's an implicit paradigm being used to express it -- there's a different expression that will resonate here. The other problem is that this is the second BOF, and that's the limit. The description of the problem will have to be different.


None received.