Updated ftsc docs

2003-05-24 16:17:09 +00:00 · 2003-05-24 16:17:09 +00:00 · 9c1957e3c1
commit 9c1957e3c1
parent e50985d01d
4 changed files with 5 additions and 462 deletions
--- a/html/Makefile
+++ b/html/Makefile
@ -17,10 +17,10 @@ H_FTSC		= ftsc/fsc-0039.html  ftsc/fsc-0056.html  ftsc/fsc-0087.html \
 		  ftsc/fsp-1005.html  ftsc/fts-0001.html  ftsc/fts-0009.html \
 		  ftsc/fsc-0049.html  ftsc/fsc-0062.html  ftsc/fsc-0093.html \
 		  ftsc/fsp-1006.html  ftsc/fts-0004.html  ftsc/index.htm \
-		  ftsc/fsc-0050.html  ftsc/fsc-0070.html  ftsc/fsp-1001.html \
+		  ftsc/fsc-0050.html  ftsc/fsc-0070.html  ftsc/fts-4008.html \
 		  ftsc/fsp-1007.html  ftsc/fts-5000.html  ftsc/fsc-0053.html \
 		  ftsc/fsc-0072.html  ftsc/fsp-1002.html  ftsc/fsp-1008.html \
-		  ftsc/fts-0006.html  ftsc/fsc-0035.html  ftsc/fsp-1010.html \
+		  ftsc/fts-0006.html  ftsc/fsc-0035.html  ftsc/fts-4009.html \
 		  ftsc/fsp-1011.html  ftsc/ftscprod.html  ftsc/fsc-0088.html \
 		  ftsc/fts-4001.html  ftsc/fts-5001.html
