2.1 Applications Area

Applications Area Report

The most important and far-reaching things happening at this IETF were the reorganization of the Directory Area and the debate on adding security into applications.

The former seems to be well established, with the old directory groups folding as "finished", and the new groups being established to deal with LDAP extensions, LDAP deployment, schema registration and non-LDAP directories when the interest and clearness of mandate warrants.

There are a few fundamental items that have to be addressed, however, including the question of whether we intend the directory work to produce a single, coherent namespace or just "tools for intranets."

The security issue is not resolved. It is clear that we need protocols to have decent security mechanisms (which does NOT mean cleartext passwords!) as a mandatory to implement function, and it is equally clear that we do not have solutions that are known to satisfy a wide range of requirements, which makes wide deployment troublesome. Further work will need to be done here.

There are currently 24 active Applications working groups, some of which are just waiting for last call completion before closing down; the area sponsored a total of seven BOFs at this IETF.

Summaries of working groups:

ACAP - Application Configuration Access Protocol

Reached consensus on all outstanding issues with base spec. CRAM-MD5 will be mandatory-to-implement authentication mechanism. Will adopt anonymous mechanism and move with base spec. Agreed to spin off naming convention and registry for language sensitive comparator functions into a separate WG to attract the right people. Selected a fixed set of 4 dataset class specifications and 1 extension which are already published IDs to shepard on standards track prior to concluding the WG. Will meet in DC and plan on concluding early next year.

APPLMIB - Application MIB

The Application MIB working group met on Monday August 11th to discuss the Application, and World Wide Web MIBs. Before starting discussion of these documents, an update on the status of our charter updates and requests for advancement of the System Application MIB to Proposed Standard Status were provided. The goal of this meeting was to complete reviews of both the WWW and Application MIBs so that final revisions could be sent out in about a month and a working group last call for both documents be issued before the next IETF. Randy Presuhn led a discussion of the Application MIB and changes that have been made since Memphis. The alignment of the MIB with the ARM efforts was also noted. Carl Kalbfleisch led a discussion of the WWW MIB and changes that have been made since Memphis. Some time was spent in discussion of how the WWW and Application MIBs tie to each other. Suggestions for a small number of additional objects were also made. Revisions to both the WWW and Application MIBs will be posted by the end of the first week in September.

ASID - Access, Searching and Indexing of Directories

The LDAPv3 last call completed and the group gave its signoff for the documents to go to the IESG. MIMEDIR and vCard were agreed to go to last call with minor changes. WHOIS++ templates and URL was agreed to go to last call. Disposition of other drafts was discussed in light of the directory reorg. The group agreed to conclude as soon as the pending last calls completed.

CALSCH - Calendaring and Scheduling

CalSch had 2 meetings at Munich. The model document, the interoperability specification and the iCalendar document were discussed. All documents will be revised and posted for WG last call in the next 4-6 weeks. A draft document specifying the mail binding of the interoperability protocol will be posted in the same time frame. Asking for a clear problem specification concluded a brief discussion of the use of LDAP to locate calendars and possibly free/busy time. Security considerations for the interoperability protocol was discussed and with the help of Bob Mahoney and Paul Hill, will be systematically developed and incorporated into the documents. Chair noted the proposed 4-6 week schedule as too optimistic.

DRUMS - Detailed Revision/Update of Message Standards

Reached consensus on outstanding issues with ABNF document, plan on finalizing it this month. Will aim to complete 821bis/822bis by next IETF, but may have to do one more cycle after that. Agreed to create a registry for email headers in a separate document.

EDIINT - Electronic Data Interchange-Internet Integration

EDIINT did not meet; its first set of documents being finished pending clarification on the situation with S/MIME.

FAX - Internet Fax

