home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 95jul / area.applications.95jul.txt < prev    next >
Text File  |  1995-10-18  |  14KB  |  307 lines

  1.  
  2. Applications Area
  3.  
  4. Directors:
  5.  
  6.  
  7.    o Harald Alvestrand:  Harald.T.Alvestrand@uninett.no
  8.    o John Klensin:  Klensin@mail1.reston.mci.net
  9.  
  10.  
  11. Area Summary reported by John Klensin/MCI and Harald Alvestrand/UNINETT
  12.  
  13. This is a report on the status of the Applications Area as of the
  14. conclusion of the Stockholm IETF meeting, July 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 Detailed Revision/Update of Message Standards (DRUMS)
  21.    o HyperText Markup Language (HTML)
  22.    o HyperText Transfer Protocol (HTTP)
  23.    o Integrated Directory Services (IDS)
  24.    o Mail Extensions (MAILEXT)
  25.    o MIME Content-Type for SGML Documents (MIMESGML)
  26.    o MIME - X.400 Gateway (MIXER)
  27.    o Notifications and Acknowledgements Requirements (NOTARY)
  28.    o Uniform Resource Identifiers (URI)
  29.  
  30.  
  31. Of these, DRUMS is new since the last IETF. The MIXER Working Group has
  32. evolved from the previous MIXER Advisory Committee (see the April 1995
  33. Area Report).  The HTTP Security BOF (HTTPSEC) held in San Jose has
  34. evolved into the Web Transaction Security Working Group (WTS), jointly
  35. managed in the Security and Applications Areas.  HTTP is jointly
  36. supervised with the Transport Area.  IDS and URI are jointly supervised
  37. with the User Services Area.
  38.  
  39. The Electronic Data Interchange Working Group (EDI) concluded its work
  40. since the last IETF. Publication of its final product, a Frequently
  41. Asked Questions (FAQ) document, is pending.  The Internet White Pages
  42. Requirements Working Group (WHIP) concluded since the last IETF. Some
  43. documents were transferred to the IDS Working Group.  The Quality
  44. Information Services Working Group (QUIS) was also concluded, as
  45. discussed in the last Area Report.  Finally, the URI Working Group
  46. concluded its work during this IETF. See its minutes and discussion
  47. below for more information.
  48.  
  49. The Applications Area sponsored three BOF sessions on mime-related media
  50. type registration (MIMEREG), content labelling of Web and other Internet
  51. materials (RTL), and mail read receipts (RECEIPT) at the Stockholm IETF.
  52. The RTL BOF was jointly sponsored with User Services and the minutes of
  53. that meeting are reported under the User Services section of these
  54. proceedings.  Summaries of each of the BOFs is reported below.
  55.  
  56.  
  57.  
  58. MIME Registration BOF (MIMEREG)
  59.  
  60. Registration procedures for MIME content types have been evolving since
  61. MIME was first approved as a Proposed Standard and these definitions
  62. began to be used in the World Wide Web and in other Internet
  63. applications.  They are now referred to as media types to reflect their
  64. broader application.  The current registration procedures call for
  65. exposure of a potential new type on a mailing list followed by review of
  66. consensus and the adequacy of the registration and description.  This
  67. procedure has probably worked better than its predecessors, but the
  68. burden on the reviewer has proved excessive.
  69.  
  70. The MIME standard also specifies that new top-level types can be
  71. defined, but discourages the registration of many of these and requires
  72. that registration be accomplished by standards-track processing.
  73.  
  74. A BOF session was held in Stockholm to review the general strategy for
  75. media type registrations and to examine the top-level type question,
  76. especially with regard to a proposal to register `chemical' as a
  77. top-level type.  Opinions on the latter subject are divided in IETF,
  78. occupying the entire range between ``no further top-level types should
  79. be registered'' and ``registration for top-level types should be fairly
  80. permissive.''  The BOF was inconclusive and further exploration in this
  81. area will be needed.
  82.  
  83.  
  84. Read the Label BOF (RTL)
  85.  
  86. In the recent past, a number of public concerns about limiting access to
  87. information on the Internet have been raised.  Most of these concerns
  88. have taken the form of calls for access limits for minors who might
  89. otherwise be exposed to material considered suitable only for adults.
  90. Countervailing concerns about the potential for censorship have been
  91. raised in response.  After brief background remarks by the chair, a
  92. discussion followed, the purpose of which was to determine the level of
  93. interest among the BOF participants in forming an IETF Working Group to
  94. develop technical specifications supporting voluntary information
  95. filtering through appropriate, end-user access software.  The results of
  96. the technical effort would permit users of the Internet to apply some
  97. form of content filtering on information obtained from Web servers, file
  98. servers, e-mail servers and other sources of information found on the
  99. Internet.  For concreteness, the discussion tended to fall back on an
  100. implicit Web browser/server model of the problem, but it was
  101. acknowledged that the general problem was more complex and that
  102. solutions should apply to all forms of information on the Internet.
  103.  
  104. Conclusions:
  105.  
  106.  
  107.    o The IETF should investigate technical possibilities for filtering
  108.      and access controls which could be voluntarily invoked by users and
  109.      voluntarily supported by information service suppliers.
  110.  
  111.    o A short-term working group charter should be prepared which would
  112.      explore technical means for creating closed groups of
  113.      clients/servers.  A particular client might participate in more
  114.      that one closed server group.  This was recognized as a coarse form
  115.      of content filtering at the level of entire servers, and thus a
  116.      very crude means of addressing the problem.
  117.  
  118.    o A longer term working group should be considered which would
  119.      explore finer-grained filtering capabilities, possibly using
  120.      `metadata' techniques.
  121.  
  122.    o Not all information in the Internet is likely to be marked, so any
  123.      proposals for filtering and access control will have to deal with
  124.      unmarked Internet information components.
  125.  
  126.  
  127.  
  128. Receipt Notifications for Internet Mail BOF (RECEIPT)
  129.  
  130. About 60 participants agreed to add read receipt functionality to
  131. Internet mail.  The charter for the working group has been accepted.
  132. The author of the specification is Roger Fajman, who promised a first
  133. draft by end of August.  A first technical solution has been drafted
  134. already to support functionality based on the NOTARY work.  Most of the
  135. available time has been spent to find out what exactly the requirements
  136. are seen both from the sender's and from the recipient's point of view.
  137. There is no consensus yet.  Privacy and security issues are a topic of
  138. the working group but will be postponed until first experience has been
  139. gained.
  140.  
  141.  
  142.  
  143. Access, Searching and Indexing of Directories Working Group (ASID)
  144.  
  145. LDAPv2 was discussed, with a draft promised by the Dallas IETF. One
  146. candidate (MDAP) was presented at the meeting, as was a different
  147. proposal for strong authentication/encryption of the LDAP session, and
  148. for supporting stand-alone LDAP.
  149.  
  150. The two Whois++ protocol documents have been approved.  The indexing
  151. document is still awaiting some issues to be resolved.  A discussion was
  152. held on various protocol aspects that have surfaced during
  153. implementation.
  154.  
  155. The common indexing protocol draft was discussed.  The group feels it
  156. still needs to be more general, separated from Whois++.  Referrals need
  157. to be URL-style, Whois++ queries need to be dropped, etc.  People should
  158. send comments to the list, after which a new draft will be submitted.
  159.  
  160. An Internet-Draft for storing PGP keys in the X.500 directory was
  161. discussed and approved by the group, following some changes to the
  162. string representation used for the keys.
  163.  
  164. A new charter was approved, with updated milestones.
  165.  
  166.  
  167. Detailed Revision/Update of Message Standards Working Group (DRUMS)
  168.  
  169. The DRUMS Working Group held its first meeting at the Stockholm IETF
  170. with about 50 people in attendance.  Since the group was only recently
  171. formed and did not yet have any documents to review, the working group
  172. meeting time was used to (a) list several important issues which might
  173. be difficult to resolve on a mailing list, and (b) to discuss in detail
  174. one of those issues:  whether to change the grammar of RFC 822 to remove
  175. ``.'', ``['', and ``]'' as terminal symbols and thus allow them to
  176. appear in ``phrase''s.  The discussion which ensued illustrated the
  177. difficulty of deciding whether to ``fix'' features of the existing
  178. protocol which are widely regarded as broken, when the ``fix'' would
  179. adversely impact the installed base.  A suggestion was made that each
  180. such decision be made only after a careful analysis of cost vs.
  181. benefit.  Since several other issues involve tradeoffs of this kind, the
  182. chair directed that a discussion of such tradeoffs and how to think
  183. about them, be held on the mailing list, as a prerequisite to further
  184. discussions about changes to the actual protocols.
  185.  
  186.  
  187. HyperText Markup Language Working Group (HTML)
  188.  
  189. The HTML Working Group reviewed goals for moving forward with various
  190. HTML extensions, including tables, metadata, super/subscripts, and
  191. internationalization.  A firm goal was set for clear progress on tables,
  192. which are close to Last Call status.
  193.  
  194.  
  195. HyperText Transfer Protocol Working Group (HTTP)
  196.  
  197. The agenda called for a discussion of the HTTP 1.0 and 1.1 documents,
  198. and a proposal for multiple transactions per connection.  As the editors
  199. of the documents were not present, the discussions were brief.  The
  200. chair noted that the milestones were out of date.  The Area Director
  201. raised considerable concern over the lack of progress and coordination
  202. in the working group.  A constructive discussion of the milestones of
  203. the working group concluded the meeting.
  204.  
  205.  
  206. Integrated Directory Services Working Group (IDS)
  207.  
  208. Reporting on pilot projects and liaison reports will be done on the IDS
  209. mailing list in the future to free up time in the working group meeting.
  210. Both the Whois++ and X.500 directory catalogues are now available
  211. on-line and currently in the process of setting up a procedure for
  212. adding in new implementation entries.  There was a lot of discussion on
  213. the X.500 schema registry and the conclusion was to try and focus on
  214. getting this operational as soon as possible.  The Internet-Draft will
  215. be reissued within the next month.  A proposal for managing the X.500
  216. root context was discussed along with two Internet-Drafts on building a
  217. directory service, one based in the US and one based in the Netherlands.
  218. The group felt that it was important to disseminate practical experience
  219. gained to as wide an audience as possible.
  220.  
  221. IDS took over the Simple Internet White Pages documents at this meeting
  222. and decided to go for two documents:  user requirements and schema
  223. requirements.  This information will be pulled from the existing WHIP
  224. document and the Internet-Drafts will be circulated by the end of
  225. August.
  226.  
  227.  
  228. Mail Extensions Working Group (MAILEXT)
  229.  
  230. MAILEXT did not meet during the Stockholm IETF. Its work is
  231. substantially complete; the remaining documents are being polished and
  232. undergoing final review before being submitted to the IESG.
  233.  
  234.  
  235. MIME Content-Type for SGML Documents Working Group
  236. (MIMESGML)
  237.  
  238. Due to a combination of circumstances, the MIMESGML Working Group met
  239. without either of the co-chairs present.
  240.  
  241. The working group seems to be at a choice point with one complete
  242. proposal on the table but a significant fraction of the working group
  243. preferring other alternatives.  That situation was discussed during the
  244. working group meeting and objections to the current draft were discussed
  245. among the attendees in Stockholm and on the MBONE. Details of the issues
  246. discussed appear in the working group minutes.  Don Stinchfield from EBT
  247. volunteered that he would author a new draft for this group that was
  248. more general, included a discussion of difficulties with the current
  249. draft, and still followed the direction of the charter.  This draft will
  250. be posted to the mailing list in August.
  251.  
  252.  
  253. MIME - X.400 Gateway Working Group (MIXER)
  254.  
  255. About 40 participants, of which three are actual implementors of
  256. RFC 1327, participated at the meeting.  A list of 16 open topics
  257. streamlined the discussion.  The issue on how much ESMTP functionality
  258. should be mandatory for MIXER gateways needs more study and has been
  259. moved onto the mailing list.  All other issues have been solved.  There
  260. will be a one-day editor's meeting for page-by-page review at Richmond
  261. UK, 17 September.  An updated version is expected soon after that
  262. meeting.
  263.  
  264. The MIXER document handling body part mappings will be split to reduce
  265. the number of needed updates.  The bit ordering for G3 faxes will be
  266. checked with more implementors to get as much agreement as possible.
  267.  
  268.  
  269. Notifications and Acknowledgements Requirements Working Group
  270. (NOTARY)
  271.  
  272. The NOTARY group did not meet in Stockholm.  It believes that its work
  273. is finished with the IETF Last Call on its documents.  Some comments
  274. came in during and after the Last Call period; a report on these will be
  275. sent.
  276.  
  277.  
  278. Uniform Resource Identifiers Working Group (URI)
  279.  
  280. While the URI working group has completed all of the items in its
  281. original charter, ongoing efforts have identified several additional
  282. work items related to resource identifiers that should be pursued.  At
  283. the same time, the working group had become sufficiently large and
  284. diffuse that some proposals for, e.g., new URL types, were not getting
  285. comprehensive review.
  286.  
  287. In Stockholm, the working group met, heard reports on work in progress
  288. and being proposed, and discussed but did not reach conclusion on a
  289. proposal for a revised charter.  The working group was advised by the
  290. Area Director, John Klensin, that general IETF procedures called for
  291. concluding the working group and starting one or more new ones as needed
  292. and that highly focused working groups with short time frames and clear
  293. objectives were preferred to more open-ended ones.  He also reminded the
  294. working group that IETF's success record with standardizing research
  295. activities has been very poor and discouraged the working group from
  296. embarking on activities that still lack a foundation in practice.
  297.  
  298. There were additional discussions in the days after the working group
  299. met, culminating in a special BOF session to review options for future
  300. work and working groups.  Several proposals were outlined.  They will be
  301. proposed in more detail on the URI Working Group mailing list and, if
  302. sufficient constituency and focus exists, submitted for approval as new
  303. working groups.
  304.  
  305. The URI Working Group was concluded at the close of the IETF meeting.
  306.  
  307.