Applications Area Directors: o Erik Huizer: erik.huizer@surfnet.nl o John Klensin: Klensin@mail1.reston.mci.net Area Summary reported by John Klensin/MCI and Erik Huizer/SURFnet This is a report on the status of the Applications Area as of the conclusion of the Danvers IETF meeting, April 1995. The Applications Area currently contains the following working groups: o Access, Searching and Indexing of Directories (ASID) o Electronic Data Interchange (EDI) o HyperText Markup Language (HTML) o HyperText Transfer Protocol (HTTP) o Integrated Directory Services (IDS) o Internet White Pages Requirements (WHIP) o Mail Extensions (MAILEXT) o MIME Content-Type for SGML Documents (MIMESGML) o Notifications and Acknowledgements Requirements (NOTARY) o Quality Information Services (QUIS) o Uniform Resource Identifiers (URI) Of these, HTTP (jointly supervised with the Transport Area) and MIMESGML are new since the last IETF. The HTTP Security BOF held in San Jose is still expected to evolve into a working group, jointly managed in the Security and Applications Areas. In addition, the Applications Area and the User Services Area jointly oversee the following working groups: o Integrated Directory Services (IDS) (Shifting to Applications) o Integration of Internet Information Resources (IIIR) o Quality Information Services (QUIS) o Uniform Resource Identifiers (URI) (Shifting to Applications) The status of these groups is described in the User Services Area Report. The Applications Area Directorate also has a special advisory committee (``MIXER'') to review and propose action on the revision of RFC 1327 (X.400 -- RFC 822 gatewaying) and related documents. Its present status is discussed below. The Internet Message Access Protocol Working Group (IMAP) concluded its work at the last IETF. The following documents were published since that meeting. o RFC 1730 ``Internet Message Access Protocol - Version 4'' o RFC 1731 ``IMAP4 Authentication mechanisms'' o RFC 1732 ``IMAP4 Compatibility With IMAP2 AND IMAP2bis'' o RFC 1733 ``Distributed Electronic Mail Models in IMAP4'' The MHSDS Working Group was concluded since the last Area Report, having completed its assigned tasks. The following documents from this working group have been submitted to the RFC Editor for publication since the last IETF. o ``Use of the X.500 Directory to support mapping between X.400 and RFC 822 Addresses'' (Experimental) o ``Representing Tables and Subtrees in the X.500 Directory'' (Experimental) o ``Representing the O/R Address hierarchy in the X.500 Directory Information Tree'' (Experimental) o ``MHS use of the X.500 Directory to support MHS Routing'' (Experimental) o ``Introducing Project Long Bud: Internet Pilot Project for the Deployment of X.500 Directory Information in Support of X.400 Routing'' (Informational) The TFTP Extensions Working Group also concluded its work. This working group has the distinction of starting with a BOF at one IETF meeting, moving to a working group, accomplishing most of its work by mailing list, and concluding its work at the next IETF meeting. Its publications were: RFC 1782 ``TFTP Option Extension'' RFC 1783 ``TFTP Blocksize Option'' RFC 1784 ``TFTP Timeout Interval and Transfer Size Options'' RFC 1785 ``TFTP Option Negotiation Analysis'' The Applications Area did not sponsor any BOF sessions during the Danvers IETF. Applications Area Directorate Advisory Committee (MIXER) NOTARY material to be folded in, revised document by mid-May. Charter for working group by mid-April, working group to be created at time of publication of new Internet-Draft. Discussion at Stockholm, final review at Dallas and publication. File transfer body part stays separate -- partially because of relationship with content-disposition (Dorner's document) (hence file names vis-a-vis path information in FTP body part). May also overlap with HTML forms. An updated version of the RFC 1327 document (temporarily called RFC 1327bis) was made available shortly before this meeting. Due to its size, a page-by-page walk through was not attempted. Publication will be delayed to permit incorporating the output of the NOTARY work, thereby updating the handling of notification requests to match contemporary Internet standards and directions. All other extensions (including file transfer body part and received notifications) will go into additional documents which might be integrated into RFC 1327bis at a much later stage. RFC 1494 needs to be updated in parallel. Next steps: o Do all editorial changes now. o Get the results of NOTARY and integrate it into RFC 1327bis. o Get the document out to the public by mid-May. o Create a charter for a working group by mid-April. The schedule for that working group will be: - General discussion of the Internet-Draft at the Stockholm IETF. - Serious last review at the Dallas IETF. - Last Call soon afterwards. - Close the group. Access, Searching and Indexing of Directories Working Group (ASID) The two WHOIS++ documents have been submitted to the IESG as a Proposed Standard. A third document is finished and approved by the group and will be submitted as soon as possible. The WHOIS++ centroids document has been revised and renamed the ``Common Indexing Protocol.'' Some further revisions suggested by the group will be done to make it more general, less tied to WHOIS++. The SOLO document has been languishing since last IETF due to the authors lack of time. The document will be split into two and resubmitted before the next IETF. The CLDAP document has been approved by the IESG as a Proposed Standard, but got lost on its way to the RFC Editor. It is being set back on track. The four LDAP and related documents have been approved as Draft Standards and published as RFCs. A new work item was added to the ASID charter to develop a new version of LDAP capable of taking advantage of some 93 X.500 extensions. A new document defining a URL format for LDAP was discussed. The document will be sent to the URI Working Group for comments, and, with any revisions, submitted as a Proposed Standard, according to the URI defined procedure. The labeledURL draft was revised, resubmitted and approved by the group, after comments at the last IETF. It will be submitted as a Proposed Standard after a suitable experimentation period. The X.500 schema management document was approved for submission as an Experimental RFC. The group was tasked by the area director and agreed to revise its charter to incorporate the indexing and LDAP 93 work. It was agreed to change the name of the group from ``Access/Synchronization of the Internet Directories'' to ``Access, Searching and Indexing of Directories.'' Electronic Data Interchange Working Group (EDI) The EDI Working Group completed its main document, now published as a Proposed Standard, RFC 1767, ``MIME Encapsulation of EDI Objects.'' The ``usage'' document is still pending, and the working group did not meet in Danvers due to lack of progress on that document. The document will be abandoned, and the working group shut down, unless significant drafts of the usage and FAQ documents are published significantly prior to the Stockholm meeting. Hypertext Markup Language Working Group (HTML) This working group is progressing on the HTML 2.0 specification. Multiple changes made during the meetings in Danvers require that a new version be issued and the specification be reviewed again by the working group before processing it as a Proposed Standard. With both HTML and HTTP (see below), a key ongoing difficulty is maintaining a coherent sequence of versions and minimum functionality, rather than having different implementations present ``laundry lists'' of enhancements to users. The work on HTML 2.0 is expected to be completed before the Stockholm IETF meeting. HyperText Transfer Protocol Working Group (HTTP) The document describing the de facto standard HTTP (version 1.0) is being completed and should be forwarded for publication soon. 1.1 is proceeding a little more slowly due to the desire to consolidate and incorporate a few widely-used features. Additional new features, such as digest authentication (signature validation) are still under consideration for version in 1.1. As discussed under HTML above, the long-term challenge for this working group is going to be to steer a coherent course, rather than having large collections of nearly-compatible clients and servers. Internet White Pages Requirements Working Group (WHIP) The documents from this working group are nearly finished, but have been delayed by general exhaustion. The group did not meet at this IETF, nor at the previous one. Its work is expected to conclude prior to the Stockholm IETF. Mail Extensions Working Group (MAILEXT) Eight documents are on the table for this working group. Small revisions will be made to most of them, then they will be disposed of as follows: o Pipelining proposal to be recommended for processing as a Proposed Standard. o 521 response code to Experimental with special attention to implementations and implementation experience. o Transport checkpointing to Experimental. o Binary to Experimental so that experience can accumulate. o MIME checklist to Informational. o Mail attributes document to be reviewed on the mailing list and submitted for publication as Informational. Prior to submission of the Experimental documents listed, the working group will prepare notes on the use of service extension keywords without ``X'' prefixes when Experimental RFCs are published. This working group will be concluded when the documents listed above are processed by IESG, presumably prior to the Stockholm IETF. A new working group will be proposed that will focus specifically on the ``applicability statement'' work. The working group concluded that the Applicability Statement work should result, not in two documents that simply update and clarify mail transport and header behavior, but in new consolidated documents. The new documents should incorporate and replace RFC 821, RFC 822, the mail sections of RFC 1123, and the basic SMTP extension mechanisms. A second new working group will be be proposed to examine UA to UA interaction issues and, in particular, to review and specify header fields and their semantics in standards track documents. The ``new header fields'' proposal will be forwarded to this group. MIME Content-Type for SGML Documents Working Group (MIMESGML) There are three documents on the table; they will be ready by mid-May. The three drafts in progress were discussed at this meeting: o Encapsulating SGML Documents using MIME, o Multipart/Related Content-Type, and o Message/External-Body Content-ID Access Type. These three documents will comprise the infrastructure for exchanging SGML documents. Specific issues discussed included representation of SGML notation declarations, representation of non-ASCII character strings, used in SGML entity declarations, that are to appear on the Content-SGML-Header. A proposed solution is to use RFC 1522. Extended discussion of character sets, character encodings, SGML record-start and -end (RS/RE) conventions ensued. The conclusion was that outside of text/SGML no charset or RS/RE processing will be done. For text/SGML only standard MIME canonicalization and translation of line end characters will be sufficient. The letter of liaison from ISO/IEC JTC1/SC16/WG8 (SDIF) was discussed. The working group chair will send the drafts to WG8 for their review. The draft will include a section on SDIF. Finally the milestones were reviewed and updated. Notifications and Acknowledgements Requirements Working Group (NOTARY) This working group is completing its major work. The report format documents (draft-ietf-notary-mime-report-01.txt, draft-ietf-notary-mime-delivery-04.txt, draft-ietf-notary-status-01.txt) and the document describing the SMTP extension for requesting delivery reports (draft-ietf-notary-smtp-drpt-03.txt) were reviewed, and some changes agreed to by the working group. New versions are being prepared and will be reviewed by the working group during the next month; the documents are expected to be submitted to the IESG in May. Quality Information Services Working Group (QUIS) Despite initial enthusiasm, this working group has failed to produce any products or even to meet effectively. It is being shut down.