home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 93mar / area.applications.93mar.txt < prev    next >
Text File  |  1993-05-12  |  10KB  |  265 lines
  1.  
  2. Applications Area
  3.  
  4. Director(s):
  5.  
  6.    o Russ Hobby:  rdhobby@ucdavis.edu
  7.    o Erik Huizer:  huizer@surfnet.nl
  8.  
  9. Area Summary reported by Russ Hobby/UC Davis
  10.  
  11. At the end of the Columbus meeting it was announced by the IAB that
  12. Brewster Kahle from Wais, Inc.  will replace Russ Hobby as a co-Director
  13. of the Applications Area.
  14.  
  15. Applications Area Directorate (APPLES)
  16.  
  17. The Applications Area Directorate met for the first time at the Columbus
  18. IETF. The Directorate will help the Area Directors on architectural
  19. matters and reviews.  Members of the Directorate are appointed by the
  20. Area Directors.  Nominations can be made by the Application Area working
  21. group Chairs.  The Directorate can be reached at <apples@surfnet.nl> and
  22. currently consists of the following individuals:
  23.  
  24.  
  25.    o Ned Freed
  26.    o John Klensin
  27.    o Steve Kille
  28.    o Christian Huitema
  29.    o Russ Hobby
  30.  
  31.  
  32. The first task of the directorate is to produce a document on an email
  33. architecture.  This document will be used as a basis for discussion on
  34. this topic in the Applications Area.  After the document has evolved to
  35. a state of maximum consensus, working groups will be created to focus on
  36. specific issues indicated by the Architecture Document.
  37.  
  38. The directorate also discussed the general problem of character sets and
  39. noted that they will be a recurring problem in many applications.  The
  40. directorate will develop an initial plan for dealing with character sets
  41. in applications and start a working group to address this problem in
  42. detail.
  43.  
  44. The directorate noted the increasing difficulty for working groups to
  45. make forward progress.  This appears to be due to the increasing size
  46. and interest in the IETF and the Internet in general.  More people, more
  47. discussions, more time.  In the future, the Applications Area desires an
  48. initial draft document be written by interested parties before a working
  49. group is formed.  While the final result of the working group may look
  50. nothing like the initial document, the initial document will provide
  51. focus for discussion.
  52.  
  53. There are four working groups jointly chartered under the User Services
  54.  
  55.  
  56.                                    1
  57.  
  58.  
  59.  
  60.  
  61.  
  62. Area and Applications Area.  They are:
  63.  
  64.  
  65.    o Integrated Directory Services (IDS)
  66.    o Integration of Internet Information Resources (IIIR)
  67.    o Uniform Resource Identifiers (URI)
  68.    o Whois and Network Information Lookup Service (WNILS)
  69.  
  70.  
  71. For a report on these Working Groups see the User Services Area Report.
  72.  
  73. There were two BOFs held that reside under the Network Management Area,
  74. but are strongly related to the Applications Area.  They are:
  75.  
  76.  
  77.    o Mail and Directory Management (MADMAN)
  78.    o IFIP Electronic Mail Management (EMAILMGT)
  79.  
  80. For a report on these BOFs see the Network Management Area Report.
  81.  
  82. Conference Control BOF (CONFCTRL)
  83.  
  84. Now that video, audio and shared applications are starting to flow over
  85. the network, there is a need for the setup and management of conference
  86. sessions.  This BOF focused on various aspects of controlling
  87. distributed network conferences.  Several people related their current
  88. work and plans were made for coordinating work through an IETF working
  89. group.
  90.  
  91. Interactive Mail Access Protocol BOF (IMAP)
  92.  
  93. The BOF discussed efforts to update and standardize IMAP. Mark Crispin
  94. has a new draft of IMAP that will be submitted as an Internet-Draft.  A
  95. sample working group charter was reviewed.
  96.  
  97. Internet Message Extensions Working Group (822EXT)
  98.  
  99. The RFC822 Message Extensions Working Group met for two sessions to
  100. review and approve the revised MIME protocol for Draft Standard.  With
  101. several clarifications and with the removal of several optional
  102. features, agreed to previously on the ietf-822 mailing list, MIME was so
  103. approved.
  104.  
  105. The Working Group has completed its Charter as currently written and is
  106. ready to conclude.  There is significant MIME related work which still
  107. needs to be addressed and for which new working groups should be formed.
  108. Among the work are MIME extensions such as the definition of a
  109. content-integrity-check and content-disposition body headers to add
  110. general functionality to MIME. There are expected to be a large number
  111. of new content-types defined, most of which should be developed in
  112. specific single-topic working groups.
  113.  
  114.  
  115.                                    2
  116.  
  117.  
  118.  
  119.  
  120.  
  121. MHS-DS Working Group (MHSDS)
  122.  
  123. The MHS-DS Working Group focused on its Long Bud pilot project at this
  124. IETF meeting.  Since the last meeting, some basic infrastructure has
  125. been established for supporting X.400 routing via the Internet X.500
  126. directory service.  By the next IETF, the Group plans to expand this
  127. infrastructure and generate some tools such that we can demonstrate that
  128. the pilot project is functional and that the directory is actually being
  129. used by some MTAs to support message routing.  To achieve this goal,
  130. specific action items were assigned to Working Group members.
  131. Specifically, two important documents will be written and circulated,
  132. and specific individuals will begin implementing important software
  133. tools.  The documents will clearly define the purpose of the pilot
  134. project, outline its short and long-term goals, specify its relationship
  135. to the existing Internet X.400 community, and indicate how to
  136. participate in the pilot.  The tools will facilitate the integration of
  137. the pilot with the existing Internet X.400 infrastructure.
  138.  
  139. In addition to working on issues relating to the Long Bud pilot project,
  140. we assigned action items for progressing three Internet-Drafts as RFCs.
  141. In addition, one or two minor technical issues were resolved which will
  142. be reflected in the next revision of the Internet-Drafts.
  143.  
  144. MIME-MHS Interworking Working Group (MIMEMHS)
  145.  
  146. There are three draft RFCs in progress:
  147.  
  148.  
  149.   1. Mapping between X.400 and RFC822 Message Bodies.
  150.   2. Equivalences between 1988 X.400 and RFC822 Message Bodies.
  151.   3. HARPOON (Rules for downgrading messages from X.400/88 to X.400/84
  152.      when MIME content-types are present).
  153.  
  154.  
  155. The first two have been stable for some time with no outstanding issues.
  156. The third (HARPOON) had some open issues and, until now, had never been
  157. discussed at an IETF meeting.
  158.  
  159. During the meeting, the HARPOON proposal was presented, the issues were
  160. resolved, and it was agreed that all three documents would be forwarded
  161. to the IESG for approval as Proposed Standards.
  162.  
  163. Minimal OSI Upper-Layers Working Group (THINOSI)
  164.  
  165. The THINOSI Working Group met for the first time as a working group.
  166. Nearly all the time was spent reviewing the first draft of the
  167. ``bytestream cookbook''.  Various changes were agreed upon, generally
  168. applying a principle of keeping things simple (and thin) for this first
  169. case, but ensuring interworking with ``full'' OSI implementations would
  170. be feasible.  It will be highly desirable to achieve alignment with the
  171. ``minimal OSI'' profile being developed in OIW and EWOS. Identifying the
  172. range of applications to be supported is central to achieving this
  173.  
  174.  
  175.                                    3
  176.  
  177.  
  178.  
  179.  
  180.  
  181. alignment - this should include at least DAP and X.400 P& if at all
  182. possible.
  183.  
  184. Office Document Architecture Working Group (ODA)
  185.  
  186. Over 1992 an international profile FOD26 was being approved.  An
  187. industrial consortium was preparing an ODA toolkit which becomes
  188. available 2Q 1993.  Pending the availability of this toolkit and the new
  189. profile, there has been little availability of new ODA implementations,
  190. though this will change during the third quarter of 1993.
  191.  
  192. The Working Group had previously expressed interest only in piloting
  193. with real products.  In view of their non-availability at present, there
  194. was little interest in the Group.
  195.  
  196. It is recommended that the Working Group conclude.  If there is further
  197. interest when products become available it can be revived, though this
  198. is unlikely to happen before November 1993.
  199.  
  200. OSI Directory Services Working Group (OSIDS)
  201.  
  202.  
  203.    o The Charter was discussed and several work items were defined.
  204.    o There is strong consensus on the need for continuation of this
  205.      Group.
  206.    o Volunteers for editing papers are hard to find.
  207.    o Schema management issue is still not resolved.  This remains a
  208.      major worry.
  209.    o A new approach to presenting Quality of data in the Directory was
  210.      discussed.  It will be put on paper and aligned with earlier ideas
  211.      of the Group.
  212.    o Representation of registration, IP-addressing and Network
  213.      Information was discussed.  A series of Internet-Drafts will be
  214.      produced on this issue.
  215.    o Representation of documents and related information in the
  216.      Directory was discussed based on four draft inputs.
  217.  
  218.  
  219. TELNET Working Group (TELNET)
  220.  
  221. The Working Group continued work on the Environment Option,
  222. Authentication and Encryption.
  223.  
  224. HP's Telnet MPX proposal for session multiplexing was discussed.  Most
  225. people were impressed with the results but felt that, in general,
  226. session multiplexing did not belong in the Telnet layer.  Perhaps this
  227. should be addressed as a TCP extension.  In the meantime, the Working
  228. Group suggested that HP submit the protocol to be an Experimental RFC.
  229.  
  230. There was enthusiastic discussion by a group of people who want to work
  231. on improving TN3270 to better match the current SNA environment.  The
  232. TELNET Working Group felt that the TN3270 work would be outside the
  233.  
  234.                                    4
  235.  
  236.  
  237.  
  238.  
  239.  
  240. scope of their Group and work should be done as a separate working
  241. group.
  242.  
  243. X.400 Operations Working Group (X400OPS)
  244.  
  245.  
  246.    o Finalized Documents:
  247.  
  248.       -  Requirements for participation in the GO-MHS Community for
  249.          Informational RFC.
  250.       -  Routing coordination for X.400 services as Experimental
  251.          Standard.
  252.       -  Evaluation of ADMDs as Informational RFC.
  253.       -  Assertion of the ADMD=IMX for Proposed Standard.
  254.       -  X.400 use of extended character sets for Proposed Standard.
  255.  
  256.  
  257.    o Work Left To Do:
  258.  
  259.       -  Automatic email distribution of tables.
  260.       -  X.400 - RFC822 mapping authorities.
  261.  
  262.  
  263.  
  264.                                    5
  265.