From f2582e56694c7e3f0f1e5c2b32fe2632c012c4d1 Mon Sep 17 00:00:00 2001 From: Michiel Broek Date: Sun, 13 Jul 2003 15:21:46 +0000 Subject: [PATCH] Updated FTSC docs --- html/Makefile | 21 +- html/ftsc/fsc-0092.html | 244 --------------------- html/ftsc/fts-4008.html | 342 +++++++++++++++++------------- html/ftsc/fts-4009.html | 456 +++++++++++++++++++++------------------- html/ftsc/index.htm | 1 - 5 files changed, 445 insertions(+), 619 deletions(-) delete mode 100755 html/ftsc/fsc-0092.html diff --git a/html/Makefile b/html/Makefile index 07900902..84fa6c07 100644 --- a/html/Makefile +++ b/html/Makefile @@ -10,19 +10,16 @@ H_BASE = basic.html dist.html manual.css \ known_bugs.html mgetty.html routing.html nodelist.html H_FTSC = ftsc/fsc-0039.html ftsc/fsc-0056.html ftsc/fsc-0087.html \ - ftsc/fts-0007.html \ - ftsc/fsc-0046.html ftsc/fsc-0057.html ftsc/fsc-0091.html \ - ftsc/fta-1005.html ftsc/fts-0008.html \ - ftsc/fsc-0048.html ftsc/fsc-0059.html ftsc/fsc-0092.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/fts-0004.html ftsc/index.htm \ + ftsc/fts-0007.html ftsc/fsc-0046.html ftsc/fsc-0057.html \ + ftsc/fsc-0091.html ftsc/fta-1005.html ftsc/fts-0008.html \ + ftsc/fsc-0048.html ftsc/fsc-0059.html ftsc/fts-0001.html \ + ftsc/fts-0009.html ftsc/fsc-0049.html ftsc/fsc-0062.html \ + ftsc/fsc-0093.html ftsc/fts-0004.html ftsc/index.htm \ ftsc/fsc-0050.html ftsc/fsc-0070.html ftsc/fts-4008.html \ - ftsc/fts-5000.html ftsc/fsc-0053.html \ - ftsc/fsc-0072.html ftsc/fsp-1002.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 + ftsc/fts-5000.html ftsc/fsc-0053.html ftsc/fsc-0072.html \ + ftsc/fsp-1002.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 H_IMAGES = images/b_arrow.gif images/magic.gif images/nodes1.png \ images/connec.gif images/mbsetup0.gif images/nodes2.png \ diff --git a/html/ftsc/fsc-0092.html b/html/ftsc/fsc-0092.html deleted file mode 100755 index 2ba446e2..00000000 --- a/html/ftsc/fsc-0092.html +++ /dev/null @@ -1,244 +0,0 @@ - - - -New control lines for forwarded messages. - - - - -
- | Document: FSC-0092
- | Version:  001
- | Date:     September 12th 1996
- | Author:   Michael Hohner
-
-
-                                 New control lines
-                              for forwarded messages
-
-                                        by
-                                  Michael Hohner
-                                  2:2490/2520.17
-
-                                  September 1996
-
-   Status of this document:
-
-         This document proposes a standard for the Fidonet(tm) community
-         and for other networks using Fido technology. It may be freely
-         distributed if unchanged.
-
-         You can reach the author at one of the addresses listed at the end
-         of the document.
-
-
-   Abstract:
-
-         Most fidonet message editors offer a "forward" function. Using
-         this function a user A can sort of "redirect" a message from user B
-         to another user C, maybe because A is not the correct recipient or
-         because C is a better person to answer the message. The name and
-         address of B are usually included in the forward in free-text format.
-         The message text is included in non-quoted format.
-
-         A problem arises when the final recipient C wants to reply to sender B
-         of the forwarded message. The forward contains the intermediate user A
-         as the sender. So user C must insert the name and address of B
-         manually, using the information contained in the message text. The
-         message editor of C can't do this automatically because of the
-         free-text format. The editor will also use incorrect quote initials,
-         which is at least irritating.
-
-         This document introduces 6 new control lines which contain the header
-         information of the original message. With these control lines the
-         message editor can use the original header information automatically.
-
-
-   Specifications:
-
-         There are 7 new control lines: FWDFROM, FWDTO, FWDORIG, FWDDEST,
-         FWDSUBJ, FWDAREA, FWDMSGID. As all control lines they start with an
-         ASCII 01 character followed by the control line name followed by
-         whitespace followed by the control line's content followed by ASCII 13.
-
-         Please note that all these control lines do not have a colon (like the
-         control lines in FTS-0001). This would be just waste of space.
-
-         FWDFROM
-         -------
-
-         This control line contains the name of the original sender as found in
-         the FROM field of the original message. Leading and trailing
-         whitespace should be removed. This control line should be omitted
-         altogether if the FROM field is empty.
-
-         FWDTO
-         -----
-
-         This control line contains the name of the original recipient as found
-         in the TO field of the original message. Leading and trailing
-         whitespace should be removed. This control line should be omitted
-         altogether if the TO field is empty.
-
-         FWDORIG
-         -------
-
-         This control line contains the address of the original sender as found
-         in the ORIG field of the original message. The usual 5D ASCII notation
-         (zone:net/node.point@domain) should be used. This control line should
-         be omitted altogether if the address is not known.
-
-         FWDDEST
-         -------
-
-         This control line contains the address of the original recipient as
-         found in the DEST field of the original message. The usual 5D ASCII
-         notation (zone:net/node.point@domain) should be used. This control line
-         should be omitted altogether if the address is not known or unsure
-         (as it is the case with forwarded echomail messages).
-
-         FWDSUBJ
-         -------
-
-         This control line contains the subject line of the original message.
-         This control line should be omitted altogether if the SUBJ field is
-         empty.
-         This control line should by made optional for security reasons. Echo
-         manager passwords are too easily revealed with it.
-
-
-         FWDAREA
-         -------
-
-         This control line contains the name of the echomail area where the
-         original message was forwarded from. It should be omitted altogether
-         if the original message was not forwarded from an echomail area.
-
-         FWDMSGID
-         --------
-
-         This control line contains the MSGID control line of the original
-         message. It should be omitted altogether if a MSGID control line is not
-         present in the original message.
-
-
-   Usage:
-
-         When the "forward" function of the message editor is invoked, the
-         editor program should generate the proposed control lines from the
-         header of the original message. If the original message already was
-         a forwarded one (indicated by the presence of at least a FWDORIG
-         control line), the editor should keep all FWD* control lines and should
-         not add any FWD* control lines. This preserves the FWD* control lines
-         of the first forwarder, containing the header data of the author of
-         the original message.
-
-         The editor should not generate FWD* control lines, if the message isn't
-         to be forwarded. A mail forwarding robot may also generate these
-         control lines, if it not just readdresses the message.
-
-         When the "reply" function of the editor is invoked the program should
-         use the control lines' contents instead of the header information. The
-         control lines should not be included in the reply.
-
-         Since it may not be immediately clear whether the user wants to reply
-         to the forwarder or to the original sender, the editor should offer a
-         means to ignore the proposed control lines and start a "normal" reply
-         instead, e.g. by two distinct functions, user preference or dialog.
-
-
-         Pseudo code:
-
-         forwarding_message:
-            if is_forwarded_message then
-               don't change FWD* control lines
-            else
-               add FWD* control lines
-
-         quoting_message:
-            if is_forwarded_message then
-               if reply_to_forwarder then
-                  use header data (normal quoting)
-               else
-                  use FWD* control lines
-               remove FWD* control lines from reply
-            else
-               use header data (normal quoting)
-
-         other_functions:
-            remove/ignore FWD* control lines
-
-
-   Example:
-
-         Message from Joe User to my boss node:
-
-            From: Joe User 1:234/567
-            To:   Harry Herrmannsdoerfer 2:2490/2520
-            Subj: Some questions
-            @MSGID: 1:234/567 12345678
-            Text: Hello Harry!
-                  ...
-
-         Harry forwards the message to me:
-
-            From: Harry Herrmannsdoerfer 2:2490/2520
-            To:   Michael Hohner 2:2490/2520.17
-            Subj: Joe's message
-            @FWDFROM Joe User
-            @FWDORIG 1:234/567
-            @FWDTO   Harry Herrmannsdoerfer
-            @FWDDEST 2:2490/2520
-            @FWDSUBJ Some questions
-            @FWDMSGID 1:234/567 12345678
-            Text: Hi Michael!
-                  ...
-
-         My answer using the new control lines:
-
-            From: Michael Hohner 2:2490/2520.17
-            To:   Joe User 1:234/567
-            Subj: Some questions
-            @REPLY: 1:234/567 12345678
-            Text: Hi Joe!
-
-                  JU> ...
-                  ...
-
-
-   Compatiblity:
-
-         Editor programs which are not prepared for the proposed control lines
-         usually just ignore them and remove them from a reply. A reply goes
-         to the forwarder. Nothing gained and nothing lost.
-
-
-   Implementations:
-
-         This proposal is implemented in the author's Fidonet editor
-         "FleetStreet for OS/2" (versions 1.17 and above).
-
-
-   Contacting the author:
-
-         The author may be contacted electronically at the following addresses:
-
-         Fidonet:    2:2490/2520.17
-         Internet:   miho@osn.de
-         CompuServe: 100425,1754
-
-         Suggestions, comments and corrections are always welcome.
-
-
- -BackGo Back - - - - diff --git a/html/ftsc/fts-4008.html b/html/ftsc/fts-4008.html index 3fb9351a..645cb397 100755 --- a/html/ftsc/fts-4008.html +++ b/html/ftsc/fts-4008.html @@ -1,151 +1,191 @@ - - - -Untitled Document - - - - -**********************************************************************
-FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
-********************************************************************** -

