2.1 Applications Area

Applications Area Report
43rd IETF - Orlando, Florida, US
December 1998
Patrik Fältström <paf@swip.net>


The Applications Area is today fighting with two problems. The first is to close down all working groups which are close to be finished, or have finished but have one small draft left on their table. The amount of work needed is not negliable, and the working group chair need a lot of support in this phase of the liftetime of a working group. Maybe change of chair is needed in some cases -- as the one running the group from the beginning might be one which have energy to start work, and have new ideas on the architecture -- but not the energy to become a "bad cop" at the end of the lifetime?

The second peoblem is the division of the working groups, and issues they work on, in two different camps (or maybe three -- where the third has not really started yet):

- Working groups which create new protocols using basic building blocks like TCP and UDP etc
- Working groups which create new protocols using other building blocks like HTTP, LDAP, XML and other "buzzwords"
- Working groups which work on creations of the hammers that are used by group number [2] (I see this group different than [1] as they need to have more "usage considerations" in their papers)
- Liason with other organizations {W3C,OMG,ECMA,Java,WAP,ISO,...} which might be the problem behind some of the hammers and screws that is invented (see above).

There is a discussion in many working groups wether a new protocol [1] should be created or old building blocks should be used. We see some "naive" people which use path [2] just because they happen to have an HTTP library, LDAP library or such -- and does not really know what the protocol can NOT be used for. For example, the lack of a global root in the LDAP world make global searches in LDAP not possible, even though non-directory people might at first glance think that is possible. This is one of the reasons LDAP need to be in group [3] and have much more applicability statements written.

In other cases, reuse of protocols, and use Applications Level Protocols as building blocks in other protocols makes sense. Reuse of MIME-encoding of body-parts have been happening for a long long time, and reuse of HTTP makes sense in some cases.

The trouble for people seem to be when to use what.

Some of this descision can only be made when thinking about scope for the protocol itself. Knowing the scope (and security considerations regarding if nothing else privacy matters) makes it possible to look at implications to the Internet as a whole (i.e. transport matters). Because of this, the Applications ADs have in several cases asked for review of some work by the Transport Area.

The discussions regarding this kind of division of the Apps Area between new protocols and reuse of others has probably just started. When one have a hammer in ones hand, everything around looks like nails -- even though some of the things are screwes or even china.

Patrik Fältström & Keith Moore
Area Directors, Applications Area

Summary of the various working groups (summaries available dec 22) written by the respective WG and BOF chairs:


ACAP: we're having a design meeting tomorrow, in which basically the goal is to change a few "MUSTS" to "SHOULD"s or possibly "MAYs". This is based on implementation experience, and the goal is to reduce the complexity of minimal implementations. The base document had to have a few things fixed, anyway. Chris and I are also working at clearing the decks for list last call of the residual required datasets specified in our charter, so we can finish up the WG for good. These are just minor administrative details, imho, but I'll report any significant changes after the fact, again FYI since this isn't even at BOF level.


All of our work items are complete. Working Group last call has been completed for some time and all technical review issues related to the WWW and Application MIB review performed at Berts direction have also been been resolved. Corrected Drafts have been available for some weeks now. The documents will be forwarded shortly from the O&M area where they have been reviewed, to the Applications Area directors for final review and approval as Proposed Standards.


The group discussed draft-ietf-conneg-syntax-03.txt and agreed that it could be put into working group last call after the incorporation of the edits recently discussed on the mailing list. The group also approved a minimum set of values for the proposed color: tag, which will be incorporated into a new revision of draft-ietf-media-features for the IESG's review. After the syntax document is sent to last call, we hope to close out all three documents,in time for the January 24th ITU deadline. The group discussed further cooporation with the W3C's CCPP group, and agreed that the current draft will be the basis of future disucssion, to be lead by Franklin Reynolds and Graham Klyne. A tentative author was also identified for a future draft on the question of registered feature sets.


We currently have three Internet Drafts representing the three milestones that we set out for ourselves. At the meeting in Orlando we spent basically the first half on the requirements document, of which the biggest suggested change was to make less confusing the definitions of MUST, SHOULD (we will probably convert the various requirements into "ratings"). The folks attending the meeting also appeared to think that support for a NEAR operator is also crucial. We spent the remaining time on the protocol document and discussed some of the bigger recent issues such as support for structured properties, I18N, etc. I am expecting to do a last call on the requirements document at some point in January after one more revision.


