ietf-nntp Revised Notes from IETF 49

[Stan Barber]

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 on daemon to another.


There was a proposal from the mailing list to do some significant document reorganization. Those present
at the meeting didn't thinkg such a reorganization was warranted at this time.