# Compatibility and Link Qualifier Extensions for EMSI Sessions

      | 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  robert@ecs.mtlnet.org

        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

Go Back