home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / reports / 1988.12 / text0010.txt < prev   
Encoding:
Text File  |  1989-01-07  |  9.3 KB  |  326 lines
  1. [ These Standards Updates are published after each IEEE 1003
  2. meeting, and are commissioned by the USENIX Association.
  3. See Part 1 for contact information.  -mod ]
  4.  
  5.  
  6.      An update on UNIX|= Standards Activities - Part 11
  7.  
  8.                     POSIX 1003.8 Update
  9.  
  10.                      December 18, 1988
  11.  
  12.            Shane P. McCarron, NAPS International
  13.  
  14. 1003.8 - Networking Extensions to POSIX
  15.  
  16. IEEE P1003.8's charter (not yet formally approved by IEEE,
  17. but pending) is to help develop an IEEE POSIX networking
  18. standard.  This was the committee's first formal meeting,
  19. and it was devoted mostly to organizational matters,
  20. particularly on setting specific technical goals and how to
  21. divide the work into subcommittees.
  22.  
  23. This working group has emerged out of the work done by the
  24. /usr/group Technical Committee's subcommittee on networking.
  25. Once this committee has been formally formed, the /usr/group
  26. networking committee will be considered to merge with the
  27. P1003.8 committee, and meet concurrently whenever P1003.8
  28. does.  Ultimately, the /usr/group committee is likely to
  29. disband completely in favor of P1003.8.
  30.  
  31. The charter ("project authorization request", or PAR) was
  32. reviewed briefly:
  33.  
  34.                            SCOPE
  35.  
  36.   1.  Define Network Services required by portable
  37.       applications consistent with existing and emerging
  38.       standards such as OSI.
  39.  
  40.   2.  Define interfaces to the network services defined
  41.       above, and where possible, language and protocol
  42.       independent programming interfaces.
  43.  
  44.   3.  Identify the requirements for new network
  45.       services/protocols and liason with appropriate
  46.       standards bodies (national and international) and
  47.       interested organizations when appropriate.
  48.  
  49. __________
  50.  
  51.   |= UNIX is a registered trademark of AT&T in the U.S. and
  52.     other countries.
  53.  
  54.  
  55.                            - 2 -
  56.  
  57.                           PURPOSE
  58.  
  59. Define and/or adopt a set of paradigms to permit the
  60. implementation of portable applications in a network
  61. environment.
  62.  
  63. Areas to be addressed by this committee include:
  64.  
  65.   A.  Interoperability between POSIX applications and non-
  66.       POSIX applications.
  67.  
  68.   B.  Bindings to OSI application layer services.
  69.  
  70.   C.  Identification of language requirements not
  71.       appropriate to applications portability, and liason
  72.       with appropriate standards bodies to ensure that
  73.       action is taken where appropriate.
  74.  
  75.   D.  The evaluation and definitions, where require, of
  76.       binding to lower layer OSI services.
  77.  
  78.   E.  The requirements to ensure interoperability among
  79.       POSIX-based distributed applications and services.
  80.  
  81.   F.  Network Services profile definitions for portable
  82.       applications (POSIX).
  83.  
  84. Subcommittee Organization
  85.  
  86. A poll was held to find out what the most important topics
  87. were as far as the group was concerned.  These turned out to
  88. be: process to process communication, directory services,
  89. network management, transparent file access, and remote
  90. procedure call.  Three main subcommittees were formed to
  91. look at some of these tasks.  Roughly, these committees were
  92. "interprocess communication", "remote procedure call", and
  93. "transparent file access".
  94.  
  95. Directory services and network management were recognized as
  96. important, but also as cutting across other functional
  97. areas.  Also, it was noted that there were not in attendance
  98. enough people with sufficient expertise in these topics to
  99. form a useful body of opinion on proposals in these areas.
  100.  
  101. Transaction processing was generally felt to be within the
  102. domain of the committee, but as a special case of remote
  103. procedure call.  It was noted that others who were not on
  104. the committee may feel otherwise.
  105.  
  106. The committee split up into subcommittees for a day to
  107. refine the definitions of the most important end products
  108.  
  109.  
  110.                            - 3 -
  111.  
  112. identified for the committee to concentrate on.
  113.  
  114. Specific Technical Goals
  115.  
  116. The following is a summary of what the committee as a whole
  117. agreed on as a result of the input from the individual
  118. subcommittees.
  119.  
  120.    o+ Transparent File Access
  121.  
  122.      It was decided that the products should be client-only
  123.      interfaces.  Three products were identified:
  124.  
  125.        1.  Full POSIX-semantic transparent file access
  126.            interface.  This would include previous
  127.            /usr/group DFS Committee work on DFS (distributed
  128.            file system).
  129.  
  130.        2.  Administrative interface to support (1).
  131.  
  132.        3.  Subset-semantic transparent file access
  133.            interfaces.  This could be vendor (e.g., MS-DOS,
  134.            Apple, etc.) or protocol (e.g., FTAM) specific.
  135.  
  136.      Work items identified so far include:
  137.  
  138.        1.  Definition of file operations
  139.  
  140.        2.  Liason to system administration; definitions of
  141.            transparent file access specific system
  142.            administrative utilities and/or interfaces
  143.  
  144.        3.  Liason with directory working group
  145.  
  146.        4.  "Appropriate approach" to the protocol invention
  147.            problem
  148.  
  149.      This group expects to finish relatively quickly (6
  150.      months or so was the estimate given), because it was
  151.      felt that a significant amount of the work needed to
  152.      produce standards in this area is already done by
  153.      definition (the P1003.1 standard).
  154.  
  155.    o+ Remote Procedure Call:
  156.  
  157.      The RPC folks apparently did not define their charter
  158.      so much as identify issues that need to be addressed.
  159.      The following was their list of issues along with
  160.      tentative resolutions (if any):
  161.  
  162.  
  163.                            - 4 -
  164.  
  165.        1.  Level of service
  166.  
  167.        2.  POSIX-to-POSIX versus POSIX-to-other (address
  168.            POSIX-to-other)
  169.  
  170.        3.  Language binding (initial target: C)
  171.  
  172.        4.  TP support
  173.  
  174.        5.  Connection re-use
  175.  
  176.        6.  Call-back/recursion
  177.  
  178.        7.  Compiler language
  179.  
  180.        8.  Data canonicalization
  181.  
  182.        9.  Authentication
  183.  
  184.       10.  Our scope versus X.500
  185.  
  186.       11.  Standard suite of services need to confer with
  187.            X3T5 on possible charter issues
  188.  
  189.       12.  Idempotency - execute once only guaranteed
  190.  
  191.       13.  Long running processes - keepalive/timeouts
  192.            probably needed
  193.  
  194.       14.  Crash recovery
  195.  
  196.       15.  Real Time issues - no real time interface
  197.  
  198.       16.  Directory services
  199.  
  200.       17.  Multiple protocol stacks
  201.  
  202.      The subgroup chose not to identify the next step in the
  203.      process (apparently meaning that they will wait for
  204.      proposals).
  205.  
  206.    o+ Interprocess Communication:
  207.  
  208.      Four products were identified:
  209.  
  210.        1.  Simple Protocol-Independent Network Interface
  211.  
  212.            Features:
  213.  
  214.           * Bidirectional byte stream virtual circuits
  215.  
  216.  
  217.                            - 5 -
  218.  
  219.           * Connectionless message exchange
  220.  
  221.           * Read/write support
  222.  
  223.           * Protocol-independent naming
  224.  
  225.           * Asynchronous communication services
  226.  
  227.           * Support for both client and server processes
  228.  
  229.           * POSIX-to-non-POSIX support
  230.  
  231.            Issues:
  232.  
  233.           * How to resolve names in a protocol-independent
  234.             manner?
  235.  
  236.           * What should the individual functions look like?
  237.  
  238.        2.  Simple Structured Data Network Interface
  239.  
  240.            Features:
  241.  
  242.            All of (1), with extensions for data description
  243.            and machine-independent representation.
  244.  
  245.           * Description of the syntactic structure of the
  246.             data; when you send the data, you reference the
  247.             structure.
  248.  
  249.           * Not all functions from (1) may work (such as,
  250.             read/write)
  251.  
  252.            Issues:
  253.  
  254.           * Structure alternatives: ASN.1, ...
  255.  
  256.           * C data structures (stub compilers)
  257.  
  258.        3.  Protocol-Option-Extended Network Interface
  259.  
  260.            Features:
  261.  
  262.           * Provides the ability to access protocol
  263.             dependent options
  264.  
  265.           * Migration path to potential future protocols
  266.  
  267.           * POSIX-to-any
  268.  
  269.  
  270.                            - 6 -
  271.  
  272.           * Virtual circuits, datagrams
  273.  
  274.            Issues:
  275.  
  276.           * Limited lifespan (?)
  277.  
  278.           * Limited utility
  279.  
  280.           * Usefulness as a migration tool
  281.  
  282.           * Relationship to (1)
  283.  
  284.        4.  OSI application level interface
  285.  
  286.            Features:
  287.  
  288.           * A family of interfaces with consistent style and
  289.             syntax which provides OSI application level
  290.             services, e.g.  FTAM, VT, ACSE, ROSE, ...
  291.  
  292.            Issues:
  293.  
  294.           * Complexity
  295.  
  296.           * Prioritization (which ones to focus on first)
  297.  
  298.      One issue that surfaced very quickly in the network IPC
  299.      discussions was the differences and relative merits of
  300.      sockets and XTI.  Some went as far as to say that the
  301.      differences were significant enough to guarantee
  302.      "religious wars" over the issue, and/or make any kind
  303.      of progress impossible in the area of product (3).
  304.  
  305.      Whatever the cause, a majority (8/0/3/3) of
  306.      participants expressed interest in working on product
  307.      (1), with products (3) and (4) having a relatively weak
  308.      level of interest.
  309.  
  310.      The committee will get down to serious business at the
  311.      next meeting (in January; 5 days).  For the next
  312.      meeting, proposals are being solicited in all areas.
  313.      The Usenix Standards Watchdog Committee contact on this
  314.      committee is Stephen Head.  He can be reached at:
  315.  
  316.                Stephen Head
  317.                Hewlett Packard
  318.                263 Mackintosh St.
  319.                Fremont, CA  94539
  320.                +1 (408) 447-2740
  321.                smh@hpda.hp.com
  322.                uunet!hpda!smh
  323.  
  324. Volume-Number: Volume 15, Number 54
  325.  
  326.