Welcome to the second BOF.
Art presented his slideset on definitions/goals/rationale for SWAP --
available online.
- no decisions have been made, really? Then what's in the draft protocol
document?
+ A webDAV derivative protocols
- How, procedurally/editorially do you reference other groups work like
WfMC?
+ don't worry about that yet; become a wg first
- WfMC has the industry reputation of being contnetious and hard to work
with. You're being a grad student :-)
+ We're not doing lots of stuff, like process definitions
- 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
- Day: it's going to solve all kinds of things and be done in 12 months. It
seems contradictory.
- ?: 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.
- 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.
- 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); LisaLi
asked if everyone else here was to prevent a WG forming (larger still, but
still a minority).
- blue herringbone: 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.
- 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.
- 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.
- 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.
- herringbone: 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.
+ that's right
- 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.