ietf-nntp Summary/Minutes from IETF41

[Stan Barber]

Minutes from the meeting of the NNTPEXT working group at IETF41

Notes taken by Brian Hernacki and edited by Stan Barber.

About 30 people attended this working group session. Stan Barber outlined the
planned discussion topics:
        - draft-ietf-nntp-imp-11.txt  is in 17th release
        - draft-ietf-nntp-base-05.txt is in 10th release
        - drafts on searching, dynamic feeding, and authentication
        - authinfo is being seperated to avoid getting the base
          bogged down in security stuff


The group decided that it was time to advance draft-ietf-nntp-imp-11.txt
to the ADs and IESG with the recommendation to publish it as an informational
RFC.

For draft-ietf-nntp-base-05.txt, there were a number of areas of discussion:

Should the negate operator (!) be added to wildmat? Dave Lawrence wants in 
since it's useful and implemented. The group decided that it should added and
MUST be required. This will be reflected in the next version of the draft.

Should the distributions operator be dropped from the NEWNEWS command? Since 
most people don't use this correctly anyways, folks at the meeting believe
that it's pretty useless.  It is already described in the 
draft-ietf-nntp-imp-0X.txt document. It could always be added as an extension 
later. The group decided to drop it from the next draft.

Should 502 be added as a valid response to the ARTICLE/STAT/BODY group of 
commands? Folks at the meeting said that it sounds like a good thing. There
was concern over how older clients would handle getting this response code.
There is already text in the current draft on how to handle unexpected codes,
so new clients written to comply with the new draft would already be able
to handle unexpected response codes. The group decided to add it.

How should adminstration infrastructure for extensions be managed? At the
previous IETF, someone suggested using the same type of management 
infrastructure IMAP is using. That would permit X-prefixed local extensions,
standards track extensions and experimental extensions. To get the latter
two classifications would require that a document defining the extension be
submitted to IESG. To facilitate moving this forward, Ned Freed will provide 
Stan with some text on this. Under this method, experimental extension would 
take about 2 months to get through the IESG. For standard extensions, one shot
working groups could be created for large batches of standard extensions. 
Other standards extensions would be handled over the mailing list. An open
question: Should this group provide a list of reviewers for the IESG?

For draft-ietf-nntpext-srch-0X.txt, there were a couple of items discussed:

At IETF41, there was considerable discussion concering UTF-8 that's not yet
in the document. When will it be there? Brian/Stephen will add some text to 
deal with UTF8 in the next draft. Once that happens, the group will make
a last call. Hopefully, that can happen on or before next IETF.

Brian Court came back to discussion draft-court-dynfeed-01.txt. This draft
addressed all the concerns brought up at IETF 41. There were some open 
discussion about how long dfeed parameters should last (currently they
are per session) and about how efficient the dynafeed process is compared
to existing mechanisms. However, the group decided to move this item forward
as a working group work item.

Concering draft-newman-nntpext-auth-00.txt,  Chris Newman talked about what he
was trying to do: take what was in the base document and make a few 
modifications. The group discussed the use of AUTHINFO GENERIC going forward.
Should we be documented and then deprecated? The draft defines AUTHINFO GENERIC
differently than current use. The group decided that Chris should remove
AUTHINFO GENERIC. It will remain in the current practices document. For the
new authenication mechansmi,  what is minimum to implement? Right now, the
document has CRAM-MD5 (just like IMAP). There was a concern that we want to 
swap this for something better later. The group decided to leave CRAM-MD5 in
as is. What about merging this back into the base document? The group decided
to leave them as is. Keith Moore likes this in particular and would like
to see this document worked though the group.