Publication: FTS-4008
- Revision: 2
- Title: Time zone information (TZUTC)
- Author: FTSC
- Issue Date: 16 May 2003
- Review Date: 16 May 2005
- Obsoletes: FTS-0010.001
- ----------------------------------------------------------------------
- Contents:
- 1. Introduction
- 2. Scope
- 3. Current practice
- 4. Control paragraph specification
- 5. Time zone table
- 6. Examples
- A. References
- B. History
- ----------------------------------------------------------------------

-


- Status of this document
- -----------------------

-

This document is a Fidonet Technical Standard (FTS), issued by the
- FTSC for the benefit of the Fidonet community.

-

This document is based on the FSP-1001 proposal by Odinn Sorensen,
- 2:236/77.
-
- This document is released to the public domain, and may be used,
- copied or modified for any purpose whatsoever.

-


- 1. Introduction
- ---------------

-

Current practice in FidoNet is to transmit message times in local
- time. This document specifies a standard for transmission of time
- zone information in FidoNet messages, in the form of a control
- paragraph (also known as a "control line" or "kludge") named - TZUTC.

-


- 2. Scope
- --------

-

This standard is specified for the transmission of FidoNet messages
- in any form where time zone information is not integrated into the
- transport format, specifically any form where the information would
- be lost if not transmitted in a control paragraph, eg. Type 2 packed
- messages. [1]

