From 9c1957e3c1c29c97b3cea4705c3e3fef1bef4d74 Mon Sep 17 00:00:00 2001 From: Michiel Broek Date: Sat, 24 May 2003 16:17:09 +0000 Subject: [PATCH] Updated ftsc docs --- html/Makefile | 4 +- html/ftsc/fsp-1001.html | 211 ---------------------------------- html/ftsc/fsp-1010.html | 243 ---------------------------------------- html/ftsc/index.htm | 9 +- 4 files changed, 5 insertions(+), 462 deletions(-) delete mode 100755 html/ftsc/fsp-1001.html delete mode 100755 html/ftsc/fsp-1010.html diff --git a/html/Makefile b/html/Makefile index f48158b8..b61bb07e 100644 --- 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 diff --git a/html/ftsc/fsp-1001.html b/html/ftsc/fsp-1001.html deleted file mode 100755 index 5f983ac3..00000000 --- a/html/ftsc/fsp-1001.html +++ /dev/null @@ -1,211 +0,0 @@ - - - -Timezone information in FTN messages. - - - - -
-**********************************************************************
-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: <current offset from UTC>
-
-  The offset has the format <[-]hhmm>, 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.
-
-
-**********************************************************************
-
- -BackGo Back - - - - diff --git a/html/ftsc/fsp-1010.html b/html/ftsc/fsp-1010.html deleted file mode 100755 index 17bc4a01..00000000 --- a/html/ftsc/fsp-1010.html +++ /dev/null @@ -1,243 +0,0 @@ - - - -FTSC Document FSP-1010, Revision 001 - -
-**********************************************************************
-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 <CR>
-  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: <FTN Address> @YYYYMMDD.HHMMSS[.Precise][.Time Zone] 
-    <Program Name> <Version> [Serial Number]<CR>
-    
-  Where ^A denotes the ASCII <SOH> (01h) character, and <CR> 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 "UTC" 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 "Via" 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
-  
-  <NAME> [VERSION] [SERIAL] <ADDRESS> <TIMESTAMP> <TIMEZONE>
-  <NAME> <ADDRESS>, <TIMESTAMP> <TIMEZONE> <VERSION>
-  
-  Not that the time stamp in the above formats is also widely
-  variable, and takes forms which include, but may not be limited to
-  
-  <Day> <Month> <Year> AT <Hour>:<Min>:[Sec]
-  <Day of Week> <Month> <Day of Month> <Year>  <Hour>:<Min>:<Sec>
-  ON <Day of Month> <Month> <Year>  <Hour>:<Min>:<Sec>
-  <Month>/<Day> <Hour>:<Min>
-  @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] "A Basic FidoNet(r) Technical Standard Revision 16", Randy
-  Bush. September 1995.
-
-  [FSC-46] "A Product Identifier for FidoNet Message Handlers",
-  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.
-
-**********************************************************************
-
-BackGo Back - - diff --git a/html/ftsc/index.htm b/html/ftsc/index.htm index ac1a8b3d..2f4f1bcf 100644 --- a/html/ftsc/index.htm +++ b/html/ftsc/index.htm @@ -12,7 +12,7 @@
-
Last update 11-Aug-2001
+
Last update 24-May-2003

 

Fidonet Technical Standards

@@ -54,7 +54,6 @@ Michiel Broek.

FSP Documents

@@ -80,15 +78,14 @@ Michiel Broek.

FTS Documents