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.