NNTPEXT at the 49th IETF Notes prepared by Stan Barber, Co-Chairman At this meeting of the working group, the main draft, draft-ietf-nntpext-base-11.txt, was the only draft discussed in detail. Most of the discussion was centered on relatively small changes to the document. The most significant changes were to remove PAT from the base document and to replace it with HDR. The HDR text will be based on the XHDR text in RFC 2980. There was also an agreement to use the BNF suggested by Clive Feather to replace the current text in section 5 (along with small changes in other parts of the document that reference information in section 5). This will hopefully clarify wildmat sufficiently, so there is no remaining big issues left in the draft. The only other issue of significance discussed was the ongoing debate on the use of "UTC" or "GMT" in the date command (and others) that clients can use to indicate to the server that the time stamp used in the command should have no time zone offset associated with it. It has always been the case that NNTP was never to be used as any kind of time protocol. However, it is important that the notion of time be consistent enough that clients won't miss articles due to time stamp skewing. The group decided that the second should be rewritten to indicate that the usage of "GMT" or "UTC" was syntactically equal and that the intent was for the server to drop a time zone offset in doing whatever time comparison was required. In addition, this section would carry a specific recommendation (a SHOULD) that all server operators use NTP to synchronize their server clocks with other clocks on the Internet. There was some discussion on specifying streaming in the draft. Some felt that it should be specified because of issues that had come up in DRUMS. However, the group did not have a clear idea of exactly how that should be done. There were others that felt it could be pushed off into an extension. Whatever the case, it will be important for all commands to indicate if they can be "streamed" or not. MODE READER was discussed, but no one in the group felt that its use should be required. A reader can choose to use it or not. It was not clear that the group thought that the current discussion of the command in the draft was in need of further refinement. There was no intent in the group to invalidate a dual daemon architecture (e.g. INN), just not require MODE READER to demarc the switch from one daemon to another. There was a proposal from the mailing list to do some significant document reorganization. Those present at the meeting didn't think such a reorganization was warranted at this time.