-


- 3. Current practice
- -------------------

-

Some control paragraphs already exist to specify the time zone of
- messages, notably "TZUTC" and "TZUTCINFO". From observations - of
- these control paragraphs in actual messages, TZUTC and TZUTCINFO are
- identical except for the name. TZUTCINFO is probably named after
- the JAM message base's [2] subfield of the same name.

-

This document adopts the TZUTC control paragraph because is the
- shortest ("TZUTC" vs "TZUTCINFO"). However, software
- implementations should be prepared to read and interpret the
- TZUTCINFO control paragraph as well.

-

The TZUTC control paragraph is inserted before the message body
- upon initial message creation, or export from a format containing
- time zone information, such as the aforementioned JAM message base.

-


- 4. Control paragraph specification
- -----------------------------

-

Messages which conform to this specification must add the following
- control paragraph:

-

^aTZUTC: <current offset from UTC>

-

Where ^a is ASCII 1, 01h.

-

The offset has the format <[-]hhmm>, where hhmm is the number of
- hours and minutes, zero-padded to two digits each, that local time
- is offset from UTC. If local time is WEST of UTC, then the offset
- is NEGATIVE. See the table below for typical offsets.

-

Note that the hh in a time zone 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 time zones.

-

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 the TZUTC control paragraph should change
- to reflect this.

