RFC 1698
Octet Sequences for Upper-Layer OSI to Support Basic Communications Applications
RFC 1698: Octet Sequences for Upper-Layer OSI to Support Basic Communications Applications 💖
okay bestie, this is RFC 1698 🎀, and it's called Octet Sequences for Upper-Layer OSI to Support Basic Communications Applications. It's from the Network Working Group series and was written by P. Furniss, a Consultant 💅. It's marked Informational and dated October 1994 🌸. Its header doesn't list any RFCs it obsoletes or updates, so it isn't replacing or changing anything else ✨.
Status of This Memo 📜
This memo gives information to the Internet community 🦋. It does not specify an Internet standard of any kind, and distribution of it is unlimited 🌈.
Abstract 💜
So this doc lays out particular octet sequences for the OSI upper-layer protocols (Session, Presentation and ACSE) when they're used to support applications with "basic communications requirements" 🧚. That covers OSI application protocols like X.400 P7 and Directory Access Protocol, plus "migrant" protocols, which were originally defined to run over other transports 🚀.
Along with the octet sequences for the supporting layer headers (and trailers) around the application data, there's some tutorial material on the OSI upper layers 📚.
An implementation that sends the octet sequences given here, and interprets the equivalent protocol it receives, can interwork with an implementation based on the base standard, as long as both are being used to support an appropriate application protocol 🫶.
Table of Contents 🍓
1. Introduction ...................................................2
2. General ........................................................3
2.1 Subdivisions of "basic communication applications" ...........3
2.2 Conformance and interworking .................................5
2.3 Relationship to other documents ..............................5
3. Contexts and titles ............................................6
3.1 The concepts of abstract and transfer syntax .................6
3.2 Use of presentation context by cookbook applications..........7
3.3 Processing Presentation-context-definition-list ..............8
3.4 Application context ..........................................9
3.5 APtitles and AEqualifiers ....................................9
4. What has to be sent and received ..............................10
4.1 Sequence of OSI protocol data units used ....................10
4.2 Which OSI fields are used ...................................12
4.3 Encoding methods and length fields ..........................14
4.3.1 Session items .............................................14
4.3.2 ASN.1/BER items (Presentation and ACSE) ...................14
4.4 BER Encoding of values for primitive datatypes ..............15
4.5 Unnecessary constructed encodings ...........................16
5. Notation ......................................................16
6. Octet sequences ...............................................17
6.1 Connection request message ..................................17
6.2 Successful reply to connection setup ........................20
6.3 Connection rejection ........................................22
6.4 Data-phase TSDU .............................................23
6.5 Closedown - release request ................................24
6.6 Closedown - release response ................................25
6.7 Deliberate abort ............................................25
6.8 Provider abort ..............................................27
6.9 Abort accept ................................................27
7. References ....................................................27
8. Other notes ...................................................28
9. Security Considerations .......................................29
10. Author's Address .............................................291. Introduction ✨
The OSI upper-layer protocols are big and complicated 😭, mostly because the protocols they describe are packed with features and options. For most applications, though, only a small slice of that function is needed 💅. An implementation that isn't meant to be a completely general platform doesn't have to implement every feature. It also doesn't have to copy the way the OSI specifications are structured, because the layers of the OSI model are purely abstract 🧠.
This document covers the protocol elements the OSI upper layers need when supporting a connection-oriented application with only basic communication requirements. That means: create a connection, optionally negotiate the data representation, send and receive data, close a connection, and abort a connection 🎀. Optionally, data can also ride along on the connection establishment, closing and abort messages 🦋.
Here, the protocol elements are given as the octet sequences that make up the "envelope" around the application data 💌. The envelope plus its enclosed data form a Transport Service Data Unit (TSDU), which can be passed through the OSI Transport Service [ISO8072]. That service may in turn be supported as specified in [RFC1006], or by any class of the OSI Transport Protocol [ISO8073] 🚀.
The octet sequences to send, and the descriptions of the alternative forms that may be received, amount to an informal re-specification of the relevant parts of the upper-layer protocols 📝. The "relevant parts" are decided by what the supported applications need. This is a bit of a reflexive definition 🙈: if application Z needs something that isn't in here, then it isn't supported. The formal specifications are still the base standards, the appropriate profiles, and the requirements of the application 🫶. Still, an implementation based on this document can interwork with an implementation based directly on the full standards when both are supporting a basic communication application ✨. The "full" implementation just shows part of its potential behaviour, since the application only invokes part of it 💜.
On top of the octet sequences, the document includes some tutorial material 📚.
2. General 🌸
2.1 Subdivisions of "basic communication applications" 🌈
Within the "basic communication applications" defined above, you can make distinctions based on how much they use the OSI upper-layer services 👀. That in turn decides how much of the protocol described in this memo a particular application will use. One distinction is:
- a) whether application data is sent on the connection establishment, close and abort, or only during "date phase" on an established connection; OR
- b) whether the application data is of only one kind (abstract syntax) and one format (transfer syntax), or more than one (i.e., how much use is made of the Presentation layer syntax negotiation and identification features)
More distinctions are possible, but this memo identifies the protocol elements needed (or not needed) by four groups of "basic communications application" 🦄. All of the groups have "basic communications requirements", since they only need connection, data transfer and (perhaps) orderly release of the connection 💖. The four groups are:
- Group I: applications that send data only on an established connection, and use a single abstract and transfer syntax 🍑.
- Group II: applications that send data on connection establishment and release, and use a single abstract and transfer syntax 🌙.
- Group III: applications that send data of only one kind (one abstract syntax) on the connection, but have more than one format (transfer syntax) specified (they use the Presentation context negotiation facility) 🔀.
- Group IV: applications that will send data of several kinds on the connection, so they have to tell apart, on each write, which kind is being sent 🎭.
Group III applications work just like Group I (or possibly Group II) once the establishment exchange has negotiated the particular transfer syntax that will be used on the connection 🤝.
Here are some possible examples of the Groups 👯:
- Group I: Application protocols designed for use over transport-level protocols. These are typically non-OSI protocols that have been "migrated" to an OSI environment. The X Window System protocol is an example 🪟.
- Group II: OSI-originated protocols with simple requirements, including many of the ROSE-based ones, such as Directory Access Protocol 📇.
- Group III: Protocols that can be treated as Group I, but for which more than one encoding of the data is known, such as a standardised one and a system-specific one. All implementations understand the standard encoding, but Presentation layer negotiation lets like-implementations use their internal encoding for transfer, without losing general interworking. The same could apply to OSI protocols 🧩.
- Group IV: OSI protocols with multiple abstract syntaxes (but with each individual message coming from a single abstract syntax) that don't use any of the special Session functional units. X.400 P7 is an example 📬.
Some OSI protocols aren't included here 🙅. Those are the ones that use more than one abstract syntax in a single message (such as FTAM or Transaction Processing), or that use Session functional units (RTSE-based protocols, Virtual Terminal) 🚫.
2.2 Conformance and interworking 💜
The protocol elements specified in this memo correspond to the kernel functional units of Session, Presentation and ACSE, plus the duplex functional unit of Session 🧸.
The octet sequences below are derived from the International Standards for the Session [ISO8327], Presentation [ISO8822] and ACSE [ISO8650] protocols 📖. The point of this memo is to summarise those specifications, as they apply to the supported application groups 🫧. That way, an implementation can be developed without directly referring to the original standards, and still interwork with implementations that did refer to them 🤝. The OSI standards (especially Presentation) allow a lot of flexibility in how protocol data units are encoded 🌀. So this memo defines particular octet sequences to send, and describes the variations you can expect in data received from an implementation based directly on the OSI standards, rather than on this cookbook 🍳. An implementation that sends these sequences and can interpret the variations described should be fully able to interwork with an implementation based directly on the OSI standards 💖. But an implementation that can only interpret the octet sequences specified here for transmission might not be able to interwork with standards-based implementations 😬.
The goal is to interwork with conformant implementations that support the relevant application (or group of applications) 🎯. Some OSI standards have conformance requirements that go beyond what's needed for successful interworking, including detecting invalid protocol 🕵️. Conformance tests sometimes go beyond the strict conformance requirements of the standard too 🙃. So an implementation based on this memo may or may not be able to formally claim conformance to the International Standard 🤷♀️. It may legitimately be able to claim conformance but still fail a conformance test, if that test is over-specified. (Efforts are being made to correct this, but in the meantime the target is interworking with conformant implementations 🫶.)
2.3 Relationship to other documents ✨
Okay so the Session, Presentation and ACSE standards are super flexible, like a lot, but the Common Upper-Layer Requirements Part 1 [CULR-1]) reins that in 💅. It's a proposed International Standardised Profile (pdISP 11188-1) that you can basically assume most implementations obey 🫶. This memo applies the restrictions of CULR-1, especially the ones about maximum sizes of fields and stuff like that. Anywhere we take advantage of a CULR-1 limitation, we flag it 🎀.
More parts of CULR are cooking 🍳. Part 3 [CULR-3] covers the protocol elements needed for "basic communications applications", and it's being developed in (informal) liaison with this memo. CULR-3 is presented as a normal profile, mostly made of prescribed answers to the questions in the PICS (Protocol Implementation Conformance Statement) of the three protocols. CULR-3 does not make the distinction between the four Groups. An implementation of this memo (at least if it supported Group IV) would be able to claim conformance to CULR-3, with the possible exception of any more-than-interworking conformance requirements inherited by CULR-3 from the base standards. ✨
An extension [XTI/mOSI] to the X/Open Transport Interface [XTI] is shortly to be published as a preliminary specification 🦋. It defines an API to the OSI upper-layers, again as appropriate to a basic communications application. XTI/mOSI would be usable as an interface to support applications in groups I, II and III, and possibly group IV.
3. Contexts and titles 🧚
3.1 The concepts of abstract and transfer syntax 🍓
OSI includes the concepts of "abstract syntax" and "transfer syntax" 👀. These are terms for the content (abstract syntax) and format "on-the-line" (transfer syntax) of the protocol elements. The combination of an abstract syntax and transfer syntax is called a presentation context.
Application protocols devised explicitly under OSI auspices have used ASN.1 for the definition of the abstract syntax, and nearly all use the Basic Encoding Rules applied to the ASN.1 to define the transfer syntax. However, there is no such requirement in OSI in general or in OSI Presentation, and still less is there any requirement to change the representation of existing application protocols to ASN.1 (for their definition) or BER (for their transmission). Not everyone realises (even in OSI circles) that all communicating applications, in all environments, are using some form of these, just under different names and without the explicit identification that the OSI Presentation provides 🤯. OSI separates the identification of the content and format of the data from the addressing.
Formal specifications of non-OSI application protocols (such as TELNET, FTP, X Windows System) generally do not use ASN.1, but will invariably be found to define abstract and transfer syntaxes 💅. For a less formalised protocol used between similar systems, the abstract syntax may be defined simply in programming language structures, and the transfer syntax determined by how some compiler represents this in memory.
The OSI Presentation protocol requires that "names" be assigned to the abstract and transfer syntaxes of the application data that is carried. The names are always object identifiers ("oid"): globally unique names assigned hierarchically 🌈. Presentation supports the negotiation of a transfer syntax for a particular abstract syntax. Several can be offered and one selected.
This transfer syntax negotiation facility may be especially useful for non-ASN.1 syntaxes where there is more than one representation available (perhaps differing in byte-ordering or character code) 🫠. In such a case, on the connection establishment, all of the transfer syntaxes supported by the initiator are offered, and any one of these accepted by the responder, at its own choice. If the two systems share some "native" format, they can negotiate that, avoiding transformation into and out of a more general format that is used for interworking with unlike systems. The same applies to an ASN.1-defined abstract syntax, but in practice non-BER encodings of ASN.1 are rare.
3.2 Use of presentation context by cookbook applications 🍪
An application protocol not originally specified with OSI Presentation in mind (a "migrant" protocol) will not normally need to identify the abstract and transfer syntaxes being used, because they are known by some other means (effectively inferred from the addressing) 🙈. A generic (anonymous, if you like) name for both syntaxes can be used, and [CULR-3] defines object identifiers for "anonymous" abstract and transfer syntax names (currently called default, but this is expected to change).
In some cases object identifier names will be assigned for the syntaxes of a migrant application protocol. If these exist, they should be used. However, since the processing required will be the same, it will be legitimate to offer both the generic and specific names, with the responder accepting the specific (if it knew it) and the generic if the specific were not known. This will provide a migration option if names are assigned to the syntaxes after implementations are deployed using the generic names 🦋.
For abstract syntaxes defined in ASN.1, object identifier names will have been assigned to the abstract syntax with the specification. This name MUST be used to identify the abstract syntax 📌. The transfer syntax will most often be the Basic Encoding Rules (BER) object id, but alternatives (e.g., Packed Encoding Rules) are possible.
For group III and group IV applications, specific object identifier names must be used for all the abstract and transfer syntaxes 🎯. If these names are not assigned with the specification (e.g., if the specification is not in ASN.1), they can be assigned by whoever needs them, ideally the "owner" of the syntax specification.
3.3 Processing Presentation-context-definition-list 🔍
In Presentation context negotiation on connection establishment, the initiator sends a list (the presentation context definition list) of the abstract syntaxes it intends to use, each with a list of transfer syntaxes. Each presentation context also has an integer identifier. To build the reply, a responder has to examine this list and work out which of the offered presentation contexts will be accepted, and which (single) transfer syntax for each. The responder sends back the reply field, the Presentation-context-definition-result-list, in the accept message 💌. The result list contains the same number of result items as the definition-list proposed presentation-contexts. They are matched by position, not by the identifiers (which are not present in the result list). An acceptance also includes the transfer syntax accepted (as there can be several offered). This can be copied from the definition list.
For the group I, group II and group III cases, only the ACSE and one application-data P-context will be used, and all other contexts rejected. For the group IV case, several presentation contexts will be accepted 🧁.
However, even for group I applications there may be synonyms for an application-data Presentation-context. Unknown synonyms are rejected. The reply shown in 6.2 includes a rejection. (It can therefore not be the reply to the connection request shown in 6.1, since that has only two items in the definition list.) 🙃
In all cases, the connection responder must identify and keep the presentation context identifiers (called pcid's here) for all the accepted presentation contexts. These are integers (odd integers, in this case). CULR-1 limits them to no greater than 32767, but they will usually be <= 255 (so taking up one octet) 🔢.
A presentation context is sometimes used (i.e., data is sent using it) before the negotiation is complete. As will be seen in section 6, in these cases, the transfer syntax name sometimes appears with the integer identifier 👀.
3.4 Application context 🌷
The Association Control Service Element also exchanges the name (another Object Identifier) of the application context, which identifies what the communication is all about, again independently of the naming and addressing 🎀. As for the syntaxes, although some name must be present in the protocol, a generic name can be used for applications that do not have a specific name assigned. (This will almost certainly be a group I application. If a specific name is assigned, it must be used.) The only negotiation allowed is that the reply may be different from that sent by the initiator. CULR-3 provides a generic application context name (i.e., assigns an object identifier) 💖.
3.5. APtitles and AEqualifiers
okay bestie, so besides the addressing stuff (the transport address and maybe the session and presentation selectors 🗺️), the communicating application entities also have names 💖. These are called Application-Entity titles (AEtitle). ACSE carries them as two fields: the Application-process titles (APtitle) and the Application-entity qualifier (AEqualifier). The AEtitle is compound, and the APtitle is everything except the last element, which is the AEqualifier. (you can run this explanation backwards and it still slaps 🔁)
There are two non-equivalent forms 👀. AP-titles and AE-titles can be a Directory Name or an Object Identifier, and AE-qualifiers can be a Relative Distinguished Name (RDN) or an integer. The forms must match, since the AE-qualifier is the last component of the AP-title. Ngl, the Directory form is probably the only one you'll see for a while 🙃.
Use of these names is kind of all over the place 🫠. This cookbook suggests that implementations should be able to handle any value for the partner's names, and set (as initiator) their own names. The main reason is OSI:non-OSI relaying (e.g., X/osi:X/tcp) 🌉. It lets the end-system's names ride along to the relay, where they can be turned into hostnames and the lower-layer address figured out. OSI assumes name-to-address lookup is possible (via the Directory or other means), but it doesn't assume address-to-name will work. So the calling AE-title is needed if the responder is going to know who the initiator is. Most protocols work perfectly fine without these names though 💅.
As for encoding, an RDN will almost always be a single attribute value assertion 🧩. The attribute is defined either by the Directory standard [ISO9594 = X.500], or in [Internet/Cosine Schema] [RFC1274]. Using the notation below, an RDN using a Directory-defined standard attribute is encoded like this:
31 80 {1 - RDN, [SET OF]
30 80 {2 - AttributeValueAssertion, [SEQUENCE]
06 03 5504yy -- OID identifying an attribute named in
-- the Directory standard
-- which one is determined by yy
13 La xxxxxx -- [Printable string]
-- could be T61 string, with tag 14
00 00 }2 - end of AVA
00 00 }1 - end of RDNThe most likely attributes for an RDN have these hex values for yy 👑:
CommonName 03
Country 06
Locality 07
State/Province 08
Organisation 0A
OrganisationUnit 0BFor non-Directory attributes, the object id name must be substituted (and that changes the length right before it) 📏.
If there are multiple attribute value assertions in the RDN, the group between {2 and 2} is repeated (with different attributes). Order is not significant 🌈.
The encoding of a [Directory] Name for the AP-titles is the RDNs (high-order first) sitting inside this wrapper:
30 80 {1 - [SEQUENCE] Name
-- put the RDN encodings here
00 00 }1An Object Identifier AP-title is encoded as a primitive (see below), with the "universal" tag for an object identifier, which is 6. The integer AE-qualifier uses the universal tag for an integer, which is 2 🧚.
4. What has to be sent and received ✨
4.1. Sequence of OSI protocol data units used
OSI defines its facilities in terms of services, but those are abstract constructs (they don't have to match procedure calls). The thing that really matters is sending the resulting protocol data unit (PDU) 📦. Each layer's PDU carries the PDU from the layer above as user data, and the layers all name their PDUs differently 🏷️. This section gives an overview of the PDUs that get exchanged. The details live in section 6 📚.
The application needs to create a connection (strictly an association at the application layer in OSI, but we're calling it a connection here 🤓), send and receive data, and close the connection. Here's how that goes:
To create connection:
First create transport-level connection.
The initiator sends the message defined in 6.1, which is Session CONNECT carrying Presentation CONNECT request [CP] carrying ACSE A-ASSOCIATE request [AARQ], optionally carrying application data.
The responder replies with the message defined in 6.2, which is Session ACCEPT carrying Presentation CONNECT response [CPA] carrying ACSE response [AARE], optionally carrying application data.
- If the responder rejects the attempt, the reply will be
Session REJECT. This is defined in 6.3, where the REJECT carries no user data. A received REJECT may carry Presentation, ACSE and application data, although 6.3 shows only how to reject at Session level.
To send and receive data on a connection:
Send the message defined in 6.4, which is an empty Session GIVE-TOKEN followed by Session S-DATA carrying Presentation P-DATA [TD] containing the application data. (The GIVE-TOKEN is just two octets required by Session for some backwards compatibility 🧃.)
To close connection gracefully:
One side sends the message defined in 6.5, which is Session FINISH carrying P-RELEASE request carrying A-RELEASE request [RLRQ], optionally carrying application data. (This side may now receive, but not send data 🙅.)
The other side replies with the message defined in 6.6, which is Session DISCONNECT carrying P-RELEASE response carrying A-RELEASE response [RLRE], optionally carrying application data. The first side disconnects the transport connection on receiving the reply.
To close connection abruptly but also send application data:
Send the message defined in 6.7, which is Session ABORT carrying Presentation U-ABORT [ARU] carrying ACSE U-ABORT [ABRT], carrying application data (delivery not guaranteed). On receiving Session ABORT, disconnect transport 💥.
To close connection abruptly:
- Either send the message defined in 6.8, which is
Session ABORTcarrying nothing; - Or, just disconnect at transport level.
A group I application is assumed (by definition) not to send data on the establishment and release exchanges. A group II application will 🫶.
It would be possible to use the abort-with-data facility with a group I application to send a (possibly non-standardised) error message for diagnostic purposes 🔍.
A special rule kicks in if a release collision happens (i.e., FINISH+P-RELEASE+RLRQ received after sending the same). The side that initiated the original upper-layer connection waits, and the other side replies with the DISCONNECT etc. 🤝
4.2. Which OSI fields are used
There are a bunch of fields (parameters) in the PDUs involved 🗂️. They can be sorted by what applications (of a particular Group) need in general. A field may be "useful", "send-only", "fixed", "fixed with default", "internal" or "not important". Even the not-important ones may come in from another implementation, but since the application has no use for them, they can be ignored 🙈. If an implementation is only meant to support one particular application, it may be able to downgrade "useful" to "not important".
The text below describes the processing required for each category, and which fields belong in each category 💅.
"Useful": when sending, an implementation of general use should be able to set any (legal) value of these fields (via the upper interface from the application, or via some configuration or lookup mechanism). It SHOULD pass received values for the Calling values to the application. (For specific applications, these fields may be either required or unnecessary.)
- AARQ:
Called application-process titleCalled application-entity qualifierCalling application-process titleCalling application-entity qualifier
"Send-only": to interwork, the implementation must be able to set any value of these, but it can ignore any received value. Both are octet strings.
Presentation selector(up to 4 octets, limited by CULR-1)Session selector(up to 16 octets, limited by base standard)
"Fixed" (constant for all applications) 🔒:
- abstract and transfer syntax identifiers for presentation context
- ACSE Version numbers: 2 for session, 1 for Presentation and ACSE
"Fixed with default": the value is specific to the application. For non-ASN.1 abstract syntaxes (group I or group II only) applications, the anonymous values assigned by the OIW minimal OSI profile [CULR-3] can be used. The CULR-3 default application context can be used where a proper context name is neither available nor needed 🎀.
Application context
CULR-3 default is {1 0 11188 3 3}
Abstract syntax identifier for application data
CULR-3 anonymous name is {1 0 11188 3 1 1}
Transfer syntax identifier for application data
CULR-3 anonymous name is {1 0 11188 3 2 1}"Internal": an arbitrary value can be sent. A received value must be stored for use in sending 📥.
- Presentation context identifiers for ACSE and the application data (always odd integers)
"Not important": for interworking, any legal received value for the other fields must be received (i.e., the pdu is parsed successfully), but it can then be ignored. There is no requirement (in this cookbook) to check the existence, value or internal format of these fields 🫠.
- All other fields (which includes a large number of session fields)
4.3. Encoding methods and length fields
Both Session and ASN.1/BER [ISO8824, ISO8825] use a type-length-value structure for their encodings, but they're different ones 🧠. The Presentation and ACSE protocols use the ASN.1/BER encoding, so a Presentation PDU containing an ACSE PDU can be constructed or parsed as if it were a single structure 🧩.
All the protocols contain PDU fields with a compound structure. If one of these is being ignored, it may be necessary (for BER, not session) to determine the lengths of its components in order to find the length of the ignored field 📐.
Many of the lengths in the specification below will vary, depending on the values of the fields 🌸.
4.3.1. Session items
The type field of a session item is always a single octet 💜.
For session items, given a particular length, there is no flexibility:
- If the length is less than 255, represent it as one octet.
- If the length is greater, represent it as three octets. The first is
0xFF, and the next two are the length, high-order octet first.
(Some "real" implementations are known to use the second encoding in all cases. This is wrong, but should only concern conformance testers 🙈.)
4.3.2. ASN.1/BER items (Presentation and ACSE) 🎀
okay so the type field for ASN.1-BER is the tag 🏷️. Large tags (>30) can be multi-octet, but there are no large tags in the protocols involved in this memo, so we're good ✨. Bit 6 (0x20) of the tag octet is 1 if the item is constructed (the value is itself one or more ASN.1 BER items) or 0 if it's primitive 🧚
there's a lot of flexibility, at the sender's option, in how lengths get represented in BER 💅 there are three forms: short, long and indefinite
- Short (usable only if the length is less than 127): one octet 💫
- Long (usable for any length): the first octet has the top bit set, and the rest is a count of how many octets are holding the length value. That many subsequent octets hold the length. A long length may use more than the minimum number of octets, so
0x8400000001is a valid representation of length 1 🤯 - Indefinite (usable only for the length of a compound field): the single octet is
0x80, then one or more items (their tag-length-values), and finally two octets of0x00(equivalent to tag and length of zero) 🌀
to interwork generally, an implementation must be able to handle any of these forms when receiving 🫶
the encodings in the octet sequences below use indefinite length for all constructed items, with a few exceptions. yes it slightly increases the number of octets sent, but the length of a varying field (e.g., user data, or a varying object identifier) only affects the length of the item itself, not the enclosing lengths. so it's possible to use the octet sequences as templates interspersed with the varying fields 🧩
⚠️ Important: this choice of indefinite (which is equivalent to the "Canonical Encoding Rules" variant of BER) applies only to the Presentation and ACSE protocols themselves. It does not apply to ASN.1/BER encoded application data. The processing required of application data may suggest alternative "best" options.
4.4 BER Encoding of values for primitive datatypes ✨
the following ASN.1 primitive datatypes are used in the thinosi stack 💖
- Integers are encoded in twos-complement, high-order first. Unlike lengths, they must be encoded in the minimum number of octets (no leading
00padding) 🔢 - Object Identifiers have a rather peculiar, but compressed, encoding 🦋
- Combine the first two integers of the OID into one element by multiplying the first (always 0, 1 or 2) by 40, and adding the second.
- Each element (that one, and each subsequent integer in the OID taken on its own) is taken as a binary number and divided into 7-bit "bytes". This is apportioned into bits 1-7 of the minimum number of octets. Bit 8 is one for all octets of the sequence except the last. (This means that elements of less than 127 are single octet integers.)
- Printable Strings: as if in ISO 646 (ASCII) 🌸
- OCTET STRING: just put the octets there 🍓
4.5 Unnecessary constructed encodings 🙈
BER allows the sender to break some items (such as OCTET STRINGS, character strings) into several pieces (i.e., as constructed encoding), or to send them as primitive. CULR-1 requires that this is only done to one level. The pieces of both OCTET STRING and character string are tagged as if they were OCTET STRING, so they have the tag 04. This memo does not include any of these optional constructions, but they may be received in interworking 👀
5. Notation 📝
the constructs are shown in their tag - length - value form, and all numbers are in hexadecimal. Comments are preceded by a - character, and multiple - mean the comment is more than just information 💜
the tag column contains one of:
- single fixed octets.
*in the tag field indicates one or more pdu fields (possibly constructed) that may be received but are not sent. If received, they can be ignored.!indicates the tag is defined elsewhere..is a place holder for the column.?preceding the tag value indicates that the field is not always present; the comment will explain.
the length column contains one of:
- explicit value
Ls- a length according to session rules, which depends on the total size of the value (usually constructed)La- a length according to BER rules.is a placeholderyyis exactly one octet (i.e., one hex digit per y) holding part of the length
the value column contains one of:
- the hex value
xxxxxx- value of varying length (sometimes constructed){n- (n = number) the start of a constructed value}n- (n = number) the end of the constructed value with the corresponding number. (The number is sometimes omitted on the innermost nest of construction)yy- as part of a value, a variable value where each y represents one hex digit?a value, possibly constructed, that may be received but is not sent. It may be ignored if received
Note that all presentation lengths may be received in one of the alternative forms. All constructed lengths are shown in indefinite form. If a received length is definite, the corresponding end item (which will be shown here as 00 00 }n) will become . . }n. 🌈
in the comments, the notation {n} refers to the constructed item bracketed by the {n and }n fields 🎀
6. Octet sequences 🧚
6.1 Connection request message ✨
Okay bestie, here's the connect request laid out line by line 💅
- CONNECT SPDU
0D Ls {1 - "SI" value for CONNECT = 13
* Ls ? - Connection Identifier
05 06 {2 - Connect/Accept Item
13 01 00 - protocol options (probably mandatory)
* Ls ?
16 01 02 -- version number (bottom bit = v1, next bit =v2.
-- may get offers of either or both
* Ls ?
14 02 0002 - Session User Requirements (functional units)
- Id (20), length (always 2), duplex fu only.
-- On receipt, other bits may be set
-- check that the 2 bit is set
* Ls ? - we do not send any Calling Session Selector
?34 Ls xxxx -- Called Session Selector (i.e., the other end's)
-- up to 16 octets - you must set what the other
-- side demands. - May be anything characters,
-- binary etc.
- {3} disappeared in editing
C1 Ls {4 -- User Data, Identifier=193. if length is > 512,
-- then identifier is 194 (hex C2) instead
- CP - P-CONNECT-RI PPDU. Everything below is in ASN.1 BER
31 80 {5 - [SET]
--- Mode-selector (the {6} group) could possibly
--- come after everything else {7}
--- This will probably only be done by
--- evil-minded conformance testers
A0 80 {6 - Mode-selector [0] IMPLICIT SET
80 01 01 - [0] IMPLICIT INTEGER {normalmode(1)}
00 00 }6
A2 La {7 - [2] unnamed IMPLICIT SEQUENCE
* La ?
?82 La xxxx - [2] Called-presentation-selector
- CULR says maximum length is 4
-- must be what the other side wants
A4 80 {8 - [4] Presentation-context-definition-list
--- items (the outer SEQUENCEs) within the {8} list may
--- be in any order.
30 80 {9 - [SEQUENCE]
02 01 01 -- Defines pcid for ACSE; received value will be
-- a one or two octet odd integer
06 04 52010001 - [OID] for ACSE abstract syntax
30 80 { - [SEQUENCE]
06 02 5101 - [OID] Transfer syntax name is BER
00 00 } - end t-s list
00 00 }9 - end acse pctx defn
30 80 {10 - [SEQUENCE]
02 01 03 -- [INTEGER] Defines pcid for application data;
-- received value will be a one or two octet odd
-- integer
06 La xxxxxx - [OID] object identifier name of application
- abstract syntax (if CULR-3 default is used, this
- line is 06 06 28D734030101)
30 80 {11
06 La xxxxxx - [OID] t-s name for application data
- (if CULR-3 default is used, this line is
- 06 06 28D734030201)
-- will be several of these if multiple t-s offered
-- (application is Group III)
-- all will have the same tag 06
00 00 }11 - end transfer syntax list for application p-ctx
00 00 }10 - end application pctx definition
-- if multiple presentation contexts are offered, (Group
-- IV), the {10} SEQUENCE will repeat appropriately
-- if multiple contexts are to be accepted, all the
-- pcid's must be remembered
00 00 }8 - end of p-ctx-def-list
* La ?
61 80 {12 - [APPLICATION 1] User-data - Fully-encoded
30 80 {13 - [SEQUENCE] PDV-list
02 01 01 -- [INTEGER], value is acse pcid
A0 80 {14 - [0] Single-ASN1
- ACSE A-ASSOCIATE request APDU - AARQ
60 80 {15 - [APPLICATION 0] - AARQ
* La ? - protocol version defaults to 1 (only one defined)
A1 80 { - [1] Application-context
06 La xxxxxx -- object identifier name of application context
- (if CULR-3 default is used, this line is
- 06 05 28D7340303)
00 00 }
-- Called application process title {16} and application
-- entity qualifier may or may not be needed (see 3.4)
?A2 80 {16 - [2] Called Application-Process title
?! La xxxxxx -- see 3.5 - either a Directory Name or an oid
?00 00 }16 - end Called APtitle
?A3 80 {17 - [3] Called Application-Entity Qualifier
?! La xxxxxx -- see 3.5
?00 00 }17
* La ?
Calling AP-title and AE-qualifier may or may not be needed.
?A6 80 {18 - [6] Calling Application-Process title
?! La xxxxxx -- see 3.5
?00 00 }18
?A7 80 {19 - [7] Calling Application-Entity Qualifier
?! La xxxxxx -- see 3.5
?00 00 }19
* La ?
-- the user information field may or may not be required
-- (not required for Group I)
?BE 80 {20 - [30] IMPLICIT SEQUENCE
?28 80 {21 - [EXTERNAL]
?06 La xxxxxx -- [OID] This is the oid identifying the transfer
-- syntax used for the user data.
-- It is (almost certainly) required even if only
-- one transfer syntax was proposed.
?02 01 03 - [INTEGER] this is the pcid for the application
- data
?A0 La xxxxxx -- [0] single-ASN.1-type - the application data
-- (see paragraph at end of this section below}
?00 00 }21 - end of EXTERNAL
-- conceivably there may be several EXTERNALS, probably in
-- different presentation contexts (different pcids)
?00 00 }20 - end of user information field
00 00 }15 - end of AARQ
00 00 }14 - end of single-ASN-type
00 00 }13 - end of PDV-list
00 00 }12 - end of Presentation User-data
00 00 }7 - end of third element of CP-type SET
00 00 }5 - end of CP-typeSo the app data inside the EXTERNAL shows up as A0 La xxxx, which assumes it's a single-ASN.1 type. That's usually the case for group II, since those tend to be OSI apps 🧚 The xxxx is the BER encoding of the application PDU (probably something like Z-BIND or Y-INITIALIZE), and the length may be indefinite. Iconic behaviour from the length honestly. 🫶
But if the app data isn't a single ASN.1 type and it's an octet-aligned value instead, then A0 La xxxx gets swapped out for 81 La xxxx, where xxxx is the value itself. In that case the length must be definite (unless an "unnecessary" constructed encoding is used.) 🙈
Same vibes apply to the other EXTERNALs riding around in the ACSE PDUs 💜
6.2 Successful reply to connection setup
Okay so if the connection attempt goes through, this is what gets sent back to the initiator on a T-DATA 🦋
0E Ls {1 - ACCEPT SPDU
* Ls ?
05 06 {2 - Connect/Accept Item
13 01 00 - Protocol Options
* Ls ?
16 01 02 - version number (this shows version 2 only)
-- if version 2 was not offered, omit all of {2}
* Ls ?
14 02 0002 - Session User Requirements (functional units)
- duplex fu only (kernel is automatic)
* Ls ?
C1 Ls {3 -- User Data.
- CPA - P-CONNECT response
31 80 {4 - [SET]
-- again, Mode-selector could come at the end
A0 80 { - Mode-selector [0]
80 01 01 - normal mode - [0], length=1, value=1
00 00 }
A2 80 {5 - [2] SEQUENCE (unnamed)
* La ?
A5 80 {6 - [5] P-context-definition-result-list
-- following result items are in the order
-- corresponding to the pctx-definition-list in
-- the connect
-- this example assumes that was ACSE, user, rubbish
-- with rubbish rejected
30 80 {7 - [SEQUENCE] result item for acse
80 01 00 -- [0] result, value 0 is acceptance
81 02 5101 - [1] accepted transfer syntax name = BER
- note that this has an implicit tag, not 06
00 00 }7 - end result item for acse p-ctx
30 80 {8 - [SEQUENCE] result item for application-data pctx
80 01 00 - [0] value 0 is acceptance
81 La xxxxxx - [1] oid for transfer syntax, as on definition list
-- if there were several (groupIII) , the one you
-- liked most
00 00 }8 - end result item for app-data p-ctx
00 00 }6 - end p-ctx-def-result-list
* La ?
61 80 {10 - [APPLICATION 1] User-data, Fully-encoded
30 80 {11 - [SEQUENCE] PDV-list
02 01 01 -- [INTEGER] value is pcid for ACSE, as stored from
-- the pctx-definition-list on the P-CONNECT
-- request
A0 80 {12 - [0] single-ASN1-type
- A-ASSOCIATE response APDU - AARE
61 80 {13 - [APPLICATION 1] identifies AARE
* La ?
A1 80 {14 - [1] Application-context
06 La xxxxxx - [OID] name of application context
- usually the same as on AARQ, can differ
00 00 }14
A2 03 {15 - [2] result
02 01 00 - [INTEGER] value 0 means accepted
00 00 }15
A3 80 {16 - [3] result-source-diagnostic
- (curiously, a non-optional field)
A1 80 {17 - [1] acse-service-user
02 01 00 - [INTEGER] value 0 = null ! (why no implicit tag)
00 00 }17 - end acse-service-user
00 00 }16 - end result source diagnostic
* La ?
-- the user information field may or may not be required
- (not used for Group I)
?BE 80 {20 - [30] IMPLICIT SEQUENCE
?28 80 {21 - [EXTERNAL]
-- the transfer-syntax oid is not present this time
?02 01 03 - [INTEGER] this is the pcid for the application
- data
?A0 La xxxx -- [0] single-ASN1-type (see note at end of 6.1)
?00 00 }21 - end of EXTERNAL
-- conceivably there may be several EXTERNALS, probably in
-- different presentation contexts (different pcids)
?00 00 }20 - end of user information field
00 00 }13 - end AARE
00 00 }12 - end single-asn1-type
00 00 }11 - end PDV-list
00 00 }10 - end Presn user-data
00 00 }5 - end [2] implicit sequence in cpa
00 00 }4 - end CPA-type setNow, if a presentation context got offered in the presentation-context-definition-list and needs rejecting, here are the octets for that 🙅 Since the result-list lines up with the definition list by position, the rejection goes at the matching spot inside {6}. (Like, it'd sit right after {8} if the rejected context was the third one.) Position matters, babe. ✨
-- next SEQUENCE is a rejection of a pctx
30 80 {9 - [SEQUENCE] result item for a rejected pctx
80 01 02 -- [0] result, value 2 is provider rejection
82 01 00 - [2] reason, value 0 is reason-not-specified
-- there are other reasons, but let's keep it
-- simple
00 00 }9 - end result item for rejected pctx6.3. Connection rejection 🙅♀️
Okay so refusing a connection happens at the session level, but it's the session user doing the refusing, and no reason gets given. Bestie, this is a compromise 🫶 so nobody gets accused of messing up the session protocol. If the implementation doesn't like what it received, it's not essential to try explaining why to the partner, though it can be super helpful if you correctly figure out the reason. (In most cases, a wise implementor will make sure an error message goes somewhere or other) 💅
0C 03 {1 - REFUSE SPDU
* Ls ?
32 01 00 - rejected by SS-user, no reasonThe far-end may send some interesting stuff explaining why you aren't getting interworking 👀 If this is a session reason, the reason code will be one octet between 81 and 86. If the rejection is higher than session, it'll be carried on S-REFUSE (so the first octet is still 0C), and the higher PDU will show up as part of the reason code, which starts with 02. (The only remaining code is 01 = user congestion.) 🌸
6.4. Data-phase TSDU ✨
This is the core of the skinny stack 🍓 The lengths shown use a particular set of choices for indefinite and definite lengths, which means the application data length only affects one field. Making the two earlier indefinite lengths definite would need more calculation, so adding 4 octets after the application data is assumed to be quicker. This header is also designed to be 20 octets long, which keeps 4-byte alignment between transport and application buffers. Implementations are recommended to use this encoding. It's possible to rapidly match incoming data against it: if there's no mismatch until the length field, you can find where the data begins without any further analysis 🧚
SPDUs
01 00 . - S-GIVE-TOKEN - required by basic concatenation
- but no parameters
01 00 . - S-DATA - no parameters - what follows is User
- Information, not User Data, so is not included in
- the SPDU length fields
- P-DATA PPDU - TD (why TD ? Typed-data id TTD !)
61 80 {1 - User-data [APPLICATION 1]
30 80 {2 - [SEQUENCE] PDV-list
02 01 03 - [INTEGER] pcid for application data, P-CONNECT PPDU
- remembered by both sides
81 83yyyyyy xxxxxx -- [1] octet-aligned presentation data value(s)
-- length of length (3 octets) then three octets yyyyyy
-- for the length of the user data xxxxxx
00 00 }2 - End-of-contents for end of PDV-list
00 00 }1 - End-of-contents for end of Presentation User-dataIf the application data is in ASN.1, and a single ASN.1 value is being sent on the TSDU, the same header works, except the tag on the presentation data values becomes A0 (= [0], constructed) 🎀
If there are multiple data values to be sent, this header can be expanded in a couple of ways:
- a) if there are several ASN.1 values from the same presentation context, they can be concatenated and treated as an octet-aligned value (using the header as shown above, with tag
81(orA1- I think its primitive)), or each ASN.1 value can be an item (taggedA0), one after the other - b) if the data values are from different presentation contexts (group IV), each one is in its own
{2}group within the{1}
On receipt, for the simple octet-aligned case, the data value may itself have a constructed encoding. This will make the tag A1, and it will contain elements each tagged 04 (OCTET STRING). According to CULR-1, these elements are primitive (otherwise they would be 24 of course) 🤓
6.5. Closedown - release request 👑
When all is done, and you want to close down gracefully, send this on T-DATA 🦋
- FINISH SPDU
09 10 {1 - 9 identifies FINISH
* Ls ? - No Transport Disconnect item
- default is release Transport-connection
C1 0E {2 - User data (code 193)
- P-RELEASE req/ind PPDU (has no name)
61 80 {3 - [APPLICATION 1], user data, fully-encoded
30 80 {4 - [SEQUENCE] PDV-list
02 01 01 -- pcid for ACSE, remembered from setup
A0 80 {5 - [0] single asn.1-type
- A-RELEASE request APDU - RLRQ
62 80 {6 - [APPLICATION 2] identifies RLRQ
80 01 00 - [0] reason, value 0 means normal
* La ?
-- the user information field may or may not be required
- ( not required for Group I)
?BE 80 {7 - [30] IMPLICIT SEQUENCE
?28 80 {8 - [EXTERNAL]
-- the transfer-syntax oid is not present this time
?02 01 03 - [INTEGER] this is the pcid for the application
- data
?A0 La xxxxx -- [0] single-ASN.1-type application data
-- (see note at end of 6.1)
?00 00 }8 - end of EXTERNAL
-- conceivably there may be several EXTERNALS, probably in
-- different presentation contexts (different pcids)
?00 00 }7 - end of user information field
00 00 }6 - end of RLRQ
00 00 }5 - end of single asn.1-type
00 00 }4 - end of PDV-list
00 00 }3 - end of Presentation User-data6.6. Closedown - release response 🌈
On receiving a FINISH, you send this to tell the other end it's all over 🥹
- Session DISCONNECT SPDU
0A Ls {1 - SI=10, DISCONNECT
C1 Ls {2 - User data
- P-RELEASE rsp PPDU
61 80 {3 - [APPLICATION 1], user data, fully-encoded
30 80 {4 - [SEQUENCE] PDV-list
02 01 01 -- [INTEGER] pcid for ACSE, remembered from setup
A0 80 {5 - [0] single asn.1-type
- A-RELEASE response APDU - RLRE
63 80 {6 - [APPLICATION 3] identifies RLRE
80 01 00 - [0] reason, value 0 means normal
* La ?
-- the user information field may or may not be required
- (not required for Group I)
?BE 80 {7 - [30] IMPLICIT SEQUENCE
?28 80 {8 - [EXTERNAL]
-- the transfer-syntax oid is not present this time
?02 01 03 - [INTEGER] this is the pcid for the application
- data
?A0 La xxxxx -- [0] single-ASN.1-type application data
-- (see note at end of 6.1)
?00 00 }8 - end of EXTERNAL
-- conceivably there may be several EXTERNALS, probably in
-- different presentation contexts (different pcids)
?00 00 }7 - end of user information field
00 00 }6 - end of RLRE
00 00 }5 - end of single asn.1-type
00 00 }4 - end of PDV-list
00 00 }3 - end of Presentation userdata6.7. Deliberate abort 🙈
It's not clear whether this is any use. Just clearing the Transport connection will be more effective 💀 It goes on T-DATA, but it asks the far-side to close the T-connection.
- Session ABORT SPDU
19 Ls {1 - SI of 25 is ABORT
11 01 03 - Transport Disconnect PV, code 17
- value = '...00011'b means please
-- release T-conn, user abort
* Ls ?
C1 11 {2 - Session User Data
- P-U-ABORT PPDU - ARU
A0 80 {3 - [0] implicit sequence for normal mode
A0 80 {4 - [0] presentation-context-identifier-list
30 80 {5 - [SEQUENCE]
02 01 01 - [INTEGER]pcid for ACSE
06 02 5101 - [OID] for acse transfer syntax = BER
00 00 }5
-- there will be one {6} group for each application
-- presentation context that is used in this message
-- if there is no user data, the {6} group can be
-- omitted
30 80 {6
02 01 03 - [INTEGER] pcid for application data
06 La xxxxxx - [OID] transfer syntax for application data
00 00 }6
00 00 }4 - end of presentation-context-identifier-list
61 80 {7 - [APPLICATION 1], user data, fully-encoded
30 80 {8 - [SEQUENCE] PDV-list
02 01 01 - [INTEGER] pcid for ACSE as on CP PPDU
A0 05 {9 - [0] single asn.1-type
- A-ABORT APDU - ABRT
64 80 {10 - [APPLICATION 4] identifies ABRT
80 01 01 - [0] value 1 is acse-service-provider
-- the user information field may or may not be required
?BE 80 {11 - [30] IMPLICIT SEQUENCE
?28 80 {12 - [EXTERNAL]
-- the transfer-syntax oid is not present this time
-- (according to CULR-1)
?02 01 03 - [INTEGER] this is the pcid for the application
- data
?A0 La xxxxx -- [0] single-ASN.1-type application data
-- (see note at end of 6.1)
?00 00 }12 - end of EXTERNAL
-- conceivably there may be several EXTERNALS, probably in
-- different presentation contexts (different pcids)
?00 00 }11 - end of user information field
00 00 }10 - end of ABRT
00 00 }9 - end of single asn.1-type
00 00 }8 - end of PDV-list
00 00 }7 - end of Presentation user-data
00 00 }3 - end of ARU-PPDU6.8. Provider abort 🚨
This gets generated when an internal error occurs (i.e., something has gone mildly (?) wrong in the cookbook implementation) 🍳 Rather than accuse anyone of protocol errors, we just abort at session 🫶
ABORT SPDU
19 03 {1 - SI=25 = ABORT SPDU
11 01 09 - Transport Disconnect PV, code 17
-- value = '...01001'b release T-conn
-- no reason
* Ls ?6.9. Abort accept 🦋
If a Session abort (of any kind) is sent, it's possible that the far-end will send back an abort accept. If this happens, disconnect the transport. (The abort messages above do not propose that the transport connection be reused, and in this case, an abort accept is just the far-end passing the transport-disconnect initiative back.) This session message need never be sent, so just disconnect the transport on receiving an abort ✨
ABORT ACCEPT SPDU
1A 00 . - SI=26 = ABORT ACCEPT SPDU, no parameters7. References 📚
Here's the reading list, bestie! 💖 Each reference keeps its tag so you can find it fast.
[CULR-1]ISO/IEC DISP 11188-1 - Information Technology - International Standardised Profile - Common Upper Layer Requirements - Part 1: Basic Connection oriented requirements (DISP ballot ends June 1994).[CULR-3]Draft of Common Upper-layer requirements - Part 3: Minimal OSI upper layers facilities (A later draft will be proposed as ISP 11188/3).[ISO8072]Information processing systems - Open Systems Interconnection - Transport service definition; ISO, 1986.[ISO8073]Information processing systems - Open Systems Interconnection - Transport protocol specification; ISO, 1986.[ISO8326]Information processing systems - Open Systems Interconnection - Basic connection oriented session service definition; ISO, 1987 (or review copy of revised text = ISO/IEC JTC1/SC21 N4657, April 1990).[ISO8327]Information processing systems - Open Systems Interconnection - Basic connection oriented session protocol specification; ISO, 1987 (or review copy of revised text = ISO/IEC JTC1/SC21 N4656, April 1990).[ISO8649]Information processing systems - Open Systems Interconnection - Service definition for the Association Control Service Element; ISO, 1989.[ISO8650]Information processing systems - Open Systems Interconnection - Protocol specification for the Association Control Service Element; ISO, 1989.[ISO8822]Information processing systems - Open Systems Interconnection - Connection-oriented presentation service definition; ISO, 1989.[ISO8823]Information processing systems - Open Systems Interconnection - Connection-oriented presentation protocol specification; ISO, 1989.[ISO8824]Information technology - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), ISO/IEC 1990.[ISO8825]Information technology - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Syntax Notation One, ISO/IEC 1990.[RFC1006]Rose, M., and D. Cass, "ISO Transport Services on Top of the TCP", STD 35, RFC 1006, Northrop Research and Technology Center, May 1987.[ISO9594]Information technology - Open Systems Interconnection - The Directory; ISO/IEC, 1990.[RFC 1274]Barker, P., and S. Kille, "The COSINE and Internet X.500 Schema", RFC 1274, University College London, November 1991.
8. Other Notes 🦋
Okay so the Session, Presentation and ACSE standards have gotten a LOT of amendments since they first dropped 💅 The only one that really matters for this cookbook is Session addendum 2, which gives us session version 2 and unlimited user data 🔥 New editions with all the amendments folded in will be published during 1994 ✨
The coding choices in the cookbook are (nearly) the ones made by the "Canonical Encoding Rules" 🫶 These are a form of Basic Encoding Rules with no optionality, specified in the new edition of ISO/IEC 8825. (The "nearly" is doing a lot of work, iykyk 😭)
There's also a defect report proposed against Presentation and ACSE 🧚 It suggests that a note in the protocol specifications recommend using the canonical encoding options when sending, and then optimising for this on receipt. 💜
9. Security Considerations 🙈
Security issues are not discussed in this memo. 😬 Nothing about security is covered in these pages, so don't go hunting for it here!
10. Author's Address 💌
Here's how to reach the author, Peter Furniss 🎀
Peter Furniss
Peter Furniss Consultants
58 Alexandra Crescent
Bromley, Kent BR1 4EX
UK
Phone & Fax +44 81 313 1833
EMail: P.Furniss@ulcc.ac.ukThat's the whole cookbook, bestie. Go build something iconic 👑🌈
📦 where this page comes from
- ietf: rfc1698 1994-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms