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