Subject: 44th IETF: BOFs - APPLCORE, DELTAV (fwd)

From: Steve Coya <[email-masked]>
Date: Thu, 04 Mar 1999 06:49:12 -0500

Attached are the descriptions (and agenda if provided) for two BOFs
meeting in Minneapolis.

For an up-to-date listing, please visit
http://www.ietf.org/meetings/wg_agenda_minneapolis.html

Application CORE Protocol BOF (applcore)

Chair: Chris Newman <[email-masked]>

DESCRIPTION:

The IETF has traditionally developed application protocols directly on
top of a raw TCP stream. However, there is a growing set of problems
which many application protocols have to solve regardless of what the
protocols do. This WG will identify the common problems that deployed
IETF protocols have solved, identify the successes and failures that
deployed IETF protocols made when addressing these problems and design
a simple core protocol to address these problems. This core protocol
may then be used by future application protocols to simplify both the
process of protocol design and the complexity of implementing
multi-protocol clients or servers.

In order to keep the WG in focus, the following items are explicitly
out-of-scope:

* Backwards compatibility with existing application protocols
  Backwards compatibility often compromises correct design. If this
  WG is successful it will impact a great number of future protocols,
  and thus the design errors which backwards compatibility might
  dictate must be avoided.

* Transport layers other than TCP/IP
  This has been a rathole in too many other WGs.

* Protocol models outside the traditional IETF client-server TCP
  application protocol model.
  The IETF doesn't have sufficient past experience in these areas.

* New features
  If a problem hasn't been solved in at least two deployed IETF
  application protocols, then it is out-of-scope for the base core
  protocol spec. This does not preclude individuals or other groups
  from doing extensions to the core protocol which might be used by
  multiple future application protocols; it just limits the scope of
  the core spec.

* Normative references to other application protocols or non-public specs
  The core protocol has to stand by itself. It may reference protocol
  building blocks that have been used by several other application
  protocols such as ABNF, language tags, UTF-8, domain names, URLs,
  MIME, SASL, GSSAPI and TLS. It must avoid normative references to
  full application protocols such as ACAP, HTTP, IMAP, LDAP, and SMTP.
  It must avoid normative references to any document which is not
  freely and publicly available on the Internet.

The WG will produce the following output:

* An RFC documenting the problems identified to solve, and giving 
  examples of existing deployed IETF protocols which succeeded or 
  made mistakes when solving those problems. A starting list of 
  problems for the WG to discuss (the WG may choose not to address 
  some of these) follows:

  * connection user authentication and privacy (e.g., SASL and STARTTLS)
  * server capability/extension announcement (e.g., SMTP EHLO)
  * extensible command/response syntax and structure
  * error status tokens and human readable error text issues
  * syntax for transfer of large (multi-line) objects 
    (e.g., dot-stuffing, length counting, chunking)
  * multiple commands in progress at the same time (command ids or tags)
  * unsolicited server messages
  * command pipelining (sending multiple commands without waiting for
    responses)
  * Structured data representation (e.g., RFC 822-style AV pairs, IMAP
    s-expressions, LDAP ASN.1, XDR, etc) in command/response syntax.
  * low bandwidth support (e.g., compression layer or packed binary
    protocol encoding)
  * connection shutdown (QUIT/LOGOUT command)

* A simplicity litmus test to determine if a proposal is acceptably
  simple. The initial litmus test will be: core protocol spec is less
  than 25 pages.

* A standards track core application protocol specification which uses
  the lessons learned from the informational document and fits the
  litmus test above. An open source implementation of the complete
  core protocol must exist prior to IETF last call. The problem
  identification draft (above) must be completed prior to IETF last
  call.

The WG may solicit strawmen for the core application protocol from
multiple document editors and select the one which is technically
best and fits this charter.

The WG may choose to do additional standards track documents which
extend the core protocol as long as they are not new features by the
above definition.

The WG may choose to do one or more APIs for using the core protocol
and adding commands/extensions to it. These might be informational
or standards track as deemed appropriate.
====================================================================
Web Versioning and Configuration Management BOF (delta-v)

Chair: Jim Whitehead <[email-masked]>

DESCRIPTION:

Versioning, parallel development, and configuration management are
important features for remote authoring of Web content. Version
management is concerned with tracking and accessing the history of
important states of a single Web resource, such as a standalone Web
page. Parallel development provides additional resource availability
in multi-user, distributed environments, letting authors make changes
on the same resource at the same time, later merging together those
changes. Configuration management addresses the problems of tracking
and accessing multiple interrelated resources over time as sets of
resources, not simply individual resources. Traditionally, artifacts
of software development, including code, design, test cases,
requirements, help files, and more have been a focus of configuration
management. Web sites, comprised of multiple inter-linked resources
(HTML, graphics, sound, CGI, and others), are an important class of
complex information artifacts that benefit from the application of
configuration management.

A sub-working-group of the WebDAV working group has been examining the
design space of a Web versioning and configuration management protocol, 
and believes the scope of this effort is sufficient to form a separate 
working group. This BOF meeting will present the charter of the proposed
working group, and will give an overview of the preliminary results of 
ongoing work on the goals and broad design approach. Comments on the 
scope of the effort, and on the preliminary approach will be solicited 
during the BOF.

AGENDA:

* Presentation on the proposed charter (15 min.)
* Overview presentation on goals and approach (15 min.)
* Open microphone for feedback (30 min.)

------- End of Forwarded Message