This is a rough draft - Megan 04/20/92 Minutes of the NNTP Working Group Eliot Lear Summary The IETF-NNTP working group met three times in San Diego to walk through the existing NNTP v2 draft and get it out the door. All changes to the NNTP document have been made, and after several formatting changes are made a new version will be put out for comments. Agenda Discussion of Security Issues in the NNTP Arhictecture Use of formats in NNTP Document walk-through News Reader Issues Action Items Two meetings occurred on Monday, and one on Wednesday night. Authentication Issues During the first meeting, we discussed the current security mechanism. It was believed that AUTHINFO was still not general enough for sites to implement certain types of authentication. The conclusion was to essentially hand over the TCP stream to a mutually agreed upon authentication system, and take it back when it is done. Seven/Eight Bit Issues After much wrangling on the topic of 7/8 bit, it was decided that the 7-bit restriction on NNTP should be removed. Commands must still be sent with the high order bit cleared, but data may contain octets with the high order bit set. In fact this is existing practice of the most common servers. The BINARY format has been removed until such time as someone can define a message format for it (see below). The IMAGE format has been renamed to PREARRANGED, to heighten the point that the option should only be used by consenting partners. Document Walkthrough Highlights There were a bunch of minor changes and clarifications. The error codes section has been reworded slightly. Specifically, certain response codes should be properly processed at any time a response code is expected, either for debugging purposes (09x codes) or certain other error conditions that may occur at any time (e.g., new authentication required). A new VERSION command has been added and required so that each side can determine the software being used by the other. The syntax of this command allows for comments at the end of either the command or the response. The expectation is that version information about particular implementations will be collected. The Connect sequence has been clarified, and discussion moved from section 3 to section 2. Continuation characters a'la SMTP and FTP have been allowed. This documents existing practice in most implementations. It was thought that this would be useful to communicate site specific connection information to the other side of a connection. The LIST command has been restructured to return the same information it gave for version 1. This was done because the change brought up more problems than it solved, and the extensions were primarily for news readers. The NEWGROUPS command is deprecated in favor of LIST. The option command has been changed so that a possible return is UNIMPLEMENTED. This is for non-standard options that are asked of unwitting servers. The BATCH option has been changed so that no articles greater than the agreed upon batch size may be transferred. To transfer larger articles the other side must first turn batch mode off. The SIMPLE authentication mechanism has been reworked to fit the changed authentication model. A new appendix is being added on implementation issues. Currently there are numerous implementations that exacerbate the worst features of the current protocol. For example, opening a connection, offering one article, not sending it, and closing the connection transfers no data. Data presented at this IETF indicates that this happens a lot. News Reader Issues We began discussing news reading issues in the last session, and came up with more questions than answers in that time frame. The following comments were made: Are we talking about an SQL interface? Should predicates be specified in the protocol? Clearly the user needs some better way to prioritize what gets presented. Should the protocol be more server event driven than NNTP? Currently the news reader software is responsible for ordering articles. But suppose an article with higher priority hits the server. How should this best be communicated to the user? Should the protocol BE NNTP with yet more extensions? Is an RPC interface the ideal? Should the client even have to know that it is going to another machine for its information? If not, are we giving up on .newsrcs? What about other work in this area? The WWW, archie, and WAIS people are all dealing with similar questions, not to mention every librarian. Should the protocol be tied to netnews? Should the distinction between netnews and EMail be eliminated, as far as this protocol is concerned? What are the differences? Also, should multiple remote sources be supported in the protocol? Should there be discovery? It doesn't take much of an imagination to see that one could easily bloat a protocol. Further discussion on how to limit the scope of a reader protocol ensued. Action Items Get a draft on NNTP out within two weeks. Get an implementation of the new version out within four. Update Charter. The former is all but done, the latter two are still being worked on.