-


- 5. Time zone table
- ------------------

-

This table gives examples of typical time zones.

-

-1000 Alaska-Hawaii Standard Time (United States)
- -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 Universal Time Coordinated (UTC)
- 0000 Greenwich Mean Time
- 0100 Central European Time
- 0100 British Summer Time
- 0200 Central European Summer Time
- 0200 Eastern European Time
- 0800 Australian Western Standard 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

-


- 6. Examples
- -----------

-

^aTZUTC: 0000
- ^aTZUTC: 0200
- ^aTZUTC: -0700

-


- A. References
- -------------

-

[1] "A Basic FidoNet(r) Technical Standard Revision 16", Randy Bush.
- September 1995.

-

[2] "The JAM message base proposal", Joaquim Homrighausen, Andrew
- Milner, Mats Birch and Mats Wallin. July 1993.

-


- B. History
- ----------

-

Rev.1, 20030409: First release (revised from FSP-1001 by FTSC)
- Rev.2, 20030516: Corrected status; clarified Section 2 on insertion
- position and export practice; fixed terminology.

-

**********************************************************************
-

- - + + + +Time zone information (TZUTC). + + + + +
+**********************************************************************
+FTSC                             FIDONET TECHNICAL STANDARDS COMMITTEE
+**********************************************************************
+
+Publication:  FTS-4008
+Revision:     2
+Title:        Time zone information (TZUTC)
+Author:       FTSC
+Issue Date:   16 May 2003
+Review Date:  16 May 2005
+Obsoletes:    FTS-0010.001
+----------------------------------------------------------------------
+Contents:
+              1. Introduction
+              2. Scope
+              3. Current practice
+              4. Control paragraph specification
+              5. Time zone table
+              6. Examples
+              A. References
+              B. History
+----------------------------------------------------------------------
+
+
+Status of this document
+-----------------------
+
+  This document is a Fidonet Technical Standard (FTS), issued by the
+  FTSC for the benefit of the Fidonet community.
+
+  This document is based on the FSP-1001 proposal by Odinn Sorensen,
+  2:236/77.
+  
+  This document is released to the public domain, and may be used,
+  copied or modified for any purpose whatsoever.
+
+
+1. Introduction
+---------------
+
+  Current practice in FidoNet is to transmit message times in local
+  time.  This document specifies a standard for transmission of time
+  zone information in FidoNet messages, in the form of a control
+  paragraph (also known as a "control line" or "kludge") named TZUTC.
+
+
+2. Scope
+--------
+
+  This standard is specified for the transmission of FidoNet messages
+  in any form where time zone information is not integrated into the
+  transport format, specifically any form where the information would
+  be lost if not transmitted in a control paragraph, eg. Type 2 packed
+  messages. [1]
+
+
+3. Current practice
+-------------------
+
+  Some control paragraphs already exist to specify the time zone of
+  messages, notably "TZUTC" and "TZUTCINFO".  From observations of
+  these control paragraphs in actual messages, TZUTC and TZUTCINFO are
+  identical except for the name.  TZUTCINFO is probably named after
+  the JAM message base's [2] subfield of the same name.
+
+  This document adopts the TZUTC control paragraph because is the
+  shortest ("TZUTC" vs "TZUTCINFO").  However, software
+  implementations should be prepared to read and interpret the
+  TZUTCINFO control paragraph as well.
+
+  The TZUTC control paragraph is inserted before the message body
+  upon initial message creation, or export from a format containing
+  time zone information, such as the aforementioned JAM message base.
+
+
+4. Control paragraph specification
+-----------------------------
+
+  Messages which conform to this specification must add the following
+  control paragraph:
+
+    ^aTZUTC: <current offset from UTC>
+
+  Where ^a is ASCII 1, 01h.
+
+  The offset has the format <[-]hhmm>, where hhmm is the number of
+  hours and minutes, zero-padded to two digits each, that local time
+  is offset from UTC.  If local time is WEST of UTC, then the offset
+  is NEGATIVE.  See the table below for typical offsets.
+
+  Note that the hh in a time zone 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 time zones.
+
+  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 the TZUTC control paragraph should change
+  to reflect this.
+
+
+5. Time zone table
+------------------
+
+  This table gives examples of typical time zones.
+
+  -1000   Alaska-Hawaii Standard Time (United States)
+  -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   Universal Time Coordinated (UTC)
+   0000   Greenwich Mean Time
+   0100   Central European Time
+   0100   British Summer Time
+   0200   Central European Summer Time
+   0200   Eastern European Time
+   0800   Australian Western Standard 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
+
+
+6. Examples
+-----------
+
+  ^aTZUTC: 0000
+  ^aTZUTC: 0200
+  ^aTZUTC: -0700
+
+
+A. References
+-------------
+
+  [1] "A Basic FidoNet(r) Technical Standard Revision 16", Randy Bush.
+  September 1995.
+
+  [2] "The JAM message base proposal", Joaquim Homrighausen, Andrew
+  Milner, Mats Birch and Mats Wallin. July 1993.
+
+
+B. History
+----------
+
+  Rev.1, 20030409: First release (revised from FSP-1001 by FTSC)
+  Rev.2, 20030516: Corrected status; clarified Section 2 on insertion
+                   position and export practice; fixed terminology.
+
+**********************************************************************
+
+ +BackGo Back + + + diff --git a/html/ftsc/fts-4009.html b/html/ftsc/fts-4009.html index 20db7ab0..8c3a65c9 100755 --- a/html/ftsc/fts-4009.html +++ b/html/ftsc/fts-4009.html @@ -1,211 +1,245 @@ - - - -Untitled Document - - - - -**********************************************************************
-FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
-********************************************************************** -

