ietf-nntp Minutes from the WG (these have been submitted to IETF)

[Stan Barber]

NNTPEX WG Minutes from IETF 40
$Id: nntp.wg.notes.txt,v 1.3 1997/12/19 04:25:42 sob Exp sob $
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 at 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).