home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 95apr / area.applications.95apr.txt < prev    next >
Text File  |  1995-05-26  |  13KB  |  322 lines
  1.  
  2. Applications Area
  3.  
  4. Directors:
  5.  
  6.  
  7.    o Erik Huizer:  erik.huizer@surfnet.nl
  8.    o John Klensin:  Klensin@mail1.reston.mci.net
  9.  
  10.  
  11. Area Summary reported by John Klensin/MCI and Erik Huizer/SURFnet
  12.  
  13. This is a report on the status of the Applications Area as of the
  14. conclusion of the Danvers IETF meeting, April 1995.
  15.  
  16. The Applications Area currently contains the following working groups:
  17.  
  18.  
  19.    o Access, Searching and Indexing of Directories (ASID)
  20.    o Electronic Data Interchange (EDI)
  21.    o HyperText Markup Language (HTML)
  22.    o HyperText Transfer Protocol (HTTP)
  23.    o Integrated Directory Services (IDS)
  24.    o Internet White Pages Requirements (WHIP)
  25.    o Mail Extensions (MAILEXT)
  26.    o MIME Content-Type for SGML Documents (MIMESGML)
  27.    o Notifications and Acknowledgements Requirements (NOTARY)
  28.    o Quality Information Services (QUIS)
  29.    o Uniform Resource Identifiers (URI)
  30.  
  31.  
  32. Of these, HTTP (jointly supervised with the Transport Area) and MIMESGML
  33. are new since the last IETF. The HTTP Security BOF held in San Jose is
  34. still expected to evolve into a working group, jointly managed in the
  35. Security and Applications Areas.
  36.  
  37. In addition, the Applications Area and the User Services Area jointly
  38. oversee the following working groups:
  39.  
  40.  
  41.    o Integrated Directory Services (IDS) (Shifting to Applications)
  42.    o Integration of Internet Information Resources (IIIR)
  43.    o Quality Information Services (QUIS)
  44.    o Uniform Resource Identifiers (URI) (Shifting to Applications)
  45.  
  46.  
  47. The status of these groups is described in the User Services Area
  48. Report.
  49.  
  50. The Applications Area Directorate also has a special advisory committee
  51. (``MIXER'') to review and propose action on the revision of RFC 1327
  52. (X.400 -- RFC 822 gatewaying) and related documents.  Its present status
  53. is discussed below.
  54.  
  55. The Internet Message Access Protocol Working Group (IMAP) concluded its
  56. work at the last IETF. The following documents were published since that
  57. meeting.
  58.  
  59.  
  60.    o RFC 1730 ``Internet Message Access Protocol - Version 4''
  61.    o RFC 1731 ``IMAP4 Authentication mechanisms''
  62.    o RFC 1732 ``IMAP4 Compatibility With IMAP2 AND IMAP2bis''
  63.    o RFC 1733 ``Distributed Electronic Mail Models in IMAP4''
  64.  
  65.  
  66. The MHSDS Working Group was concluded since the last Area Report, having
  67. completed its assigned tasks.  The following documents from this working
  68. group have been submitted to the RFC Editor for publication since the
  69. last IETF.
  70.  
  71.  
  72.    o ``Use of the X.500 Directory to support mapping between X.400 and
  73.      RFC 822 Addresses'' (Experimental)
  74.  
  75.    o ``Representing Tables and Subtrees in the X.500 Directory''
  76.      (Experimental)
  77.  
  78.    o ``Representing the O/R Address hierarchy in the X.500 Directory
  79.      Information Tree'' (Experimental)
  80.  
  81.    o ``MHS use of the X.500 Directory to support MHS Routing''
  82.      (Experimental)
  83.  
  84.    o ``Introducing Project Long Bud:  Internet Pilot Project for the
  85.      Deployment of X.500 Directory Information in Support of X.400
  86.      Routing'' (Informational)
  87.  
  88.  
  89. The TFTP Extensions Working Group also concluded its work.  This working
  90. group has the distinction of starting with a BOF at one IETF meeting,
  91. moving to a working group, accomplishing most of its work by mailing
  92. list, and concluding its work at the next IETF meeting.  Its
  93. publications were:
  94.  
  95. RFC 1782 ``TFTP Option Extension'' RFC 1783 ``TFTP Blocksize Option''
  96. RFC 1784 ``TFTP Timeout Interval and Transfer Size Options'' RFC 1785
  97. ``TFTP Option Negotiation Analysis''
  98.  
  99. The Applications Area did not sponsor any BOF sessions during the
  100. Danvers IETF.
  101.  
  102.  
  103. Applications Area Directorate Advisory Committee (MIXER)
  104.  
  105. NOTARY material to be folded in, revised document by mid-May.  Charter
  106. for working group by mid-April, working group to be created at time of
  107. publication of new Internet-Draft.  Discussion at Stockholm, final
  108. review at Dallas and publication.  File transfer body part stays
  109. separate -- partially because of relationship with content-disposition
  110. (Dorner's document) (hence file names vis-a-vis path information in FTP
  111. body part).  May also overlap with HTML forms.
  112.  
  113. An updated version of the RFC 1327 document (temporarily called
  114. RFC 1327bis) was made available shortly before this meeting.  Due to its
  115. size, a page-by-page walk through was not attempted.  Publication will
  116. be delayed to permit incorporating the output of the NOTARY work,
  117. thereby updating the handling of notification requests to match
  118. contemporary Internet standards and directions.
  119.  
  120. All other extensions (including file transfer body part and received
  121. notifications) will go into additional documents which might be
  122. integrated into RFC 1327bis at a much later stage.  RFC 1494 needs to be
  123. updated in parallel.
  124.  
  125. Next steps:
  126.  
  127.  
  128.    o Do all editorial changes now.
  129.    o Get the results of NOTARY and integrate it into RFC 1327bis.
  130.    o Get the document out to the public by mid-May.
  131.    o Create a charter for a working group by mid-April.  The schedule
  132.      for that working group will be:
  133.       -  General discussion of the Internet-Draft at the Stockholm IETF.
  134.       -  Serious last review at the Dallas IETF.
  135.       -  Last Call soon afterwards.
  136.       -  Close the group.
  137.  
  138.  
  139.  
  140. Access, Searching and Indexing of Directories Working Group (ASID)
  141.  
  142. The two WHOIS++ documents have been submitted to the IESG as a Proposed
  143. Standard.  A third document is finished and approved by the group and
  144. will be submitted as soon as possible.
  145.  
  146. The WHOIS++ centroids document has been revised and renamed the ``Common
  147. Indexing Protocol.''  Some further revisions suggested by the group will
  148. be done to make it more general, less tied to WHOIS++.
  149.  
  150. The SOLO document has been languishing since last IETF due to the
  151. authors lack of time.  The document will be split into two and
  152. resubmitted before the next IETF.
  153.  
  154. The CLDAP document has been approved by the IESG as a Proposed Standard,
  155. but got lost on its way to the RFC Editor.  It is being set back on
  156. track.
  157.  
  158. The four LDAP and related documents have been approved as Draft
  159. Standards and published as RFCs.
  160.  
  161. A new work item was added to the ASID charter to develop a new version
  162. of LDAP capable of taking advantage of some 93 X.500 extensions.
  163.  
  164. A new document defining a URL format for LDAP was discussed.  The
  165. document will be sent to the URI Working Group for comments, and, with
  166. any revisions, submitted as a Proposed Standard, according to the URI
  167. defined procedure.
  168.  
  169. The labeledURL draft was revised, resubmitted and approved by the group,
  170. after comments at the last IETF. It will be submitted as a Proposed
  171. Standard after a suitable experimentation period.
  172.  
  173. The X.500 schema management document was approved for submission as an
  174. Experimental RFC.
  175.  
  176. The group was tasked by the area director and agreed to revise its
  177. charter to incorporate the indexing and LDAP 93 work.  It was agreed to
  178. change the name of the group from ``Access/Synchronization of the
  179. Internet Directories'' to ``Access, Searching and Indexing of
  180. Directories.''
  181.  
  182.  
  183. Electronic Data Interchange Working Group (EDI)
  184.  
  185. The EDI Working Group completed its main document, now published as a
  186. Proposed Standard, RFC 1767, ``MIME Encapsulation of EDI Objects.''  The
  187. ``usage'' document is still pending, and the working group did not meet
  188. in Danvers due to lack of progress on that document.  The document will
  189. be abandoned, and the working group shut down, unless significant drafts
  190. of the usage and FAQ documents are published significantly prior to the
  191. Stockholm meeting.
  192.  
  193.  
  194. Hypertext Markup Language Working Group (HTML)
  195.  
  196. This working group is progressing on the HTML 2.0 specification.
  197. Multiple changes made during the meetings in Danvers require that a new
  198. version be issued and the specification be reviewed again by the working
  199. group before processing it as a Proposed Standard.  With both HTML and
  200. HTTP (see below), a key ongoing difficulty is maintaining a coherent
  201. sequence of versions and minimum functionality, rather than having
  202. different implementations present ``laundry lists'' of enhancements to
  203. users.  The work on HTML 2.0 is expected to be completed before the
  204. Stockholm IETF meeting.
  205.  
  206.  
  207. HyperText Transfer Protocol Working Group (HTTP)
  208.  
  209. The document describing the de facto standard HTTP (version 1.0) is
  210. being completed and should be forwarded for publication soon.  1.1 is
  211. proceeding a little more slowly due to the desire to consolidate and
  212. incorporate a few widely-used features.  Additional new features, such
  213. as digest authentication (signature validation) are still under
  214. consideration for version in 1.1.  As discussed under HTML above, the
  215. long-term challenge for this working group is going to be to steer a
  216. coherent course, rather than having large collections of
  217. nearly-compatible clients and servers.
  218.  
  219.  
  220. Internet White Pages Requirements Working Group (WHIP)
  221.  
  222. The documents from this working group are nearly finished, but have been
  223. delayed by general exhaustion.  The group did not meet at this IETF, nor
  224. at the previous one.  Its work is expected to conclude prior to the
  225. Stockholm IETF.
  226.  
  227.  
  228. Mail Extensions Working Group (MAILEXT)
  229.  
  230. Eight documents are on the table for this working group.  Small
  231. revisions will be made to most of them, then they will be disposed of as
  232. follows:
  233.  
  234.  
  235.    o Pipelining proposal to be recommended for processing as a Proposed
  236.      Standard.
  237.  
  238.    o 521 response code to Experimental with special attention to
  239.      implementations and implementation experience.
  240.  
  241.    o Transport checkpointing to Experimental.
  242.  
  243.    o Binary to Experimental so that experience can accumulate.
  244.  
  245.    o MIME checklist to Informational.
  246.  
  247.    o Mail attributes document to be reviewed on the mailing list and
  248.      submitted for publication as Informational.
  249.  
  250.  
  251. Prior to submission of the Experimental documents listed, the working
  252. group will prepare notes on the use of service extension keywords
  253. without ``X'' prefixes when Experimental RFCs are published.
  254.  
  255. This working group will be concluded when the documents listed above are
  256. processed by IESG, presumably prior to the Stockholm IETF. A new working
  257. group will be proposed that will focus specifically on the
  258. ``applicability statement'' work.  The working group concluded that the
  259. Applicability Statement work should result, not in two documents that
  260. simply update and clarify mail transport and header behavior, but in new
  261. consolidated documents.  The new documents should incorporate and
  262. replace RFC 821, RFC 822, the mail sections of RFC 1123, and the basic
  263. SMTP extension mechanisms.
  264.  
  265. A second new working group will be be proposed to examine UA to UA
  266. interaction issues and, in particular, to review and specify header
  267. fields and their semantics in standards track documents.  The ``new
  268. header fields'' proposal will be forwarded to this group.
  269.  
  270.  
  271.  
  272. MIME Content-Type for SGML Documents Working Group (MIMESGML)
  273.  
  274. There are three documents on the table; they will be ready by mid-May.
  275.  
  276. The three drafts in progress were discussed at this meeting:
  277.  
  278.  
  279.    o Encapsulating SGML Documents using MIME,
  280.    o Multipart/Related Content-Type, and
  281.    o Message/External-Body Content-ID Access Type.
  282.  
  283.  
  284. These three documents will comprise the infrastructure for exchanging
  285. SGML documents.  Specific issues discussed included representation of
  286. SGML notation declarations, representation of non-ASCII character
  287. strings, used in SGML entity declarations, that are to appear on the
  288. Content-SGML-Header.  A proposed solution is to use RFC 1522.  Extended
  289. discussion of character sets, character encodings, SGML record-start and
  290. -end (RS/RE) conventions ensued.  The conclusion was that outside of
  291. text/SGML no charset or RS/RE processing will be done.  For text/SGML
  292. only standard MIME canonicalization and translation of line end
  293. characters will be sufficient.
  294.  
  295. The letter of liaison from ISO/IEC JTC1/SC16/WG8 (SDIF) was discussed.
  296. The working group chair will send the drafts to WG8 for their review.
  297. The draft will include a section on SDIF.
  298.  
  299. Finally the milestones were reviewed and updated.
  300.  
  301.  
  302.  
  303. Notifications and Acknowledgements Requirements Working Group
  304. (NOTARY)
  305.  
  306. This working group is completing its major work.  The report format
  307. documents (draft-ietf-notary-mime-report-01.txt,
  308. draft-ietf-notary-mime-delivery-04.txt, draft-ietf-notary-status-01.txt)
  309. and the document describing the SMTP extension for requesting delivery
  310. reports (draft-ietf-notary-smtp-drpt-03.txt) were reviewed, and some
  311. changes agreed to by the working group.  New versions are being prepared
  312. and will be reviewed by the working group during the next month; the
  313. documents are expected to be submitted to the IESG in May.
  314.  
  315.  
  316.  
  317. Quality Information Services Working Group (QUIS)
  318.  
  319. Despite initial enthusiasm, this working group has failed to produce any
  320. products or even to meet effectively.  It is being shut down.
  321.  
  322.