Publication: FTS-4009
- Revision: 1
- Title: Netmail tracking (Via)
- Author: FTSC
- Issue Date: 16 May 2003
- Review Date: 16 May 2005
- ----------------------------------------------------------------------
- Contents:
- 1. Current practice
- 2. Control paragraph specification
- 3. Examples
- 4. Deprecated formats
- A. References
- B. History
- ----------------------------------------------------------------------

-

Status of this document
- -----------------------

-

This document is a Fidonet Technical Standard (FTS), issued by the
- FTSC for the benefit of the Fidonet community.

-

This document is based on the FSP-1010 proposal by Colin Turner,
- 2:443/13, and Joaquim Homrighausen, 2:201/330.
-
- This document is released to the public domain, and may be used,
- copied or modified for any purpose whatsoever.

-


- 1. Current practice
- -------------------

-

As Netmail messages are routed through FidoNet, or as they are
- processed on a system, Via control paragraphs are added to track
- their progress.
-
- The Via control paragraphs 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 paragraph by a single
- ASCII carriage-return character (0Dh). There is no limit to the
- number of Via control paragraphs in each message.

-

Note that the "Via" tag is in mixed case, not all upper case like
- most control tags.
-
- A Via control paragraph is typically added:
-
- when a Netmail packer packs the Netmail for transmission to
- another system;
-
- when a netmail tracker inspects a Netmail.

