summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1085.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1085.txt')
-rw-r--r--doc/rfc/rfc1085.txt1795
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