ABNF to Draft status is in WG last call, will go to IESG for last call after revision for editorial changes by end of next week. Message Format draft will go to WG last call immediately and will go to IESG last call after one more revision for a few wording clarifications (Jan 8th). A new draft of the SMTP spec will come out by end of next week and will go into WG last call. WG rough concensus that controversial changes to drafts at this late date must be supported by at least four people prior to consideration. Intention is that there won't be another DRUMS meeting.


The meeting began with a review of the results of the last ITU Study Group 8 meeting held in November. At that meeting, a draft amendment of T.37 was "determined" for the full mode; the technical details are specified by reference to the "eifax" Internet Draft, as well as the "reporting extensions" and "fax-feature-schema" documents. The ITU needs RFC numbers and copies of the final documents as soon as possible as part of the approval process, which is targeted for completion in April 1999. There are three completed drafts "Goals", "eifax" and "reporting-extensions". The latter two documents will be submitted to the IESG once the "fax-feature-schema" document is complete. The schema document was reviewed by the authors and a new version will be posted after the meeting. It was agreed there would be a final one week Last Call on this document. The status of three documents referenced by "eifax" from the CONNEG working group was reviewed; all but the "syntax" document are in review by the IESG. The group also reviewed additional charter milestones and supported updating of the simple mode RFCs, an implementor's guide and documents on onramp/offramps. An updated set of charter milestones will be posted after the meeting. There were various interworking activities for the simple mode and TIFF profiles which were reviewed. In Japan, 8 companies tested simple mode implementations. In San Jose, 13 companies tested simple mode and about 4 companies tested TIFF profiles; almost all features of RFC 2305 are supported in multiple implementations. A new IPP over fax concept was also presented briefly and a mailing list is being set up which is a separate activity from the Fax WG.


The HTTP Working Group has completed its work. We have issued final drafts of the HTTP protocol specification (in two parts), and we are waiting for A-D review and IESG balloting. We're hoping to see the HTTP RFCs issue and the working group close soon.


The IMPP working group met Monday Night (Dec 7th, 1998). After a brief review of the current version of the charter, Jonathan Rosenberg presented his suggestion that SIP could meet the requirements of the working group. Vijay Saraswat presented AOL's TOC protocol, explaining that we might be able to learn something from a protocol that, though inadequate, is in a similar space. (Vijay does not work for AOL and was not involved in the development of implementation of the TOC protocol.) Marc Horowitz briefly described Zephyr, another system that offers lessons but is at the same time not adequate to meet our needs. Jesse Vincent presented an overview of the state of consensus and difference on the mailing list as he and Mark Day interpret it. This presentation led to many comments.

Comments lasted until 9:30, with input from Dave Crocker suggesting that
modified versions of e-mail technology could solve many of the problems,
Frank Dawson suggested that the group consider using vCard technology for
content passing, and many others. After the session wrapped (at 9:30) many
people, including a number of members of the security community continued
in informal discussion. Another 2 hours were spent discussing and defining
security expectations of an IMPP based system.


Around 40 people attended. Many people from the Internet Fax group were

In consultation with the Application Area Director the following IPP WG documents have been submitted for acceptance as Informational RFCs, to meet the market requirements for a set of stable specifications. They collectively define IPP/1.0:
· draft-ietf-ipp-req-03.txt
· draft-ietf-ipp-req-rat-04.txt
· draft-ietf-ipp-req-mod-11.txt
· draft-ietf-ipp-req-pro-07.txt
· draft-ietf-ipp-req-lpd-ipp-map-05.txt

A decision from the IESG can be expected in early 1999.

Discussion about update of the charter. This was not considered necessary, but the following remaining tasks within the current charter were identified:
· IPP URL Scheme
· Security solution using TLS (with or without use of SASL)
· Notifications

With these additions, IPP could progress to the standards track.

Presentation and discussion of combining Internet Fax and IPP. Keith Moore suggested to make preparations for a separate IETF WG on this subject, and plan for a BOF in the next IETF meeting. 10+ people indicated that they are willing to participate in this work. This work is also of potential interest to the ITU.


