RFC 1085
ISO presentation services on top of TCP/IP based internets
RFC 1085: ISO Presentation Services on top of TCP/IP-based internets 🎀
Network Working Group 🦋 Author: M. Rose, TWG 💖 Request for Comments: 1085 ✨ Date: December 1988 🌸 Status: proposes a standard for the Internet community 👑 Obsoletes / Updates: the title block doesn't list either, so it doesn't obsolete or update anything 🙈
Status of this Memo ✨
Okay so this memo is literally proposing a standard for the Internet community 🔥 and distribution is unlimited, so everyone can pass it around 💅
1. Introduction 🌸
Okay bestie, [RFC1006] describes a way to run the ISO transport service on top of the Transmission Control Protocol (TCP) [RFC793] and the Internet Protocol (IP) [RFC791] 🦋 Once you've done that, you can build "real" ISO applications on TCP/IP-based internets by just implementing the OSI session, presentation, and application services on top of the transport service access point that sits on the TCP. Super straightforward, but there are some environments where you want all that rich OSI application-layer goodness, and it's just not practical to build the whole underlying OSI stack (the presentation, session, and transport services on top of TCP) 😭 So this memo describes a "stream-lined" way to support OSI application services on TCP/IP-based internets for those constrained environments 🧚
2. Terminology 💅
So since this memo is mostly about concepts from Open Systems Interconnection (OSI) as promulgated by the International Organization for Standardization (ISO), the terminology is meant to stay fully consistent with that world 🌈 Even though the whole point is to run this mechanism on the Internet and other TCP/IP-based internets, the author is apologetic but unyielding 🙈 If you're more used to the terms from that second world, sorry in advance, but this is how it's going to be 💀
Not a substitute for the "correct" definitions in the proper ISO documents, but here's a quick summary of the terms used in this memo ✨
- Application Context: The collection of application service elements that cooperatively interact within an application-entity. 🎀
- Application Service Element: A standardized mechanism, defined by both a service and a protocol, that provides a well-defined capability, for example:
- 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. Its fundamental responsibility is to maintain transfer syntaxes, which are used to serialize application protocol data units for transmission on the network and then de-serialize them on 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] to produce a stream of octets. De-serialization is the inverse process. 🍓
It's assumed you already know the terminology from the reference model [ISO7498], the service conventions in that model [ISO8509], and the connection-oriented presentation service [ISO8822], so no spoon-feeding here 💅
3. Scope 🧚
Okay so the mechanism in this memo is aimed at one specific class of OSI applications: entities whose application context contains only an Association Control Service Element (ACSE) and a Remote Operations Service Element (ROSE) 🎀 A Directory Services Element (DSE) is also assumed for the application-entity to use, but only in a very limited sense 🙈 Here's how one of these entities is organized:
+------------------------------------------------------------+
| |
| Application-Entity |
| |
| +------+ +------+ +------+ |
| | ACSE | | ROSE | | DSE | |
| +------+ +------+ +------+ |
| |
+------------------------------------------------------------+
| |
| Presentation Services |
| |
| P-CONNECT P-RELEASE P-DATA |
| P-U-ABORT |
| P-P-ABORT |
| |
+------------------------------------------------------------+This memo is not applicable to entities with a more extensive application context, like one that contains a Reliable Transfer Service Element 😭 The mechanism could be modified to support additional elements, but honestly, those extensions would just defeat the purpose of giving the majority of OSI applications the minimal software infrastructure they need to run 💀
The motivation for this memo came from a requirement to run the ISO Common Management Information Protocol (CMIP) over TCP/IP-based internets ✨ In its current definition, CMIP uses precisely the application service elements provided for here. CMIP users might want a quality of service that's different from a connection with a high level of reliability, because that would allow reduced use of connection-related resources 🌈 This memo proposes a mechanism to implement this less robust (and less costly) quality of service 🫶
4. Approach 🎀
The approach in this memo relies on the following architectural nuances 🔥
- 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 mean you could get a "cheap" emulation of the ISO presentation services by just serializing ASN.1 objects over a TCP connection 🤯 And that's exactly what this memo proposes 👑
So given that, this memo details how the essential features of the ISO presentation service can be kept while using a protocol that's totally different from the one in [ISO8823]. Here's the overall composition:
+-----------+ +-----------+
| PS-user | | PS-user |
+-----------+ +-----------+
| |
| PS interface PS interface |
| [ISO8822] |
| |
+----------+ ISO Presentation Services on the TCP +----------+
| client |-----------------------------------------| server |
+----------+ (this memo) +----------+
| |
| TCP interface TCP interface |
| [RFC793] |
| |In greater detail, the "client" and "server" boxes implement the protocol described in this memo. Each box has 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.
Here's the software architecture used to model a network entity with this approach 🧚
+---------+ +----------+ +-----+
| | | | 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 mainly concerned with negotiating transfer syntaxes, plus transforming to and from them 🤓 But with this memo's mechanism, no negotiation component is employed 💀 Instead, this memo specifies the fixed contexts that exist over each presentation connection offered, plus some other constants that get rid of the need for presentation layer negotiation entirely 💅✨
Part 1 of the serve is done, bestie 🍓
5. Fundamental Parameters ✨
okay so this section is where we get into the parameters the presentation service actually uses, and yes, they're defined right here bestie 💅
1. Presentation address 🎀
the structure of a presentation address lives in Addendum 3 to [ISO7498] 📖. this memo treats it as an ordered-tuple that holds:
- one or more network addresses
- a transport selector
- a session selector
- a presentation selector
each selector is an uninterpreted octet string, and it's allowed to be of possibly zero length 🙈. the mechanism in this memo completely ignores the values of these selectors (literally ignores them, no cap), but heads up: the value of the presentation selector does get preserved by the provider 💜.
a network address has three components 🦋:
- a 32-bit IP address
- a set showing which transport services are available at that IP address. right now only two members are defined, TCP and UDP, and as experience grows, other transport services may be added 🌈. as a local matter, if a member is present, it can have an "intensity" attached, which is either
"possibly present"or"definitely present"✨ - a 16-bit port number
because of all this, any application-entity living in the network can be identified by its network address 👑.
2. Presentation context list 🍓
this is a list of one or more presentation contexts, and each one 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 these components can take is severely restricted by this memo. exactly two contexts are defined: one for association control, and one for the specific application service element being carried as ROS APDUs (check the section on connection establishment for the precise values 👀).
if the presentation context list shows up in a "result" list (for example, the Presentation context result list parameter for the P-CONNECT service), there's a fourth component too 😭:
- an acceptance indicator
this tells you whether the context was accepted by both the service provider and the remote peer. if it wasn't accepted, a brief reason, like "abstract syntax not supported", is given 💀.
for the novice reader: think of the abstract syntax notation as the vocabulary of a language (the words that can be spoken), and the abstract transfer notation as the pronunciation 🗣️.
3. User data 🫶
user data passes through the presentation service interface as ASN.1 objects (in a locally defined form). each object has a presentation context identifier attached, and the PCI is how the data knows which context it's meant for 🔥. the range the PCI can take is severely restricted by this memo, and exactly one of the 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 describes some characteristic of the communication (like desired throughput, for example) along with some value in an arbitrary unit of measure. for our purposes, only one QoS element is interpreted: "transport-mapping". right now, "transport-mapping" takes one of two values, "tcp-based" or "udp-based", and those can also be called "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 listed in the network address 🧚.
5. Version of Session Service 💅
some application service elements (like the ACSE) invoke different procedures depending on the (negotiated) version of the session service that's available. implementations of this memo always indicate that session service version 2 has been negotiated 🫶.
6. Choice of Transport Service 🦋
okay so the conversation so far has centred on TCP as the underlying transport protocol 🎀. but it's also been noted that it may be desirable to allow a quality of service with less reliability, so you can take advantage of some other characteristic of the transport service 👀.
this introduces several profound impacts on the model, and it's beyond the scope of this memo to list them all 😭. what this memo does propose is a mechanism for implementing such a facility 💜.
to begin, we use the quality of service parameter on the P-CONNECT service to choose an underlying transport service. only one element is interpreted right now, "transport-mapping", which takes the value "tcp-based" or "udp-based". if the value is "tcp-based", the presentation provider uses TCP as the underlying transport service. if the value of "transport-mapping" is "udp-based", the presentation provider uses 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 UDP, because it's not the intent of this memo to "re-invent" the facilities in TCP 💅. so, it is critical to understand that:
low-quality means LOW-QUALITY! 🙈
because UDP is a packet-oriented protocol, the role of the serialization module needs a slight redefinition 🍓. for the serializer, each top-level ASN.1 object placed on the input queue forms a single UDP datagram on the output queue, which is given to the network. for the de-serializer, each UDP datagram placed on the input queue from the network forms a single top-level ASN.1 object placed on the output queue ✨. "top-level ASN.1 object" refers to the protocol data units being exchanged by the presentation providers 🧚.
this memo currently permits a choice between two transport protocols, the TCP or the UDP. but as experience grows and other transport protocols get deployed (like the VMTP), future incarnations of this memo will allow those transport protocols to be used too 🦋. it's a three-step process 🔥:
- first, the set of transport services defined for the network address gets updated
- second, a corresponding value is added to the range of the quality of service element
"transport-mapping" - third, the following sections of this memo get modified accordingly
7. Connection Establishment 💖
the Connection Establishment facility consists of one service, the P-CONNECT service 🎀.
7.1. The P-CONNECT Service ✨
okay so this one is the big one 💖 P-CONNECT brings two identified application-entities into communication. When it works, you get a presentation connection (with an initial defined context set) between them, and that connection is there for their later chats too. it's a confirmed service, and its effects are sequenced and non-destructive 🫶
if the udp-based service gets picked, the presentation connection should be used infrequently and will have minimal reliability characteristics 🙈 lowkey a little fragile, but that's the deal
for our purposes, P-CONNECT:
- requests TCP or UDP resources,
- builds a fixed defined context set, and
- exchanges initial user data.
here's how each parameter of P-CONNECT gets read, plus the defaults 💅
- Calling Presentation Address 🧚
This is a presentation address. The ISO presentation service says this one is mandatory, but in practice a local implementation rule can be used to figure out an "ephemeral" address to use.
- Called Presentation Address 🎀
This is a presentation address. When you're issuing the P-CONNECT.REQUEST primitive, this parameter may contain more than one network address. In the P-CONNECT.INDICATION primitive, though, only one network address is present: the one actually used to establish the presentation connection. (Appendix C describes a strategy that might be used to determine the actual network address.)
- Responding Presentation Address 🌸
This parameter is identical to the value of the Called Presentation Address parameter of the P-CONNECT.INDICATION primitive.
- Multiple defined Contexts 🦋
Always TRUE. This parameter is only present in the DIS version of the presentation service.
- 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.8825the 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- Presentation context result list 🍓
identical to the presentation context definition list, with the addition that the acceptance indicator for both contexts is "accepted".
- Default Context Name 🫧
None.
- Default Context Result 🙃
Not applicable.
- Quality of Service 🔥
the element "transport-mapping" takes the value "tcp-based" or "udp-based". the range of values may be extended in the future.
- Presentation Requirements 💜
None (the kernel functional unit is always used).
- Session Requirements 🫶
Full duplex.
- Initial synchronization point serial number 🌙
None.
- Initial Assignment of tokens ✨
None.
- Session connection identifier 🧚♀️
unlike the "real" presentation service, depending on the quality of service selected, this parameter can matter a LOT to the presentation provider 😭 so 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. the reason is that when the session connection identifier is represented with ASN.1, the tag and length octets get added anyway 💅
- User Data 💖
A single ASN.1 object is present: the appropriate A-ASSOCIATE PDU, carried in presentation context 3.
- Result 🎀
One of the following values: acceptance, user-rejection, provider-rejection (transient), or provider-rejection (permanent).
8. Connection Termination 💀
the Connection Termination facility is made up of three services: the P-RELEASE, P-U-ABORT, and P-P-ABORT services. 🙈
8.1. The P-RELEASE Service 🌸
this service gives the service user access to a negotiated release facility. its effects are sequenced and non-destructive. either presentation user is allowed to request it. but if there's a 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, P-RELEASE:
- waits for the serialization module to drain,
- sends release user data, and
- releases TCP or UDP resources
here's how the parameters of P-RELEASE get read, plus the defaults 🦋
- Result 🌈
Release accepted.
- User data 🍓
A single ASN.1 object is present, the appropriate A-RELEASE PDU,
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 the correspondent presentation user gets told about the termination. its effects are not sequenced with respect to preceding service invocations, and they may be destructive. it does not need the agreement of both service users 🫠
for our purposes, P-U-ABORT:
- flushes the serialization module,
- sends abort user data, and
- releases TCP or UDP resources
here's how the parameters of P-U-ABORT get read, plus the defaults 💜
- Presentation context identifier list 🧚
Contained in the ASN.1 objects, if any, that are delivered as user data.
- 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 is how the service provider can indicate that the presentation connection is terminating for reasons internal to the service provider. its effects are not sequenced with respect to preceding service invocations. running it disrupts any other concurrently active service, so it may be destructive 🔥
for our purposes, P-P-ABORT:
- flushes the serialization module, and
- releases TCP or UDP resources
here's how the parameters of P-P-ABORT get read, plus the defaults 🎀
- Provider reason 🙈
An integer code detailing why the connection was aborted. The codes include, but are not limited to: invalid PPDU parameter, unexpected PPDU, unrecognized PPDU, and specified reason.
- Abort data 🌙
None.
9. Information Transfer 🦋
the Information Transfer facility has lots of services, but only one of them, the P-DATA service, is provided by this memo. main character energy 👑
9.1. The P-DATA Service 💅
this service gives the service user a data transfer capability. its effects are sequenced and non-destructive. 🫶
if the udp-based service is selected, there's an upper bound on the size of the serialized ASN.1 objects that can be transmitted. this limit, imposed by UDP, is 65536 octets. as a practical matter, it's probably a good idea to keep datagrams less than or equal to 536 octets in size 🥹
for our purposes, P-DATA:
- sends user data
here's how the parameters of P-DATA get read, plus the defaults ✨
- User data 🌸
A single ASN.1 object is present: a remote operations APDU, carried in presentation context 1.
10. Elements of Procedure 🧠
okay this part is the rulebook for how the service provider behaves 📖 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
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 only10.1. Elements of Procedure specific to the tcp-based service 🧚
okay bestie, for every presentation connection the provider keeps track of three things 💅
- a local designator for the PS-user
- a local designator for a TCP connection
- the state of the connection (e.g.,
IDLE,WAIT1, and so on) ✨
when an event shows up from the network, the provider goes hunting for the matching presentation connection 🔍. matching is super simple: it just compares the local designators for the TCP connection 🎀. and whenever a connection is sitting in or going back to IDLE 😴, any resources tied to it (like hooking onto a local TCP port) get released 🫶.
now, when the procedures say "placed on the input queue for the serializer" 📬, that phrase means something different depending on what kind of PDU it is (lowkey confusing, I know 💀). for a regular PDU, which is anything that is not an abort PDU (user-initiated or provider-initiated), it just gets appended to the queue, no matter how many are already waiting 🌈.
abort PDUs are the drama queens 👑. for those, the provider checks the queue first. if the input queue is non-empty, or the serializer is busy transmitting to the network, the abort PDU gets discarded 🗑️ and the serializer is flushed, which aborts any output to the network that's in progress 💥. but if the input queue is empty, the Abort PDU is appended to the queue and a small timer starts ⏱️. if that timer expires before the PDU has been serialized and transmitted, the serializer gets flushed, aborting any output to the network in progress 😭.
in general, whenever the TCP connection is closed (either locally by the provider, or remotely by the network) or has errored, the serializer gets flushed 🧹. the one exception: if a ReleaseResponse PDU is being serialized and transmitted to the network, 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 🦋
for the udp-based service, the provider maintains the following 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
- a local designator for an UDP endpoint
- the state of the connection (e.g.,
IDLE,WAIT1, and so on) - a retransmission counter
when an event comes in from the network, the provider finds the associated presentation connection 🔎. this time 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 🍓. also, whenever a connection remains in or returns to IDLE, any associated resources, such as an attachment to a local UDP port, are released 🌸.
in the procedures that follow, "placed on the input queue for the serializer" means something a bit different here 📬. the ASN.1 object is serialized, and the resulting sequence of octets is sent as a single UDP datagram 🚀.
10.3. State Transitions ✨
okay bestie, this is the state machine part and it's giving plot twist 🦋 Here are the rules for moving between states. If an event tied to a user-generated primitive isn't listed, then it's an interface error for the user to issue that primitive in that state 🙈 Every state has to think about every possible incoming PDU, no skipping 💅
For the tcp-based service, we assume that some entity starts a passive TCP open 🎀 When that passive open completes, the entity uses some local rule to find a PS-user for the incoming presentation connection. That presentation connection then goes into the IDLE state. The entity keeps listening for other passive opens to complete. How this entity works is totally a local matter, because the listener is just a modeling artifact and not something you have to build 🧚
And if the udp-based service is picked, then the provider swaps in CL-UserData PDUs instead of UserData PDUs 🌈
IDLE state
Event: P-CONNECT.REQUEST primitive issued
okay so when a P-CONNECT.REQUEST shows up, the provider looks at the quality of service parameter and the list of network addresses in the called presentation address parameter, then picks an address for the presentation connection. How it decides is a local matter (Appendix C has a strategy that might be used 👀). For the rest of this, we assume a network address that supports the desired quality of service has been found ✨
Next, based on the network address chosen from the called presentation address parameter, the provider picks a compatible network address from the calling presentation address parameter. It attaches itself to the port tied to that address. (By local determination, this address doesn't have to be used, and an "ephemeral" port may be chosen by the provider 🍓)
For the tcp-based service, the provider tries 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 stays in the IDLE state 💀
Regardless, the user data parameter is placed in a ConnectRequest PDU, which goes 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 goes 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 goes on the input queue for the serializer. The provider enters the IDLE state 🧹
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 is not an Abort PDU, the provider constructs a provider-initiated Abort PDU, which goes on the input queue for the serializer. Regardless, the provider issues the P-P-ABORT.INDICATION primitive and enters 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 goes on the input queue for the serializer, the small timer starts 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 goes 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 🎀
Event: P-U-ABORT.REQUEST primitive issued
The user data parameter is placed in an Abort PDU, which goes 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 goes on the input queue for the serializer. Regardless, the provider issues the P-P-ABORT.INDICATION primitive and enters the IDLE state 😭
DATA state
Event: P-DATA.REQUEST primitive issued
The user data parameter is placed in a UserData PDU, which goes on the input queue for the serializer. The provider stays in the DATA state, no drama 💅
Event: P-RELEASE.REQUEST primitive issued
The user data parameter is placed in a ReleaseRequest PDU, which goes 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 goes on the input queue for the serializer. The provider enters the IDLE state 🧹
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 goes on the input queue for the serializer. Regardless, the provider issues the P-P-ABORT.INDICATION primitive and enters the IDLE state 😭
WAIT3 state
Event: P-U-ABORT.REQUEST primitive issued
The user data parameter is placed in an Abort PDU, which goes 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 🌸
Event: any other PDU received
If the PDU is not an Abort PDU, the provider constructs a provider-initiated Abort PDU, which goes on the input queue for the serializer. Regardless, the provider issues the P-P-ABORT.INDICATION primitive and enters 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 goes 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 goes on the input queue for the serializer, the small timer starts 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 goes 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 goes 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 goes on the input queue for the serializer. Regardless, the provider issues the P-P-ABORT.INDICATION primitive and enters the IDLE state 😭
11. Directory Services ✨
okay so this isn't technically part of the presentation service 🙈 but this memo still assumes and specifies a minimal Directory service capability for the application-entity to use 💅
The Directory Service Element has two jobs 🗺️ First, a service name gets mapped into an application entity title, which is a global handle on the service 🫶 Second, that application-entity title gets mapped onto a presentation address ✨
The structure of presentation addresses was defined in Section 5 🎀
The structure of application-entity titles is less solidly agreed upon right now 🥺 Since the presentation service doesn't interpret these objects, this memo doesn't specify their structure. If the DIS version of association control is being used, then an OBJECT IDENTIFIER will do the job 💖 If the IS version is being employed instead, then application-entity titles have two parts: an application-process title and an application-entity qualifier 🧩 The suggestion is that the AP-Title uses an OBJECT IDENTIFIER and the AE-Qualifier uses NULL 🌈
This memo requires the following mapping rules 📋
- 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 a 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"- Any locally defined mapping rules may be used to map the service designation into an application-entity title 🔮
- The application-entity title is then mapped into a presentation address 💌 That address has uninterpreted transport, session, and presentation selectors, plus one or more network addresses, and each of those network addresses contains:
- the 32-bit IP address resolved from the
<designator>portion of the service name 🌐 - a set indicating which transport services are available 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 32-bit IP address resolved from the
The way the mappings get obtained is pretty straightforward, honestly 😌 The directory services element uses the Domain Name System along with a local table, which can be used to resolve the address using local rules 🧚
In the simplest implementations, DNS is used to map the <designator> to an IP address, and to fill in the set of transport services available at that IP address 💅 The port number is found in a local table derived from the current Assigned Numbers document 📖 And finally, the presentation selector is empty 🫧
A more ambitious implementation would use a local table to maybe provide a presentation selector 🚀 This would be useful in "proxy" connections, for example 👀 The network address would resolve to the proxy agent for the non-IP device, and the presentation selector would tell the proxy agent which particular non-IP device is wanted 💜 Of course, this implies that the local table and the proxy agent bilaterally agree on how to interpret each presentation selector 🤝
12. Remarks 🌸
okay, so to begin: if you really wanted to run ISO applications on a TCP/IP-based network, the method proposed by [RFC1006] is the preferred way to do it 🙌 BUT if you're in a constrained environment and need to host an application layer entity with a minimal amount of underlying OSI infrastructure, this memo proposes an alternative mechanism 🧚 Also, an OSI application built with this approach can be moved directly into an [RFC1006]-based environment with no modifications at all ✨
A key motivation is therefore to minimize the size of the alternate underlying infrastructure specified by this memo 🎯 As more and more presentation services functionality gets added, the method proposed here would start to approximate the ISO presentation protocol 👀 Since that's totally against the key motivation, featurism must be avoided at all costs 💀🫶
13. Acknowledgements 💖
Several individuals contributed to the technical quality of this memo, and they deserve all the shoutouts 🥹
- 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 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 🧾
this is the ASN.1 bit, so it's all code and gets copied exactly 🫡
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
}
-- 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
-- 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
}
-- 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
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
}
ENDAppendix B: 💖
this one's empty in the original, so there's nothing to rewrite here 🙈
Okay bestie, this is the Example of Serialization 🎀 Let's walk through a ROSE call from start to finish 💅
Consider this call to ROSE:
RO-INVOKE (operation number = 5
operation class = synchronous
argument = NONE
invocation identifier = 1
linked invocation id. = NONE
priority = 0)
.REQUESTUltimately, ROSE hands things off to 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 {}
}
})
.REQUESTNext, the presentation provider builds a UserData PDU and sends it over the transport connection 🦋
[5] {
{
1,
5,
{}
}
}Now we apply the basic encoding rules for ASN.1, and we end up with a 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 lenOf course, in real life the argument wouldn't be NONE, and that would be what dominates the size of the UserData PDU 🌸 But it's worth noting that the overhead of the encoding mechanism is on the order of 10 octets. Hardly a staggering amount, iykyk 💜
Appendix C: Determination of Network Called Address 🗺️
Okay so, Appendix C is all about how the presentation provider picks a network address. As described in Section 10, when the P-CONNECT.REQUEST primitive gets issued, the presentation provider has to figure out which of the network addresses in the called presentation address parameter to use for the presentation connection 💅 Step one is to look at the quality of service parameter and keep only the network addresses that support the matching transport service. Real talk, most addresses will probably support the exact same transport services, so QoS filtering will either let all of them through or none of them 🙈 This appendix describes a local policy you could use when picking an address 🦋
The policy splits failures into two flavours: "underlying failures" and "connection establishment failures" 💜 An "underlying failure" happens when the initiating presentation provider can't reach the responding presentation provider using the desired transport service. For the tcp-based service, that means a TCP connection couldn't be established for some reason. For the udp-based service, it means no response came back before the final time-out. A "connection establishment failure" is different. The responding presentation provider can be contacted, but the presentation connection gets rejected, either by the presentation provider or by the correspondent presentation user 💀
Now for the policy itself 🎀 Start with the first network address in the list and attempt the connection procedure. If that fails because of an "underlying failure", try the next network address in the list. Keep going until either an underlying connection is established or every network address has been exhausted. But if a "connection establishment failure" occurs, the presentation provider immediately tells the presentation user about the failure, and no further network addresses get considered 🛑
Note that this is only one conformant policy of many 🌈 For example, the presentation provider might want to order network addresses based on the "intensity" associated with the members 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📦 where this page comes from
- ietf: rfc1085 1988-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms