Text 8452, 247 rader
Skriven 2017-03-27 10:16:57 av Fred Riccio (1:132/174)
   Kommentar till text 8450 av Ward Dossche (2:292/854)
Ärende: Repost: Proposed changes: FTS-5001.006 - Part 2
=======================================================
 WD> The message displays grunged on my system, obviously too long.

 WD> Can you chop it up pls?

   ----- FTS-5001.006.Part2 begins -----


5.5. Gateway Flag
-----------------

  The following flag defines gateways to other domains (networks).

    Flag   Meaning

    Gx..x  Gateway to domain 'x..x', where 'x..x` is a string
           of alphanumeric characters. Valid values for
           'x..x' are assigned by the FidoNet International
           Coordinator or the Zone Coordinators Council. They
           will also adequately distribute a list of valid
           values.


5.6. Mail Period Flags
----------------------

  The Mail Period Flags indicate compliance with another zone's ZMH.
  Since ZMH is mandatory within one's own zone, it is not indicated.

  These flags have the form "#nn" or !nn where nn is the UTC hour the
  mail period begins, # indicates Bell 212A compatibility, and !
  indicates incompatibility with Bell 212A.  For example:

    Flag   Meaning

    #02    Zone 2 mail hour (02:30 - 03:30 UTC)
    #08    Zone 4 mail hour (08:00 - 09:00 UTC)
    #09    Zone 1 mail hour (09:00 - 10:00 UTC)
    #17    Zone 3 mail hour (17:00 - 18:00 UTC)

  The above listing of the ZMH for each individual zone is only given
  for your convenience. It was correct at the time of this writing,
  but could be changed at any time by following the procedures
  established in Fidonet policy. The FTSC has no role in determining
  the Mail Hour of any Zone. You'll find an up-to-date list in the
  comments at the end of the Fidonet Nodelist.

  NOTE:  When applicable, the mail period flags may be strung together
  with no intervening commas, e.g. "#02#09".


5.7. System Online Flags
------------------------

  The flag Tyz is used by non-CM nodes online not only during ZMH, y
  is a letter indicating the start and z a letter indicating the end
  of the online period as defined below (times in UTC):

    A  0:00,  a  0:30,   B  1:00,  b  1:30,   C  2:00,  c  2:30,
    D  3:00,  d  3:30,   E  4:00,  e  4:30,   F  5:00,  f  5:30,
    G  6:00,  g  6:30,   H  7:00,  h  7:30,   I  8:00,  i  8:30,
    J  9:00,  j  9:30,   K 10:00,  k 10:30,   L 11:00,  l 11:30,
    M 12:00,  m 12:30,   N 13:00,  n 13:30,   O 14:00,  o 14:30,
    P 15:00,  p 15:30,   Q 16:00,  q 16:30,   R 17:00,  r 17:30,
    S 18:00,  s 18:30,   T 19:00,  t 19:30,   U 20:00,  u 20:30,
    V 21:00,  v 21:30,   W 22:00,  w 22:30,   X 23:00,  x 23:30.

  For example TuB shows an online period from 20:30 until 1:00 UTC.


  Daylight saving time
  --------------------

  If a node changes online times with respect to UTC when daylight
  saving time becomes effective (which would be the case with most
  part time nodes), then this is to be taken into account when
  assigning this flag. An online times flag assigned to a node should
  not be altered for the specific purpose of adjusting due to daylight
  saving time, since large difference files (NODEDIFF's) would result
  if every node was allowed to do this, e.g. a node used to be online
  from 2300 to 0800 in local time, which in winter is UTC, but in the
  summer it becomes BST (British Summer Time). This is one hour ahead
  of UTC, and the corresponding availability times of a node during
  the summer period were 2200 to 0700 UTC. Therefore its online times
  flag would have indicated availability between the hours of 2300 and
  0700 UTC, the daily time period encompassing both times, so the flag
  would be TXH.


5.8. ISDN Capability Flags
--------------------------

  Nodelist   Specification of minimal support required for this flag;
      flag   any additional support to be arranged via agreement
             between users

   V110L     ITU-T V.110 19k2 async ('low').
             NOTE: some implementations are limited to 9600bps.
   V110H     ITU-T V.110 38k4 async ('high').
   V120L     ITU-T V.120 56k async, layer 2 framesize 259, window 7,
             modulo 8.
   V120H     ITU-T V.120 64k async, layer 2 framesize 259, window 7,
             modulo 8.
   X75       ITU-T X.75 SLP (single link procedure) with 64kbit/s B
             channel; layer 2 max. framesize 2048, window 2, non-ext.
             mode (modulo 8); layer 3 transparent (no packet layer).
   ISDN      Other configurations. Use only if none of the above
             fits.

   NOTE: No flag implies another. Each capability MUST be specifically
   listed.


5.9. Internet Capabilities
--------------------------

Basic Syntax
------------

  Internet capability flags use the format:

    <flag>[:<internet address>][:<port>]

  Where <internet address> is:
    * a fully qualified domain name (FQDN), or
    * an IPv6 address encased in square brackets, or
    * an IPv4 address in dotted-quad format, or
    * an email address,

  depending on the protocol, and <port> is the service port number.

  <internet address> may be omitted if the address is available in
  another field (see below).  <port> should be omitted if it is the
  default port for that particular service, and is not permitted for
  email addresses.

  The mailer software is expected to be able to determine whether
  <internet address> is an IPv4 quad, an IPv6 encased address, a
  host name or email address by itself.


Advanced usage
--------------

  Several methods of listing Internet capability flags are widely
  used and subject to change at any time.  Internet capable software
  should provide a suitable manual override mechanism to compensate
  for the volatility of the nodelist format, and be able to deal with
  prolonged connection failures (e.g. by automatically putting waiting
  mail on hold, and notifying the local sysop).


  Shorthand flags
  ---------------

  For brevity, a node that lists multiple Internet capability flags
  that require the same address may list the address only once, and
  specify only port numbers per flag if required.

  Ideally, a node should use the flags specifically intended for this
  purpose, but that is not always the case.  Be prepared to look for
  addresses under any flag of the same type.

  Multihomed systems
  ------------------

  Multihomed systems or systems that are otherwise reacheable by more
  than one address, may - instead of adding another A or AAAA record
  to the DNS zone of the host name - repeat the flag(s) carrying the
  address with another address.

  Example:  INA:host1.example1.tld,INA:host2.example2.tld,IBN

  This method is not to be used to signal that a system is IPV4 and
  IPv6 capable. Additional IPv6 capability should be advertised by
  adding an AAAA record to an already listed host name.


  Alternate fields
  ----------------

  If the address is not attached to any of the Internet capability
  flags, it may be present in another field (see FTS-5000).

  Because of this, systems using Internet capability flags should
  avoid entering data in such fields that may be mistaken for Internet
  related information.  For example, a node with an email flag should
  not use a system name that could be confused with an email address.


  DNS Distributed Nodelist
  ------------------------

  "Precompiled" IP connection information may also be obtained from
  one of the local or publicly available DNS Distributed Nodelist
  (DDN) services. This is documented in FTS-5004.


Indirect Delivery
-----------------

  Not all Internet tunneling methods require the originating node and
  the destination node to make a direct, realtime connection.  Relays
  through the FTP or email servers of an ISP may serve as an example.

  To avoid unusual delays, nodes using such 3rd party relays should
  check regularly for new mail -- daily for non-CM nodes, and hourly
  for CM nodes is recommended.

  Where multiple protocols are available, the originating node should
  select the most direct method, and avoid protocols that may be using
  relays.


Standard Flags
--------------

        Default
  Flag     port  Description
  --------------------------

   INA   (none)  This flag sets the default Internet address used
                 for any non-email based flag that does not specify
                 its own. This flag does not carry a port number.
   IP    (none)  Mostly used during the introduction of IP capable
                 systems to the nodelist, is similar to the INA flag
                 but may or may not specify an Internet address.
                 Both usages are deprecated in favour of INA.

   IBN    24554  Binkp (FTS-1026 - FTS-1029)
   IFC    60179  RAW ifcico (FTS-1024)
   IFT       21  FTP (RFC-0959); Note there is currently no widely
                 accepted authentication scheme for FTP transfers by
                 Fidonet mailers.
   ITN       23  Telnet connection using FTS-1 or any other protocol
                 designed for classic POTS and modem. 
   IVM     3141  Vmodem connection using FTS-1 or any other protocol
                 designed for classic POTS and modem. 

   INO4  (none)  Indicates that an otherwise IP capable node is unable
                 to accept incoming connections over IPv4. (FRL-1038)
                 This flag does not carry an address or port number. 


   ----- FTS-5001.006.Part2 ends -----

--- Msged/NT 6.0.1
 * Origin: Somewhere in New Hampshire's White Mountains (1:132/174)