The mandatory-to-implement discussion has concluded with the choice of MUST DIGEST-MD5 (derived from HTTP digest) and MAY on Start TLS, and the drafts have completed last call and will be sent to the ADs to progress to Proposed Standard. The language tags and dynamic entries drafts which had gone through last call many months ago have also been sent to the ADs for PS, and the simple paged draft for informational. Five drafts, virtual list view, sorting, X.509 SASL, C API and ACL requirements are currently in last call, and no showstopper problems are anticipated. There was concensus that the access control model draft, which defines operations on access control elements, was the right approach to continue. There was also concensus to add to the charter a new work item to investigate the use of families of entries to represent compound attributes, based on a proposal being done for X.500.


Chris Harding opened by describing related work going on in The Open Group and offered an open-ended invitation for all LDUPers to attend.

We then reviewed the outstanding drafts. The author of the replica requirements draft was not present. There are some open comments on this draft; we will try to get it into WG Last Call no later than the end of January. The LDAP Architecture Draft is proceeding well, with some discussion continuing on low level features. We will try to align the participants and issue a revised draft by the end of January. The LDUP Replication Information Model was published and discussion is just starting.

The LDUP Conflict Detection and Resolution Draft was delayed due to work overload by the author, but will be release by the end of next week.

As far as the remaining drafts, the LDUP Replication Information Transport Protocol is due by the end of January; the LDUP Mandatory Replica Management draft is still in need of coauthors, and an estimate for the various Replication Profile drafts depends mostly on the Mandatory Replica Management draft and the Conflict Detection and Resolution Draft. Co-authors were committed to this draft, and a "drafty draft" was promised for Minneapolis.


This meeting concentrated on ietf-nntpext-base-07.txt. It was decided to drop the manditory space following commands in the ABF section of this document. It was also decided that the current dicussion about article numbers would be retained. Should USEFOR actually include the "Replaces" header in their RFC, it may be necessary to review this, but that's unlikely to occur before this new NNTP base spec is forwarded to IESG. Ian King will spend some time contributing more to the "Security Considerations" section of this document. Tale will contribute more clarification and examples to the wildmat section. These clarifications will address Internationalization and the use of the recently added ! operator.


There is no objection to the publication of draft-rfced-info-blinov-00.txt, referred to the WG for comment, as Informational. On the main v1.0 protocol document, there were no objections to the decisions at the Tokyo WG meeting and there was agreement to re-target the draft to Proposed rather than Informational. There was also support for possibly publishing updated modular subsets of this large document based on implementation experience. The HTTP Supplement will be updated and probably needs another round of comments. There was a lot of interest in the list of known planned v1.0 implementations. There were no objections to some delay in starting the next version specification but there were suggestions that it be v1.5 instead of v2.0 since it will be mostly upward compatible. The suggested additional work item of cataloging/standarizing HTML Form Field names for commerce had essentially no support so, unless something unexpected happens, I would not expect to put it in a revised charter. There were no objections to the scheduled con calls and WG meeting Feb 8-11, 99. I reserved some time for discussion of taxation and there seemed to be a consensus that some optional hooks should be included but not much and not soon. I'll probably submit a revised charter soon showing changed milestones are documnt target status.


URLREG did not meet at IETF 43; the chairs felt that issues has been well discussed at previous meetings. Nonetheless, both chairs have received input from WG members expressing dissatisfaction with the current procedures draft. The chairs met with the AD and discussed a strategy for restructuring the document to set forth (known) process for registration in the 'IETF' tree, and guidelines for creating alternative trees. The author will submit the new draft to the list, and unless there is strong sentiment that another meeting is necessary, will submit it to Last Call before Minneapolis. The group's other deliverable, the guidelines draft, is already in Last Call and is considered complete.


The URN Working Group is not meeting at the Orlando IETF.

The WG is down to the final review of the remaining documentation. There are minor changes required to some documents.

URN Namespace Definition Mechanisms
- Has been last-called by the IESG for BCP.

URI Resolution Services Necessary for URN Resolution
- Somewhere between IESG & RFC editor on its way to Experimental

A URN Namespace for IETF Documents
- Work required: final concordance with Namespace Definition Mechanisms paper (if changes necessary)

NAPTR Registration Procedures document
- Work required: wg last call

Following on to the proposal to move the NAPTR work to the standards-track, we have two new Internet-Drafts:

Resolution of Uniform Resource Identifiers using the Domain Name System

The Naming Authority Pointer (NAPTR) DNS Resource Record

These are essentially a split of RFC 2168 into a document defining the NAPTR RR, and a document describing a URN RDS using NAPTR.


