ietf-nntp Revised Notes from IETF 49

Lee Kindness lkindness at csl.co.uk
Thu Jan 25 02:18:15 PST 2001


Stan O. Barber writes:
 > Lee Kindness wrote:
 > > It's important to note that UTC is NOT is rfc-977 and although it's
 > > more 'correct' it doesn't buy as anything apart from code
 > > bloat. Compliant clients will ALWAYS use the GMT token because they
 > > cannot be sure if UTC will be understood by the server.
 > I would be surprised if it adds much code bloat since the intent is
 > for the server to treat the string "GMT" and "UTC" as meaning the
 > same thing, whatever that might mean from the server implementors
 > point of view.

You fail to understand that the addition of the 'UTC' token is totally 
pointless!

Every NNTP server that conforms to the new standard will have to
accept the 'GMT' and 'UTC' tokens on the date related
commands. However NNTP clients will only ever use the 'GMT' token
since it guarantees conformity with RFC-977 and the new standard. Thus 
EVERY server will have code to support the 'UTC' token but no client
will ever issue it!

There is no excuse for this - it is bad design!

 > NNTP was never supposed to be a time server. The intent was for the
 > server to drop the localization for time zone when either of these
 > strings are present. Nothing more, nothing less.

This does not concern me, I agree that the date related functions in
NNTP shouldn't be guaranteed acurate (a dedicated protocol such as NTP 
should be used for this). However I don't see the need to be
'politically correct' (which UTC isn't) and introduce the 'UTC' token.

-- 
 Lee Kindness                  lkindness at csl.co.uk
 Software Engineer             Concept Systems Ltd.



More information about the ietf-nntp mailing list