43rd IETF Meeting:SWAP BoF Minutes

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.

Carl-Uno:
- 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). 
* How many people are willing to work on this problem?
1-3 hands.
* How many people feel the problem isn't well enough defined to begin work?
About 1/3 to 1/2 of the room raised hands.
[??]
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. 

** End of meeting ***

Received on Monday, 21 December 1998 14:45:09 UTC