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 known_bugs.html mgetty.html routing.html nodelist.html
H_FTSC = ftsc/fsc-0039.html ftsc/fsc-0056.html ftsc/fsc-0087.html \ H_FTSC = ftsc/fsc-0039.html ftsc/fsc-0056.html ftsc/fsc-0087.html \
ftsc/fts-0007.html \ ftsc/fts-0007.html ftsc/fsc-0046.html ftsc/fsc-0057.html \
ftsc/fsc-0046.html ftsc/fsc-0057.html ftsc/fsc-0091.html \ ftsc/fsc-0091.html ftsc/fta-1005.html ftsc/fts-0008.html \
ftsc/fta-1005.html ftsc/fts-0008.html \ ftsc/fsc-0048.html ftsc/fsc-0059.html ftsc/fts-0001.html \
ftsc/fsc-0048.html ftsc/fsc-0059.html ftsc/fsc-0092.html \ ftsc/fts-0009.html ftsc/fsc-0049.html ftsc/fsc-0062.html \
ftsc/fsp-1005.html ftsc/fts-0001.html ftsc/fts-0009.html \ ftsc/fsc-0093.html ftsc/fts-0004.html ftsc/index.htm \
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/fsc-0050.html ftsc/fsc-0070.html ftsc/fts-4008.html \
ftsc/fts-5000.html ftsc/fsc-0053.html \ ftsc/fts-5000.html ftsc/fsc-0053.html ftsc/fsc-0072.html \
ftsc/fsc-0072.html ftsc/fsp-1002.html \ ftsc/fsp-1002.html ftsc/fts-0006.html ftsc/fsc-0035.html \
ftsc/fts-0006.html ftsc/fsc-0035.html ftsc/fts-4009.html \ ftsc/fts-4009.html ftsc/fsp-1011.html ftsc/ftscprod.html \
ftsc/fsp-1011.html ftsc/ftscprod.html ftsc/fsc-0088.html \ ftsc/fsc-0088.html ftsc/fts-4001.html ftsc/fts-5001.html
ftsc/fts-4001.html ftsc/fts-5001.html
H_IMAGES = images/b_arrow.gif images/magic.gif images/nodes1.png \ H_IMAGES = images/b_arrow.gif images/magic.gif images/nodes1.png \
images/connec.gif images/mbsetup0.gif images/nodes2.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>
<html> <!-- $Id$ -->
<head> <HEAD>
<title>Untitled Document</title> <TITLE>Time zone information (TZUTC).</TITLE>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> </HEAD>
</head>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<body> <BODY
**********************************************************************<br> BGCOLOR="#FFFFFF"
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE<br> TEXT="#000000"
********************************************************************** LINK="#0000FF"
<p>Publication: FTS-4008<br> VLINK="#000080"
Revision: 2<br> ALINK="#FF0000"
Title: Time zone information (TZUTC)<br> >
Author: FTSC<br> <PRE>
Issue Date: 16 May 2003<br> **********************************************************************
Review Date: 16 May 2005<br> FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
Obsoletes: FTS-0010.001<br> **********************************************************************
----------------------------------------------------------------------<br>
Contents:<br> Publication: FTS-4008
1. Introduction<br> Revision: 2
2. Scope<br> Title: Time zone information (TZUTC)
3. Current practice<br> Author: FTSC
4. Control paragraph specification<br> Issue Date: 16 May 2003
5. Time zone table<br> Review Date: 16 May 2005
6. Examples<br> Obsoletes: FTS-0010.001
A. References<br> ----------------------------------------------------------------------
B. History<br> Contents:
----------------------------------------------------------------------</p> 1. Introduction
<p><br> 2. Scope
Status of this document<br> 3. Current practice
-----------------------</p> 4. Control paragraph specification
<p> This document is a Fidonet Technical Standard (FTS), issued by the<br> 5. Time zone table
FTSC for the benefit of the Fidonet community.</p> 6. Examples
<p> This document is based on the FSP-1001 proposal by Odinn Sorensen,<br> A. References
2:236/77.<br> B. History
<br> ----------------------------------------------------------------------
This document is released to the public domain, and may be used,<br>
copied or modified for any purpose whatsoever.</p>
<p><br> Status of this document
1. Introduction<br> -----------------------
---------------</p>
<p> Current practice in FidoNet is to transmit message times in local<br> This document is a Fidonet Technical Standard (FTS), issued by the
time. This document specifies a standard for transmission of time<br> FTSC for the benefit of the Fidonet community.
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 This document is based on the FSP-1001 proposal by Odinn Sorensen,
TZUTC.</p> 2:236/77.
<p><br>
2. Scope<br> This document is released to the public domain, and may be used,
--------</p> copied or modified for any purpose whatsoever.
<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> 1. Introduction
be lost if not transmitted in a control paragraph, eg. Type 2 packed<br> ---------------
messages. [1]</p>
<p><br> Current practice in FidoNet is to transmit message times in local
3. Current practice<br> time. This document specifies a standard for transmission of time
-------------------</p> zone information in FidoNet messages, in the form of a control
<p> Some control paragraphs already exist to specify the time zone of<br> paragraph (also known as a "control line" or "kludge") named TZUTC.
messages, notably &quot;TZUTC&quot; and &quot;TZUTCINFO&quot;. From observations
of<br>
these control paragraphs in actual messages, TZUTC and TZUTCINFO are<br> 2. Scope
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> This standard is specified for the transmission of FidoNet messages
shortest (&quot;TZUTC&quot; vs &quot;TZUTCINFO&quot;). However, software<br> in any form where time zone information is not integrated into the
implementations should be prepared to read and interpret the<br> transport format, specifically any form where the information would
TZUTCINFO control paragraph as well.</p> be lost if not transmitted in a control paragraph, eg. Type 2 packed
<p> The TZUTC control paragraph is inserted before the message body<br> messages. [1]
upon initial message creation, or export from a format containing<br>
time zone information, such as the aforementioned JAM message base.</p>
<p><br> 3. Current practice
4. Control paragraph specification<br> -------------------
-----------------------------</p>
<p> Messages which conform to this specification must add the following<br> Some control paragraphs already exist to specify the time zone of
control paragraph:</p> messages, notably "TZUTC" and "TZUTCINFO". From observations of
<p> ^aTZUTC: &lt;current offset from UTC&gt;</p> these control paragraphs in actual messages, TZUTC and TZUTCINFO are
<p> Where ^a is ASCII 1, 01h.</p> identical except for the name. TZUTCINFO is probably named after
<p> The offset has the format &lt;[-]hhmm&gt;, where hhmm is the number of<br> the JAM message base's [2] subfield of the same name.
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> This document adopts the TZUTC control paragraph because is the
is NEGATIVE. See the table below for typical offsets.</p> shortest ("TZUTC" vs "TZUTCINFO"). However, software
<p> Note that the hh in a time zone offset is not limited to a maximum<br> implementations should be prepared to read and interpret the
of 12. This is because the International Date Line does not run<br> TZUTCINFO control paragraph as well.
exactly along the boundary between zone -1200 and +1200. The<br>
minutes part is 00 for most time zones.</p> The TZUTC control paragraph is inserted before the message body
<p> All four digits must be present. If the offset is negative, there<br> upon initial message creation, or export from a format containing
must be a minus ('-', ASCII 45, 2Dh) in front of the offset.</p> time zone information, such as the aforementioned JAM message base.
<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> 4. Control paragraph specification
<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> Messages which conform to this specification must add the following
<p><br> control paragraph:
5. Time zone table<br>
------------------</p> ^aTZUTC: &lt;current offset from UTC&gt;
<p> This table gives examples of typical time zones.</p>
<p> -1000 Alaska-Hawaii Standard Time (United States)<br> Where ^a is ASCII 1, 01h.
-0900 Hawaii Daylight Time<br>
-0800 Pacific Standard Time<br> The offset has the format &lt;[-]hhmm&gt;, where hhmm is the number of
-0700 Pacific Daylight Time<br> hours and minutes, zero-padded to two digits each, that local time
-0700 Mountain Standard Time<br> is offset from UTC. If local time is WEST of UTC, then the offset
-0600 Mountain Daylight Time<br> is NEGATIVE. See the table below for typical offsets.
-0600 Central Standard Time<br>
-0500 Central Daylight Time<br> Note that the hh in a time zone offset is not limited to a maximum
-0500 Eastern Standard Time<br> of 12. This is because the International Date Line does not run
-0400 Eastern Daylight Time<br> exactly along the boundary between zone -1200 and +1200. The
-0400 Atlantic Standard Time<br> minutes part is 00 for most time zones.
-0330 Newfoundland Standard Time<br>
-0300 Atlantic Daylight Time<br> All four digits must be present. If the offset is negative, there
-0100 West Africa Time<br> must be a minus ('-', ASCII 45, 2Dh) in front of the offset.
0000 Universal Time Coordinated (UTC)<br>
0000 Greenwich Mean Time<br> Implementations must NOT put a plus ('+', ASCII 43, 2Bh) in front of
0100 Central European Time<br> the offset for positive numbers, but robust implementations should
0100 British Summer Time<br> be prepared to find (and ignore) a plus if it exists.
0200 Central European Summer Time<br>
0200 Eastern European Time<br> If local time changes as a result of, for example, daylight savings
0800 Australian Western Standard Time<br> time, then the offset in the TZUTC control paragraph should change
0800 China Coast Time<br> to reflect this.
0900 Japan Standard Time<br>
0900 Australian Western Daylight Time<br>
0930 Australian Central Standard Time<br> 5. Time zone table
1000 Australian Eastern Standard Time<br> ------------------
1030 Australian Central Daylight Time<br>
1100 Australian Eastern Daylight Time<br> This table gives examples of typical time zones.
1200 New Zealand Standard Time<br>
1300 New Zealand Daylight Time</p> -1000 Alaska-Hawaii Standard Time (United States)
<p><br> -0900 Hawaii Daylight Time
6. Examples<br> -0800 Pacific Standard Time
-----------</p> -0700 Pacific Daylight Time
<p> ^aTZUTC: 0000<br> -0700 Mountain Standard Time
^aTZUTC: 0200<br> -0600 Mountain Daylight Time
^aTZUTC: -0700</p> -0600 Central Standard Time
<p><br> -0500 Central Daylight Time
A. References<br> -0500 Eastern Standard Time
-------------</p> -0400 Eastern Daylight Time
<p> [1] &quot;A Basic FidoNet(r) Technical Standard Revision 16&quot;, Randy Bush.<br> -0400 Atlantic Standard Time
September 1995.</p> -0330 Newfoundland Standard Time
<p> [2] &quot;The JAM message base proposal&quot;, Joaquim Homrighausen, Andrew<br> -0300 Atlantic Daylight Time
Milner, Mats Birch and Mats Wallin. July 1993.</p> -0100 West Africa Time
<p><br> 0000 Universal Time Coordinated (UTC)
B. History<br> 0000 Greenwich Mean Time
----------</p> 0100 Central European Time
<p> Rev.1, 20030409: First release (revised from FSP-1001 by FTSC)<br> 0100 British Summer Time
Rev.2, 20030516: Corrected status; clarified Section 2 on insertion<br> 0200 Central European Summer Time
position and export practice; fixed terminology.</p> 0200 Eastern European Time
<p>**********************************************************************<br> 0800 Australian Western Standard Time
</p> 0800 China Coast Time
</body> 0900 Japan Standard Time
</html> 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>
<html> <!-- $Id$ -->
<head> <HEAD>
<title>Untitled Document</title> <TITLE>Netmail Tracking (Via)</TITLE>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> </HEAD>
</head>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<body> <BODY
**********************************************************************<br> BGCOLOR="#FFFFFF"
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE<br> TEXT="#000000"
********************************************************************** LINK="#0000FF"
<p>Publication: FTS-4009<br> VLINK="#000080"
Revision: 1<br> ALINK="#FF0000"
Title: Netmail tracking (Via)<br> >
Author: FTSC<br> <PRE>
Issue Date: 16 May 2003<br> **********************************************************************
Review Date: 16 May 2005<br> FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
----------------------------------------------------------------------<br> **********************************************************************
Contents:<br>
1. Current practice<br> Publication: FTS-4009
2. Control paragraph specification<br> Revision: 1
3. Examples<br> Title: Netmail tracking (Via)
4. Deprecated formats<br> Author: FTSC
A. References<br> Issue Date: 16 May 2003
B. History<br> Review Date: 16 May 2005
----------------------------------------------------------------------</p> ----------------------------------------------------------------------
<p>Status of this document<br> Contents:
-----------------------</p> 1. Current practice
<p> This document is a Fidonet Technical Standard (FTS), issued by the<br> 2. Control paragraph specification
FTSC for the benefit of the Fidonet community.</p> 3. Examples
<p> This document is based on the FSP-1010 proposal by Colin Turner,<br> 4. Deprecated formats
2:443/13, and Joaquim Homrighausen, 2:201/330.<br> A. References
<br> B. History
This document is released to the public domain, and may be used,<br> ----------------------------------------------------------------------
copied or modified for any purpose whatsoever.</p>
<p><br> Status of this document
1. Current practice<br> -----------------------
-------------------</p>
<p> As Netmail messages are routed through FidoNet, or as they are<br> This document is a Fidonet Technical Standard (FTS), issued by the
processed on a system, Via control paragraphs are added to track<br> FTSC for the benefit of the Fidonet community.
their progress.<br>
<br> This document is based on the FSP-1010 proposal by Colin Turner,
The Via control paragraphs are stored in a block which starts after<br> 2:443/13, and Joaquim Homrighausen, 2:201/330.
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> This document is released to the public domain, and may be used,
ASCII carriage-return character (0Dh). There is no limit to the<br> copied or modified for any purpose whatsoever.
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> 1. Current practice
<br> -------------------
A Via control paragraph is typically added:<br>
<br> As Netmail messages are routed through FidoNet, or as they are
when a Netmail packer packs the Netmail for transmission to<br> processed on a system, Via control paragraphs are added to track
another system;<br> their progress.
<br>
when a netmail tracker inspects a Netmail.</p> The Via control paragraphs are stored in a block which starts after
<p><br> any message text. New Via lines should be added to the end of the
2. Control paragraph specification<br> block separated from the preceding control paragraph by a single
----------------------------------</p> ASCII carriage-return character (0Dh). There is no limit to the
<p> The Via control paragraph is formatted as a number of fields,<br> number of Via control paragraphs in each message.
separated by single space (20h) characters, as follows<br>
<br> Note that the "Via" tag is in mixed case, not all upper case like
^AVia &lt;FTN Address&gt; @YYYYMMDD.HHMMSS[.Precise][.Time Zone] <br> most control tags.
&lt;Program Name&gt; &lt;Version&gt; [Serial Number]&lt;CR&gt;<br>
<br> A Via control paragraph is typically added:
Where ^A denotes the ASCII &lt;SOH&gt; (01h) character, and &lt;CR&gt; is the<br>
carriage-return character (0Dh).<br> when a Netmail packer packs the Netmail for transmission to
<br> another system;
The fields are defined as follows:<br>
<br> when a netmail tracker inspects a Netmail.
FTN Address<br>
-----------</p>
<p> This field is mandatory and is the FidoNet Technology address of <br> 2. Control paragraph specification
the system inserting the control paragraph, using standard Fidonet<br> ----------------------------------
addressing notation, Z:N/F[.P][@domain]<br>
<br> The Via control paragraph is formatted as a number of fields,
@YYYYMMDD.HHMMSS<br> separated by single space (20h) characters, as follows
----------------<br>
<br> ^AVia &lt;FTN Address&gt; @YYYYMMDD.HHMMSS[.Precise][.Time Zone]
This field is mandatory and consists of a time stamp. This is the<br> &lt;Program Name&gt; &lt;Version&gt; [Serial Number]&lt;CR&gt;
time at which the stamp was placed. The subcomponents are<br>
<br> Where ^A denotes the ASCII &lt;SOH&gt; (01h) character, and &lt;CR&gt; is the
YYYY, the calendar year, in full four digit, decimal form;<br> carriage-return character (0Dh).
MM, the calendar month, in the range 01 to 12, this must be a<br>
zero padded, two digit decimal number;<br> The fields are defined as follows:
DD, the day of the month, in the range 01 to 31, this must be a<br>
zero padded, two digit decimal number;<br> FTN Address
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> This field is mandatory and is the FidoNet Technology address of
two digit decimal number;<br> the system inserting the control paragraph, using standard Fidonet
SS. seconds, in the range 00 to 59, this must be a zero padded,<br> addressing notation, Z:N/F[.P][@domain]
two digit decimal number.<br>
<br> @YYYYMMDD.HHMMSS
Precise<br> ----------------
-------<br>
<br> This field is mandatory and consists of a time stamp. This is the
This field is optional and takes the form of extra precision in the<br> time at which the stamp was placed. The subcomponents are
time stamp.<br>
<br> YYYY, the calendar year, in full four digit, decimal form;
If this field is present:<br> MM, the calendar month, in the range 01 to 12, this must be a
<br> zero padded, two digit decimal number;
it must begin with a single period character;<br> DD, the day of the month, in the range 01 to 31, this must be a
<br> zero padded, two digit decimal number;
this period must be followed by one or more decimal digits;<br> HH, hours, in the range 00 to 23, this must be a zero padded,
<br> two digit decimal number;
the field has ended when another period or space is encountered;<br> MM, minutes, in the range 00 to 59, this must be a zero padded,
<br> two digit decimal number;
each decimal digit in the field following this character<br> SS. seconds, in the range 00 to 59, this must be a zero padded,
represents the time of the via line in fractions of a second,<br> two digit decimal number.
such that the the first digit represents tenths of a second,<br>
the second digit represents hundreds of a second and so on.</p> Precise
<p> Robust implementations must check to ensure this field is numeric to<br> -------
avoid confusion with the Time Zone field.<br>
<br> This field is optional and takes the form of extra precision in the
Time Zone<br> time stamp.
---------</p>
<p> This field is optional, and must be a short, widely accepted<br> If this field is present:
alphabetical abbreviation of the time zone that the time stamp<br>
in the Via line pertains to.<br> it must begin with a single period character;
<br>
The use of various Time Zone values is deprecated, implementations<br> this period must be followed by one or more decimal digits;
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> the field has ended when another period or space is encountered;
where possible.<br>
<br> each decimal digit in the field following this character
The Time Zone field may only be omitted when it is not possible for<br> represents the time of the via line in fractions of a second,
the implementation to determine the correct offset from UTC, and in<br> such that the the first digit represents tenths of a second,
this case the time stamp must represent local time on the generating<br> the second digit represents hundreds of a second and so on.
system.</p>
<p> Robust implementations must check to ensure this field is not<br> Robust implementations must check to ensure this field is numeric to
numeric to avoid confusion with the Precise field.<br> avoid confusion with the Time Zone field.
<br>
Program Name<br> Time Zone
------------<br> ---------
<br>
This field is a mandatory string field of up to ten (10) characters<br> This field is optional, and must be a short, widely accepted
naming the product inserting the Via line.<br> alphabetical abbreviation of the time zone that the time stamp
<br> in the Via line pertains to.
Version<br>
-------</p> The use of various Time Zone values is deprecated, implementations
<p> This field is a mandatory string field of up to ten (10) characters<br> should attempt to convert the timestamp in the control paragraph to
specifying the version of the product inserting the Via line,<br> Universal Time (GMT or UTC) and use the "UTC" Time Zone indicator,
including any alpha, beta or gamma status.<br> where possible.
<br>
Serial Number<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
This field is an optional string field of up to ten (10) characters<br> system.
identifying the specific copy of the product inserting the Via line.</p>
<p><br> Robust implementations must check to ensure this field is not
3. Examples<br> numeric to avoid confusion with the Precise field.
-----------</p>
<p> Example of valid usage are<br> Program Name
<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> This field is a mandatory string field of up to ten (10) characters
^AVia 1:2/3.0 @19990101.002102.UTC FastEcho 1.46.1 21321<br> naming the product inserting the Via line.
^AVia 1:2/3 @19990323.230132 FakeMail 1.2<br>
^AVia 1:2/3 @20030403.182824.UTC Gleipner/Java 1.0/pre<br> Version
^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> This field is a mandatory string field of up to ten (10) characters
^AVia Squish/386 1.11 1:2/3, Thu Apr 03 2003 at 23:16 UTC<br> specifying the version of the product inserting the Via line,
^AVia 1:2/3 FTrack 3.1/W32 04 Apr 2003 09:33:07 UTC+1000<br> including any alpha, beta or gamma status.
^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> Serial Number
^AVia BBBS/NT v4.01 Flag-4 1:2/3.0, @030505155114 EDT+5</p> -------------
<p><br>
4. Deprecated formats<br> This field is an optional string field of up to ten (10) characters
---------------------</p> identifying the specific copy of the product inserting the Via line.
<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> 3. Examples
consistent.<br> -----------
<br>
New implementations may need to parse these formats, but must not<br> Example of valid usage are
generate them.<br>
<br> ^AVia 1:2/3 @19990305.043212.UTC O/T-Track+ 2.69
The formats in use include, but are not limited to<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
&lt;NAME&gt; [VERSION] [SERIAL] &lt;ADDRESS&gt; &lt;TIMESTAMP&gt; &lt;TIMEZONE&gt;<br> ^AVia 1:2/3 @19990323.230132 FakeMail 1.2
&lt;NAME&gt; &lt;ADDRESS&gt;, &lt;TIMESTAMP&gt; &lt;TIMEZONE&gt; &lt;VERSION&gt;<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
Not that the time stamp in the above formats is also widely<br> ^AVia D'Bridge 1.58 1:2/3 04/03 20:47
variable, and takes forms which include, but may not be limited to<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
&lt;Day&gt; &lt;Month&gt; &lt;Year&gt; AT &lt;Hour&gt;:&lt;Min&gt;:[Sec]<br> ^AVia 1:2/3 FTrack 3.1/W32 04 Apr 2003 09:33:07 UTC+1000
&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> ^AVia ifmail 1:2/3@fidonet, Fri Apr 11 2003 at 06:01 (2.15)
ON &lt;Day of Month&gt; &lt;Month&gt; &lt;Year&gt; &lt;Hour&gt;:&lt;Min&gt;:&lt;Sec&gt;<br> ^AVia RTrk+ 1:2/3@fidonet, Apr 22 2003 at 18:25
&lt;Month&gt;/&lt;Day&gt; &lt;Hour&gt;:&lt;Min&gt;<br> ^AVia BBBS/NT v4.01 Flag-4 1:2/3.0, @030505155114 EDT+5
@YYMMDDHHMMSS<br>
<br>
In the last listed format, observe in particular the two digit year<br> 4. Deprecated formats
and lack of period to separate the date from time.</p> ---------------------
<p><br>
A. References<br> Some other formats for the Via line are in use today, but these
-------------</p> formats are rather variable and inconsistent in nature, while
<p> [FTS-1] &quot;A Basic FidoNet(r) Technical Standard Revision 16&quot;, Randy<br> the format specified above is both more widespread and more
Bush. September 1995.</p> consistent.
<p> [FSC-46] &quot;A Product Identifier for FidoNet Message Handlers&quot;,<br>
Joaquim Homrighausen, August 1994.</p> New implementations may need to parse these formats, but must not
<p><br> generate them.
B. History<br>
----------</p> The formats in use include, but are not limited to
<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> &lt;NAME&gt; [VERSION] [SERIAL] &lt;ADDRESS&gt; &lt;TIMESTAMP&gt; &lt;TIMEZONE&gt;
<p>**********************************************************************<br> &lt;NAME&gt; &lt;ADDRESS&gt;, &lt;TIMESTAMP&gt; &lt;TIMEZONE&gt; &lt;VERSION&gt;
</p>
</body> Not that the time stamp in the above formats is also widely
</html> 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-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-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-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> <li><a href="fsc-0093.html">FSC-0093 Reduced seen-by lines, F.Ellermann</a>
</ul> </ul>