-


- 2. Control paragraph specification
- ----------------------------------

-

The Via control paragraph 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
- carriage-return 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 control paragraph, using standard Fidonet
- addressing notation, Z:N/F[.P][@domain]
-
- @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.

-

Robust implementations must check to ensure this field is numeric to
- avoid confusion with the Time Zone field.
-
- 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 control paragraph to
- Universal Time (GMT or UTC) and use the "UTC" Time Zone indicator,
- where possible.
-
- The Time Zone field may only be omitted 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.

-

Robust implementations must check to ensure this field is not
- numeric to avoid confusion with the Precise field.
-
- Program Name
- ------------
-
- This field is a mandatory string field of up to ten (10) characters
- naming the product inserting the Via line.
-
- Version
- -------

-

This field is a mandatory string field of up to ten (10) characters
- specifying the version of the product inserting the Via line,
- including any alpha, beta or gamma status.
-
- Serial Number
- -------------
-
- This field is an optional string field of up to ten (10) characters
- identifying the specific copy of the product inserting the Via line.

-


- 3. Examples
- -----------

-

Example of valid usage are
-
- ^AVia 1:2/3 @19990305.043212.UTC O/T-Track+ 2.69
- ^AVia 1:2/3@fidonet @19980331.231202.UTC FrontDoor 2.32.mL
- ^AVia 1:2/3.0 @19990101.002102.UTC FastEcho 1.46.1 21321
- ^AVia 1:2/3 @19990323.230132 FakeMail 1.2
- ^AVia 1:2/3 @20030403.182824.UTC Gleipner/Java 1.0/pre
- ^AVia 1:2/3 @20030403.193223.UTC hpt 1.2.2-stable/os2
- ^AVia D'Bridge 1.58 1:2/3 04/03 20:47
- ^AVia 1:2/3@fidonet @20030404.030004.UTC O/T-Track+ 2.66b
- ^AVia Squish/386 1.11 1:2/3, Thu Apr 03 2003 at 23:16 UTC
- ^AVia 1:2/3 FTrack 3.1/W32 04 Apr 2003 09:33:07 UTC+1000
- ^AVia ifmail 1:2/3@fidonet, Fri Apr 11 2003 at 06:01 (2.15)
- ^AVia RTrk+ 1:2/3@fidonet, Apr 22 2003 at 18:25
- ^AVia BBBS/NT v4.01 Flag-4 1:2/3.0, @030505155114 EDT+5

-


- 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 implementations 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 separate 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. History
- ----------

-

Rev.1, 20030516: First release (revised from FSP-1010 by FTSC; note
- the lack of a colon after the "Via" tag)

-

**********************************************************************
-