The Internet Fax work group met on Wednesday, August 13. The updated charter and milestones were reviewed. The focus of the work group continues to be on developing standards for the "messaging" model of Internet fax, which will emulate commercial fax use. The current status of drafts for TIFF-F and TIFF-FX was reviewed. A proposal was presented on how to align the TIFF-F minimum set with the use of TIFF-F within WIDE. Two modifications to the values for the TIFF-F minimum set of fields were proposed to accomplish the alignment and there was a consensus to support the proposal. The group also agreed to use the simplified TIFF file structure per WIDE when using the TIFF-F minimum set. There was discussion during the rest of the meeting on three aspects of the fax messaging: addressing and routing, confirmation of receipt and security. It was agreed that address content needs to be contained in the e-mail address and several alternatives were reviewed. There was consensus on the use of DSN for confirmation of receipt: the issuance of confirmation should result from the actual message delivery to the recipient and not before. The group also reviewed what levels of privacy and authentication would meet likely customer expectations for fax.

FIND - Common Indexing Protocol

The FIND working group reviewed all the documents in the queue and agreed to go to last call as soon as was feasible. There are still a few problems with dealing with index objects as Mime types and the group agreed after an examination of RFC 2048 that they would have to create a new cip tree to handle different types of cip index objects. After this is approved by the IESG, the documents will have to be updated, but we all thought the Washington DC meeting would be the last.

FTPEXT - Extensions to FTP

FTPEXT did not meet

HTTP - HyperText Transfer Protocol

The HTTP working group is making good progress toward completing the transition from Proposed to Draft Standard. At the meeting, we reviewed the open issues and made good progress on many of them. Some proposals for extensions to HTTP will result in 'Experimental' RFCs. A "HTTP/1.1 interoperability test" is being planned for testing implementations (browser, proxy, and origin server) against each other. RFC 2109 (state management) has technical difficulties; it seems likely that we will recycle with a new draft that will be closer to current (interoperable) implementations, and with a revised (but not weakened) discussion of privacy considerations. Content negotiation has a broader scope than HTTP, and some of the work on it will result in work that may extend beyond HTTP-WG; others will result in Experimental RFCs. Our revised charter calls for being mainly complete with HTTP/1.1 by the December IETF, and with the possibility that the group may close or become dormant soon after.

IDS - Integrated Directory Services

IDS did not meet

IPP - Internet Printing Protocol

The Monday session meeting was attended by about 35 experts and the Wednesday session by about 25. Total of 48 experts signed up on the attendance sheet. All of the WGs Internet-Drafts were open to review and comments. The Model & Semantics, Security, Protocol Specification, and LPD Mapping I-Ds still had a few open issues, which will be discussed further on the IPP DL. For the remaining documents, the only comment was that some alignment and updating is still needed to reflect changes in the other I-Ds. Highlights of the more important discussion points:

a) In the Model & Semantics I-D Exact compression algorithms to be used. Instruction from Keith Moore not to reference Job Monitoring MIB, as this is not an IETF project. Instruction to also MIME types rather than MIB enums to reference document formats. Job-URI vs. Printer-URI plus Job ID; recent change criticized, further discussion needed. Order of result from Get-Jobs. Media-ready versus media-supported. No clear agreement whether both are needed.
b) Security I-D This document will be split over the Model & Semantics and the Protocol Specification I-Ds in next draft. Some further work needed on how client and server can always negotiate security features, even if no security is required. This problem is basically a generic HTTP problem, but a specific solution for IPP seems to be required.
c) Protocol specification I-D Discussion of POST versus a new PRINT method. Reasons for using PRINT over POST were not compelling. Will only be discussed if new strong arguments can be brought up in favor of a change.
d) LPD Mapping made clear that this is an INFORMATIONAL document only. Content considered as hints and example to implementors of gateways.
e) General - The chairs made clear that the intent of the WG is to move current I-Ds to final call in September.

LSMA - Large Scale Multicast Applications

(Note: This has been culled from the minutes)

