| Document: FSC-0088
 | Version:  001
 | Date:     31 October, 1995
 |
 | Robert Williamson FidoNet#1:167/104.0

   Compatibility and Link Qualifier Extensions for EMSI Sessions
   Robert Williamson FidoNet#1:167/104.0  [email protected]

   Purpose:

   The  basic  purpose of this document is to start discussions which will
   hopefully result in an improved handshake negotiation protocol.

   Scope:

   Relation of flags to Types of files transferred:

   The  FSC-0056  EMSI  specification  (hereafter  referred  to as EMSI-I)
   makes  little  distinction  between  ARCmail/packets and other types of
   files,  such  as  files attached and TIC'ed files.  In EMSI-I, the term
   'Mail'  when  not  used  in  conjunction with the term 'compressed', is
   interpreted to mean ANY file.

   This  extension  (hereafter  referred to as EMSI-II) makes reference to
   and  allows control of types of files in addition to 'compressed mail'.
   References  to  'Mail'  are  changed to 'File' where common practice so
   indicates.   The  additional qualifier flags described provide for more
   control as to the types of files a system is prepared to receive.


   Relation of flags to presented addresses:

   The  EMSI-I  specification does not allow qualification for any address
   other than the PRIMARY address.  This means that Link flags are limited
   in  application  to  either  all  presented addresses or to the primary
   presented address only.

   This  extension  also  allows  application  of  Link  flags to specific
   addresses other than the primary.


   Distinctions between Calling and Answering System:

   In  the EMSI-I spec, the type of flags that may be presented is limited
   by  the  status  of the site.  Certain flags may only be presented when
   the  site  is the caller and other flags may only be presented when the
   site   is   the   answerer.    This  proposed  extension  removes  this
   distinction.

   In the EMSI-I spec, certain Link and Capability (a.k.a:  Compatibility)
   flags  are  caller-driven, while others are controlled by the answering
   system.  This specification attempts to harmonize these discrepancies.

   A  attempt  is made to remain somewhat backwards compatible and to have
   new  flags  follow the original flag naming convention.  However, IMHO,
   it  would  be preferable to harmonize the flags; reducing the number of
   them  while retaining the fine type control, so that the same codes are
   used in all sessions.

   Under  both  EMSI-I and EMSI-II, any flags that are not understood, are
   to  be  ignored.   Therfore,  if  a site presents it's flags in EMSI-II
   format  and  the  other site does not do EMSI-II, it is permissable for
   that site to interpret all flags according to EMSI-I specifications.


   Specifics:

   Compatibility flags:

   Compatibility  flags  consist of a string of codes that specify the
   PROTOCOL CAPABILITIES and ENABLED FEATURES of the mailer.

   ARC, XMA
   These  EMSI-I  compatibility  flags  have  no  meaning  relavant to the
   transfer  of  files  and  are  not  to  be presented under EMSI-II.  If
   received, they are to be ignored.


   FNC
   The FNC EMSI-I compatibility flag has been identified as a 'mistake' by
   the  author  of EMSI-I.  This is agreeable as that specification called
   for   the   creation   of   a   filename   that  was  ALWAYS  8.3,  not
   up-to-8.up-to-3.
   It   is   not  to  be  presented  under  EMSI-II.   If  received  as  a
   compatibility flag, it is to be ignored.


   Protocol Selection:

   In  the EMSI-I spec, a requirement is placed upon the calling system to
   present  it's  available  protocols  in  order  of preference.  A quote
   follows:

       The calling system must list supported protocols first and
       descending order of preference (the most desirable protocol
       should be listed first).
       The answering system should only present one protocol and it
       should be the first item in the compatibility_codes field.

   Some mailer authors have interpreted 'the compatibility_codes field' in
   the  second  sentence  to  mean  that  of the answering system, thereby
   making  protocol  selection RECEIVER-PREFS driven.  This interpretation
   makes  unnecessary  the  'decending  order' requirement placed upon the
   calling   system,   so  shall  be  considered  in  conflict  with  that
   requirement.

    Most   mailer  authors  have  interpreted  that  phrase  to  mean  the
   'compatibility_codes  field'  OF  THE  CALLER,  thereby making protocol
   selection  CALLER-PREFS  driven.   Since  EMSI-I  was intended to be "a
   clear  protocol  definition  for  state-of-the-art  E-Mail  systems  to
   follow",  they  cannot  be  faulted  for  interpretation.  Caller-prefs
   driven  selection  is state-of-the-art, receiver-prefs driven selection
   is older technolgy, such as Wazoo.

   This   specification   requires   that   the   second  interpretation,
   CALLER-PREFS driven, be mandatory.


   New Compatibilty Flags:
   ----------------------

   EII
   Indicates   that   the   system   will   interpret   flags  under  this
   specification, if other end also presents this flag.  IF either or both
   systems  do  not  present  this  flag,  all  interpretations  are  done
   according to EMSI-I.

   DFB
   Indicates  that  the  system  presenting  is  capabable of fall-back to
   FTS1/WAZOO  negotiation  in the case of failure of EMSI handshake or no
   common  protocol.   Since  ZMO  is  the  minimum required protocol, NCP
   should  only  occur  if  the  answering  system  presents more than one
   protocol..  (ie. it's broken)

   FRQ
   Indicates  that  the  system  will  accept  and  process  file requests
   received  during  outbound  calls.   In other words, the calling system
   will  do a second turnaround for uni-directional protocols, to send the
   files requested, at his cost.

   NRQ
   NRQ should be presented ONLY IF the mailer does not have a file request
   server, task or function and cannot accept requests..  It should NOT be
   used to indicate that the  function  is  temporarly disabled.

   When  examined,  No  requests will be sent.  It would be advisable that
   the  mailer  alert  the  system  operator  of this occurance to prevent
   continued polling of the remote site.


   Protocol Capabilities:

   Protocol   capability   flags  are  presented  in  decending  order  of
   preference  by  the  caller.  The answering system selects and presents
   the  FIRST  protocol  from  the  callers  list  that  it supports.  The
   answering system must present only ONE protocol.

   HYD  Hydra bi-directional    (link flags define parameters)
   JAN  Janus bi-directional
   TZA  DirectZap               (TrapDoor DirectZap varient)
   DZA  DirectZap               (Zmodem variant, reduced escape set)
   ZAP  ZedZap                  (Zmodem variant, upe 8K blocks)
   ZMO  Zmodem w/1,024 packets  (Wazoo ZedZip)
   SLK  SeaLink                 (no TYSNC, No MDM7, No TeLink)
                                (8-32k window/ReSync/OverDrive/LongNames)

   NCP
   This  is  presented  if  no compatible protocol can be negotiated under
   EMSI.   Since  in  most  FTN  networks,  a  common protocol DOES exist,
   fallback   to  WaZoo  and  FTS1  negotiation  is  expected.   If  these
   negotiation methods are not available, the session is terminated.

   This  condition  should  never  occur  under  normal circumstances.  It
   should  be  considered as a problem with the design or configuration of
   one of the mailers involved.

   Link flags:
   ----------

   Link  flags  consist  of a string of codes that specify DESIRED CONNECT
   CONDITIONS.   They  apply  to  the CURRENT SESSION ONLY.  Under EMSI-I,
   there are four TYPES of link flags:  communications parameters, session
   parameters, pickup options and hold options.  Under EMSI-II, only three
   types  are  used,  the communications parameters type is REMOVED, as it
   serves no purpose whatsoever in FTN operations.


   Link Session options:

   FNC
   If  either  system  presents  this  flag,  it is an indication that the
   presenting   system   requires   filename   conversion   to  cp/m-msdos
   conventions.  The other system will convert filenames to cp/m cpm/msdos
   8.3 conventions before sending.
   The   convention   is   defined   as   a  filename  consisting  of  two
   parts,  the  filepart  and  extension.   The filepart and extension are
   separated  by a period ".".  The filepart may be from 1 to 8 characters
   in  length  and  the  extension  may  be  from  0 to 3 characters.  The
   character set shall be any uppercase character in the range A-Z and any
   numeric  character  in  the  range  0-9.   If  the extension is of zero
   length, the period may or may not be present.


   RMA
   Indicates that the presenting site is able to send and process multiple
   file  requests.   If both sites present this flag, the caller will send
   any REQ files found for each AKA presented by the answering system.
   The answering system will process each received REQ.

   RH1
   Indicates  that  under  the  Hydra  protocol,  batch  one contains file
   requests only, while batch 2 is reserved for all other files.


   (others to be defined)

   Pickup and Hold Flags:

   Under  the  EMSI-I  specification, Link Pickup flags are only presented
   when  calling (an Outbound Session) and are examined and processed only
   when  answering  (an  Inbound  Session)  and  Link  Hold flags are only
   presented  when  answering  (an  Inbound  Session) and are examined and
   processed only when calling (an Outbound Session).

   With  EMSI-II,  BOTH  Pickup and Hold flags are presented by both sites
   during  a  session.   This  allows  more control for those systems, for
   example,  which  cannot  modify  addresses  presented or rotate akas to
   change  the  primary  address  presented  on  a per-session or per-site
   basis.


   Link Pickup and Hold:

   Each  system can present one of three (or more) Link options related to
   application of addresses.  If neither of these flags are presented, PUA
   is to be assumed.

   Neither  PUA  nor  PUP  is  to  be  presented  if  only one address was
   presented.

            PUP     Pickup FILES for primary address only
         /  PUA     Pickup FILES for all presented addresses
        /   PUn     Pickup FILES for address number n in AKA list
one of |
        \
         \  NPU     No FILE pickup desired. (calling system)
            HAT     Hold all FILES          (answering system)
            HAn     Hold all FILES for address number n in AKA list


   Qualifiers:

   Qualifiers  are  processed  in  the  order presented, with any conflict
   being  resolved  by  subsequent  qualifiers overridding any conflicting
   previous qualifier in the list.

   Qualifiers may be not be presented with either NPU or HAT and should be
   ignored if received with NPU or HAT.

   PickUp:

       PMO     PickUp Mail (ARCmail and Packets) ONLY
       PMn     PickUp Mail ONLY for address number n in AKA list

       NFE     No TIC'S, associated files or files
               attachs desired
       NFn     No TIC'S, associated files or file attaches,
               for address number n in AKA list

       NXP     No compressed mail pickup desired
       NXn     No compressed mail pickup desired,
               for address number n in AKA list

       NRQ     File requests not accepted by caller
               This  flag is presented if file request processing
               is disabled TEMPORARILY for any reason
       NRn     File requests not accepted by caller
               for address number n in AKA list

    Note that NFE,NPX,NRQ != NPU

   Hold:

       HNM     Hold all traffic EXCEPT Mail (ARCmail and Packets)
       HNn     Hold all traffic EXCEPT Mail (ARCmail and Packets)
               for address number n in AKA list

       HXT     Hold compressed mail traffic.
       HXn     Hold compressed mail traffic.
               for address number n in AKA list

       HFE     Hold tic's and associated files
               and file attaches other than mail
       HFn     Hold tic's and associated files
               and file attaches other than mail
               for address number n in AKA list

       HRQ     Hold file requests (not processed at this time)
               This  flag is presented if file request processing
               is disabled TEMPORARILY for any reason
       HRn     Hold file requests (not processed at this time)
               for address number n in AKA list

    Note that HXT,HRQ,HFE == HAT

   -eot-

You are viewing proxied material from gopher.altexxanet.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.