bbs/deb-mbse
Archived
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Updated FTSC docs

Browse Source
This commit is contained in:
Michiel Broek 2003-07-13 15:21:46 +00:00
parent 1ba8de5d89
commit f2582e5669
5 changed files with 445 additions and 619 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
html/Makefile
View File

@ -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 \

244
html/ftsc/fsc-0092.html
View File

@ -1,244 +0,0 @@
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>New control lines for forwarded messages.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
| 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&gt; ...
...
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.
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

342
html/ftsc/fts-4008.html
View File

@ -1,151 +1,191 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body>
**********************************************************************<br>
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE<br>
**********************************************************************
<p>Publication: FTS-4008<br>
Revision: 2<br>
Title: Time zone information (TZUTC)<br>
Author: FTSC<br>
Issue Date: 16 May 2003<br>
Review Date: 16 May 2005<br>
Obsoletes: FTS-0010.001<br>
----------------------------------------------------------------------<br>
Contents:<br>
1. Introduction<br>
2. Scope<br>
3. Current practice<br>
4. Control paragraph specification<br>
5. Time zone table<br>
6. Examples<br>
A. References<br>
B. History<br>
----------------------------------------------------------------------</p>
<p><br>
Status of this document<br>
-----------------------</p>
<p> This document is a Fidonet Technical Standard (FTS), issued by the<br>
FTSC for the benefit of the Fidonet community.</p>
<p> This document is based on the FSP-1001 proposal by Odinn Sorensen,<br>
2:236/77.<br>
<br>
This document is released to the public domain, and may be used,<br>
copied or modified for any purpose whatsoever.</p>
<p><br>
1. Introduction<br>
---------------</p>
<p> Current practice in FidoNet is to transmit message times in local<br>
time. This document specifies a standard for transmission of time<br>
zone information in FidoNet messages, in the form of a control<br>
paragraph (also known as a &quot;control line&quot; or &quot;kludge&quot;) named
TZUTC.</p>
<p><br>
2. Scope<br>
--------</p>
<p> This standard is specified for the transmission of FidoNet messages<br>
in any form where time zone information is not integrated into the<br>
transport format, specifically any form where the information would<br>
be lost if not transmitted in a control paragraph, eg. Type 2 packed<br>
messages. [1]</p>
<p><br>
3. Current practice<br>
-------------------</p>
<p> Some control paragraphs already exist to specify the time zone of<br>
messages, notably &quot;TZUTC&quot; and &quot;TZUTCINFO&quot;. From observations
of<br>
these control paragraphs in actual messages, TZUTC and TZUTCINFO are<br>
identical except for the name. TZUTCINFO is probably named after<br>
the JAM message base's [2] subfield of the same name.</p>
<p> This document adopts the TZUTC control paragraph because is the<br>
shortest (&quot;TZUTC&quot; vs &quot;TZUTCINFO&quot;). However, software<br>
implementations should be prepared to read and interpret the<br>
TZUTCINFO control paragraph as well.</p>
<p> The TZUTC control paragraph is inserted before the message body<br>
upon initial message creation, or export from a format containing<br>
time zone information, such as the aforementioned JAM message base.</p>
<p><br>
4. Control paragraph specification<br>
-----------------------------</p>
<p> Messages which conform to this specification must add the following<br>
control paragraph:</p>
<p> ^aTZUTC: &lt;current offset from UTC&gt;</p>
<p> Where ^a is ASCII 1, 01h.</p>
<p> The offset has the format &lt;[-]hhmm&gt;, where hhmm is the number of<br>
hours and minutes, zero-padded to two digits each, that local time<br>
is offset from UTC. If local time is WEST of UTC, then the offset<br>
is NEGATIVE. See the table below for typical offsets.</p>
<p> Note that the hh in a time zone offset is not limited to a maximum<br>
of 12. This is because the International Date Line does not run<br>
exactly along the boundary between zone -1200 and +1200. The<br>
minutes part is 00 for most time zones.</p>
<p> All four digits must be present. If the offset is negative, there<br>
must be a minus ('-', ASCII 45, 2Dh) in front of the offset.</p>
<p> Implementations must NOT put a plus ('+', ASCII 43, 2Bh) in front of<br>
the offset for positive numbers, but robust implementations should<br>
be prepared to find (and ignore) a plus if it exists.</p>
<p> If local time changes as a result of, for example, daylight savings<br>
time, then the offset in the TZUTC control paragraph should change<br>
to reflect this.</p>
<p><br>
5. Time zone table<br>
------------------</p>
<p> This table gives examples of typical time zones.</p>
<p> -1000 Alaska-Hawaii Standard Time (United States)<br>
-0900 Hawaii Daylight Time<br>
-0800 Pacific Standard Time<br>
-0700 Pacific Daylight Time<br>
-0700 Mountain Standard Time<br>
-0600 Mountain Daylight Time<br>
-0600 Central Standard Time<br>
-0500 Central Daylight Time<br>
-0500 Eastern Standard Time<br>
-0400 Eastern Daylight Time<br>
-0400 Atlantic Standard Time<br>
-0330 Newfoundland Standard Time<br>
-0300 Atlantic Daylight Time<br>
-0100 West Africa Time<br>
0000 Universal Time Coordinated (UTC)<br>
0000 Greenwich Mean Time<br>
0100 Central European Time<br>
0100 British Summer Time<br>
0200 Central European Summer Time<br>
0200 Eastern European Time<br>
0800 Australian Western Standard Time<br>
0800 China Coast Time<br>
0900 Japan Standard Time<br>
0900 Australian Western Daylight Time<br>
0930 Australian Central Standard Time<br>
1000 Australian Eastern Standard Time<br>
1030 Australian Central Daylight Time<br>
1100 Australian Eastern Daylight Time<br>
1200 New Zealand Standard Time<br>
1300 New Zealand Daylight Time</p>
<p><br>
6. Examples<br>
-----------</p>
<p> ^aTZUTC: 0000<br>
^aTZUTC: 0200<br>
^aTZUTC: -0700</p>
<p><br>
A. References<br>
-------------</p>
<p> [1] &quot;A Basic FidoNet(r) Technical Standard Revision 16&quot;, Randy Bush.<br>
September 1995.</p>
<p> [2] &quot;The JAM message base proposal&quot;, Joaquim Homrighausen, Andrew<br>
Milner, Mats Birch and Mats Wallin. July 1993.</p>
<p><br>
B. History<br>
----------</p>
<p> Rev.1, 20030409: First release (revised from FSP-1001 by FTSC)<br>
Rev.2, 20030516: Corrected status; clarified Section 2 on insertion<br>
position and export practice; fixed terminology.</p>
<p>**********************************************************************<br>
</p>
</body>
</html>
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>Time zone information (TZUTC).</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: 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: &lt;current offset from UTC&gt;
Where ^a is ASCII 1, 01h.
The offset has the format &lt;[-]hhmm&gt;, 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.
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

