Straw Polls

New Message Reply About this list Date view Thread view Subject view Author view

From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Wed Sep 06 2000 - 05:27:44 CDT


Here are the issues on which I need some guidance. Please reply by next
Thursday, Sept 14th, at the latest.

Note that I have left the question of whether to deal with signed
headers, cancel-locks, etc in our present draft to be decided later. The
only question asked now is whether to proceed towards a free-standing
RFC on the basis of the draft at present under discussion, or to do
something substantially different.

-------------------------------------------------------------------------------

1. Signed headers

A. Do we proceed on the basis of draft-lindsey-usefor-signed-00.txt?
   This means discussing it further to refine the details, and then submitting
   it as an RFC for either an experimental protocol or a proposed standard.
   (The question of whether it is referenced in our main draft or is deferred
   to some future extension of that draft is a separate issue, to be decided
   later.)

   The alternative to proceeding with the present draft is to invite
   completely separate proposals (I think there is agreement that _some_
   mechanism of this sort is needed).

   [YES / NO]

B. In the event the answer to A is YES, do we canonicalise dates as days since
   Jan 1st 1970 (in which case a time hh:mm:60 canonicalises the same as
   hh:mm+1:00) or do we canonicalise dates using date-time syntax (in which
   case hh:mm:60 and hh:mm+1:00 are regarded as different). The proposed
   wording of the two cases is at the end of this message.

   [DAYS since 1/1/1970]
   [date-time syntax]

2. "ought"

   Do we proceed on the basis of using "ought" as the word to indicate best
   practice in "social" cases where interoperability would not be affected,
   but the utility of Usenet to its users would. If this is agreed, then I
   will propose wording to define the usage, and then go through the document
   indicating where "SHOULD" should be changed to "ought".

   NOTE: Last time we were divided on this issue, but since then the IETF
   high-ups have indicated that using SHOULD for these cases is wrong, and they
   won't let us define "OUGHT". So we have not much choice, really.

   [YES / NO]

3. Mail-Copies-To

   Do we proceed to define the Mail-Copies-To header?
   The alternative would be to do nothing about this, or to include some
   alternative mechanism. Mail-Copies-To would, of course, have to be defined
   pretty much in conformance with its present informal usage.

   NOTE: Last time we voted 7:7 on this issue, so I am asking the question
   again in the hope of getting a clear result.

   [YES / NO]

   If NO, it would be helpful to indicate any alternative you have in mind.

And here are the promised wordings for the date canonicalizations.

[1st alternative text]

   2. Any date-time occurring in a Date, Resent-Date or Expires header
      (but not in any other header) is converted into the number of
      seconds since the start of January 1st 1970 UTC, ignoring any leap
      seconds and expressed as a decimal number without leading zeroes.

        NOTE: POSIX-compliant systems can implement this simply by using
        the POSIX 'mktime' routine [POSIX] with the TZ environment
        variable set to 'GMT'. Observe that the effect is to treat "31
        Dec 2000 23:59:60 +0000" (which is a legitimate date-time as
        defined by [MESSFOR]) as being identical to "1 Jan 2001 00:00:00
        +0000".
[Can someone give me a reference to the proper POSIX document?]

[2nd alternative text]

   2. Any date-time occurring in a Date, Resent-Date or Expires header
      (but not in any other header) is converted to UTC and written as a
      date-time in the format
       07 dec 2000 23:59:60 +0000
      Note absence of day-of-week, leading zero included in day, month-
      name in lower case, seconds included, year as four digits, and
      timezone preceded by a "+" as opposed to a "-", and observe that
      any FWS will be removed in the next step, giving
       07dec200023:59:60+0000

        NOTE: Observe that the effect is to treat "31 Dec 2000 23:59:60
        +0000" (which is a legitimate date-time as defined by [MESSFOR])
        as being different from "1 Jan 2001 00:00:00 +0000".

Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email: chl@clw.cs.man.ac.uk Web: http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 437 4506 Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5


New Message Reply About this list Date view Thread view Subject view Author view


This archive was generated by hypermail 2b29.