NNTPEX WG Minutes from IETF 40 By STAN BARBER [Note: Thanks to Brian Hernacki of Netscape for submitting his notes to help me develop this summary.] *** Introduction of the New WG Chairs ** This was the first meeting of the WG with the new co-chairs, Ned Freed of Innosoft and Stan Barber of Academ Consulting Services. Previously, Stan had been serving as document editor and principle author of the initial two documents from the group. He will continue in this role and serve as "lead" chair. Ned will arbitrate problems concerning the initial two documents and keep Stan from making mistakes. All decisions concerning documents will go through both of them before going to the AD's and IESG. If anyone wants the WG to consider any particular extension, it must be submitted through the IETF Internet-Drafts mechanism. Sending it to the extensions list is a good way to get some discussion, but it won't officially be considered by NNTPEXT unless it is in the Internet-Drafts repository. ** Current Status ** The "common practices" document is in its 11th release. There have been no major show-stopping comments about this draft in the last three months. Those that have come in will be included (along with a table of contents and some examples) in the 12th release that should come out around the 15th of December. It is expected that this document will go to WG last call around that time. If there are no other problem found, this document will go to the AD's in early January with a recommendation for publication as an Informational RFC. In the current practices draft, there are references to certain things like "moderated groups" that are not fully defined and not fully referenced. Stan said that he intended to keep those types of things out of the common practices draft and reference RFC 1036. He will comb through the document for the next release and see that such ambiguities are clarified. He welcome any specific references that anyone would care to point out. Please send them to the list (ietf-nntp@academ.com). ** RFC977bis ** The "RFC977bis" document is in the 8th release and has gone through significant changes since the last IETF. The main revisions have been in adding internationalization features. Initially, there was the addition of a CHARSET command. After considerable discussion in the newsgroup (and input from the unofficial RFC1036bis group), the CHARSET idea was replaced by the notion of changing the default character set in NNTP from US-ASCII to UTF-8. This change is reflected in the most recent draft. There was some discussion about setting the language for certain kinds of response text, but it was decided that should probably be put into a language extension. There was a suggestion to provide a mechanism for getting the various AUTHINFO GENERIC mechanisms supported. Chris Lewis was not at the meeting, but his input will be solicited. Such information could be returned as part of a LIST EXTENSIONS response or another command or as a response to AUTHINFO GENERIC without any arguments. There was also a request to clarify which commands are subject to authorization and to clarify the difference between the 450, 452 and 502 responses when doing various forms of access control. 502 was not included in AUTHINFO section of the current draft except in the "transition issues" section. It was strongly suggested that 502 be used when there is no access to this command irrespective of authorization credentials. There was also some confusion about the requirement to log the email address in the AUTHINFO GENERIC section. Since this was included based on information from Chris Lewis, he will need to be polled about this as well. Finally, there was discussion about how information made available to a client may change depending on the change in authentication credentials. There was a general discussion about how the response from LIST might differ depending on the current state of credentials. RFC 977 was not clear on this. Many implementations do not do restrictions on the response to LIST, but when individual GROUP commands are issued for groups for which the client does not have adequate credentials, access may be denied. There was a lengthy discussion about various modifications to WILDMAT. The main area was in how to specify WILDMAT in the context of UTF-8. The current draft specifies that WILDMAT would work on characters (not octets). There is also concern about how to match on text elements for which multiple equivalent character sequences are possible (i.e. both precomposed forms and a dynamically composed forms exist).There was also a discussion about adding a "not" (!) operator to WILDMAT, but there was no strong consensus on this. There was also no consensus about using the WILDMAT format to specify distributions in those commands where distributions can be specified. Discussion continued on what format the response from LIST EXTENSIONS should take. Stan suggested that folks look at the format outlined in a draft from the FTP extensions group. See "draft-ietf-ftpext-feat-02.txt" for the details. More discussion on this will be done on the list. There was also some discussion of how the LIST EXTENSIONS response might change given a client's authorization status. The IMAP4 folks had already been down this path and their conclusions was that all capabilities should be listed even if some of them are not available to a particular authenticated user. This seems reasonable. There might be more discussion about this on the list as well. The group decided that the response for OVER will compress any string of non-printing US-ASCII white space to a single white space in a response. The group decided that DATE will continue to response using GMT/UTC. NEWGROUPS and NEWNEWS would continue to use time based on the server's local timezone. These two commands will also support GMT/UTC when specified. The group also wants to see that clients do all queries in GMT/UTC going forward. Servers will continue to accept both. The group decided that the BODY command would not be modified to display the MIME-type and there continue to be no specific limit on the total size of any response, single or multi-lined. The group decided not to put SLAVE back into the spec. The group decided not to put in a VERSION command. The group requested that referenced to Usenet be replaced by references to netnews. The group decided to require that response codes be restricted to three digits and that leading zeros should not be permitted. There was a discussion of modifying the specifics of the response from LIST NEWSGROUPS command to permit that URLs providing information about the newsgroup. There is nothing specific in the that prohibits this from being done presently. The group also wants better language concerning the specifics of the fourth field returned by LIST/LIST ACTIVE. The current idea is to define y n and m and acknowledge that there may be other flags added via the standard extensions mechanism. The new version of this document with the changes decided by the WG at IETF should be available before the end of January 1998. ** GET/LIST EXTENSIONS ** These were not discussed in the WG. They will be discussed more on the extensions list. ** SEARCH EXTENSION ** The group decided to rename this to SRCH. The next version of the draft will reflect the internationalization steps in the RFC977bis document. There was also some discussion on moving the PAT :TEXT stuff into the basic definition of PAT. This will be discussed further on the ietf-nntp mailing list. Will SRCH interpret MIME body types before searching them. The group decided that this was a bad idea, mostly based on IMAP4's experience in this area. There was also a request for the authors to better define how to search for non-existant (as opposed to blank) headers (e.g. Search for articles that don't have a MIME-Version: line).