456
html/ftsc/fts-4009.html
View File

@ -1,211 +1,245 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body>
**********************************************************************<br>
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE<br>
**********************************************************************
<p>Publication: FTS-4009<br>
Revision: 1<br>
Title: Netmail tracking (Via)<br>
Author: FTSC<br>
Issue Date: 16 May 2003<br>
Review Date: 16 May 2005<br>
----------------------------------------------------------------------<br>
Contents:<br>
1. Current practice<br>
2. Control paragraph specification<br>
3. Examples<br>
4. Deprecated formats<br>
A. References<br>
B. History<br>
----------------------------------------------------------------------</p>
<p>Status of this document<br>
-----------------------</p>
<p> This document is a Fidonet Technical Standard (FTS), issued by the<br>
FTSC for the benefit of the Fidonet community.</p>
<p> This document is based on the FSP-1010 proposal by Colin Turner,<br>
2:443/13, and Joaquim Homrighausen, 2:201/330.<br>
<br>
This document is released to the public domain, and may be used,<br>
copied or modified for any purpose whatsoever.</p>
<p><br>
1. Current practice<br>
-------------------</p>
<p> As Netmail messages are routed through FidoNet, or as they are<br>
processed on a system, Via control paragraphs are added to track<br>
their progress.<br>
<br>
The Via control paragraphs are stored in a block which starts after<br>
any message text. New Via lines should be added to the end of the<br>
block separated from the preceding control paragraph by a single<br>
ASCII carriage-return character (0Dh). There is no limit to the<br>
number of Via control paragraphs in each message.</p>
<p> Note that the &quot;Via&quot; tag is in mixed case, not all upper case like<br>
most control tags.<br>
<br>
A Via control paragraph is typically added:<br>
<br>
when a Netmail packer packs the Netmail for transmission to<br>
another system;<br>
<br>
when a netmail tracker inspects a Netmail.</p>
<p><br>
2. Control paragraph specification<br>
----------------------------------</p>
<p> The Via control paragraph is formatted as a number of fields,<br>
separated by single space (20h) characters, as follows<br>
<br>
^AVia &lt;FTN Address&gt; @YYYYMMDD.HHMMSS[.Precise][.Time Zone] <br>
&lt;Program Name&gt; &lt;Version&gt; [Serial Number]&lt;CR&gt;<br>
<br>
Where ^A denotes the ASCII &lt;SOH&gt; (01h) character, and &lt;CR&gt; is the<br>
carriage-return character (0Dh).<br>
<br>
The fields are defined as follows:<br>
<br>
FTN Address<br>
-----------</p>
<p> This field is mandatory and is the FidoNet Technology address of <br>
the system inserting the control paragraph, using standard Fidonet<br>
addressing notation, Z:N/F[.P][@domain]<br>
<br>
@YYYYMMDD.HHMMSS<br>
----------------<br>
<br>
This field is mandatory and consists of a time stamp. This is the<br>
time at which the stamp was placed. The subcomponents are<br>
<br>
YYYY, the calendar year, in full four digit, decimal form;<br>
MM, the calendar month, in the range 01 to 12, this must be a<br>
zero padded, two digit decimal number;<br>
DD, the day of the month, in the range 01 to 31, this must be a<br>
zero padded, two digit decimal number;<br>
HH, hours, in the range 00 to 23, this must be a zero padded,<br>
two digit decimal number;<br>
MM, minutes, in the range 00 to 59, this must be a zero padded,<br>
two digit decimal number;<br>
SS. seconds, in the range 00 to 59, this must be a zero padded,<br>
two digit decimal number.<br>
<br>
Precise<br>
-------<br>
<br>
This field is optional and takes the form of extra precision in the<br>
time stamp.<br>
<br>
If this field is present:<br>
<br>
it must begin with a single period character;<br>
<br>
this period must be followed by one or more decimal digits;<br>
<br>
the field has ended when another period or space is encountered;<br>
<br>
each decimal digit in the field following this character<br>
represents the time of the via line in fractions of a second,<br>
such that the the first digit represents tenths of a second,<br>
the second digit represents hundreds of a second and so on.</p>
<p> Robust implementations must check to ensure this field is numeric to<br>
avoid confusion with the Time Zone field.<br>
<br>
Time Zone<br>
---------</p>
<p> This field is optional, and must be a short, widely accepted<br>
alphabetical abbreviation of the time zone that the time stamp<br>
in the Via line pertains to.<br>
<br>
The use of various Time Zone values is deprecated, implementations<br>
should attempt to convert the timestamp in the control paragraph to<br>
Universal Time (GMT or UTC) and use the &quot;UTC&quot; Time Zone indicator,<br>
where possible.<br>
<br>
The Time Zone field may only be omitted when it is not possible for<br>
the implementation to determine the correct offset from UTC, and in<br>
this case the time stamp must represent local time on the generating<br>
system.</p>
<p> Robust implementations must check to ensure this field is not<br>
numeric to avoid confusion with the Precise field.<br>
<br>
Program Name<br>
------------<br>
<br>
This field is a mandatory string field of up to ten (10) characters<br>
naming the product inserting the Via line.<br>
<br>
Version<br>
-------</p>
<p> This field is a mandatory string field of up to ten (10) characters<br>
specifying the version of the product inserting the Via line,<br>
including any alpha, beta or gamma status.<br>
<br>
Serial Number<br>
-------------<br>
<br>
This field is an optional string field of up to ten (10) characters<br>
identifying the specific copy of the product inserting the Via line.</p>
<p><br>
3. Examples<br>
-----------</p>
<p> Example of valid usage are<br>
<br>
^AVia 1:2/3 @19990305.043212.UTC O/T-Track+ 2.69<br>
^AVia 1:2/3@fidonet @19980331.231202.UTC FrontDoor 2.32.mL<br>
^AVia 1:2/3.0 @19990101.002102.UTC FastEcho 1.46.1 21321<br>
^AVia 1:2/3 @19990323.230132 FakeMail 1.2<br>
^AVia 1:2/3 @20030403.182824.UTC Gleipner/Java 1.0/pre<br>
^AVia 1:2/3 @20030403.193223.UTC hpt 1.2.2-stable/os2<br>
^AVia D'Bridge 1.58 1:2/3 04/03 20:47<br>
^AVia 1:2/3@fidonet @20030404.030004.UTC O/T-Track+ 2.66b<br>
^AVia Squish/386 1.11 1:2/3, Thu Apr 03 2003 at 23:16 UTC<br>
^AVia 1:2/3 FTrack 3.1/W32 04 Apr 2003 09:33:07 UTC+1000<br>
^AVia ifmail 1:2/3@fidonet, Fri Apr 11 2003 at 06:01 (2.15)<br>
^AVia RTrk+ 1:2/3@fidonet, Apr 22 2003 at 18:25<br>
^AVia BBBS/NT v4.01 Flag-4 1:2/3.0, @030505155114 EDT+5</p>
<p><br>
4. Deprecated formats<br>
---------------------</p>
<p> Some other formats for the Via line are in use today, but these<br>
formats are rather variable and inconsistent in nature, while<br>
the format specified above is both more widespread and more<br>
consistent.<br>
<br>
New implementations may need to parse these formats, but must not<br>
generate them.<br>
<br>
The formats in use include, but are not limited to<br>
<br>
&lt;NAME&gt; [VERSION] [SERIAL] &lt;ADDRESS&gt; &lt;TIMESTAMP&gt; &lt;TIMEZONE&gt;<br>
&lt;NAME&gt; &lt;ADDRESS&gt;, &lt;TIMESTAMP&gt; &lt;TIMEZONE&gt; &lt;VERSION&gt;<br>
<br>
Not that the time stamp in the above formats is also widely<br>
variable, and takes forms which include, but may not be limited to<br>
<br>
&lt;Day&gt; &lt;Month&gt; &lt;Year&gt; AT &lt;Hour&gt;:&lt;Min&gt;:[Sec]<br>
&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;<br>
ON &lt;Day of Month&gt; &lt;Month&gt; &lt;Year&gt; &lt;Hour&gt;:&lt;Min&gt;:&lt;Sec&gt;<br>
&lt;Month&gt;/&lt;Day&gt; &lt;Hour&gt;:&lt;Min&gt;<br>
@YYMMDDHHMMSS<br>
<br>
In the last listed format, observe in particular the two digit year<br>
and lack of period to separate the date from time.</p>
<p><br>
A. References<br>
-------------</p>
<p> [FTS-1] &quot;A Basic FidoNet(r) Technical Standard Revision 16&quot;, Randy<br>
Bush. September 1995.</p>
<p> [FSC-46] &quot;A Product Identifier for FidoNet Message Handlers&quot;,<br>
Joaquim Homrighausen, August 1994.</p>
<p><br>
B. History<br>
----------</p>
<p> Rev.1, 20030516: First release (revised from FSP-1010 by FTSC; note<br>
the lack of a colon after the &quot;Via&quot; tag)</p>
<p>**********************************************************************<br>
</p>
</body>
</html>
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>Netmail Tracking (Via)</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: 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 &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
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
&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 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)
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

1
html/ftsc/index.htm
View File

@ -44,7 +44,6 @@ Michiel Broek.
<li><a href="fsc-0087.html">FSC-0087 File forwarding in FidoNet technology networks, R.Williamson</a>
<li><a href="fsc-0088.html">FSC-0088 Compatibility and Link Qualifier Extensions for EMSI Sessions, R.Williamson</a>
<li><a href="fsc-0091.html">FSC-0091 ISDN nodelist flags (rev.002), A.Lenz</a>
<li><a href="fsc-0092.html">FSC-0092 New control lines for forwarded messages, M.Hohner</a>
<li><a href="fsc-0093.html">FSC-0093 Reduced seen-by lines, F.Ellermann</a>
</ul>