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