- - + + + +Netmail Tracking (Via) + + + + +
+**********************************************************************
+FTSC                             FIDONET TECHNICAL STANDARDS COMMITTEE
+**********************************************************************
+
+Publication:  FTS-4009
+Revision:     1
+Title:        Netmail tracking (Via)
+Author:       FTSC
+Issue Date:   16 May 2003
+Review Date:  16 May 2005
+----------------------------------------------------------------------
+Contents:
+              1. Current practice
+              2. Control paragraph specification
+              3. Examples
+              4. Deprecated formats
+              A. References
+              B. History
+----------------------------------------------------------------------
+
+Status of this document
+-----------------------
+
+  This document is a Fidonet Technical Standard (FTS), issued by the
+  FTSC for the benefit of the Fidonet community.
+
+  This document is based on the FSP-1010 proposal by Colin Turner,
+  2:443/13, and Joaquim Homrighausen, 2:201/330.
+  
+  This document is released to the public domain, and may be used,
+  copied or modified for any purpose whatsoever.
+
+
+1. Current practice
+-------------------
+
+  As Netmail messages are routed through FidoNet, or as they are
+  processed on a system, Via control paragraphs are added to track
+  their progress.
+  
+  The Via control paragraphs 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 paragraph by a single
+  ASCII carriage-return character (0Dh).  There is no limit to the
+  number of Via control paragraphs in each message.
+
+  Note that the "Via" tag is in mixed case, not all upper case like
+  most control tags.
+  
+  A Via control paragraph is typically added:
+  
+    when a Netmail packer packs the Netmail for transmission to
+    another system;
+    
+    when a netmail tracker inspects a Netmail.
+
+
+2. Control paragraph specification
+----------------------------------
+
+  The Via control paragraph 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
+  carriage-return 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 control paragraph, using standard Fidonet
+  addressing notation, Z:N/F[.P][@domain]
+  
+  @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.
+
+  Robust implementations must check to ensure this field is numeric to
+  avoid confusion with the Time Zone field.
+        
+  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 control paragraph to
+  Universal Time (GMT or UTC) and use the "UTC" Time Zone indicator,
+  where possible.
+  
+  The Time Zone field may only be omitted 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.
+
+  Robust implementations must check to ensure this field is not
+  numeric to avoid confusion with the Precise field.
+  
+  Program Name
+  ------------
+  
+  This field is a mandatory string field of up to ten (10) characters
+  naming the product inserting the Via line.
+  
+  Version
+  -------
+
+  This field is a mandatory string field of up to ten (10) characters
+  specifying the version of the product inserting the Via line,
+  including any alpha, beta or gamma status.
+  
+  Serial Number
+  -------------
+  
+  This field is an optional string field of up to ten (10) characters
+  identifying the specific copy of the product inserting the Via line.
+
+
+3. Examples
+-----------
+
+  Example of valid usage are
+  
+  ^AVia 1:2/3 @19990305.043212.UTC O/T-Track+ 2.69
+  ^AVia 1:2/3@fidonet @19980331.231202.UTC FrontDoor 2.32.mL
+  ^AVia 1:2/3.0 @19990101.002102.UTC FastEcho 1.46.1 21321
+  ^AVia 1:2/3 @19990323.230132 FakeMail 1.2
+  ^AVia 1:2/3 @20030403.182824.UTC Gleipner/Java 1.0/pre
+  ^AVia 1:2/3 @20030403.193223.UTC hpt 1.2.2-stable/os2
+  ^AVia D'Bridge 1.58 1:2/3  04/03 20:47
+  ^AVia 1:2/3@fidonet @20030404.030004.UTC O/T-Track+ 2.66b
+  ^AVia Squish/386 1.11 1:2/3, Thu Apr 03 2003 at 23:16 UTC
+  ^AVia 1:2/3 FTrack 3.1/W32 04 Apr 2003 09:33:07 UTC+1000
+  ^AVia ifmail 1:2/3@fidonet, Fri Apr 11 2003 at 06:01 (2.15)
+  ^AVia RTrk+ 1:2/3@fidonet, Apr 22 2003 at 18:25
+  ^AVia BBBS/NT v4.01 Flag-4 1:2/3.0, @030505155114 EDT+5
+
+
+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 implementations 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 separate 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. History
+----------
+
+  Rev.1, 20030516: First release (revised from FSP-1010 by FTSC; note
+                   the lack of a colon after the "Via" tag)
+
+**********************************************************************
+
+ +BackGo Back + + + diff --git a/html/ftsc/index.htm b/html/ftsc/index.htm index c6ed51ed..a7db6750 100644 --- a/html/ftsc/index.htm +++ b/html/ftsc/index.htm @@ -44,7 +44,6 @@ Michiel Broek.
  • FSC-0087 File forwarding in FidoNet technology networks, R.Williamson
  • FSC-0088 Compatibility and Link Qualifier Extensions for EMSI Sessions, R.Williamson
  • FSC-0091 ISDN nodelist flags (rev.002), A.Lenz -
  • FSC-0092 New control lines for forwarded messages, M.Hohner
  • FSC-0093 Reduced seen-by lines, F.Ellermann