RFC 3340
The Application Exchange Core
📜 The Application Exchange Core (RFC 3340) 💖
okay bestie, let's get into it ✨ this is Part 1 of 7 🎀
RFC 3340 is titled "The Application Exchange Core" 🦋 It was written by M. Rose (Dover Beach Consulting, Inc.), G. Klyne (Clearswift Corporation), and D. Crocker (Brandenburg InternetWorking) 👑 It's a Standards Track document from the Network Working Group, dated July 2002 🗓️ The header doesn't list anything it obsoletes or updates, so it's a standalone spec 🌸
Status of This Memo
okay so this part is the legal stuff, but it's important 🙈 this document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💅 if you want the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚 and distribution of this memo is unlimited 🌈
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. 💜
Abstract
so the abstract is short and sweet 🍓 this memo describes Application Exchange (APEX) Core, which is an extensible, asynchronous message relaying service for application layer programs 🧚
Table of Contents
here's the whole table of contents, copied exactly so nothing gets lost 🎀
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Architecture at a Glance . . . . . . . . . . . . . . . . . 4
2. Service Principles . . . . . . . . . . . . . . . . . . . . 5
2.1 Modes of Operation . . . . . . . . . . . . . . . . . . . . 5
2.2 Naming of Entities . . . . . . . . . . . . . . . . . . . . 6
2.2.1 Comparing Endpoints . . . . . . . . . . . . . . . . . . . 7
3. Service Provisioning . . . . . . . . . . . . . . . . . . . 7
3.1 Connection Establishment . . . . . . . . . . . . . . . . . 7
3.2 Authentication . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Authorization . . . . . . . . . . . . . . . . . . . . . . 8
3.4 Confidentiality . . . . . . . . . . . . . . . . . . . . . 8
3.5 Relaying Integrity . . . . . . . . . . . . . . . . . . . . 8
3.6 Traffic Analysis . . . . . . . . . . . . . . . . . . . . . 9
4. The APEX . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1 Use of XML and MIME . . . . . . . . . . . . . . . . . . . 9
4.2 Profile Identification and Initialization . . . . . . . . 10
4.3 Message Syntax . . . . . . . . . . . . . . . . . . . . . . 11
4.4 Message Semantics . . . . . . . . . . . . . . . . . . . . 11
4.4.1 The Attach Operation . . . . . . . . . . . . . . . . . . . 11
4.4.2 The Bind Operation . . . . . . . . . . . . . . . . . . . . 13
4.4.3 The Terminate Operation . . . . . . . . . . . . . . . . . 14
4.4.4 The Data Operation . . . . . . . . . . . . . . . . . . . . 15
4.4.4.1 Relay Processing of Data . . . . . . . . . . . . . . . . . 17
4.4.4.2 Application Processing of Data . . . . . . . . . . . . . . 18
4.5 APEX Access Policies . . . . . . . . . . . . . . . . . . . 19
4.5.1 Access Policies in the Endpoint-Relay Mode . . . . . . . . 19
4.5.2 Access Policies in the Relay-Relay Mode . . . . . . . . . 20
5. APEX Options . . . . . . . . . . . . . . . . . . . . . . . 20
5.1 The statusRequest Option . . . . . . . . . . . . . . . . . 22
6. APEX Services . . . . . . . . . . . . . . . . . . . . . . 26
6.1 Use of the APEX Core DTD . . . . . . . . . . . . . . . . . 27
6.1.1 Transaction-Identifiers . . . . . . . . . . . . . . . . . 27
6.1.2 The Reply Element . . . . . . . . . . . . . . . . . . . . 28
6.2 The Report Service . . . . . . . . . . . . . . . . . . . . 28
7. Registration Templates . . . . . . . . . . . . . . . . . . 29
7.1 APEX Option Registration Template . . . . . . . . . . . . 29
7.2 APEX Service Registration Template . . . . . . . . . . . . 29
7.3 APEX Endpoint Application Registration Template . . . . . 30
8. Initial Registrations . . . . . . . . . . . . . . . . . . 30
8.1 Registration: The APEX Profile . . . . . . . . . . . . . . 30
8.2 Registration: The System (Well-Known) TCP port number for
apex-mesh . . . . . . . . . . . . . . . . . . . . . . . . 31
8.3 Registration: The System (Well-Known) TCP port number for
apex-edge . . . . . . . . . . . . . . . . . . . . . . . . 31
8.4 Registration: The statusRequest Option . . . . . . . . . . 31
8.5 Registration: The Report Service . . . . . . . . . . . . . 32
9. DTDs . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.1 The APEX Core DTD . . . . . . . . . . . . . . . . . . . . 32
9.2 The Report Service DTD . . . . . . . . . . . . . . . . . . 34
10. Reply Codes . . . . . . . . . . . . . . . . . . . . . . . 35
11. Security Considerations . . . . . . . . . . . . . . . . . 36
References . . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 38
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 39
B. IANA Considerations . . . . . . . . . . . . . . . . . . . 39
Full Copyright Statement . . . . . . . . . . . . . . . . . 401. Introduction ✨
okay so network applications can be broadly sorted by five operational characteristics 🦋
- server push or client pull;
- synchronous (interactive) or asynchronous (batch);
- time-assured or time-insensitive;
- best-effort or reliable; and,
- stateful or stateless.
for example 💅
- the world-wide web is a pull, synchronous, time-insensitive, reliable, stateless service; whilst
- Internet mail is a push, asynchronous, time-insensitive, best-effort (without DSN), stateless service.
messaging apps are wildly different when it comes to their operational needs 🌸 some need timeliness and reliability guarantees, and others literally don't care 🙈
but these features come with a cost, both in infrastructure and in configuration complexity 💀 so the underlying service has to be extensible, so it can support different requirements in a consistent way 🫶
this memo defines a core messaging service that handles a range of those operational characteristics ✨ on top of that core, the service supports a bunch of tailored services for both user-based and programmatic exchanges 👑
1.1 Overview
APEX gives you an extensible, asynchronous message relaying service for application layer programs 💖
at its core, APEX is a best-effort datagram service 🌈 each datagram (just called "data") is originated and received by APEX "endpoints", which are applications that dynamically attach to the APEX "relaying mesh" 🧚
the data carries:
- an originating endpoint;
- opaque content (via a URI-reference);
- one or more recipient endpoints; and,
- zero or more options.
options change the semantics of the service 🔥 they can apply per-recipient or per-data, and they can be processed by a single relay or by multiple relays 💅
APEX also has additional services layered on top of the relaying mesh, like access control and presence information 🎀
APEX is specified, in part, as a BEEP [1] "profile" 🦋 so lots of things (like authentication) come from the BEEP core 🫶 in this memo, the terms "peer", "initiator", "listener", "client", and "server" are used in the BEEP context 👑 and Section 2.1 of the BEEP core memo talks about the roles a BEEP peer can play ✨
one thing to keep in mind 🙈 the terms "endpoint" and "relay" are APEX-specific, so they don't exist in BEEP land 🍓
1.2 Architecture at a Glance
here's the APEX stack 🧚
+-------------+
| APEX | an APEX process is either:
| process |
+-------------+ - an application attached as an APEX
| | endpoint; or,
| APEX |
| | - an APEX relay
+-------------+
| | APEX services are realized as applications
| BEEP | having a special relationship with the APEX
| | relays in their administrative domain
+-------------+
| TCP |
+-------------+
| ... |
+-------------+and here's how the APEX entities fit together across administrative domains 💜
administrative domain #1 administrative domain #2
+----------------------------+ +----------------------------+
| +------+ | | +------+ |
| | | | | | | |
| | appl | | | | appl | |
| | | | | | | |
| +......+ +------+ | | +------+ +......+ |
| | | | | | | | | | | |
| |end- | |relay | | | |relay | |end- | |
| | point| | | | | | | | point| |
| +------+ +------+ | | +------+ +------+ |
| | | | | | | | | | | |
| | APEX | | APEX | | | | APEX | | APEX | |
| | | | | | | | | | | |
| +------+ +------+ | | +------+ +------+ |
| || || || | | || || || |
| ============= ================ ============= |
+----------------------------+ +----------------------------+
| <---- APEX relaying mesh ----> |Note: relaying between administrative domains is configured using SRV RRs. Accordingly, the actual number of relays between two endpoints is not fixed. ⚠️
2. Service Principles 👑
2.1 Modes of Operation
APEX has two modes 🦋
endpoint-relay: the endpoint is always the BEEP initiator of the service, and relays are always the BEEP listeners 💅 in this mode, applications attach as endpoints, and then data transmission happens ✨
relay-relay: relays are typically (but not necessarily) in different administrative domains 🌈 in this mode, applications bind as relays, and then data transmission happens 🧚
in the endpoint-relay mode, an endpoint (the BEEP initiator) can:
- attach as one or more endpoints;
- send data to other endpoints;
- receive data from other endpoints; and,
- terminate any of its attachments.
a relay (the BEEP listener) can, on top of handling requests from a BEEP initiator:
- terminate any of the endpoint's attachments;
- deliver data from other endpoints; and,
- indicate the delivery status of data the endpoint sent earlier.
in the relay-relay mode, a relay (BEEP listener or initiator) can:
- bind as one or more administrative domains;
- send data;
- receive data; and,
- terminate any bindings. 🎀
2.2 Naming of Entities ✨
okay so endpoints get names, and they use this ABNF [2] syntax 🎀
;; Domain is defined in [3], either a FQDN or a literal
entity = local "@" Domain
local = address [ "/" subaddress ]
address = token
subaddress = token
;; all non-control characters, excluding "/" and "@" delimiters
token = 1*(%x20-2E / %x30-3F / %x41-7E / UTF-8) ;; [4]There are two extra conventions on top of that syntax, so pay attention 👀
- the "apex=" convention: every endpoint identity whose local-part starts with "apex=" is reserved for APEX services that are registered with the IANA. 🦋
- the "subaddress" convention: if the solidus character ("/", decimal code 47) shows up in the local-part, it marks a subaddress of an endpoint identity. For example,
fred/appl=wb@example.comis a subaddress of the APEX endpointfred@example.com💅
Subaddresses that start with "appl=" are reserved for APEX endpoint applications that are registered with the IANA. 🌸
Relays don't get a name of their own, but they do work on behalf of administrative domains. Those domains are identified by a FQDN or a domain-literal, like example.com or [10.0.0.1] ✨
In APEX, the fundamental entities are "endpoints" and "relays". APEX is carried over BEEP, and BEEP's fundamental entity is the "peer". How BEEP peers relate to APEX endpoint and relay entities is spelled out in APEX's Access Policies (Section 4.5). 🫶
2.2.1 Comparing Endpoints
Here's the tea ☕ The "local" part is a string of UTF-8 [4] octets, so comparisons on it use exact matching. That means they're case-sensitive, no cap.
So fred@example.com and Fred@example.com are two different endpoints. 🙈 Of course, relays serving the example.com administrative domain can choose to treat those two endpoints the same when it comes to routing and delivery. It's giving flexible 💖
Last thing, and it matters! If an APEX endpoint is written in a transmission encoding, the encoding gets reversed before you compare anything. For example, if URL encoding is used, then apex:fred@example.com is identical to apex:f%72ed@example.com 🧚
3. Service Provisioning
3.1 Connection Establishment
The SRV algorithm [5] is how you find the IP/TCP addressing info for the relays that belong to an administrative domain identified by a FQDN. 🔥 You plug in these values:
service: "apex-edge"(for the endpoint-relay mode), or"apex-mesh"(for the relay-relay mode);protocol: "tcp"; and,domain:the administrative domain.
If the administrative domain is a domain-literal instead, the IP address info comes straight from the literal. The TCP port number is whatever the IANA assigned for the registration in Section 8.2. 🌈
3.2 Authentication
Authentication is all about provisioning for each BEEP peer (c.f., Section 4.5). 🔐
An APEX relay can be provisioned so that a BEEP peer identity matches a given endpoint identity. For example, a relay in the example.com administrative domain might be configured to let a BEEP peer called fred@example.com attach as the APEX endpoint fred@example.com 🎀
3.3 Authorization
Authorization is also a matter of provisioning for each BEEP peer (c.f., Section 4.5). 💅
Typically, a relay requires its BEEP peer to authenticate first, as a prelude to authorization. An endpoint usually doesn't require the same from its BEEP peer. 🦋
3.4 Confidentiality
Confidentiality is a matter of provisioning for each BEEP peer. 🌸
Typically, any data an originating endpoint considers sensitive gets its content encrypted for the intended recipient endpoint(s), rather than relying on hop-by-hop encryption. Similarly, an originating endpoint signs the content if it wants end-to-end authentication. 🫶
3.5 Relaying Integrity
Data gets relayed according to SRV entries in the DNS. So relaying integrity is a function of the DNS and of the applications that use the DNS 🧚 Extra assurance shows up if the BEEP initiator requires that the BEEP listener authenticate itself. ✨
3.6 Traffic Analysis
Hop-by-hop protection for data moving through the relaying mesh (endpoint identities and content) comes from the BEEP level, through the use of a transport security profile. 🔒
Other traffic characteristics, like the volume and timing of transmissions, are not protected from third-party analysis. 👀
4. The APEX
Section 8.1 has the BEEP profile registration for APEX. 💖
4.1 Use of XML and MIME
Each BEEP payload exchanged via APEX has an XML document and possibly some arbitrary MIME content. 🎀
If the BEEP payload is only an XML document, the mapping to a BEEP payload is straightforward, like this:
C: MSG 1 2 . 111 39
C: Content-Type: application/beep+xml
C:
C: <terminate transID='1' />
C: ENDOtherwise, if there's arbitrary MIME content, a URI-reference [6] in the XML control document points to it. That URI-reference can contain an absolute-URI (and maybe a fragment-identifier), or it can be a relative-URI made up of just a fragment-identifier. 🦋 The arbitrary MIME content goes in the BEEP payload using a "multipart/related" [7], identified with a "cid" URL [8]. The XML control document sits at the start of the "multipart/related", like so:
C: MSG 1 1 . 42 1234
C: Content-Type: multipart/related; boundary="boundary";
C: start="<1@example.com>";
C: type="application/beep+xml"
C:
C: --boundary
C: Content-Type: application/beep+xml
C: Content-ID: <1@example.com>
C:
C: <data content='cid:2@example.com'>
C: <originator identity='fred@example.com' />
C: <recipient identity='barney@example.com' />
C: </data>
C: --boundary
C: Content-Type: image/gif
C: Content-Transfer-Encoding: binary
C: Content-ID: <2@example.com>
C:
C: ...
C: --boundary--
C: ENDBEEP gives you an 8bit-wide path, so a "transformative" Content-Transfer-Encoding (like "base64" or "quoted-printable") should not be used. 🙅♀️ Also, MIME [9] requires the value of the "Content-ID" header to be globally unique. Don't skip this one, bestie 🫶
If the arbitrary MIME content is itself an XML document, it can sit right inside the control document as a "data-content" element. It's then identified with a URI-reference that's just a fragment-identifier, like this:
C: MSG 1 1 . 42 295
C: Content-Type: application/beep+xml
C:
C: <data content='#Content'>
C: <originator identity='fred@example.com' />
C: <recipient identity='barney@example.com' />
C: <data-content Name='Content'>
C: <statusResponse transID='86'>
C: <destination identity='barney@example.com'>
C: <reply code='250' />
C: </destination>
C: </statusResponse>
C: </data-content>
C: </data>
C: END4.2 Profile Identification and Initialization
APEX is identified as
http://iana.org/beep/APEXin the BEEP "profile" element during channel creation. 💜
No elements are required to be exchanged during channel creation. 🌸 However, in the endpoint-relay mode, the BEEP initiator will typically include an "attach" element during channel creation, like this:
<start number='1'>
<profile uri='http://iana.org/beep/APEX'>
<![CDATA[<attach endpoint='fred@example.com'
transID='1' />]]>
</profile>
</start>Similarly, in the relay-relay mode, the BEEP initiator will typically include an "bind" element during channel creation, like this:
<start number='1'>
<profile uri='http://iana.org/beep/APEX'>
<![CDATA[<bind relay='example.com'
transID='1' />]]>
</profile>
</start>4.3 Message Syntax
Section 9.1 defines the BEEP payloads that are used in APEX. 🧚
4.4 Message Semantics
4.4.1 The Attach Operation
When an application wants to attach to the relaying mesh as a given endpoint, it sends an "attach" element to a relay. 🎀 Here's the basic flow:
+-------+ +-------+
| | -- attach -----> | |
| appl. | | relay |
| | <--------- ok -- | |
+-------+ +-------+
C: <attach endpoint='fred@example.com' transID='1' />
S: <ok />Or it can attach more than one endpoint over the same exchange ✨
+-------+ +-------+
| | -- attach -----> | |
| | | |
| | <--------- ok -- | |
| appl. | | relay |
| | -- attach -----> | |
| | | |
| | <--------- ok -- | |
+-------+ +-------+
C: <attach endpoint='fred@example.com' transID='1' />
S: <ok />
C: <attach endpoint='wilma@example.com' transID='2' />
S: <ok />Or the relay can say no, with an error 🙅♀️
+-------+ +-------+
| | -- attach -----> | |
| appl. | | relay |
| | <------ error -- | |
+-------+ +-------+
C: <attach endpoint='fred@example.com' transID='1' />
S: <error code='537'>access denied</error>The "attach" element has an "endpoint" attribute, a "transID" attribute, and zero or more "option" elements. 💅
- the "endpoint" attribute specifies the endpoint that the application wants to attach as;
- the "transID" attribute specifies the transaction-identifier associated with this operation; and,
- the "option" elements, if any, specify additional processing options (Section 5).
When a relay receives an "attach" element, it runs through these steps, in order 👑
- If the transaction-identifier refers to a previous, non-terminated operation on this BEEP channel, an "error" element having code 555 is returned.
- If the relay is in a different administrative domain than this endpoint, an "error" element having code 553 is returned.
- If the application is not authorized to attach as this endpoint (c.f., Section 4.5.1), an "error" element having code 537 is returned.
- If any options are present, they are processed.
- If another application has already attached as this endpoint, an "error" element having code 554 is returned.
- Otherwise, the application is bound as this endpoint, and an "ok" element is returned. 🥳
4.4.2 The Bind Operation ✨
okay so when an application wants to identify itself as a relay, it sends a bind element to another relay 🦋, e.g.,
+-------+ +-------+
| | -- bind -------> | |
| relay | | relay |
| #1 | <--------- ok -- | #2 |
+-------+ +-------+
C: <bind relay='example.com' transID='1' />
S: <ok />or
+-------+ +-------+
| | -- bind -------> | |
| | | |
| | <--------- ok -- | |
| relay | | relay |
| #1 | -- bind -------> | #2 |
| | | |
| | <--------- ok -- | |
+-------+ +-------+
C: <bind relay='example.com' transID='1' />
S: <ok />
C: <bind relay='rubble.com' transID='2' />
S: <ok />or
+-------+ +-------+
| | -- bind -------> | |
| relay | | relay |
| #1 | <------ error -- | #2 |
+-------+ +-------+
C: <bind relay='example.com' transID='1' />
S: <error code='537'>access denied</error>The bind element has a relay attribute, a transID attribute, and contains zero or more option elements 💅:
- the
relayattribute specifies the administrative domain on whose behalf the application wants to serve; - the
transIDattribute specifies the transaction-identifier associated with this operation; and, - the
optionelements, if any, specify additional processing options (Section 5).
when a relay receives a bind element, it does these steps:
- If the transaction-identifier refers to a previous, non-terminated operation on this BEEP channel, an
errorelement having code 555 is returned. - If the application is not authorized to bind on behalf of this administrative domain (c.f., Section 4.5.2), an
errorelement having code 537 is returned. - If any options are present, they are processed.
- Otherwise, the application is accepted as serving this administrative domain, and an
okelement is returned. 🎉
4.4.3 The Terminate Operation
when an application or relay wants to release an attachment or binding, it sends a terminate element 🫶, e.g.,
+-------+ +-------+
| | -- terminate --> | |
| appl. | | relay |
| | <--------- ok -- | |
+-------+ +-------+
C: <terminate transID='1' />
S: <ok />or
+-------+ +-------+
| | -- terminate --> | |
| appl. | | relay |
| | <------ error -- | |
+-------+ +-------+
C: <terminate transID='13' />
S: <error code='550'>unknown transaction-identifier</error>or
+-------+ +-------+
| | <-- terminate -- | |
| appl. | | relay |
| | -- ok ---------> | |
+-------+ +-------+
C: <terminate transID='1' />
S: <ok />The terminate element has a transID attribute, an optional code attribute, an optional xml:lang attribute, and may contain arbitrary textual content 🌸:
- the
transIDattribute specifies the transaction-identifier associated with this operation; - the
codeattribute, if present, is a three-digit reply code meaningful to programs (c.f., Section 10); - the
xml:langattribute, if present, specifies the language that the element's content is written in; and, - the textual content is a diagnostic (possibly multiline) which is meaningful to implementers, perhaps administrators, and possibly even users.
when an application or relay receives a terminate element, it does these steps:
- If the value of the transaction-identifier is zero, then all associations established by this application over this BEEP session, either as an endpoint attachment or a relay binding, are terminated, and an
okelement is returned. - Otherwise, if the transaction-identifier does not refer to a previous unterminated operation on this BEEP channel, an
errorelement having code 550 is returned. - Otherwise, the application is no longer bound as an endpoint or a relay, and an
okelement is returned.
4.4.4 The Data Operation
when an application or relay wants to transmit data over the relaying mesh, it sends a data element 🧚, e.g.,
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| #1 | <--------- ok -- | |
+-------+ +-------+
C: <data content='cid:1@example.com'>
<originator identity='fred@example.com' />
<recipient identity='barney@example.com' />
</data>
S: <ok />or
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| #1 | <------ error -- | |
+-------+ +-------+
C: <data content='cid:1@example.com'>
<originator identity='fred@example.com' />
<recipient identity='barney@example.com' />
</data>
S: <error code='537'>access denied</error>or
+-------+ +-------+
| | -- data -------> | |
| relay | | appl. |
| | <--------- ok -- | #2 |
+-------+ +-------+
C: <data content='cid:1@example.com'>
<originator identity='fred@example.com' />
<recipient identity='barney@example.com' />
</data>
S: <ok />The data element has a content attribute, and contains an originator element, one or more recipient elements, zero or more option elements, and, optionally, a data-content element 💜:
- the
contentattribute is a URI-reference that specifies the contents of the data (c.f., Section 4.1); - the
originatorelement refers to the endpoint sending the data; - each
recipientelement refers to an endpoint destination for the data; - the
optionelements, if any, specify additional processing options (Section 5), termed per-data options; and, - the
data-contentelement, if present, specifies a nested XML entity that is referenced using a URI fragment-identifier as the value of thecontentattribute.
The originator element has an identity attribute, and contains zero or more option elements:
- the
identityattribute specifies the sending endpoint; and - the
optionelements, if any, specify additional processing options for the originator, termed per-originator options.
Each recipient element has an identity attribute, and contains zero or more option elements:
- the
identityattribute specifies the destination endpoint; and - the
optionelements, if any, specify additional processing options for this recipient, termed per-recipient options.
4.4.4.1 Relay Processing of Data
when a relay receives a data element, it does these steps:
- If the BEEP client is not authorized to originate or relay data on behalf of the
originatorendpoint (c.f., Section 4.5), anerrorelement having code 537 is returned. - If any per-data options are present, they are processed.
- An
okelement is returned. - If any per-originator options are present, they are processed.
- For each recipient:
- If any per-recipient options are present, they are processed.
- If the recipient endpoint is not in the administrative domain associated with the relay, then an APEX session is established to a relay that accepts data for the recipient's administrative domain, and a new
dataelement, containing thatrecipientelement and all applicable options, is sent to that relay.
If an APEX session is established, the new data is sent, and the recipient's relay returns an ok element, then the recipient is considered to be successfully processed.
- Otherwise, if the recipient endpoint is in the same administrative domain as the relay, the APEX access service must check that the originator endpoint is allowed to communicate with the recipient endpoint (the access entries [10] whose "owner" is the recipient must contain a
core:datatoken for the originator), and the recipient endpoint must be currently attached.
If so, a new data element, containing only that recipient element, is sent to the corresponding application. If the recipient's endpoint returns an ok element, then the recipient is considered to be successfully processed.
Providing that these semantics are preserved, a relay may choose to optimize its behavior by grouping multiple recipients in a single data element that is subsequently transmitted ✨.
Finally, note that a relay receiving a data element from an application may be configured to add administrative-specific options.
Regardless, all relays are expressly forbidden from modifying the content of the data element at any time 🙈.
4.4.4.2 Application Processing of Data
when an application receives a data element, it does these steps:
- If any per-data or per-originator options are present, they are not processed (but may be noted).
- For each recipient:
- If any per-recipient options are present, they are not processed (but may be noted).
- If the application is not attached as the recipient endpoint, then an error in processing has occurred.
- Otherwise, the
dataelement is further processed in an application-specific manner, and the recipient is considered to be successfully processed.
- If no recipients could be successfully processed, an
errorelement is returned; otherwise, anokelement is returned.
4.5 APEX Access Policies
access to APEX is provided by the juxtaposition of:
- authenticating as a BEEP peer;
- attaching as an APEX endpoint or binding as an APEX relay; and,
- being listed as an actor by the APEX access service (c.f., [10]).
Each of these activities occurs according to the policies of the relevant administrative domain:
- each administrative domain is responsible for keeping its own house in order through "local provisioning"; and,
- each administrative domain decides the level of trust to associate with other administrative domains.
4.5.1 Access Policies in the Endpoint-Relay Mode ✨
- okay so when an application wants to attach to the relaying mesh 🕸️, local provisioning maps BEEP peer identities to allowed APEX endpoints (c.f., Step 3 of Section 4.4.1).
Typically the identity function is used, e.g., if an application authenticates itself as the BEEP peer named as fred@example.com, it is allowed to attach as the APEX endpoint named as fred@example.com. 💖
However, using the "subaddress" convention of Section 2.2, an application authorized to attach as a given APEX endpoint is also authorized to attach as any subaddress of that APEX endpoint. So an application authorized to attach as fred@example.com is also authorized to attach as fred/appl=wb@example.com. 🦋
- when an application wants to send data, local provisioning maps attached endpoints to allowed originators (c.f., Step 1 of Section 4.4.4.1). 🎀
Typically the identity function is used, e.g., if an application attaches as the APEX endpoint named as fred@example.com, it is allowed to send data originating from that same APEX endpoint. Super simple. 💅
Other policies are permissible though! For example, the administrative domain may allow the application attached as wilma@example.com to send data originating as either wilma@example.com or fred@example.com. Main character energy for Wilma 👑
- finally, when a relay is delivering to an endpoint within its own administrative domain, it consults the recipient's access entry looking for an entry having the originator as an actor (c.f., Step 5.3 of Section 4.4.4.1). 🧚
4.5.2 Access Policies in the Relay-Relay Mode 🌸
- when an application wants to bind as a relay on behalf of an administrative domain, local provisioning may map BEEP peer identities to allowed APEX relays (c.f., Step 3).
If so, then typically the identity function is used. e.g., if an application authenticates itself as the BEEP peer named as example.com, it is allowed to bind as a relay on behalf of the administrative domain example.com. 🫶
- when a relay is sending data, no access policies, per se, are applied. Nothing to see here, bestie 🙈
- when a relay is receiving data, local provisioning maps BEEP peer identities to allowed originators (c.f., Step 1 of Section 4.4.4.1).
Typically the identity function is used, e.g., if a relay authenticates itself as being from the same administrative domain as the originator of the data, then the data is accepted. ✨
In addition, some relays may also be configured as "trusted" intermediaries, so that if a BEEP peer authenticates itself as being from such a relay, then the data is accepted. trusted intermediaries are lowkey the VIPs of the mesh 👑
5. APEX Options 🎀
APEX, at its core, provides a best-effort datagram service. Options are used to alter the semantics of the core service. 💜
The semantics of the APEX "option" element are context-specific. Accordingly, the specification of an APEX option must define:
- the identity of the option;
- the context in which the option may appear;
- what content, if any, is contained within the option; and,
- the processing rules for the option.
An option registration template (Section 7.1) organizes this information. 📋
An "option" element is contained within either a "data", "originator", "recipient", or an "attach" element, all of which are termed the "containing" element. The "option" element has several attributes and contains arbitrary content:
- the
internaland theexternalattributes, exactly one of which is present, uniquely identify the option; - the
targetHopattribute specifies which relays should process the option; - the
mustUnderstandattribute specifies whether the option, if unrecognized, must cause an error in processing to occur; - the
transIDattribute specifies a transaction-identifier for the option; and, - the
localizeattribute, if present, specifies one or more language tokens, each identifying a desirable language tag to be used if textual diagnostics are returned to the originator.
Note that if the containing element is an "attach", then the values of thetargetHopandtransIDattributes are ignored. 🙈
The value of the internal attribute is the IANA-registered name for the option. If the internal attribute is not present, then the value of the external attribute is a URI or URI with a fragment-identifier. Note that a relative-URI value is not allowed. 🔗
The targetHop attribute specifies which relay(s) should process the option:
this: the option applies to this relay, and must be removed prior to transmitting the containing element.final: the option applies to this relay, only if the relay will transmit the containing element directly to the recipient.all: the option applies to this relay and is retained for the next.
Note that a final relay does not remove any options as it transmits the containing element directly to the recipient. 🧚
The mustUnderstand attribute specifies whether the relay may ignore the option if it is unrecognized, and is consulted only if the targetHop attribute indicates that the option applies to that relay. If the option applies, and if the value of the mustUnderstand attribute is true, and if the relay does not "understand" the option, then an error in processing has occurred. this part is serious, bestie, read it twice 😭
5.1 The statusRequest Option
Okay so, Section 8.4 is where you'll find the APEX option registration for the "statusRequest" option 💅
If this option is present, then each applicable relay sends a "statusResponse" message back to the originator 🦋 It does this by issuing a data operation where the originator is the report service attached to the issuing relay, the recipient is the endpoint address of the "statusRequest" originator, and the content is a "statusResponse" element ✨
A "statusRequest" option MUST NOT be present in any data operation containing a "statusResponse" element. 🙈 In general, applications should be careful to avoid potential looping behaviors if an option is received in error. Nobody wants an infinite loop, bestie 💀
Consider these examples 🌸
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| #1 | <--------- ok -- | |
+-------+ +-------+
C: <data content='cid:1@example.com'>
<originator identity='fred@example.com' />
<recipient identity='barney@example.com' />
<option internal='statusRequest' targetHop='final'
mustUnderstand='true' transID='86' />
</data>
S: <ok />
+-------+ +-------+
| | -- data -------> | |
| relay | | appl. |
| | <--------- ok -- | #2 |
+-------+ +-------+
C: <data content='cid:1@example.com'>
<originator identity='fred@example.com' />
<recipient identity='barney@example.com' />
<option internal='statusRequest' targetHop='final'
mustUnderstand='true' transID='86' />
</data>
S: <ok />
+-------+ +-------+
| | <------- data -- | |
| appl. | | relay |
| #1 | -- ok ---------> | |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='apex=report@example.com' />
<recipient identity='fred@example.com' />
<data-content Name='Content'>
<statusResponse transID='86'>
<destination identity='barney@example.com'>
<reply code='250' />
</destination>
</statusResponse>
</data-content>
</data>
S: <ok />or
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| #1 | <--------- ok -- | |
+-------+ +-------+
C: <data content='cid:1@example.com'>
<originator identity='fred@example.com' />
<recipient identity='barney@example.com' />
<option internal='statusRequest' targetHop='final'
mustUnderstand='true' transID='86' />
</data>
S: <ok />
+-------+ +-------+
| | <------- data -- | |
| appl. | | relay |
| #1 | -- ok ---------> | |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='apex=report@example.com' />
<recipient identity='fred@example.com' />
<data-content Name='Content'>
<statusResponse transID='86'>
<destination identity='barney@example.com'>
<reply code='550'>unknown endpoint
identity</reply>
</destination>
</statusResponse>
</data-content>
</data>
S: <ok />or
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| #1 | <--------- ok -- | #1 |
+-------+ +-------+
C: <data content='cid:1@example.com'>
<originator identity='fred@example.com' />
<recipient identity='barney@rubble.com' />
<option internal='statusRequest' targetHop='final'
mustUnderstand='true' transID='86' />
</data>
S: <ok />
+-------+ +-------+
| | -- data -------> | |
| relay | | relay |
| #1 | <--------- ok -- | #2 |
+-------+ +-------+
C: <data content='cid:1@example.com'>
<originator identity='fred@example.com' />
<recipient identity='barney@rubble.com' />
<option internal='statusRequest' targetHop='final'
mustUnderstand='true' transID='86' />
</data>
S: <ok />
+-------+ +-------+
| | -- data -------> | |
| relay | | appl. |
| #2 | <--------- ok -- | #2 |
+-------+ +-------+
C: <data content='cid:1@example.com'>
<originator identity='fred@example.com' />
<recipient identity='barney@example.com' />
<option internal='statusRequest' targetHop='final'
mustUnderstand='true' transID='86' />
</data>
S: <ok />
+-------+ +-------+
| | <------- data -- | |
| relay | | relay |
| #1 | -- ok ---------> | #2 |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='apex=report@rubble.com' />
<recipient identity='fred@example.com' />
<data-content Name='Content'>
<statusResponse transID='86'>
<destination identity='barney@rubble.com'>
<reply code='250' />
</destination>
</statusResponse>
</data-content>
</data>
S: <ok />
+-------+ +-------+
| | <------- data -- | |
| appl. | | relay |
| #1 | -- ok ---------> | #1 |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='apex=report@rubble.com' />
<recipient identity='fred@example.com' />
<data-content Name='Content'>
<statusResponse transID='86'>
<destination identity='barney@rubble.com'>
<reply code='250' />
</destination>
</statusResponse>
</data-content>
</data>
S: <ok />Note that a trace of a data's passage through the relaying mesh can be achieved by setting the "targetHop" attribute to "all" 🔍✨
6. APEX Services ✨
APEX, at its core, provides a best-effort datagram service 🌈 Within an administrative domain, all relays must be able to handle messages for any endpoint within that administrative domain. APEX services are logically defined as endpoints but, given their ubiquitous semantics, they do not necessarily need to be associated with a single physical endpoint. So they may be provisioned co-resident with each relay within an administrative domain, even though they are logically provided on top of the relaying mesh, i.e.,
+----------+ +----------+ +----------+ +---------+
| APEX | | APEX | | APEX | | |
| access | | presence | | report | | ... |
| service | | service | | service | | |
+----------+ +----------+ +----------+ +---------+
| | | |
| | | |
+----------------------------------------------------------------+
| |
| APEX core |
| |
+----------------------------------------------------------------+That is, applications communicate with an APEX service by exchanging data with a "well-known endpoint" (WKE) 🧚
For example, APEX applications communicate with the report service by exchanging data with the well-known endpoint "apex=report" in the corresponding administrative domain. E.g., "apex=report@example.com" is the endpoint associated with the report service in the "example.com" administrative domain 💖
The specification of an APEX service must define:
- the WKE of the service;
- the syntax and sequence of messages exchanged with the service;
- what access control tokens are consulted by the service.
A service registration template (Section 7.2) organizes this information 📋
Finally, note that within a single administrative domain, the relaying mesh makes use of the APEX access service in order to determine if an originator is allowed to transmit data to a recipient (c.f., Step 5.3 of Section 4.4.4.1) 👑
6.1 Use of the APEX Core DTD
The specification of an APEX service may use definitions found in the APEX core DTD (Section 9.1). For example, the reply operation (Section 6.1.2) is defined to provide a common format for responses 🎀
6.1.1 Transaction-Identifiers
In using APEX's transaction-identifiers, note the following 🫶
- In the endpoint-relay and relay-relay modes, transaction-identifiers are meaningful only during the lifetime of a BEEP channel.
For example, when an application issues the attach operation, the associated transaction-identifier has meaning only within the context of the BEEP channel used for the attach operation. When the BEEP connection is released, the channel no longer exists and the application is no longer attached to the relaying mesh 😭
- In contrast, when an application communicates with an APEX service, transaction-identifiers are often embedded in the data that is sent. This means that transaction-identifiers are potentially long-lived.
For example, an application may attach as an endpoint, send data (containing an embedded transaction-identifier) to a service, and, some time later, detach from the relaying mesh. Later on, a second application may attach as the same endpoint, and send data of its own (also containing embedded transaction-identifiers). Subsequently, the second application may receive data from the service responding to the first application's request and containing the transaction-identifier used by the first application. The plot thickens 🍓
To minimize the likelihood of ambiguities with long-lived transaction-identifiers, the values of transaction-identifiers generated by applications should appear to be unpredictable 🔮💜
6.1.2 The Reply Element
okay so lots of APEX services use a reply operation 💌 each service decides when a "reply" element gets sent, but the actual syntax of that element lives in Section 9.1 🫶
the "reply" element has a "code" attribute, a "transID" attribute, an optional "xml:lang" attribute, and it can hold arbitrary textual content ✨
- the "code" attribute holds a three-digit reply code (c.f., Section 10) 🔢
- the "transID" attribute names the transaction-identifier this reply belongs to 🎀
- the "xml:lang" attribute, if it's there, tells you what language the content is written in 🌍
- the textual content is a diagnostic (it can be multiline) that's meaningful to implementers, maybe administrators, and possibly even users 💅
6.2 The Report Service
okay this is the report service, and Section 8.5 has its APEX service registration 📋
- inside an administrative domain, you reach the service using the well-known endpoint of "apex=report" 🦋
- Section 9.2 defines the syntax of the operations you swap with it 💜
- a consumer of the service never starts a conversation with it 🙈
- the service is the one that starts talking, by sending data containing the "statusResponse" operation 📣
if a relay processes a "statusRequest" option (Section 5.1), it sends data back to the originator with a "statusResponse" element (Section 9.2) 💖
the "statusResponse" element has a "transID" attribute and holds one or more "destination" elements:
- the "transID" attribute carries the value that was in the "statusRequest" option ✨
- each "destination" element has an "identity" attribute and holds a "reply" element:
- the "identity" attribute names the recipient endpoint being reported on 🧚
- the "reply" element (Section 6.1.2) tells you the delivery status of that recipient 🌸
7. Registration Templates
7.1 APEX Option Registration Template
when you register an APEX option, you hand over the following info 📝
- Option Identification: the NMTOKEN or URI that authoritatively identifies this option 🔖
- Present in: the APEX elements where the option is allowed to show up 👀
- Contains: the XML content that lives inside the "option" element 🧩
- Processing Rules: the processing rules attached to the option ⚙️
- Contact Information: the postal and electronic contact info for the author of the profile 💌
7.2 APEX Service Registration Template
when you register an APEX service, you give the following info 💅
- Well-Known Endpoint: the local-part of an endpoint identity, starting with "apex=" 🦋
- Syntax of Messages Exchanged: the elements that get swapped with the service 🎀
- Sequence of Messages Exchanged: the order that data gets exchanged with the service in 🔁
- Access Control Tokens: the token(s) used to control access to the service (c.f., [10]) 🔐
- Contact Information: the postal and electronic contact info for the author of the profile 💌
note that the endpoints "apex=all" and "apex=core" may not be assigned 🚫
7.3 APEX Endpoint Application Registration Template
when you register an APEX endpoint application, you provide the following info 🧚
- Endpoint Application: the subaddress used for an endpoint application, starting with "appl=" 🌈
- Application Definition: the syntax and semantics of the endpoint application this registration identifies 📖
- Contact Information: the postal and electronic contact info for the author of the profile 💌
8. Initial Registrations
8.1 Registration: The APEX Profile
here's the APEX profile registration, bestie 🎀
- Profile Identification:
http://iana.org/beep/APEX🔗 - Messages exchanged during Channel Creation: "attach", "bind" 🛠️
- Messages starting one-to-one exchanges: "attach", "bind", "terminate", or "data" 💬
- Messages in positive replies: "ok" ✅
- Messages in negative replies: "error" ❌
- Messages in one-to-many exchanges: none 🙅
- Message Syntax: c.f., Section 9.1 📐
- Message Semantics: c.f., Section 4.4 🧠
- Contact Information: c.f., the "Authors' Addresses" section of this memo 💌
8.2 Registration: The System (Well-Known) TCP port number for apex-mesh
the relay-relay port registration 🔌
- Protocol Number: TCP 🧵
- Message Formats, Types, Opcodes, and Sequences: c.f., Section 9.1 📜
- Functions: c.f., Section 4.4 ⭐
- Use of Broadcast/Multicast: none 📵
- Proposed Name: APEX relay-relay service 🌸
- Short name: apex-mesh 🍓
- Contact Information: c.f., the "Authors' Addresses" section of this memo 💌
8.3 Registration: The System (Well-Known) TCP port number for apex-edge
the endpoint-relay port registration 🔌
- Protocol Number: TCP 🧵
- Message Formats, Types, Opcodes, and Sequences: c.f., Section 9.1 📜
- Functions: c.f., Section 4.4 ⭐
- Use of Broadcast/Multicast: none 📵
- Proposed Name: APEX endpoint-relay service 🌸
- Short name: apex-edge 🍓
- Contact Information: c.f., the "Authors' Addresses" section of this memo 💌
8.4 Registration: The statusRequest Option
the statusRequest option registration 🎟️
- Option Identification: statusRequest 🔖
- Present in: APEX's "data" and "recipient" elements 👀
- Contains: nothing 🫙
- Processing Rules: c.f., Section 5.1 ⚙️
- Contact Information: c.f., the "Authors' Addresses" section of this memo 💌
8.5 Registration: The Report Service
and the report service registration 📋
- Well-Known Endpoint: apex=report 🦋
- Syntax of Messages Exchanged: c.f., Section 9.2 📐
- Sequence of Messages Exchanged: c.f., Section 6.2 🔁
- Access Control Tokens: none 🔓
- Contact Information: c.f., the "Authors' Addresses" section of this memo 💌
9. DTDs
9.1 The APEX Core DTD
this is the core DTD, and yes, it's copied exactly 🫶
<!--
DTD for the APEX core, as of 2001-07-09
Refer to this DTD as:
<!ENTITY % APEXCORE PUBLIC "-//IETF//DTD APEX CORE//EN" "">
%APEXCORE;
-->
<!ENTITY % BEEP PUBLIC "-//IETF//DTD BEEP//EN" "">
%BEEP;
<!--
DTD data types:
entity syntax/reference example
====== ================ =======
APEX endpoint
ENDPOINT entity, fred@example.com
c.f., Section 2.2
domain, either a FQDN or a literal
DOMAIN c.f., [RFC-2821] example.com or [10.0.0.1]
seconds
SECONDS 0..2147483647 600
timestamp
TIMESTAMP c.f., [12] 2000-05-15T13:02:00-08:00
unique-identifier
UNIQID 1..2147483647 42
unique-identifier OR zero
UNIZID 0..2147483647 0
-->
<!ENTITY % ENDPOINT "CDATA">
<!ENTITY % DOMAIN "CDATA">
<!ENTITY % SECONDS "CDATA">
<!ENTITY % TIMESTAMP "CDATA">
<!ENTITY % UNIQID "CDATA">
<!ENTITY % UNIZID "CDATA">
<!--
APEX messages, exchanged as application/beep+xml
role MSG RPY ERR
====== === === ===
I attach ok error
I or L bind ok error
I or L terminate ok error
I or L data ok error
-->
<!ELEMENT attach (option*)>
<!ATTLIST attach
endpoint %ENDPOINT; #REQUIRED
transID %UNIQID; #REQUIRED>
<!ELEMENT bind (option*)>
<!ATTLIST bind
relay %DOMAIN; #REQUIRED
transID %UNIQID; #REQUIRED>
<!ELEMENT terminate (#PCDATA)>
<!ATTLIST terminate
code %XYZ; "250"
xml:lang %LANG; #IMPLIED
transID %UNIZID; "0">
<!ELEMENT data (originator,recipient+,option*,data-content?)>
<!ATTLIST data
content %URI; #REQUIRED>
<!ELEMENT originator (option*)>
<!ATTLIST originator
identity %ENDPOINT; #REQUIRED>
<!ELEMENT recipient (option*)>
<!ATTLIST recipient
identity %ENDPOINT; #REQUIRED>
<!ELEMENT data-content
ANY>
<!ATTLIST Name ID #REQUIRED>
<!ELEMENT ok EMPTY>
<!ELEMENT reply (#PCDATA)>
<!ATTLIST reply
code %XYZ; #REQUIRED
transID %UNIQID; #REQUIRED
xml:lang %LANG; #IMPLIED>
<!-- either the "internal" or the "external" attribute is present in
an option -->
<!ELEMENT option ANY>
<!ATTLIST option
internal NMTOKEN ""
external %URI; ""
targetHop (this|final|all) "final"
mustUnderstand
(true|false) "false"
transID %UNIQID; #REQUIRED
localize %LOCS; "i-default">9.2 The Report Service DTD
and the report service DTD 📡
<!--
DTD for the APEX report service, as of 2000-12-12
Refer to this DTD as:
<!ENTITY % APEXREPORT PUBLIC "-//Blocks//DTD APEX REPORT//EN" "">
%APEXREPORT;
-->
<!ENTITY % APEXCORE PUBLIC "-//Blocks//DTD APEX CORE//EN" "">
%APEXCORE;
<!--
Synopsis of the APEX report service
service WKE: apex=report
message exchanges:
service initiates consumer replies
================= ================
statusResponse (nothing)
access control tokens: none
-->
<!ELEMENT statusResponse
(destination+)>
<!ATTLIST statusResponse
transID %UNIQID; #REQUIRED>
<!ELEMENT destination (reply)>
<!ATTLIST destination
identity %ENDPOINT; #REQUIRED>10. Reply Codes
here are the reply codes, sorted out for you 🔢
code meaning
==== =======
250 transaction successful
421 service not available
450 requested action not taken
451 requested action aborted
454 temporary authentication failure
500 general syntax error (e.g., poorly-formed XML)
501 syntax error in parameters (e.g., non-valid XML)
504 parameter not implemented
530 authentication required
534 authentication mechanism insufficient
535 authentication failure
537 action not authorized for user
538 authentication mechanism requires encryption
550 requested action not taken
553 parameter invalid
554 transaction failed (e.g., policy violation)
555 transaction already in progress11. Security Considerations
okay security is serious business, so pay attention 🚨🔐
go check Section 3 and Section 4.5 for the security stuff, like relaying integrity 🛡️
service provisioning is a policy matter, but at a minimum, all APEX implementations must provide the following tuning profiles 💅
- for authentication:
http://iana.org/beep/SASL/DIGEST-MD5🔑 - for confidentiality:
http://iana.org/beep/TLS(using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher) 🔒 - for both:
http://iana.org/beep/TLS(using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting client-side certificates) 🔐✨
on top of that, APEX endpoint implementations may choose to offer MIME-based security services that provide message integrity and confidentiality, like OpenPGP [13] or S/MIME [14] 💌
either way, since APEX is a profile of the BEEP, go check [1]'s Section 9 for the BEEP-specific security issues 🧐
finally, the statusRequest option (Section 5.1) may be used to expose private network topology 🫣 so an administrator may wish to choose to disable this option except at the ingress/egress points for its administrative domain 🚧
References 📚✨
okay so this is the bibliography bestie, every doc the spec is built on 🧚 each one has its own number so the text can point right at it 💅
- [1] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
- [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
- [3] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
- [4] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, October 1996.
- [5] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
- [6] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
- [7] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998.
- [8] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.
- [9] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
- [10] Rose, M., Klyne, G. and D. Crocker, "The Application Exchange (APEX) Access Service", RFC 3341, July 2002.
- [11] Rose, M., Klyne, G. and D. Crocker, "The Application Exchange (APEX) Presence Service", Work in Progress.
- [12] Newman, C. and G. Klyne, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
- [13] Elkins, M., Del Torto, D., Levien, R. and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.
- [14] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
Appendix A. Acknowledgements 💖
the authors gave a huge shoutout to everyone who helped make this happen 🫶 these legends contributed:
Jeffrey Altman, Harald Alvestrand, Eric Dixon, Ronan Klyne, Darren New, Chris Newman, Scott Pead, and Bob Wyman. ✨
Appendix B. IANA Considerations 🦋
okay so this is the part where IANA gets its registry homework 📋
The IANA has registered "APEX" as a standards-track BEEP profile, as specified in Section 8.1.
The IANA has registered "apex-mesh" as a TCP port number, as specified in Section 8.2.
The IANA has registered "apex-edge" as a TCP port number, as specified in Section 8.3.
The IANA maintains a list of:
- APEX options, c.f., Section 7.1;
- APEX services, c.f., Section 7.2; and,
- APEX endpoint applications, c.f., Section 7.3.
For each list, the IESG is responsible for assigning a designated expert to review the specification prior to the IANA making the assignment. As a courtesy to developers of non-standards track APEX options and services, the mailing list apexwg@invisible.net may be used to solicit commentary. 🌈
The IANA makes the registrations specified in Section 8.4 and Section 8.5. 🎀
Authors' Addresses 👯
here's where you can find the people who wrote this 💜
Marshall T. Rose
Dover Beach Consulting, Inc.
POB 255268
Sacramento, CA 95865-5268
US
Phone: +1 916 483 8878
EMail: mrose@dbc.mtview.ca.us
Graham Klyne
Clearswift Corporation
1310 Waterside
Arlington Business Park
Theale, Reading RG7 4SA
UK
Phone: +44 11 8903 8903
EMail: Graham.Klyne@MIMEsweeper.com
David H. Crocker
Brandenburg InternetWorking
675 Spruce Drive
Sunnyvale, CA 94086
US
Phone: +1 408 246 8253
EMail: dcrocker@brandenburg.com
URI: http://www.brandenburg.com/Full Copyright Statement ⚖️
this one's the legal stuff, so I've kept it word for word so nothing gets lost in translation 🙈
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Acknowledgement 🌸
last but not least, the RFC Editor function gets its funding from the Internet Society, so that's who keeps the lights on 💡
Funding for the RFC Editor function is currently provided by the Internet Society. ✨
📦 where this page comes from
- ietf: rfc3340 2002-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms