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