--- a/html/ftsc/fsp-1001.html
+++ b/html/ftsc/fsp-1001.html
@ -1,211 +0,0 @@
 <HTML>
 <!-- $Id$ -->
 <HEAD>
 <TITLE>Timezone information in FTN messages.</TITLE>
 </HEAD>
 <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
 <BODY
 BGCOLOR="#FFFFFF"
 TEXT="#000000"
 LINK="#0000FF"
 VLINK="#000080"
 ALINK="#FF0000"
 >
 <PRE>
 **********************************************************************
 FTSC                             FIDONET TECHNICAL STANDARDS COMMITTEE
 **********************************************************************
 Publication:    FSP-1001
 Revision:       2
 Title:          Timezone information in FTN messages
 Author:         Odinn Sorensen, 2:236/77
 Revision Date:  27 September 1997
 Expiry Date:    13 September 1999
 ----------------------------------------------------------------------
 Contents:
                1. Scope
                2. Current practice
                3. Kludge specification
                4. Timezone table
                5. Examples
 ----------------------------------------------------------------------
 Status of this document
 -----------------------
  This document is a Fidonet Standards Proposal (FSP).
  This document specifies an optional Fidonet standard protocol for
  the Fidonet community, and requests discussion and suggestions for
  improvements.
  This document is released to the public domain, and may be used,
  copied or modified for any purpose whatever.
 Abstract
 --------
  Current practice for Fidonet Technology Network (FTN) messages is to
  store dates in local time. Timezone information (if known) is
  usually lost. This document specifies a standard for storage of
  timezone information in FTN messages, in the form of a kludge named
  TZUTC.
 1. Scope
 --------
  This standard is specified for FTN messages in any form where
  timezone information is not integrated in the message storage or
  transport format. Specifically any form where the information would
  be lost if not stored in a kludge, such as in FTS-1 stored messages
  or packets.
 2. Current practice
 -------------------
  Some kludges already exist to specify the timezone of messages,
  notably "TZUTC" and "TZUTCINFO". Other kludges may exist.
  To the authors knowledge, no official specification exists for any
  of these kludges.
  From observations of these kludges in actual messages, TZUTC and
  TZUTCINFO are identical except for the name. TZUTCINFO is probably
  named after the JAM msgbase subfield of the same name.
  This document adopts and documents the TZUTC kludge because it is
  the shortest of them.
 3. Kludge specification
 -----------------------
  Messages which conform to this specification must add the kludge:
    ^aTZUTC: &lt;current offset from UTC&gt;
  The offset has the format &lt;[-]hhmm&gt;, where hhmm is the number of
  hours and minutes that local time is offset from UTC. If local time
  is WEST of UTC (Greenwich), then the offset is NEGATIVE. See the
  table below for typical offsets.
  Note that the hh in a timezone offset is not limited to a maximum of
  12. This is because the International Date Line does not run exactly
  along the boundary between zone -1200 and +1200. The minutes part is
  00 for most timezones.
  All four digits must be present. If the offset is negative, there
  must be a minus ('-', ASCII 45, 2Dh) in front of the offset.
  Implementations must NOT put a plus ('+', ASCII 43, 2Bh) in front of
  the offset for positive numbers, but robust implementations should
  be prepared to find (and ignore) a plus if it exists.
  If local time changes as a result of, for example, daylight savings
  time, then the offset in TZUTC need to be changed to reflect this.
  When this kludge is present in a message, the "date written" field
  in the stored message is guaranteed to be in local time for the
  given timezone. Note that this specification does not specify the
  timezone for any other date fields. Other date fields (such as "date
  received, arrived, processed, etc.") are usually in local time for
  the system on which the messages are stored.
 4. Timezone table
 -----------------
  This table gives examples of typical timezones.
  -1000   Alaska-Hawaii Standard Time
  -0900   Hawaii Daylight Time
  -0800   Pacific Standard Time
  -0700   Pacific Daylight Time
  -0700   Mountain Standard Time
  -0600   Mountain Daylight Time
  -0600   Central Standard Time
  -0500   Central Daylight Time
  -0500   Eastern Standard Time
  -0400   Eastern Daylight Time
  -0400   Atlantic Standard Time
  -0330   Newfoundland Standard Time
  -0300   Atlantic Daylight Time
  -0100   West Africa Time
   0000   Greenwich Mean Time
   0100   Central European Time
   0100   British Summer Time
   0200   Central European Summer Time
   0200   Eastern European Time
   0800   Australian Western Time
   0800   China Coast Time
   0900   Japan Standard Time
   0900   Australian Western Daylight Time
   0930   Australian Central Standard Time
   1000   Australian Eastern Standard Time
   1030   Australian Central Daylight Time
   1100   Australian Eastern Daylight Time
   1200   New Zealand Standard Time
   1300   New Zealand Daylight Time
 5. Examples
 -----------
  ^aTZUTC: 0000
  ^aTZUTC: 0200
  ^aTZUTC: -0700
 6. Redundancy
 -------------
  If the TZUTC data duplicates a field in a storage format in such a
  way that no information is lost in conversion to or from the field,
  then it is recommended that the kludge is not stored in the message.
  However, implementations are allowed to store the TZUTC even when
  redundant.
 A. References
 -------------
  [FTS-1] "A Basic FidoNet(r) Technical Standard Revision 16", Randy
  Bush. September 1995.
  [JAM] "The JAM message base proposal", Joaquim Homrighausen, Andrew
  Milner, Mats Birch and Mats Wallin. July 1993.
 B. Author contact data
 ----------------------
  Odinn Sorensen
  Fidonet: 2:236/77
  E-mail:  odinn@goldware.dk
  WWW:     http://www.goldware.dk
 C. History
 ----------
  Rev.1, 970913: First release.
  Rev.2, 970927: Updated the timezone table. Added section about
                 redundancy. Clarified what happens when local time
                 changes. Clarified some of what the specification
                 doesn't cover.
 **********************************************************************
 </PRE>
 <A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
 </BODY>
 </HTML>
--- a/html/ftsc/fsp-1010.html
+++ b/html/ftsc/fsp-1010.html
@ -1,243 +0,0 @@
 <HTML>
 <!-- $Id$ -->
 <HEAD>
 <TITLE>FTSC Document FSP-1010, Revision 001</TITLE>
 <BODY
 BGCOLOR="#FFFFFF"
 TEXT="#000000"
 LINK="#0000FF"
 VLINK="#000080"
 ALINK="#FF0000"
 >
 <PRE>
 **********************************************************************
 FTSC                             FIDONET TECHNICAL STANDARDS COMMITTEE
 **********************************************************************
 Publication:    FSP-1010
 Revision:       1
 Title:          Via kludge specification
 Author:         Colin Turner,
                Joaquim Homrighausen
 Revision Date:  26 April 1999
 Expiry Date:    26 April 2001
 ----------------------------------------------------------------------
 Contents:
                1. Current practice
                2. Kludge specification
                3. Examples
                4. Deprecated formats
 ----------------------------------------------------------------------
 Status of this document
 -----------------------
  This document is a Fidonet Standards Proposal (FSP).
  This document specifies an optional Fidonet standard protocol for
  the Fidonet community, and requests discussion and suggestions for
  improvements.
  This document is released to the public domain, and may be used,
  copied or modified for any purpose whatever.
 Abstract
 --------
  Current practice for Fidonet Technology Network (FTN) NetMail
  messages is to track their progress through the network and
  programs by using control lines. These control lines are in
  the form of a kludge named Via.
 1. Current practice
 -------------------
  As NetMail messages are routed through a FidoNet Technology Network
  or as they are processed on a system, Via control lines are used to
  track their progress.
  A single NetMail message may have any number of Via control lines.
  The Via control lines are stored in a block which starts after any
  message text. New Via lines should be added to the end of the block
  separated from the preceding control line by a single ASCII &lt;CR&gt;
  character (0Dh).
  A Via control line is typically added:
    when a netmail packer packs the NetMail for transmission to
    another system;
    when a netmail tracker inspects a NetMail.
 2. Kludge specification
 -----------------------
  The Via control line is formatted as a number of fields, separated
  by single space (20h) characters, as follows
    ^AVia: &lt;FTN Address&gt; @YYYYMMDD.HHMMSS[.Precise][.Time Zone] 
    &lt;Program Name&gt; &lt;Version&gt; [Serial Number]&lt;CR&gt;
  Where ^A denotes the ASCII &lt;SOH&gt; (01h) character, and &lt;CR&gt; is the
  character (0Dh).
  The fields are defined as follows:
  FTN Address
  -----------
  This field is mandatory and is the FidoNet Technology address of 
  the system inserting the kludge. This may or may not include a
  domain indicator.
  @YYYYMMDD.HHMMSS
  ----------------
  This field is mandatory and consists of a time stamp. This is the
  time at which the stamp was placed. The subcomponents are
  YYYY, the calendar year, in full four digit, decimal form;
  MM,   the calendar month, in the range 01 to 12, this must be a
        zero padded, two digit decimal number;
  DD,   the day of the month, in the range 01 to 31, this must be a
        zero padded, two digit decimal number;
  HH,   hours, in the range 00 to 23, this must be a zero padded,
        two digit decimal number;
  MM,   minutes, in the range 00 to 59, this must be a zero padded,
        two digit decimal number;
  SS.   seconds, in the range 00 to 59, this must be a zero padded,
        two digit decimal number.
  Precise
  -------
  This field is optional and takes the form of extra precision in the
  time stamp.
  If this field is present:
    it must begin with a single period character;
    this period must be followed by one or more decimal digits;
    the field has ended when another period or space is encountered;
    each decimal digit in the field following this character
    represents the time of the via line in fractions of a second,
    such that the the first digit represents tenths of a second,
    the second digit represents hundreds of a second and so on.
  Time Zone
  ---------
  This field is optional, and must be a short, widely accepted
  alphabetical abbreviation of the time zone that the time stamp
  in the Via line pertains to.
  The use of various Time Zone values is deprecated, implementations
  should attempt to convert the timestamp in the kludge to Universal
  Time (GMT or UTC) and use the &quot;UTC&quot; Time Zone indicator, where
  possible.
  The Time Zone field may only be ommitted when it is not possible
  for the implementation to determine the correct offset from UTC,
  and in this case the time stamp must represent local time on the
  generating system.
  Program Name
  ------------
  This field is mandatory, and must follow the format used in the PID
  control line (detailed in FSC-46).
  Version
  -------
  This field is mandatory, and must follow the format used in the PID
  control line (detailed in FSC-46).
  Serial Number
  -------------
  This field is optional, and must follow the format used in the PID
  control line (detailed in FSC-46).
  Note that unlike many kludges, the &quot;Via&quot; text of the kludge itself
  is in mixed, and not all upper case.
 3. Examples
 -----------
  Example of valid usage are
  ^AVia 2:443/13 @19990305.043212.UTC O/T-Track+ 2.69
  ^AVia 2:443/13@fidonet @19980331.231202.UTC FrontDoor 2.32.mL
  ^AVia 2:443/13.0 @19990101.002102.UTC FastEcho 1.46.1 21321
  ^AVia 2:443/13 @19990323.230132 FakeMail 1.2
  ^AVia 2:2480/18@fidonet @19990307.182128.47.UTC ITrack+ 1.3/G6 FP000069
 4. Deprecated formats
 ---------------------
  Some other formats for the Via line are in use today, but these
  formats are rather variable and inconsistent in nature, while
  the format specified above is both more widespread and more
  consistent.
  New implentations may need to parse these formats, but must not
  generate them.
  The formats in use include, but are not limited to
  &lt;NAME&gt; [VERSION] [SERIAL] &lt;ADDRESS&gt; &lt;TIMESTAMP&gt; &lt;TIMEZONE&gt;
  &lt;NAME&gt; &lt;ADDRESS&gt;, &lt;TIMESTAMP&gt; &lt;TIMEZONE&gt; &lt;VERSION&gt;
  Not that the time stamp in the above formats is also widely
  variable, and takes forms which include, but may not be limited to
  &lt;Day&gt; &lt;Month&gt; &lt;Year&gt; AT &lt;Hour&gt;:&lt;Min&gt;:[Sec]
  &lt;Day of Week&gt; &lt;Month&gt; &lt;Day of Month&gt; &lt;Year&gt;  &lt;Hour&gt;:&lt;Min&gt;:&lt;Sec&gt;
  ON &lt;Day of Month&gt; &lt;Month&gt; &lt;Year&gt;  &lt;Hour&gt;:&lt;Min&gt;:&lt;Sec&gt;
  &lt;Month&gt;/&lt;Day&gt; &lt;Hour&gt;:&lt;Min&gt;
  @YYMMDDHHMMSS
  In the last listed format, observe in particular the two digit year
  and lack of period to seperate the date from time.
 A. References
 -------------
  [FTS-1] &quot;A Basic FidoNet(r) Technical Standard Revision 16&quot;, Randy
  Bush. September 1995.
  [FSC-46] &quot;A Product Identifier for FidoNet Message Handlers&quot;,
  Joaquim Homrighausen, August 1994.
 B. Author contact data
 ----------------------
  Colin Turner
  Fidonet: 2:443/13
  E-mail:  ct@piglets.com
  WWW:     http://www.piglets.com
  Joaquim Homrighausen
  Fidonet: 2:201/330
  E-mail:  joho@defsol.se
  WWW:     http://www.defsol.se
 C. History
 ----------
  Rev.1, 990426: First release.
 **********************************************************************
 </PRE>
 <A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
 </BODY>
--- a/html/ftsc/index.htm
+++ b/html/ftsc/index.htm
@ -12,7 +12,7 @@
 </HEAD>
 <BODY>
 <BLOCKQUOTE>
-<h5>Last update 11-Aug-2001</h5>
+<h5>Last update 24-May-2003</h5>
 <P>&nbsp;<P>
 <h1>Fidonet Technical Standards</h1>
@ -54,7 +54,6 @@ Michiel Broek.
 <h3>FSP Documents</h3>
 <ul>
 <li><a href="fsp-1001.html">FSP-1001 Timezone information in FTN messages, O.Sorensen</a>
 <li><a href="fsp-1002.html">FSP-1002 Numeric reply indication in FTN subject lines, O.Sorensen</a>
 <li><a href="fsp-1003.html">FSP-1003 Suggested use of Nodelist Fields, L.Kindness</a>
 <li><a href="fsp-1004.html">FSP-1004 Standard Fidonet Addressing, L.Kindness</a>
@ -63,7 +62,6 @@ Michiel Broek.
 <li><a href="fsp-1007.html">FSP-1007 Multiple recipient address specification to gateway, R.v.d.Winkel</a>
 <li><a href="fsp-1008.html">FSP-1008 New control lines for forwarded messages, M.Hohner</a>
 <li><a href="fsp-1009.html">FSP-1009 Year 2000 issues in FTN software, M.Hohner</a>
 <li><a href="fsp-1010.html">FSP-1010 Via kludge line specification, C. Turner and J. Homrighausen</a>
 <li><a href="fsp-1011.html">FSP-1011 BinkP - a protocol for transferring Fidonet mail over reliable connections, Dima Maloff</a>
 </ul>
@ -80,15 +78,14 @@ Michiel Broek.
 <h3>FTS Documents</h3>
 <ul>
 <li><a href="fts-0001.html">FTS-0001 A basic FidoNet(r) technical standard, R.Bush</a>
 <li>FTS-0002 Obsoleted by FTS-0005
 <li>FTS-0003 Obsoleted by FTS-0006
 <li><a href="fts-0004.html">FTS-0004 Echomail specification, B.Hartman</a>
 <li>FTS-0005 Obsoleted by FTS-5000
 <li><a href="fts-0006.html">FTS-0006 YOOHOO and YOOHOO/2U2, V.Perriello</a>
 <li><a href="fts-0007.html">FTS-0007 SEAlink protocol extension, P.Becker</a>
 <li><a href="fts-0008.html">FTS-0008 Bark file-request protocol extension, P.Becker</a>
 <li><a href="fts-0009.html">FTS-0009 Message identification and reply linkage, J.Nutt</a>
 <li><a href="fts-4001.html">FTS-4001 Addressing Control Paragraphs, Goran Eriksson</a>
 <li><a href="fts-4008.html">FTS-4008 Time zone information (TZUTC)</a>
 <li><a href="fts-4009.html">FTS-4009 Netmail tracking (Via)</a>
 <li><a href="fts-5000.html">FTS-5000 The distribution nodelist, David Hallford</a>
 <li><a href="fts-5001.html">FTS-5001 Nodelist flags and user flags, David Hallford</a>
 </ul>