The WebDAV WG met on Thursday, December 10, 1998, from 1300-1500, with 42 people in attendance. Three main topics were discussed: advanced collections goals and protocol (<draft-ietf-webdav-collection-protocol-02> and <draft-ietf-webdav-collection-reqts-03>), versioning (<draft-ietf-webdav-versioning-00>), and issues from the distributed authoring protocol (<draft-ietf-webdav-protocol-10>). There was a brief discussion at the end of the meeting on additional properties (draft was not submitted in time for the meeting). Prior to the main meeting, two informal breakout sessions were held on the topics of Access Control and Advanced Collections.

Judith Slein led discussion on Advanced Collections, discussing the issues: - What mechanism should be used to disable the referential capabilities of reference resources
- Optional backpointers
- Enforcement of referential integrity

Geoff Clemm led discussion on versioning. A versioning goals document will be out soon. During the meeting these issues were discussed:
- Data model for a versioned resource
- Whether checked-in resources are mutable/immutable
- Semantics of checkout
- Use of lock as a mechanism for checkout

Jim Whitehead led discussion of the following issues from the distributed authoring protocol document.
- URI vs. URL distinction in draft
- Storing attributes submitted in XML properties
- Namespace consistency


The Domain Registry Protocol BOF meet on 8 December to consider the formation of a working group for specifying a protocol to permit domain name administrative acclivities between registrars and registries. A candidate specification <draft-crispin-srs-00.txt> has provided a basis for technical discussions. Online discussion is at ietf-srs@core.nrw.net and already surfaced a paradigm issue between "light registrar" and "heavy registrar" architectures. The basic distinctions between these architectures was reviewed, along with other domain name service basics. Categories of service requirements were reviewed, and a draft working group charter was discussed. There appeared to be strong group consensus to proceed with a working group, although there is concern about its meeting an aggressive schedule. Such a schedule would be helpful to parallel activities, outside the IETF, but the area director advice was to focus on technical work rather than working groups status. Discussion of requirements surfaced concerns over flexibility and security. These will be pursued further on the mailing list. The BOF chair would like to note that this BOF provided an excellent opportunity for a difficult meeting, given the history of the topic, but that all participants in the meeting were extremely constructive.

HTTP/NG BOF (Transport / Apps)

It was a bimodal result: great interest (strong consensus, probably unanimity) in desire for standards track MUX specification, interest (rough consensus) in a requirements document for something like HTTP/NG's middle layers, but no interest in standards track work at the middle and higher levels of the HTTP-NG proposal at this time.

[Comment from Area Director: Much of the transport part of this is being folded into the RUTS followon in Transport Area (the MUX stuff that is)]


IKSTEL BOF discussed the Internet Kermit Service and various approaches to correcting the current Telnet Authentication/Encryption situation. The was no consensus as to the formation of a Working Group at the end of the meeting. Further discussion will take place on the telnet-ietf@bsdi.com mailing list including the posting of a proposed charter for a working group to tackle the Telnet Auth/Encrypt issues.

John Klensin is going to visit Columbia University in January to discuss the Internet Kermit Service with myself and Frank da Cruz.

My personal opinion is that given the dynamics of the meeting that a quick review of the current Telnet Auth, Encrypt, Auth mode, and Encrypt mode drafts should be done by myself and Ted T'so and they should be submitted for Last Call in order to formalize what is already in use. Then a WG if it is created can address only the question of whether something further needs to be done.


Three "competing" I-Ds, already fairly similar in the relevant areas, were summarized by their authors. It was agreed, modulo some details which the minutes should reflect, that the differences should be hammered out on the list. As this was not expected to take long or be controversial, it was agreed that this would be attempted, in the hope (and expectation) that a WG would *not* need to be formed. There was strong consensus to keep the scope narrow, focusing on local e-mail aliasing only. There was also strong consensus that doing this at all was a Good Thing.

SIEVE NON-BOF BOF (did not meet officially)

The Sieve non-BOF BOF met and made some minor revisions. The most significant issue was reject-behavior for scripts that required certain extensions; a suggestion was made, argued for, and rejected to allow conditional processing of messages based on the presence or absence of specific extensions. This being resolved, we agreed to issue version 6 of the draft based on a list of accumulated revisions, and all existing experimental implementations will be brought in compliance with this draft. A web page is being set up as well to provide a medium for posting scripts from various authors to check against different implementations. Attendance was good for something that had only been barely set up: 28 by my count, and the meeting was poolside 8-).