doc: Add RFC documents

1 files changed, 1795 insertions, 0 deletions

diff --git a/doc/rfc/rfc1085.txt b/doc/rfc/rfc1085.txt
new file mode 100644
index 0000000..d4e5ef2
--- /dev/null
+++ b/doc/rfc/rfc1085.txt
@@ -0,0 +1,1795 @@
+
+
+
+
+
+
+Network Working Group                                            M. Rose
+Request for Comments: 1085                                           TWG
+                                                           December 1988
+
+
+                       ISO Presentation Services
+                    on top of TCP/IP-based internets
+
+Status of this Memo
+
+   This memo proposes a standard for the Internet community.
+   Distribution of this memo is unlimited.
+
+1. Introduction
+
+   [RFC1006] describes a mechanism for providing the ISO transport
+   service on top of the Transmission Control Protocol (TCP) [RFC793]
+   and Internet Protocol (IP) [RFC791].  Once this method is applied,
+   one may implement "real" ISO applications on top of TCP/IP-based
+   internets, by simply implementing OSI session, presentation, and
+   application services on top of the transport service access point
+   which is provided on top of the TCP.  Although straight-forward,
+   there are some environments in which the richness provided by the OSI
+   application layer is desired, but it is nonetheless impractical to
+   implement the underlying OSI infrastructure (i.e., the presentation,
+   session, and transport services on top of the TCP).  This memo
+   describes an approach for providing "stream-lined" support of OSI
+   application services on top of TCP/IP-based internets for such
+   constrained environments.
+
+2. Terminology
+
+   In as much as this memo is concerned primarily with concepts defined
+   in the framework of Open Systems Interconnection (OSI) as promulgated
+   by the International Organization for Standardization (ISO), the
+   terminology used herein is intended to be entirely consistent within
+   that domain of discourse.  This perspective is being taken despite
+   the expressed intent of implementing the mechanism proposed by this
+   memo in the Internet and other TCP/IP-based internets.  For those
+   more familiar with the terminology used in this latter domain, the
+   author is apologetic but unyielding.
+
+   Although no substitute for the "correct" definitions given in the
+   appropriate ISO documents, here is a short summary of the terms used
+   herein.
+
+
+
+
+
+
+Rose                                                            [Page 1]
+
+RFC 1085               ISO Presentation Services           December 1988
+
+
+      Application Context:
+         The collection of application service elements which
+         cooperatively interact within an application-entity.
+
+      Application Service Element:
+         A standardized mechanism, defined by both a service and a
+         protocol, which provides a well-defined capability, e.g.,
+
+         ROSE -  the Remote Operations Service Element,
+                 which orchestrates the invocation of "total"
+                 operations between application-entities [ISO9066/2].
+
+         ACSE -  the Association Control Service Element,
+                 which manages associations between application
+                 entities [ISO8650].
+
+      Object Identifier:
+         An ordered set of integers, used for authoritative
+         identification.
+
+      Presentation Service:
+         A set of facilities used to manage a connection between two
+         application-entities.  The fundamental responsibility of the
+         presentation service is to maintain transfer syntaxes which
+         are used to serialize application protocol data units for
+         transmission on the network and subsequent de-serialization
+         for reception.
+
+      Protocol Data Unit (PDU):
+         A data object exchanged between service providers.
+
+      Serialization:
+         The process of applying an abstract transfer notation to an
+         object described using abstract syntax notation one (ASN.1)
+         [ISO8824] in order to produce a stream of octets.
+         De-serialization is the inverse process.
+
+         It is assumed that the reader is familiar with terminology
+         pertaining to the reference model [ISO7498], to the service
+         conventions in the model [ISO8509], and to the
+         connection-oriented presentation service [ISO8822].
+
+3. Scope
+
+   The mechanism proposed by this memo is targeted for a particular
+   class of OSI applications, namely those entities whose application
+   context contains only an Association Control Service Element (ACSE)
+   and a Remote Operations Service Element (ROSE).  In addition, a
+
+
+
+Rose                                                            [Page 2]
+
+RFC 1085               ISO Presentation Services           December 1988
+
+
+   Directory Services Element (DSE) is assumed for use by the
+   application-entity, but only in a very limited sense.  The
+   organization of such an entity is as follows:
+
+
+      +------------------------------------------------------------+
+      |                                                            |
+      |                     Application-Entity                     |
+      |                                                            |
+      |    +------+              +------+              +------+    |
+      |    | ACSE |              | ROSE |              | DSE  |    |
+      |    +------+              +------+              +------+    |
+      |                                                            |
+      +------------------------------------------------------------+
+      |                                                            |
+      |                Presentation Services                       |
+      |                                                            |
+      |    P-CONNECT         P-RELEASE         P-DATA              |
+      |                      P-U-ABORT                             |
+      |                      P-P-ABORT                             |
+      |                                                            |
+      +------------------------------------------------------------+
+
+
+   The mechanism proposed by this memo is not applicable to entities
+   whose application context is more extensive (e.g., contains a
+   Reliable Transfer Service Element).  The mechanism proposed by this
+   memo could be modified to support additional elements.  However, such
+   extensions would, at this time, merely serve to defeat the purpose of
+   providing the minimal software infrastructure required to run the
+   majority of OSI applications.
+
+   The motivation for this memo was initially derived from a requirement
+   to run the ISO Common Management Information Protocol (CMIP) in
+   TCP/IP-based internets.  In its current definition, CMIP uses
+   precisely the application service elements provided for herein.  It
+   may be desirable to offer CMIP users a quality of service different
+   than the one offered by a connection with a high-quality level of
+   reliability.  This would permit a reduced utilization of connection-
+   related resources.  This memo proposes a mechanism to implement this
+   less robust -- and less costly -- quality of service.
+
+4. Approach
+
+   The approach proposed by this memo relies on the following
+   architectural nuances:
+
+
+
+
+
+Rose                                                            [Page 3]
+
+RFC 1085               ISO Presentation Services           December 1988
+
+
+     - the TCP is a stream-oriented transport protocol
+
+     - ASN.1 objects, when represented as a stream of octets are
+       self-delimiting
+
+     - The ISO presentation service permits the exchange of ASN.1
+       objects
+
+     - The ACSE and ROSE require the following presentation
+       facilities:
+
+           The Connection Establishment Facility
+
+           The Connection Termination Facility
+
+           The Information Transfer Facility (P-DATA
+           service only)
+
+     - The majority of the parameters used by the services which
+       provide these facilities can be "hard-wired" to avoid
+       negotiation
+
+   In principle, these nuances suggest that a "cheap" emulation of the
+   ISO presentation services could be implemented by simply serializing
+   ASN.1 objects over a TCP connection.  This approach is precisely what
+   is proposed by this memo.
+
+   Given this perspective, this memo details how the essential features
+   of the ISO presentation service may be maintained while using a
+   protocol entirely different from the one given in [ISO8823]. The
+   overall composition proposed by this memo is as follows:
+
+
+   +-----------+                                       +-----------+
+   |  PS-user  |                                       |  PS-user  |
+   +-----------+                                       +-----------+
+        |                                                     |
+        | PS interface                           PS interface |
+        |  [ISO8822]                                          |
+        |                                                     |
+   +----------+   ISO Presentation Services on the TCP  +----------+
+   |  client  |-----------------------------------------|  server  |
+   +----------+              (this memo)                +----------+
+        |                                                     |
+        | TCP interface                         TCP interface |
+        |  [RFC793]                                           |
+        |                                                     |
+
+
+
+
+Rose                                                            [Page 4]
+
+RFC 1085               ISO Presentation Services           December 1988
+
+
+   In greater detail, the "client" and "server" boxes implement the
+   protocol described in this memo.  Each box contains three modules:
+
+      - a dispatch module, which provides the presentation services
+        interface,
+
+      - a serialization module, containing a serializer, which takes
+        an ASN.1 object and applies the encoding rules of [ISO8825]
+        to produce a stream of octets, and a de-serializer, which
+        performs the inverse operation, and
+
+      - a network module, which manages a TCP connection.
+
+   The software architecture used to model a network entity using this
+   approach is as follows:
+
+
+   +---------+    +----------+                                   +-----+
+   |         |    |          |  output +---------------+  input  |  n  |
+   |         |    |          |<--------| de-serializer |<--------|  e  |
+   |         |    |          |   queue +---------------+  queue  |  t  |
+   | PS-user |----| dispatch |                                   |  w  |
+   |         |    |          |  input  +---------------+ output  |  o  |
+   |         |    |          |-------->|   serializer  |-------->|  r  |
+   |         |    |          |  queue  +---------------+ queue   |  k  |
+   +---------+    +----------+                                   +-----+
+
+                                 |---- serialization module ----|
+
+
+   The ISO presentation layer is concerned primarily with the
+   negotiation of transfer syntaxes in addition to the transformation to
+   and from transfer syntax.  However, using the mechanism proposed by
+   this memo, no negotiation component will be employed.  This memo
+   specifies the fixed contexts which exist over each presentation
+   connection offered.  This memo further specifies other constants
+   which are used in order to eliminate the need for presentation layer
+   negotiation.
+
+5. Fundamental Parameters
+
+   There are certain parameters which are used by the presentation
+   service and are defined here.
+
+      1. Presentation address:
+
+      The structure of a presentation address is presented in Addendum 3
+      to [ISO7498].  This memo interprets a presentation address as an
+
+
+
+Rose                                                            [Page 5]
+
+RFC 1085               ISO Presentation Services           December 1988
+
+
+      ordered-tuple containing:
+
+         - one or more network addresses
+         - a transport selector
+         - a session selector
+         - a presentation selector
+
+      Each selector is an uninterpreted octet string of possibly zero
+      length.  The mechanism proposed in this memo completely ignores
+      the values of these selectors.  Note however that the value of the
+      presentation selector is preserved by the provider.
+
+      A network address is interpreted as containing three components:
+
+         - a 32-bit IP address
+
+         - a set indicating which transport services are available
+           at the IP address  (currently only two members are defined:
+           TCP and UDP; as experience is gained, other transport
+           services may be added); as a local matter, if a member is
+           present it may have an "intensity" associated with it:
+           either "possibly present" or "definitely present"
+
+         - a 16-bit port number
+
+      As a consequence of these interpretations, any application-entity
+      residing in the network can be identified by its network address.
+
+      2. Presentation context list
+
+      A list of one or more presentation contexts.  Each presentation
+      context has three components:
+
+         - a presentation context identifier (PCI), an integer
+
+         - an abstract syntax name, an object identifier
+
+         - an abstract transfer name, an object identifier
+
+      The range of values these components may take is severely
+      restricted by this memo.  In particular, exactly two contexts are
+      defined: one for association control and the other for the
+      specific application service element which is being carried as ROS
+      APDUs (see the section on connection establishment for the precise
+      values).
+
+      In addition, if the presentation context list appears in a
+      "result" list (e.g., the Presentation context result list
+
+
+
+Rose                                                            [Page 6]
+
+RFC 1085               ISO Presentation Services           December 1988
+
+
+      parameter for the P-CONNECT service), a fourth component is
+      present:
+
+         - an acceptance indicator
+
+      which indicates if the context was accepted by both the service
+      provider and the remote peer.  If the context was not accept, a
+      brief reason, such as "abstract syntax not supported" is given.
+
+      For the novice reader, one might think of the abstract syntax
+      notation as defining the vocabulary of some language, that is, it
+      lists the words which can be spoken.  In contrast, the abstract
+      transfer notation defines the pronunciation of the language.
+
+      3. User data
+
+      User data passes through the presentation service interface as
+      ASN.1 objects (in a locally defined form).  Associated with each
+      object is a presentation context identifier.  The PCI
+      distinguishes the context for which the data is intended.  The
+      range of values the PCI may take is severely restricted by this
+      memo.  Exactly one of two contexts must always be used: either the
+      value for the ACSE presentation context or the value for the ROSE.
+
+      4. Quality of Service
+
+      Quality of service is a collection of "elements".  Each element
+      denotes some characteristics of the communication, e.g., desired
+      throughput, and some value in an arbitrary unit of measure.  For
+      our purposes, only one quality of service element is interpreted,
+      "transport-mapping".  Currently, the "transport-mapping" element
+      takes on one of two values: "tcp-based" or "udp-based".  At
+      present, the two values may also be referred to as "high-quality"
+      or "low-quality", respectively.
+
+      As experience is gained, other values may be added.  These values
+      would correspond directly to the new transport services which are
+      listed in the network address.
+
+      5. Version of Session Service
+
+      Some application service elements (e.g., the ACSE) invoke
+      different procedures based on the (negotiated) version of the
+      session service available.  Implementations of this memo always
+      indicate that session service version 2 has been negotiated.
+
+
+
+
+
+
+Rose                                                            [Page 7]
+
+RFC 1085               ISO Presentation Services           December 1988
+
+
+6. Choice of Transport Service
+
+   Discussion thus far has centered along the use of the TCP as the
+   underlying transport protocol.  However, it has also been noted that
+   it may be desirable to permit a quality of service with less
+   reliability in order to take advantage of some other characteristic
+   of the transport service.
+
+   The introduction of this service has several profound impacts on the
+   model, and it is beyond the scope of this memo to enumerate these
+   impacts.  However, this memo does propose a mechanism by which such a
+   facility is implemented.
+
+   To begin, we use the quality of service parameter for the P-CONNECT
+   service to select an underlying transport service.  Only one element
+   is currently interpreted, "transport-mapping" which takes the value
+   "tcp-based" or "udp-based".  If the value is "tcp-based", then the
+   presentation provider will use TCP as the underlying transport
+   service. If, however, the value of "transport-mapping" is "udp-
+   based", then the presentation provider will use the UDP instead.
+
+   The User Datagram Protocol (UDP) [RFC768] is used to implement the
+   udp-based service.  Very few transport-level facilities are placed on
+   top of the UDP service, i.e., it is not the intent of this memo to
+   "re-invent" the facilities in the TCP.  Hence, It is critical to
+   understand that
+
+           low-quality means LOW-QUALITY!
+
+   Because the UDP is a packet-oriented protocol, it is necessary to
+   slightly redefine the role of the serialization module.  For the
+   serializer, we say that each top-level ASN.1 object placed on the
+   input queue will form a single UDP datagram on the output queue which
+   is given to the network.  Similarly, for the de-serializer, we say
+   that each UDP datagram placed on the input queue from the network
+   will form a single top-level ASN.1 object placed on the output queue.
+   The term "top-level ASN.1 object" refers, of course, to the protocol
+   data units being exchanged by the presentation providers.
+
+   It should be noted that in its current incarnation, this memo permits
+   the choice of two different transport protocols, e.g., the TCP or the
+   UDP.  However, as experience is gained and as other transport
+   protocols are deployed (e.g., the VMTP), then future incarnations of
+   this memo will permit these transport protocols to be used.  This is
+   a three step process: first, the set of transport services defined
+   for the network address is updated; second, a corresponding value is
+   added to the range of the quality of service element "transport-
+   mapping"; and, third, the following sections of this memo are
+
+
+
+Rose                                                            [Page 8]
+
+RFC 1085               ISO Presentation Services           December 1988
+
+
+   modified accordingly.
+
+7. Connection Establishment
+
+   The Connection Establishment facility consists of one service, the
+   P-CONNECT service.
+
+7.1. The P-CONNECT Service
+
+   This service is used to bring two identified application-entities
+   into communication.  Its successful use results in a presentation
+   connection, with an initial defined context set, being established
+   between then.  This connection is available for their subsequent
+   communication.  This is a confirmed service whose effects are
+   sequenced and non-destructive.
+
+   If the udp-based service is selected, then a presentation connection
+   is formed which should be used infrequently and will have minimal
+   reliability characteristics.
+
+   For our purposes, the P-CONNECT service:
+
+      - requests TCP or UDP resources,
+
+      - builds a fixed defined context set, and
+
+      - exchanges initial user data.
+
+   Following are the interpretation of and the defaults assigned to the
+   parameters of the P-CONNECT service:
+
+      1. Calling Presentation Address
+
+        This is a presentation address.  Although the ISO presentation
+        service states that this parameter is mandatory, in practice, a
+        local implementation rule may be used to determine an
+        "ephemeral" address to use.
+
+      2. Called Presentation Address
+
+        This is a presentation address.  Note that when issuing the P-
+        CONNECT.REQUEST primitive, this parameter may contain more than
+        one network address.  In the P-CONNECT.INDICATION primitive
+        however, only one network address, the one actually used to
+        establish the presentation connection, is present.  (Appendix C
+        describes a strategy which might be used to determine the actual
+        network address).
+
+
+
+
+Rose                                                            [Page 9]
+
+RFC 1085               ISO Presentation Services           December 1988
+
+
+      3. Responding Presentation Address
+
+        This parameter is identical to the value of the Called
+        Presentation Address parameter of the P-CONNECT.INDICATION
+        primitive.
+
+      4. Multiple defined Contexts
+
+        Always TRUE.  Note that this parameter is present only in the
+        DIS version of the presentation service.
+
+      5. Presentation context definition list
+
+      Two contexts are defined:
+
+      PCI     Abstract Syntax Name            Abstract Transfer Name
+      ---     --------------------            ----------------------
+       1      specific to the application     "iso asn.1 abstract
+                                              transfer"
+                                              1.0.8825
+
+       3      "acse pci version 1"            "iso asn.1 abstract
+                                              transfer"
+              2.2.1.0.0                       1.0.8825
+
+      The abstract syntax and transfer names for the ACSE PCI are for
+      use with the DIS version of association control.  If the IS
+      version is being used, then this PCI is used instead:
+
+       3      "acse pci version 1"            "asn.1 basic encoding"
+              2.2.1.0.1                       2.1.1
+
+      6. Presentation context result list
+
+        Identical to the Presentation context definition list with the
+        addition that the acceptance indicator for both contexts is
+        "accepted".
+
+      7. Default Context Name
+
+        None.
+
+      8. Default Context Result
+
+        Not applicable.
+
+
+
+
+
+
+Rose                                                           [Page 10]
+
+RFC 1085               ISO Presentation Services           December 1988
+
+
+      9. Quality of Service
+
+        The element "transport-mapping" takes the value "tcp-based" or
+        "udp-based".  In the future the range of values may be extended.
+
+      10. Presentation Requirements
+
+        None (the kernel functional unit is always used).
+
+      11. Session Requirements
+
+        Full duplex.
+
+      12. Initial synchronization point serial number
+
+        None.
+
+      13. Initial Assignment of tokens
+
+        None.
+
+      14. Session connection identifier
+
+        Unlike the "real" presentation service, depending on the quality
+        of service selected, this parameter may have great significance
+        to presentation provider.  Hence, the following format of the
+        session connection identifier is mandated by this memo.
+
+        user data:        a local string encoded as a T.61 string
+                          using ASN.1, e.g., given string "gonzo":
+
+                          14     05     67   6f   6e   7a   6f
+                          tag  length   "g"  "o"  "n"  "z"  "o"
+
+        common data:      a universal time encoding using ASN.1, e.g.,
+                          given time "880109170845":
+
+                          17     0c     38   38   30   31   30   ...
+                          tag  length   "8"  "8"  "0"  "1"  "0"  ...
+
+        additional data:  any string encoded as a T.61 string using ASN.1
+                          (optional)
+
+        As a local convention, the presentation provider may disregard
+        the first two octets of each data component for transmission on
+        the network as when the session connection identifier is
+        represented with ASN.1, the tag and length octets will be added
+        anyway.
+
+
+
+Rose                                                           [Page 11]
+
+RFC 1085               ISO Presentation Services           December 1988
+
+
+      15. User Data
+
+        A single ASN.1 object is present, the appropriate A-ASSOCIATE
+        PDU, carried in presentation context 3.
+
+      16. Result
+
+        One of the following values: acceptance, user-rejection,
+        provider-rejection (transient), or provider-rejection
+        (permanent).
+
+8. Connection Termination
+
+   The Connection Termination facility consists of three services, the
+   P-RELEASE, P-U-ABORT, and P-P-ABORT services.
+
+8.1. The P-RELEASE Service
+
+   This service provides the service user with access to a negotiated
+   release facility.  This service has effects which are sequenced and
+   non-destructive.  Either presentation user is permitted to request
+   this service.  However, in the event of collision, a provider-
+   initiated abort procedure will be invoked.
+
+   If the udp-based service is selected, then any data in transit may be
+   discarded.
+
+      For our purposes, the P-RELEASE service:
+
+      - waits for the serialization module to drain,
+
+      - sends release user data, and
+
+      - releases TCP or UDP resources
+
+   Following are the interpretation of and the defaults assigned to the
+   parameters of the P-RELEASE service:
+
+      1. Result
+
+        Release accepted.
+
+      2. User data
+
+        A single ASN.1 object is present, the appropriate A-RELEASE PDU,
+
+
+
+
+
+
+Rose                                                           [Page 12]
+
+RFC 1085               ISO Presentation Services           December 1988
+
+
+8.2. The P-U-ABORT Service
+
+   This service can be used by either presentation user to force the
+   release of a presentation connection at any time and have the
+   correspondent presentation user informed of this termination.  This
+   service has effects which are not sequenced with respect to preceding
+   service invocations and may be destructive.  It does not require the
+   agreement of both service users.
+
+      For our purposes, the P-U-ABORT service:
+
+      - flushes the serialization module,
+
+      - sends abort user data, and
+
+      - releases TCP or UDP resources
+
+   Following are the interpretation of and the defaults assigned to the
+   parameters of the P-U-ABORT service:
+
+      1. Presentation context identifier list
+
+        Contained in the ASN.1 objects, if any, that are delivered as
+        user data.
+
+      2. User data
+
+        A single ASN.1 object is present, an A-ABORT PDU, carried in
+        presentation context 3.
+
+8.3. The P-P-ABORT Service
+
+   This service is the means by which the service provider may indicate
+   the termination of the presentation connection for reasons internal
+   to the service provider.  This service has effects which are not
+   sequenced with respect to preceding service invocations.  The
+   execution of this service disrupts any other concurrently active
+   service and may thus be destructive.
+
+      For our purposes, the P-P-ABORT service:
+
+      - flushes the serialization module, and
+
+      - releases TCP or UDP resources
+
+   Following are the interpretation of and the defaults assigned to the
+   parameters of the P-P-ABORT service.
+
+
+
+
+Rose                                                           [Page 13]
+
+RFC 1085               ISO Presentation Services           December 1988
+
+
+      1. Provider reason
+
+        An integer code detailing why the connection was aborted. Codes
+        include, but are not limited to: invalid PPDU parameter,
+        unexpected PPDU, unrecognized PPDU, and specified reason.
+
+      2. Abort data
+
+        None.
+
+9. Information Transfer
+
+   Although the Information Transfer facility consists of many services,
+   only one, the P-DATA service, is provided by this memo.
+
+9.1. The P-DATA Service
+
+   This services provides the service user with a data transfer
+   capability.  This service has effects which are sequenced and non-
+   destructive.
+
+   If the udp-based service is selected, then there is an upper-bound on
+   the size of the serialized ASN.1 objects which may be transmitted.
+   This limit, imposed by the UDP, is 65536 octets.  As a practical
+   matter, it is probably a good idea to keep datagrams less than or
+   equal to 536 octets in size.
+
+   For our purposes, the P-DATA service:
+
+              - sends user data
+
+   Following are the interpretation of and the defaults assigned to the
+   parameters of the P-DATA service:
+
+      1. User data
+
+        A single ASN.1 object is present, a remote operations APDU,
+        carried in presentation context 1.
+
+10. Elements of Procedure
+
+   The service provider is in one of the following states:
+
+           IDLE, WAIT1, WAIT2, DATA, WAIT3, or WAIT4
+
+        The possible events are:
+
+           PS-user         P-CONNECT.REQUEST
+
+
+
+Rose                                                           [Page 14]
+
+RFC 1085               ISO Presentation Services           December 1988
+
+
+                           P-CONNECT.RESPONSE
+                           P-RELEASE.REQUEST
+                           P-RELEASE.RESPONSE
+                           P-DATA.REQUEST
+                           P-U-ABORT.REQUEST
+
+           network         TCP closed or errored(*)
+                           receive ConnectRequest PDU
+                           receive ConnectResponse PDU
+                           receive ReleaseRequest PDU
+                           receive ReleaseResponse PDU
+                           receive UserData(*) or CL-UserData(**) PDU
+                           receive user-initiated Abort PDU
+                           receive provider-initiated Abort PDU
+                           timer expires(**)
+
+
+        The possible actions are:
+
+           PS-user         P-CONNECT.INDICATION
+                           P-CONNECT.CONFIRMATION
+                           P-RELEASE.INDICATION
+                           P-RELEASE.CONFIRMATION
+                           P-DATA.INDICATION
+                           P-U-ABORT.INDICATION
+                           P-P-ABORT.INDICATION
+
+           network         open TCP(*)
+                           close TCP(*)
+                           send ConnectRequest PDU
+                           send ConnectResponse PDU
+                           send ReleaseRequest PDU
+                           send ReleaseResponse PDU
+                           send UserData(*) or CL-UserData(**) PDU
+                           send user-initiated Abort PDU
+                           send provider-initiated Abort PDU
+                           set timer(**)
+
+           (*)   tcp-based service only
+           (**)  udp-based service only
+
+10.1. Elements of Procedure specific to the tcp-based service
+
+   The provider maintains the following information for each
+   presentation connection:
+
+      - a local designator for the PS-user
+
+
+
+
+Rose                                                           [Page 15]
+
+RFC 1085               ISO Presentation Services           December 1988
+
+
+      - a local designator for a TCP connection
+
+      - the state of the connection (e.g., IDLE, WAIT1, and so on)
+
+   Upon receiving an event from the network, the provider finds the
+   associated presentation connection.  Matching is done by simply
+   comparing local designators for the TCP connection.  Whenever a
+   connection remains in or returns to the IDLE state, any associated
+   resources, such as an attachment to a local TCP port, are released.
+
+   In the procedures which follow, outgoing PDUs are "placed on the
+   input queue for the serializer".  This has a different meaning
+   depending on the type of PDU being enqueued.  If the PDU is not an
+   abort PDU (user-initiated or provider-initiated), then the PDU is
+   simply appended to the input queue regardless of the number of PDUs
+   present.  If however, the PDU is an abort PDU, then the provider
+   checks the size of the input queue.  If the input queue is non-empty
+   or if the serializer is busy transmitting to the network, then the
+   abort PDU is discarded, and the serializer is flushed, aborting any
+   output to the network in progress.  However, if the input queue is
+   empty, then the Abort PDU is appended to the queue, and a small timer
+   started.  If the timer expires before the PDU has been serialized and
+   transmitted, then the serializer is flushed, aborting any output to
+   the network in progress.
+
+   Further, in general, whenever the TCP connection is closed (either
+   locally by the provider, or remotely by the network) or has errored,
+   the serializer is flushed.  The one exception to this is if a
+   ReleaseResponse PDU is being serialized and transmitted to the
+   network.  In this case, the provider will not close the TCP
+   connection until after the serializer has finished.
+
+10.2. Elements of Procedure specific to the udp-based service
+
+   The provider maintains the following information for each
+   presentation connection:
+
+      - a local designator for the PS-user
+
+      - the 32-bit IP address and 16-bit UDP port number of the
+        initiating host
+
+      - the 32-bit IP address and 16-bit UDP port number of the
+        responding host
+
+      - the session connection identifier used to establish the
+        presentation connection
+
+
+
+
+Rose                                                           [Page 16]
+
+RFC 1085               ISO Presentation Services           December 1988
+
+
+      - a local designator for an UDP endpoint
+
+      - the state of the connection (e.g., IDLE, WAIT1, and so on)
+
+      - a retransmission counter
+
+   Upon receiving an event from the network, the provider finds the
+   associated presentation connection.  Matching is done on the basis of
+   addresses, ports, and the session connection identifier (i.e., two
+   different presentation connections may differ only in their session
+   connection identifier).  If no presentation connection can be found,
+   then for the purposes of discussion, it may be assumed that a
+   "vanilla" presentation connection is created and initialized to the
+   IDLE state.  Further, whenever a connection remains in or returns to
+   the IDLE state, any associated resources, such as an attachment to a
+   local UDP port, are released.
+
+   In the procedures which follow, outgoing PDUs are "placed on the
+   input queue for the serializer".  This means that the ASN.1 object is
+   serialized and the resulting sequence of octets is sent as a single
+   UDP datagram.
+
+10.3. State Transitions
+
+   Following are the rules for transitioning states.  If an event
+   associated with a user-generated primitive is omitted, then it is an
+   interface error for the user to issue that primitive in the given
+   state.  Each state considers all possible incoming PDUs.
+
+   We assume that for the tcp-based service, that some entity starts a
+   passive TCP open.  When the passive open completes, the entity, using
+   some local rule, locates a PS-user to be associated with the incoming
+   presentation connection.  This presentation connection is then placed
+   in the IDLE state.  The entity then continues listening for other
+   passive opens to complete.  The mechanisms associated with this
+   entity are entirely a local matter, the concept of this listener is
+   introduced solely as a modeling artifact.
+
+   Finally, if the udp-based service is selected, then CL-UserData PDUs
+   are exchanged by the provider instead of UserData PDUs.
+
+
+                                    IDLE state
+
+        Event:     P-CONNECT.REQUEST primitive issued
+
+   Based on the quality of service parameter and the list of network
+   addresses in the called presentation address parameter, the provider
+
+
+
+Rose                                                           [Page 17]
+
+RFC 1085               ISO Presentation Services           December 1988
+
+
+   selects an address for the use of the presentation connection.  The
+   method for making this determination is a local matter.  (Appendix C
+   discusses a strategy which might be used.)  For the discussion that
+   follows, we assume that a network address supporting the desired
+   quality of service has been determined.
+
+   Based on the network address chosen from the called presentation
+   address parameter, the provider selects a compatible network address
+   from the calling presentation address parameter.  The provider
+   attaches itself to the port associated with this network address.
+   (By local determination, this address need not be used, and an
+   "ephemeral" port may be chosen by the provider.)
+
+   For the tcp-based service, the provider attempts to establish a TCP
+   connection to the network address listed in the called presentation
+   address.  If the connection can not be established, the P-
+   CONNECT.CONFIRMATION(-) primitive is issued with a reason of
+   provider-rejection, and the provider remains in the IDLE state.
+
+   Regardless, the user data parameter is placed in a ConnectRequest
+   PDU, which is put on the input queue for the serializer.
+
+   For the udp-based service, the provider sets the retransmission
+   counter to a small value (e.g., 2), and now starts a small timer.
+
+   Regardless, the provider enters the WAIT1 state.
+
+
+        Event:     ConnectRequest PDU received
+
+   The provider issues the P-CONNECT.INDICATION primitive and enters the
+   WAIT2 state.
+
+
+        Event:     any other PDU received
+
+   If the PDU is not an Abort PDU, the provider constructs a provider-
+   initiated Abort PDU, which is put on the input queue for the
+   serializer.  Regardless, the provider remains in the IDLE state.
+
+
+                                    WAIT1 state
+
+        Event:     P-U-ABORT.REQUEST primitive issued
+
+   The user data parameter is placed in an Abort PDU, which is put on
+   the input queue for the serializer.  The provider enters the IDLE
+   state.
+
+
+
+Rose                                                           [Page 18]
+
+RFC 1085               ISO Presentation Services           December 1988
+
+
+        Event:     ConnectResponse PDU received
+
+   For the udp-based service, the timer is cancelled.  If the PDU
+   indicates rejection, the P-CONNECT.CONFIRMATION(-) primitive is
+   issued and the provider enters the IDLE state.  Otherwise, the P-
+   CONNECT.CONFIRMATION(+) primitive is issued and the provider enters
+   the DATA state.
+
+
+        Event:     user-initiated Abort PDU received
+
+   The provider issues the P-U-ABORT.INDICATION primitive and enters the
+   IDLE state.
+
+
+        Event:     any other PDU received
+
+   If the PDU not an Abort PDU, the provider constructs a provider-
+   initiated Abort PDU, which is put on the input queue for the
+   serializer.  Regardless, The provider issues the P-P-ABORT.INDICATION
+   primitive and enters the the IDLE state.
+
+
+        Event:     timer expires
+
+   The provider decrements the retransmission counter.  If the resulting
+   value is less than or equal to zero, the provider issues the P-
+   CONNECT.CONFIRMATION(-) primitive and enters the IDLE state.
+   Otherwise, a ConnectRequest PDU is put on the input queue for the
+   serializer, the small timer is started again, and the provider
+   remains in the WAIT1 state.
+
+
+                                    WAIT2 state
+
+        Event:     P-CONNECT.RESPONSE primitive issued
+
+   The user data parameter is placed in a ConnectResponse PDU, which is
+   put on the input queue for the serializer.  If the result parameter
+   had the value user-rejection, the provider enters the IDLE state.
+   Otherwise if the parameter had the value acceptance, the provider
+   enters the DATA state.
+
+
+
+
+
+
+
+
+
+Rose                                                           [Page 19]
+
+RFC 1085               ISO Presentation Services           December 1988
+
+
+        Event:     P-U-ABORT.REQUEST primitive issued
+
+   The user data parameter is placed in an Abort PDU, which is put on
+   the input queue for the serializer.  The provider enters the IDLE
+   state.
+
+
+        Event:     user-initiated Abort PDU received
+
+   The provider issues the P-U-ABORT.INDICATION primitive and enters the
+   IDLE state.
+
+
+        Event:     any other PDU received
+
+   If the PDU is not an Abort PDU, the provider constructs a provider-
+   initiated Abort PDU, which is put on the input queue for the
+   serializer.  Regardless, The provider issues the P-P-ABORT.INDICATION
+   primitive and enters the the IDLE state.
+
+
+                                    DATA state
+
+        Event:     P-DATA.REQUEST primitive issued
+
+   The user data parameter is placed in a UserData PDU, which is put on
+   the input queue for the serializer.  The provider remains in the DATA
+   state.
+
+
+        Event:     P-RELEASE.REQUEST primitive issued
+
+   The user data parameter is placed in a ReleaseRequest PDU, which is
+   put on the input queue for the serializer.
+
+   For the udp-based service, the provider sets the retransmission
+   counter to a small value (e.g., 2), and now starts a small timer.
+
+   Regardless, the provider enters the WAIT3 state.
+
+
+        Event:     P-U-ABORT.REQUEST primitive issued
+
+   The user data parameter is placed in an Abort PDU, which is put on
+   the input queue for the serializer.  The provider enters the IDLE
+   state.
+
+
+
+
+
+Rose                                                           [Page 20]
+
+RFC 1085               ISO Presentation Services           December 1988
+
+
+        Event:     UserData PDU received
+
+   The provider issues the P-DATA.INDICATION primitive and remains in
+   the DATA state.
+
+
+        Event:     ReleaseRequest PDU received
+
+   The provider issues the P-RELEASE.INDICATION primitive, and enters
+   the WAIT4 state.
+
+
+        Event:     user-initiated Abort PDU received
+
+   The provider issues the P-U-ABORT.INDICATION primitive and enters
+    the IDLE state.
+
+
+        Event:     any other PDU received
+
+   If the PDU is not an Abort PDU, the provider constructs a provider-
+   initiated Abort PDU, which is put on the input queue for the
+   serializer.  Regardless, the provider issues the P-P-ABORT.INDICATION
+   primitive and enters the the IDLE state.
+
+
+                                    WAIT3 state
+
+        Event:     P-U-ABORT.REQUEST primitive issued
+
+   The user data parameter is placed in an Abort PDU, which is put on
+   the input queue for the serializer.  The provider enters the IDLE
+   state.
+
+
+        Event:     ReleaseResponse PDU received
+
+   For the udp-based service, the timer is cancelled.  The provider
+   issues the P-RELEASE.CONFIRMATION primitive and enters the IDLE
+   state.
+
+
+        Event:     user-initiated Abort PDU received
+
+   The provider issues the P-U-ABORT.INDICATION primitive and enters the
+   IDLE state.
+
+
+
+
+
+Rose                                                           [Page 21]
+
+RFC 1085               ISO Presentation Services           December 1988
+
+
+        Event:     any other PDU received
+
+   If the PDU is not an Abort PDU, the provider constructs a provider-
+   initiated Abort PDU, which is put on the input queue for the
+   serializer.  Regardless, the provider issues the P-P-ABORT.INDICATION
+   primitive and enters the the IDLE state.
+
+
+        Event:     timer expires
+
+   The provider decrements the retransmission counter.  If the resulting
+   value is less than or equal to zero, the provider constructs a
+   provider-initiated Abort PDU, which is put on the input queue for the
+   serializer.  It then issues the P-P-ABORT.INDICATION primitive and
+   enters the IDLE state.  Otherwise, a ReleaseRequest PDU is put on the
+   input queue for the serializer, the small timer is started again, and
+   the provider remains in the WAIT3 state.
+
+
+                                    WAIT4 state
+
+        Event:     P-RELEASE.RESPONSE primitive issued
+
+   The user data parameter is placed in a ReleaseResponse PDU, which is
+   put on the input queue for the serializer.  The provider now enters
+   the IDLE state.
+
+        Event:     P-U-ABORT.REQUEST primitive issued
+
+   The user data parameter is placed in an Abort PDU, which is put on
+   the input queue for the serializer.  The provider now enters the IDLE
+   state.
+
+
+        Event:     user-initiated Abort PDU received
+
+   The provider issues the P-U-ABORT.INDICATION primitive and enters the
+   IDLE state.
+
+
+        Event:     any other PDU received
+
+   If the PDU is not an Abort PDU, the provider constructs a provider-
+   initiated Abort PDU, which is put on the input queue for the
+   serializer.  Regardless, the provider issues the P-P-ABORT.INDICATION
+   primitive and enters the the IDLE state.
+
+
+
+
+
+Rose                                                           [Page 22]
+
+RFC 1085               ISO Presentation Services           December 1988
+
+
+11. Directory Services
+
+   Although not properly part of the presentation service, this memo
+   assumes and specifies a minimal Directory service capability for use
+   by the application-entity.
+
+   The function of the Directory Service Element is to provide two
+   mappings: first, a service name is mapped into an application entity
+   title, which is a global handle on the service; and, second, the
+   application-entity title is mapped onto a presentation address.
+
+   The structure of presentation addresses were defined in Section 5.
+
+   The structure of application-entity titles is less solidly agreed
+   upon at the present time.  Since objects of this type are not
+   interpreted by the presentation service, this memo does not specify
+   their structure.  If the DIS version of association control is being
+   used, then use of an OBJECT IDENTIFIER will suffice.  If the IS
+   version is being employed, then application-entity titles consist of
+   two parts: an application-process title and an application-entity
+   qualifier.  It is suggested that the AP-Title use an OBJECT
+   IDENTIFIER and that the AE-Qualifier use NULL.
+
+   This memo requires the following mapping rules:
+
+      1.  The service name for an OSI application-entity using the
+      mechanisms proposed by this memo is:
+
+              <designator> "-" <qualifier>
+
+      where <designator> is a string denoting either domain name or a
+      32-bit IP address, and <qualifier> is a string denoting the type
+      of application-entity desired, e.g.,
+
+              "gonzo.twg.com-mgmtinfobase"
+
+      2.  Any locally defined mapping rules may be used to map the
+      service designation into an application-entity title.
+
+      3.  The application-entity title is then mapped into a
+      presentation address, with uninterpreted transport, session, and
+      presentation selectors, and one or more network addresses, each
+      containing:
+
+         -the 32-bit IP address resolved from the <designator> portion
+          of the service name,
+
+         - a set indicating which transport services are available
+
+
+
+Rose                                                           [Page 23]
+
+RFC 1085               ISO Presentation Services           December 1988
+
+
+           at the IP address,
+
+         - the 16-bit port number resolved from the <qualifier>
+           portion of the service name (using the Assigned Numbers
+           document), and
+
+         - optionally, a presentation selector, which is an
+           uninterpreted sequence of octets.
+
+   The method by which the mappings are obtained are straight-forward.
+   The directory services element employs the Domain Name System along
+   with a local table which may be used to resolve the address employing
+   local rules.
+
+   In the simplest of implementations, the DNS is used to map the
+   <designator> to an IP address, and to fill-in the set of transport
+   services available at the IP address.  The port number is found in a
+   local table derived from the current Assigned Numbers document.
+   Finally, the presentation selector is empty.
+
+   A more ambitious implementation would use a local table to perhaps
+   provide a presentation selector.  This would be useful, e.g., in
+   "proxy" connections.  The network address would resolve to the proxy
+   agent for the non-IP device, and the presentation selector would
+   indicate to the proxy agent the particular non-IP device desired.
+   This implies, of course, that the local table and the proxy agent
+   bilaterally agree as to the interpretation of each presentation
+   selector.
+
+12. Remarks
+
+   To begin, if one really wanted to implement ISO applications in a
+   TCP/IP-based network, then the method proposed by [RFC1006] is the
+   preferred method for achieving this.  However, in a constrained
+   environment, where it is necessary to host an application layer
+   entity with a minimal amount of underlying OSI infrastructure, this
+   memo proposes an alternative mechanism.  It should be noted that an
+   OSI application realized using this approach can be moved directly to
+   an [RFC1006]-based environment with no modifications.
+
+   A key motivation therefore is to minimize the size of the alternate
+   underling infrastructure specified by this memo.  As more and more
+   presentation services functionality is added, the method proposed
+   herein would begin to approximate the ISO presentation protocol.
+   Since this in contrary to the key motivation, featurism must be
+   avoided at all costs.
+
+
+
+
+
+Rose                                                           [Page 24]
+
+RFC 1085               ISO Presentation Services           December 1988
+
+
+13. Acknowledgements
+
+   Several individuals contributed to the technical quality of this
+   memo:
+
+           Karl Auerbach, Epilogue Technologies
+           Joseph Bannister, Unisys
+           Amatzia Ben-Artzi, Sytek
+           Stephen Dunford, Unisys
+           Lee Labarre, MITRE
+           Keith McCloghrie, The Wollongong Group
+           Jim Robertson, Bridge Communications
+           Glenn Trewitt, Stanford University
+
+14. References
+
+     [ISO7498]  Information Processing Systems - Open Systems
+                Interconnection, "Basic Reference Model", October, 1984.
+
+     [ISO8509]  Information Processing Systems - Open Systems
+                Interconnection, " Service Conventions".
+
+     [ISO8650]  Information Processing Systems - Open Systems
+                Interconnection, " Protocol Specification for the
+                Association Control Service Element (Final Text
+                of DIS 8650)", January, 1988.
+
+     [ISO8822]  Information Processing Systems - Open Systems
+                Interconnection, " Connection Oriented Presentation
+                Service Definition (Final Text of DIS 8822)",
+                April, 1988.
+
+     [ISO8823]  Information Processing Systems - Open Systems
+                Interconnection, " Connection Oriented Presentation
+                Protocol Specification (Final Text of DIS 8822)",
+                April, 1988.
+
+     [ISO8824]  Information Processing Systems - Open Systems
+                Interconnection, " Specification of Abstract Syntax
+                Notation One (ASN.1)", December, 1987.
+
+     [ISO8825]  Information Processing Systems - Open Systems
+                Interconnection, "Specification of basic encoding rules
+                for Abstract Syntax Notation One (ASN.1)",
+                December, 1987.
+
+     [ISO9072/2]  Information Processing Systems - Text Communication
+                  MOTIS, " Remote Operations Part 2: Protocol
+
+
+
+Rose                                                           [Page 25]
+
+RFC 1085               ISO Presentation Services           December 1988
+
+
+                  Specification (Working Document for DIS 9072/2)",
+                  November, 1987.
+
+     [RFC768]  Postel, J., "User Datagram Protocol", RFC 768, USC/ISI,
+               28 August 1980.
+
+     [RFC791]  Postel, J., "Internet Protocol - DARPA Internet Program
+               Protocol Specification", RFC 791, USC/ISI,
+               September 1981.
+
+     [RFC793]  Postel, J., "Transmission Control Protocol - DARPA
+               Internet Program Protocol Specification", RFC 793,
+               USC/ISI, September 1981.
+
+     [RFC1006]  Rose, M., and D. Cass, "ISO Transport 1 on Top of the
+                TCP Version: 3", Northrop Research and Technology
+                Center, May 1987.
+
+Appendix A:
+
+Abstract Syntax Definitions
+
+   RFC1085-PS DEFINITIONS ::=
+
+   BEGIN
+
+   PDUs ::=
+           CHOICE {
+               connectRequest
+                   ConnectRequest-PDU,
+
+               connectResponse
+                   ConnectResponse-PDU,
+
+               releaseRequest
+                   ReleaseRequest-PDU,
+
+               releaseResponse
+                   ReleaseResponse-PDU,
+
+               abort
+                   Abort-PDU,
+
+               userData
+                   UserData-PDU,
+
+               cL-userData
+                   CL-UserData-PDU
+
+
+
+Rose                                                           [Page 26]
+
+RFC 1085               ISO Presentation Services           December 1988
+
+
+           }
+
+
+
+   -- connect request PDU
+
+   ConnectRequest-PDU ::=
+       [0]
+           IMPLICIT SEQUENCE {
+               version[0]          -- version-1 corresponds to to this
+                                      memo
+                   IMPLICIT INTEGER { version-1(0) },
+
+               reference
+                   SessionConnectionIdentifier,
+
+               calling
+                   PresentationSelector
+                   OPTIONAL,
+
+               called[2]
+                   IMPLICIT PresentationSelector
+                   OPTIONAL,
+
+               asn[3]              -- the ASN for PCI #1
+                   IMPLICIT OBJECT IDENTIFIER,
+
+               user-data
+                   UserData-PDU
+           }
+
+   SessionConnectionIdentifier ::=
+       [0]
+           SEQUENCE {
+               callingSSUserReference
+                   T61String,
+
+               commonReference
+                   UTCTime,
+
+               additionalReferenceInformation[0]
+                   IMPLICIT T61String
+                   OPTIONAL
+           }
+
+   PresentationSelector ::=
+       [1]
+           IMPLICIT OCTET STRING
+
+
+
+Rose                                                           [Page 27]
+
+RFC 1085               ISO Presentation Services           December 1988
+
+
+   -- connect response PDU
+
+   ConnectResponse-PDU ::=
+       [1]
+           IMPLICIT SEQUENCE {
+               reference           -- present only in the udp-based
+                                   -- service
+                   SessionConnectionIdentifier
+                   OPTIONAL,
+
+               responding
+                   PresentationSelector
+                   OPTIONAL,
+
+               reason[2]           -- present only if the connection
+                                   -- was rejected
+                   IMPLICIT Rejection-reason
+                   OPTIONAL,
+
+               user-data           -- present only if reason is absent
+                                   -- OR has the
+                                   -- value rejected-by-responder
+                   UserData-PDU
+                   OPTIONAL
+           }
+
+   Rejection-reason ::=
+           INTEGER {
+               rejected-by-responder(0)
+               called-presentation-address-unknown(1),
+               local-limit-exceeded(3),
+               protocol-version-not-supported(4),
+           }
+
+
+   -- release request PDU
+
+   ReleaseRequest-PDU ::=
+       [2]
+           IMPLICIT SEQUENCE {
+               reference           -- present only in the udp-based
+                                   -- service
+                   SessionConnectionIdentifier
+                   OPTIONAL,
+
+               user-data
+                   UserData-PDU
+           }
+
+
+
+Rose                                                           [Page 28]
+
+RFC 1085               ISO Presentation Services           December 1988
+
+
+   -- release response PDU
+
+   ReleaseResponse-PDU ::=
+       [3]
+           IMPLICIT SEQUENCE {
+               reference           -- present only in the udp-based
+                                   -- service
+                   SessionConnectionIdentifier
+                   OPTIONAL,
+
+               user-data
+                   UserData-PDU
+           }
+
+   -- abort PDU
+
+   Abort-PDU ::=
+       [4]
+           SEQUENCE {
+               reference           -- present only in the udp-based
+                                   -- service
+                   SessionConnectionIdentifier
+                   OPTIONAL,
+
+               user-data   -- MAY BE present on user-initiated abort
+                   UserData-PDU
+                   OPTIONAL,
+
+               reason[1]   -- ALWAYS present on provider-initiated abort
+                   IMPLICIT Abort-reason
+                   OPTIONAL
+           }
+
+   Abort-reason ::=
+           INTEGER {
+               unspecified(0),
+               unrecognized-ppdu(1),
+               unexpected-ppdu(2),
+               unrecognized-ppdu-parameter(4),
+               invalid-ppdu-parameter(5),
+               reference-mismatch(9)
+           }
+
+
+   -- data PDU
+
+   UserData-PDU ::=
+       [5]                         -- this is the ASN.1 object
+
+
+
+Rose                                                           [Page 29]
+
+RFC 1085               ISO Presentation Services           December 1988
+
+
+           ANY                     -- if it is a top-level PDU, it
+                                   -- is in PCI #1, otherwise PCI #3
+
+
+   -- data PDU for the udp-based service
+
+   CL-UserData-PDU ::=
+       [6]
+           IMPLICIT SEQUENCE {
+               reference
+                   SessionConnectionIdentifier,
+
+               user-data[0]                -- this is the ASN.1 object
+                   ANY                     -- it is always in PCI #1
+           }
+
+   END
+
+Appendix B:
+
+Example of Serialization
+
+
+   Consider the following call to ROSE:
+
+           RO-INVOKE (operation number      = 5
+                      operation class       = synchronous
+                      argument              = NONE
+                      invocation identifier = 1
+                      linked invocation id. = NONE
+                      priority              = 0)
+               .REQUEST
+
+   Ultimately, ROSE will use the P-DATA service:
+
+           P-DATA (user data = {
+                                 1,        -- this is the PCI
+                                 {         -- this is the ASN.1 object
+                                    invokeID 1,
+                                    operation-value 5,
+                                    argument {}
+                                 }
+                               })
+               .REQUEST
+
+   The presentation provider will construct a UserData PDU and send this
+   via the transport connection:
+
+
+
+
+Rose                                                           [Page 30]
+
+RFC 1085               ISO Presentation Services           December 1988
+
+
+      [5] {
+            {
+              1,
+              5,
+              {}
+            }
+          }
+
+   Applying the basic encoding rules for ASN.1, we have an stream of 12
+   octets.
+
+      a5  0a                                       [5]
+      tag len
+
+      a0  08                               [0]
+      tag len
+      02  01  01           invokeID 1
+      tag len value
+
+      02  01  05           operation-value 5
+      tag len value
+
+      30  00                       argument NULL
+      tag len
+
+   Of course, in actual use, the argument would not be NONE and this
+   could be expected to dominate the size of the UserData PDU.  However,
+   it is worth nothing that the overhead of the encoding mechanism used
+   is on the order of 10 octets, hardly a staggering amount!
+
+Appendix C:
+
+Determination of Network Called Address
+
+   As described in Section 10, when the P-CONNECT.REQUEST primitive is
+   issued the presentation provider must determine which of the network
+   addresses present in the called presentation address parameter to use
+   for the presentation connection.  The first step in this
+   determination is to examine the quality of service parameter and
+   consider only those network addresses which support the corresponding
+   transport service.  In practice, it is likely that each network
+   address will support exactly the same transport services, so using
+   quality of service as a discriminant will either permit all or none
+   or the network addresses present to be selected.  This appendix
+   describes a local policy which might be employed when deciding which
+   network address to use.
+
+   The policy distinguishes between "underlying failures" and
+
+
+
+Rose                                                           [Page 31]
+
+RFC 1085               ISO Presentation Services           December 1988
+
+
+   "connection establishment failures".  An "underlying failure" occurs
+   when, using the desired transport service, the initiating
+   presentation provider is unable to contact the responding
+   presentation provider.  For the tcp-based service, this means that a
+   TCP connection could not be established for some reason.  For the
+   udp-based service, it means that a response was not received before
+   final time-out.  In contrast, a "connection establishment failure"
+   occurs when the responding presentation provider can be contacted,
+   but the presentation connection is rejected by either the
+   presentation provider or the correspondent presentation user.
+
+   The policy is simple: starting with the first network address
+   present, attempt the connection procedure.  If the procedure fails
+   due to an "underlying failure", then the next network address in the
+   list is tried.  This process is repeated until either an underlying
+   connection is established or all network addresses are exhausted.
+   If, however, a "connection establishment failure" occurs, then the
+   presentation provider immediately indicates this failure to the
+   presentation user and no further network addresses are considered.
+
+   Note that this is only one conformant policy of many.  For example,
+   the presentation provider may wish to order network addresses based
+   on the "intensity" associated with the members present in the set of
+   transport services for each network address.
+
+Author's Address:
+
+   Marshall Rose
+   The Wollongong Group
+   1129 San Antonio Road
+   Palo Alto, CA 94303
+
+   Phone: (415) 962-7100
+
+   EMail: mrose@TWG.COM
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose                                                           [Page 32]
+
\ No newline at end of file