From: Claus Färber (list-ietf-wg-apps-usefor@faerber.muc.de)
Date: Sat Sep 09 2000 - 04:05:00 CDT
Charles Lindsey <chl@clw.cs.man.ac.uk> schrieb/wrote:
> 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.) [YES / NO]
NO. Wait until we have finished the basic format specification.
> 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]
date-time
> 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".
NO, we don't have a choice. Besides, using newly defined phrases will
only confuse the reader.
Further, we should remove the "social" cases from a format
specification. The belong to separate documents, probably on a per-
hierachy (group) basis.
> 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.
I'd rather call it 'Followup-CC-To', which expresses much better what it
is meant to do.
Further, a diffrent name will avoid problems caused by incosistent use
of this informally defined header.
Claus
-- http://www.faerber.muc.de