home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / nntp / nntp-minutes-92mar.txt < prev    next >
Encoding:
Text File  |  1993-02-17  |  5.1 KB  |  135 lines
  1. This is a rough draft - Megan 04/20/92
  2.  
  3.           Minutes of the NNTP Working Group
  4.                   Eliot Lear
  5.  
  6. Summary
  7.  
  8. The IETF-NNTP working group met three times in San Diego to walk
  9. through the existing NNTP v2 draft and get it out the door. All
  10. changes to the NNTP document have been made, and after several
  11. formatting changes are made a new version will be put out for comments.
  12.  
  13. Agenda
  14.  
  15.     Discussion of Security Issues in the NNTP Arhictecture
  16.     Use of formats in NNTP
  17.     Document walk-through
  18.     News Reader Issues
  19.     Action Items
  20.  
  21. Two meetings occurred on Monday, and one on Wednesday night.
  22.  
  23. Authentication Issues
  24.  
  25. During the first meeting, we discussed the current security mechanism.
  26. It was believed that AUTHINFO was still not general enough for sites
  27. to implement certain types of authentication.  The conclusion was to
  28. essentially hand over the TCP stream to a mutually agreed upon
  29. authentication system, and take it back when it is done.
  30.  
  31. Seven/Eight Bit Issues
  32.  
  33. After much wrangling on the topic of 7/8 bit, it was decided that the
  34. 7-bit restriction on NNTP should be removed. Commands must still be
  35. sent with the high order bit cleared, but data may contain octets with
  36. the high order bit set. In fact this is existing practice of the most
  37. common servers. The BINARY format has been removed until such time as
  38. someone can define a message format for it (see below). The IMAGE
  39. format has been renamed to PREARRANGED, to heighten the point that the
  40. option should only be used by consenting partners.
  41.  
  42. Document Walkthrough Highlights
  43.  
  44. There were a bunch of minor changes and clarifications. The error
  45. codes section has been reworded slightly. Specifically, certain
  46. response codes should be properly processed at any time a response
  47. code is expected, either for debugging purposes (09x codes) or certain
  48. other error conditions that may occur at any time (e.g., new
  49. authentication required).
  50.  
  51. A new VERSION command has been added and required so that each side
  52. can determine the software being used by the other. The syntax of this
  53. command allows for comments at the end of either the command or the
  54. response. The expectation is that version information about particular
  55. implementations will be collected.
  56.  
  57. The Connect sequence has been clarified, and discussion moved from
  58. section 3 to section 2.
  59.  
  60. Continuation characters a'la SMTP and FTP have been allowed. This
  61. documents existing practice in most implementations. It was thought
  62. that this would be useful to communicate site specific connection
  63. information to the other side of a connection.
  64.  
  65. The LIST command has been restructured to return the same information
  66. it gave for version 1.  This was done because the change brought up
  67. more problems than it solved, and the extensions were primarily for
  68. news readers.
  69.  
  70. The NEWGROUPS command is deprecated in favor of LIST.
  71.  
  72. The option command has been changed so that a possible return is
  73. UNIMPLEMENTED. This is for non-standard options that are asked of
  74. unwitting servers.
  75.  
  76. The BATCH option has been changed so that no articles greater than the
  77. agreed upon batch size may be transferred. To transfer larger articles
  78. the other side must first turn batch mode off.
  79.  
  80. The SIMPLE authentication mechanism has been reworked to fit the
  81. changed authentication model.
  82.  
  83. A new appendix is being added on implementation issues. Currently
  84. there are numerous implementations that exacerbate the worst features
  85. of the current protocol. For example, opening a connection, offering
  86. one article, not sending it, and closing the connection transfers no
  87. data. Data presented at this IETF indicates that this happens a lot.
  88.  
  89. News Reader Issues
  90.  
  91. We began discussing news reading issues in the last session, and came
  92. up with more questions than answers in that time frame. The following
  93. comments were made:
  94.  
  95. Are we talking about an SQL interface? Should predicates be specified
  96. in the protocol? Clearly the user needs some better way to prioritize
  97. what gets presented.
  98.  
  99. Should the protocol be more server event driven than NNTP? Currently
  100. the news reader software is responsible for ordering articles. But
  101. suppose an article with higher priority hits the server. How should
  102. this best be communicated to the user?
  103.  
  104. Should the protocol BE NNTP with yet more extensions?
  105.  
  106. Is an RPC interface the ideal? Should the client even have to know
  107. that it is going to another machine for its information? If not, are
  108. we giving up on .newsrcs?
  109.  
  110. What about other work in this area? The WWW, archie, and WAIS people
  111. are all dealing with similar questions, not to mention every
  112. librarian.
  113.  
  114. Should the protocol be tied to netnews? Should the distinction between
  115. netnews and EMail be eliminated, as far as this protocol is concerned?
  116. What are the differences?
  117.  
  118. Also, should multiple remote sources be supported in the protocol?
  119. Should there be discovery?
  120.  
  121. It doesn't take much of an imagination to see that one could easily
  122. bloat a protocol. Further discussion on how to limit the scope of a
  123. reader protocol ensued.
  124.  
  125. Action Items
  126.  
  127.     Get a draft on NNTP out within two weeks.
  128.  
  129.     Get an implementation of the new version out within four.
  130.  
  131.     Update Charter.
  132.  
  133. The former is all but done, the latter two are still being worked on.
  134.  
  135.