Jon Crowcroft gave a brief history and restated the purpose of the WG. He suggested that the recent work, as illustrated by the draft i-d in the next section, represented a broader take on our work than the original membership and charter. The DIS (and share dealing networks) have timeliness requirements that suggest network provisioning/over-engineering or int-serv and rsvp deployment, which then make the requirements on reliability, timeliness, latency and so on easier to achieve in the application and middleware domains. The broader remit, in the "public" or "open" Internet environment today, without deployed int-serv/rsvp, means that tradeoffs need to be assimilated into the middleware/application levels. This is beyond our original intention, where we had a goal of pushing back on the other WGs in the IETF (RSVP, Int-Serv, IDMR, ION, Mboned, and recently, the IRTF RM group), a set of fairly well defined protocol scaling and performance requirements (as documented in the Scenarios and Limitations drafts. Mark Pullen agreed that the HLA had moved on from the specifics of DIS, and that perhaps this broader view was needed.

Presentation of draft-ietf-lsma-requirements-00.txt Peter Bagnall [Other Author: R Briscoe] Slides available at: http://www.labs.bt.com/people/bagnalpm/lsma/munich.ppt [html and ppt 4 version TBA on the WG email list] Expiration: 29 January 1998 BT 29 July 1997 Taxonomy of Communication Requirements for Large-scale Multicast Applications. Peter presented an overview of the excellent (well received) requirements i-d. There were a number of points raised by Dave Oran (regarding idea of fairness, property of relative delays, errors and jitter seen by different receivers in heterogeneous delivery - this is a nice definition of the problem where the parameters are defined specifically at each receiver (or sub set of receivers) and the differences defined as a separate characterization of requirement. Then it becomes application specific how we add new receivers and whether we degrade average performance, or allow lower quality reception to some, or reject new receivers somehow (at the middleware application level) if we cannot tolerate group degradation or a wide variation (or any variation) or support it through resource reservation. The view was expressed that the API should be able to express and control all these (and other) options for behavior. Kirstein mentions Air Traffic Control as another strong requirements pull in this area (akin to the HLA/DIS one). The requirements on security for LSMA were briefly discussed - two nice applications were mentions: Games with large prisms and database synchronization - these put a lot of stress on current Internet Security mechanisms (in fact, large scale multicast with good secure timeliness to avoid _cheating_ appears to be a research topic, rather than something ripe for IETF standardization nwork - ed.] Tony Ballardie (IDMR co-wg chair) asked what application requirement pushback on IDMR there was. There was a discussion about interaction between application performance requirements and tree types (symmetric, shared/source based changes etc). Dave Oran and Mark Pullen commented that this was a key working area of the group so far, that we seemed to be moving up a level as well though. Christopher Bonatti asked about general APIs and the re-usability of techniques for LSMA. The WG Chair asked for feedback, and commented on the usefulness of the general notion (esp. the fairness versus heterogeneity, and scaling questions). Dave Oran commented on the "big picture" requirements to _reduce_ the black box nature of the Internet architecture. Ken Carlberg asked about the difference between Intranet and Internet requirements.

Document Deployment draft-myjak-lsma-scenarios-00.txt draft-pullen-lsma-limitations-00.txt. It was agreed that these should go to WG last call between now and the next meeting, and, if ok, then try to be progressed to informational RFC.

AOB None

Actions Jon Crowcroft to pursue with Area Director(s) whether LSMA should stay with current charter and wrap up, or complete current business at Washington IETF (40th!) and re-charter then with broader (or narrower) remit to include less DIS, and more general HLA and other LSMA (in the natural interpretation of the words) form along the lines presented in the draft-ietf-lsma-requirements-00.txt document.

MADMAN - Mail and Directory Management

MADMAN did not meet.

MHTML - MIME Encapsulation of Aggregate HTML Documents

MHTML met at IETF 39 with 28 participants and resolved all issues on its agenda. It was then decided that the MHTML specifications should be recycled as Proposed to replace the faulty proposed MHTML standard RFCs currently in circulation. The group then set September 30 as its date for moving the new documents to IETF Last Call. The new drafts will be posted as soon as possible for WG review and open discussion on the mailing list. All output of the meeting is subject to review and consensus evaluation on the MHTML Mailing List. MHTML WG plans to meet at IETF 40 in December.

MIXER - MIME - X.400 Gateway

MIXER did not meet, having completed its work. The WG will be shut down once the last documents are processed through Last Call.

NNTPEXT - NNTP Extensions

NNTPEXT did not meet, having gone through a change of chairs just before the IETF, and the new chairs concluding that nothing worthwhile could be done on short notice.


PRINTMIB did not meet

RECEIPT - Receipt Notifications for Internet Mail

RECEIPT did not meet; its output document is in IETF Last Call.

TIP - Transaction Internet Protocol

The TIP WG met and discussed the Requirements, TIP and SCP I-Ds. No significant issues were found with any of these specs. Editorial updates are required to the Requirements and TIP I-Ds. It was decided to drop SCP as a separate I-D (for a generalized multiplexing protocol), and include it as an Appendix in the TIP I-D, and limit it's scope for use with TIP only. It was decided to add support for global transaction identifiers (such that TIP transaction branches may be either tightly- or loosely coupled with each other). The subject of requirements for generalized electronic commerce came up, this is outside the scope of TIP, but perhaps should be the subject of further IETF activity. It is hoped to wrap-up the first versions of the Requirements and TIP I-Ds before the Washington meeting.

TN3270E - Telnet TN3270 Enhancements

No summary submitted.

URLREG - Uniform Resource Locator Registration Procedures

No summary submitted.

URN - Uniform Resource Names

There was no discussion regarding existing documents (i.e., no one had any comments to offer). This is not surprising, as they are already a few revisions old. Therefore, they will be finalized and last-called. The primary issue of the meeting was namespaces -- what they are, who gets them, how they are registered, and what it means to maintain them. There was a lot of discussion, tending towards a vague sense that an interim position will be to define baseline technical requirements, and require every potential URN namespace proposal to go through the RFC process. There is more discussion to be had here -- but the Namespace Requirements document editor felt he had heard enough consensus to put together a draft document that can be used to focus future discussion. The hope is still to aim for a December wrap-up of the group.

A representative of CNRI presented the CNRI Handles work, and brought up questions about the reserved characters in the URN syntax. Handles may make a potential URN namespace, but he was referred to the working group's mailing list archive for the discussion regarding the selection of reserved characters in the URN syntax (largely inherited from URI syntax).

WEBDAV - WWW Distributed Authoring and Versioning

The WEBDAV Working Group met at the Munich IETF on Monday, August 11, 1997, from 13:00 to 15:00. There were 54 attendees throughout the duration of the meeting. Jim Whitehead chaired the meeting, and Del Jensen recorded notes. The meeting began with a short overview presentation on WebDAV, which was followed by a presentation giving an overview of the design of the properties and collections functionality in the WebDAV protocol specification. After this presentation, the remainder of the meeting was concerned with discussing a series of open issues. During the issues discussion, the attendees were in favor of the following recommendations:

1. The DAV property identifiers (i.e., ";DAV/" + property URL), discussed in Section 2.4 of draft-ietf-webdav-requirements-01.txt, should not be used, and should be removed from the spec.
2. The SEARCH method (Section 2.6.5) should be renamed to PROPGET (or GETPROP or FINDPROP), and should be limited to retrieving just named resources from a given resource. There should be an additional mechanism for retrieving the names of all properties on a given resource without having to retrieve their values as well.
3. The property attributes "live" and "read-only" (Section 2.3.1, 2.3.2) should not be returned with each property instance retrieval, but should instead be retrievable via a schema discovery mechanism (TBD) which would state the extent (i.e., which namespace) and attributes (live, read-only) of a property.
4. The Depth header (and hence recursive semantics for method invocations) should be moved to a separate specification, which will proceed separately from draft-ietf-webdav-protocol. There was a suggestion to not use a Depth header, but to instead define separate functions (e.g., DEEPCOPY) for the recursive analog to existing methods.
5. Atomic locking of collections (Section of draft-ietf-webdav-re quirements-01.txt) was discussed, and it was agreed that the requirement should stay as-is, that efforts should be made to satisfy this requirement in the protocol specification, but that there should be an awareness that this requirement might not be satisfied.
6. Authoring support for language variants was discussed, and no firm resolution was achieved.

Summaries of BOFs:


The group accepted the charter with a couple of additional items. Work items were split into four categories: access control, replication, APIs, and various extensions. Most of the existing proposed extensions were agreed to go to last call within a month. Editors were assigned for replication and access control requirements. API documents were agreed to be revised, shooting for last call by December.


Harald presented the to be IETF policy for the handling of character sets, which briefly consists of the following: all information, in the format of strings for human consumption, transported using IETF protocols must have the character set and language declared. The default character set should be ISO 10646(Unicode) with UTF-8 as transport encoding. Language tags according to RFC 1766 should be used. A short discussion followed which made it quite obvious that there was rough consensus among the people in the room that this was a good thing. No summary submitted.


The DIRDEP BOF was well attended. After some discussion of the BOF agenda, the motivation for a DIRDEP WG, and prioritization of fundamental goals for such a WG, the BOF attendees indicated, via a rough consensus poll of the room, that they thought such a working group would be useful. Names of volunteers to edit most of the documents aligned with the goals agree upon by BOF attendees. The lack of volunteers for documents related to piloting activities suggests that this goal should not remain on the list of topics such a WG will address. The remaining fundamental goals (most important first) were: naming and interconnecting directories, schema-related issues, guidelines for client and server implementors, locating directory services, and help for people who deploy directories. The BOF attendees also indicated support for dealing with only LDAP deployment issues as well as changing the proposed WG name to LDAP Service Deployment (lsd). An updated charter will be developed and posted to the mailing list for discussion. Document editors will begin drafting documents after consensus is achieved on the new charter. No summary submitted.


The AAARG BOF met Wednesday evening and spent most of the time discussing the nature of the problem(s) as various participants perceived it and some desired solution characteristics. There was great concern that the total set of desired characteristics might preclude any solution, so any attempt to list the desired properties may have to prioritize them. There was interest in forming a WG to pursue this, although the BOF didn't get around to discussing a charter.

A subsequent meeting of some participants Thursday afternoon came to the conclusion that any further effort should:

1. Look at specific Application Area protocols and list desired properties of an authentication mechanism;
2. Try to describe the consequences of those properties;
3. Try to examine available mechanisms to see how they satisfy the desired properties;
4. Produce a document with recommendations for application protocol developers.

It was suggested that a WG in the applications area should not attempt to produce a security protocol.
Chris Newman and Randy Gellens volunteered to act as document editors, and Paul Krumviede volunteered to act as chair (or co-chair).

The next action items are to produce the minutes and to compose a draft charter. Steve Hole will be working the former, and Paul Krumviede will attempt to produce a draft charter by the end of next week (the 22nd).


A BOF was held to see if there was interest in working on requirements for a next generation HTTP protocol. Over 50 people attended. After a general overview of the problem and discussion, a list of topics that might result in informational documents was produced, including:

1. Survey of existing HTTP usage,
2. Understanding usage and non-usage of HTTP,
3. How POST is being (ab)used in HTTP to tunnel other protocols,
4. What administrative boundary controls are needed for a new protocol,
5. Recommendations on firewall policy,
6. Tunneling of SSL,
7. Caching strategy,
8. HTTP use in proprietary systems,
9. General family goals. These might form the basis for deliverables in a working group charter. The attendees were polled asking how many might actually do real work to produce some documents; there seemed to be on the order of 8-10 people who claim they will be willing to contribute. A short discussion on schedule also ensued; best would be a schedule by the Spring IETF if possible, as other prototyping work is beginning now, and for input to have the most impact, it needs to be timely in nature. Charter and schedule bashing will occur on a mailing list to be set up as a result of the BOF.

Previous PageNext Page