Invisible Worlds, Inc.

131 Stony Circle Suite 500 Santa Rosa CA 95401 US +1 707 578 2350 mrose@invisible.net http://invisible.net/

Applications application protocols BEEP BXXP application framework This memo describes a generic application protocol kernel for connection-oriented, asynchronous interactions called the BEEP (Blocks Extensible Exchange Protocol) core. BEEP permits simultaneous and independent exchanges within the context of a single application user-identity, supporting both textual and binary messages.

This memo describes a generic application protocol kernel for connection-oriented, asynchronous interactions called BEEP. At BEEP's core is a framing mechanism that permits simultaneous and independent exchanges of messages between peers. Messages are arbitrary MIME content, but are usually textual (structured using XML). All exchanges occur in the context of a channel — a binding to a well-defined aspect of the application, such as transport security, user authentication, or data exchange. Each channel has an associated "profile" that defines the syntax and semantics of the messages exchanged. Implicit in the operation of BEEP is the notion of channel management. In addition to defining BEEP's channel management profile, this document defines: the TLS transport security profile; and, the SASL family of profiles. Other profiles, such as those used for data exchange, are defined by an application protocol designer.

A BEEP session is mapped onto an underlying transport service. A separate series of documents describe how a particular transport service realizes a BEEP session. For example, describes how a BEEP session is mapped onto a single TCP connection. When a session is established, each BEEP peer advertises the profiles it supports. Later on, during the creation of a channel, the client supplies one or more proposed profiles for that channel. If the server creates the channel, it selects one of the profiles and sends it in a reply; otherwise, it may indicate that none of the profiles are acceptable, and decline creation of the channel. Channel usage falls into one of two categories: these are used by profiles that perform initialization once the BEEP session is established (e.g., negotiating the use of transport security); although several exchanges may be required to perform the initialization, these channels become inactive early in the BEEP session and remain so for the duration. these are used by profiles that support data exchange; typically, these channels are created after the initial tuning channels have gone quiet. Note that because of their special nature, only one tuning channel may be established at any given time; in contrast, BEEP allows multiple data exchange channels to be simultaneously in use.

Although BEEP is peer-to-peer, it is convenient to label each peer in the context of the role it is performing at a given time: When a BEEP session is established, the peer that awaits new connections is acting in the listening role, and the other peer, which establishes a connection to the listener, is acting in the initiating role. In the examples which follow, these are referred to as "L:" and "I:", respectively. A BEEP peer starting an exchange is termed the client; similarly, the other BEEP peer is termed the server. In the examples which follow, these are referred to as "C:" and "S:", respectively. Typically, a BEEP peer acting in the server role is also acting in a listening role. However, because BEEP is peer-to-peer in nature, no such requirement exists.

BEEP allows three styles of exchange: the client sends a "MSG" message asking the server to perform some task, the server performs the task and replies with a "RPY" message (termed a positive reply). the client sends a "MSG" message, the server does not perform any task and replies with an "ERR" message (termed a negative reply). the client sends a "MSG" message, the server, during the course of performing some task, replies with zero or more "ANS" messages, and, upon completion of the task, sends a "NUL" message, which signifies the end of the reply. The first two styles are termed one-to-one exchanges, whilst the third style is termed a one-to-many exchange.

A message is structured according to the rules of MIME. Accordingly, each message may begin with "entity-headers" (c.f., MIME's Section 3). If none, or only some, of the "entity-headers" are present: the default "Content-Type" is "application/octet-stream"; and, the default "Content-Transfer-Encoding" is "binary". Normally, a message is sent in a single frame. However, it may be convenient or necessary to segment a message into multiple frames (e.g., if only part of a message is ready to be sent). Each frame consists of a header, the payload, and a trailer. The header and trailer are each represented using printable ASCII characters and are terminated with a CRLF pair. Between the header and the trailer is the payload, consisting of zero or more octets.

For example, here is a message contained in a single frame that contains a payload of 120 octets spread over 5 lines (each line is terminated with a CRLF pair): C: MSG 0 1 . 52 120 C: Content-Type: application/beep+xml C: C: <start number='1'> C: <profile uri='http://iana.org/beep/SASL/OTP' /> C: </start> C: END In this example, note that the entire message is represented in a single frame.

The ABNF for a frame is: frame = data / mapping data = header payload trailer header = msg / rpy / err / ans / nul msg = "MSG" SP common CR LF rpy = "RPY" SP common CR LF ans = "ANS" SP common SP ansno CR LF err = "ERR" SP common CR LF nul = "NUL" SP common CR LF common = channel SP msgno SP more SP seqno SP size channel = 0..2147483647 msgno = 0..2147483647 more = "." / "*" seqno = 0..4294967295 size = 0..2147483647 ansno = 0..2147483647 payload = *OCTET trailer = "END" CR LF mapping = ;; each transport mapping may define additional frames

The frame header consists of a three-character keyword (one of: "MSG", "RPY", "ERR", "ANS", or "NUL"), followed by zero or more parameters. A single space character (decimal code 32, " ") separates each component. The header is terminated with a CRLF pair. The channel number ("channel") must be a non-negative integer (in the range 0..2147483647). The message number ("msgno") must be a non-negative integer (in the range 0..2147483647) and have a different value than all other "MSG" messages on the same channel for which a reply has not been completely received. The continuation indicator ("more", one of: decimal code 42, "*", or decimal code 46, ".") specifies whether this is the final frame of the message: at least one other frame follows for the message; or, this frame completes the message. The sequence number ("seqno") must be a non-negative integer (in the range 0..4294967295) and specifies the sequence number of the first octet in the payload, for the associated channel (c.f., ). The payload size ("size") must be a non-negative integer (in the range 0..2147483647) and specifies the exact number of octets in the payload. (This does not include either the header or trailer.)

Note that a frame may have an empty payload, e.g., S: RPY 0 1 * 287 20 S: ... S: ... S: END S: RPY 0 1 . 307 0 S: END

The answer number ("ansno") must be a non-negative integer (in the range 0..4294967295) and must have a different value than all other answers in progress for the message being replied to. There are two kinds of frames: data and mapping. Each transport mapping (c.f., ) may define its own frames. For example, defines the SEQ frame. The remainder of this section discusses data frames.

When a message is segmented and sent as several frames, those frames must be sent sequentially, without any intervening frames from other messages on the same channel. However, there are two exceptions: first, no restriction is made with respect to the interleaving of frames for other channels; and, second, in a one-to-many exchange, multiple answers may be simultaneously in progress. Accordingly, frames for "ANS" messages may be interleaved on the same channel — the answer number is used for collation, e.g., S: ANS 1 0 * 0 20 0 S: ... S: ... S: END S: ANS 1 0 * 20 20 1 S: ... S: ... S: END S: ANS 1 0 . 40 10 0 S: ... S: END which shows two "ANS" messages interleaved on channel 1 as part of a reply to message number 0. Note that the sequence number is advanced for each frame sent on the channel, and is independent of the messages sent in those frames.

There are several rules for identifying poorly-formed frames: if the header doesn't start with "MSG", "RPY", "ERR", "ANS", or "NUL"; if any of the parameters in the header cannot be determined or are invalid (i.e., syntactically incorrect); if the value of the channel number doesn't refer to an existing channel; if the header starts with "MSG", and the message number refers to a "MSG" message that has been completely received but for which a reply has not been completely sent; if the header doesn't start with "MSG", and refers to a message number for which a reply has already been completely received; if the header doesn't start with "MSG", and refers to a message number that has never been sent (except during session establishment, c.f., ); if the header starts with "MSG", "RPY", "ERR", or "ANS", and refers to a message number for which at least one other frame has been received, and the three-character keyword starting this frame and the immediately-previous received frame for this message number are not identical; if the header starts with "NUL", and refers to a message number for which at least one other frame has been received, and the keyword of of the immediately-previous received frame for this reply isn't "ANS"; if the continuation indicator of the previous frame received on the same channel was intermediate ("*"), and its message number isn't identical to this frame's message number; if the value of the sequence number doesn't correspond to the expected value for the associated channel (c.f., ); or, if the header starts with "NUL", and the continuation indicator is intermediate ("*") or the payload size is non-zero. If a frame is poorly-formed, then the session is terminated without generating a response, and it is recommended that a diagnostic entry be logged.

The frame payload consists of zero or more octets. Every payload octet sent in each direction on a channel has an associated sequence number. Numbering of payload octets within a frame is such that the first payload octet is the lowest numbered, and the following payload octets are numbered consecutively. (When a channel is created, the sequence number associated with the first payload octet of the first frame is 0.) The actual sequence number space is finite, though very large, ranging from 0..4294967295 (2**32 - 1). Since the space is finite, all arithmetic dealing with sequence numbers is performed modulo 2**32. This unsigned arithmetic preserves the relationship of sequence numbers as they cycle from 2**32 - 1 to 0 again. Consult Sections 2 through 5 of for a discussion of the arithmetic properties of sequence numbers. When receiving a frame, the sum of its sequence number and payload size, modulo 4294967296 (2**32), gives the expected sequence number associated with the first payload octet of the next frame received. Accordingly, when receiving a frame if the sequence number isn't the expected value for this channel, then the BEEP peers have lost synchronization, then the session is terminated without generating a response, and it is recommended that a diagnostic entry be logged.

The frame trailer consists of "END" followed by a CRLF pair. When receiving a frame, if the characters immediately following the payload don't correspond to a trailer, then the session is terminated without generating a response, and it is recommended that a diagnostic entry be logged.

The semantics of each message is channel-specific. Accordingly, the profile associated with a channel must define: the initialization messages, if any, exchanged during channel creation; the messages that may be exchanged in the payload of the channel; and, the semantics of these messages. A profile registration template organizes this information.

When defining the behavior of the profile, the template must specify how poorly-formed "MSG" messages are replied to. For example, the channel management profile sends a negative reply containing an error message (c.f., ). If a poorly-formed reply is received on channel zero, the session is terminated without generating a response, and it is recommended that a diagnostic entry be logged. If a poorly-formed reply is received on another channel, then the channel must be closed using the procedure in .

When a BEEP session starts, only channel number zero is defined, which is used for channel management. contains the profile registration for BEEP channel management. Channel management allows each BEEP peer to advertise the profiles that it supports (c.f., ), bind an instance of one of those profiles to a channel (c.f., ), and then later close any channels or release the BEEP session (c.f., ). A BEEP peer should support at least 257 concurrent channels.

When a BEEP session is established, each BEEP peer signifies its availability by immediately sending a positive reply with a message number of zero that contains a "greeting" element, e.g., L: <wait for incoming connection> I: <open connection> L: RPY 0 0 . 0 110 L: Content-Type: application/beep+xml L: L: <greeting> L: <profile uri='http://iana.org/beep/TLS' /> L: </greeting> L: END I: RPY 0 0 . 0 52 I: Content-Type: application/beep+xml I: I: <greeting /> I: END Note that this example implies that the BEEP peer in the initiating role waits until the BEEP peer in the listening role sends its greeting — this is an artifact of the presentation; in fact, both BEEP peers send their replies independently.

The "greeting" element has two optional attributes ("features" and "localize") and zero or more "profile" elements, one for each profile supported by the BEEP peer acting in a server role: the "features" attribute, if present, contains one or more feature tokens, each indicating an optional feature of the channel management profile supported by the BEEP peer; the "localize" attribute, if present, contains one or more language tokens (defined in ), each identifying a desirable language tag to be used by the remote BEEP peer when generating textual diagnostics for the "close" and "error" elements (the tokens are ordered from most to least desirable); and, each "profile" element contained within the "greeting" element identifies a profile, and unlike the "profile" elements that occur within the "start" element, the content of each "profile" element may not contain an optional initialization message. defines a registration template for optional features.

When a BEEP peer wants to create a channel, it sends a "start" element on channel zero, e.g., C: MSG 0 1 . 52 120 C: Content-Type: application/beep+xml C: C: <start number='1'> C: <profile uri='http://iana.org/beep/SASL/OTP' /> C: </start> C: END

The "start" element has a "number" attribute, an optional "serverName" attribute, and one or more "profile" elements: the "number" attribute indicates the channel number (in the range 1..2147483647) used to identify the channel in future messages; the "serverName" attribute, an arbitrary string, indicates the desired server name for this BEEP session; and, each "profile" element contained with the "start" element has a "uri" attribute, an optional "encoding" attribute, and arbitrary character data as content: the "uri" attribute authoritatively identifies the profile; the "encoding" attribute, if present, specifies whether the content of the "profile" element is represented as a base64-encoded string; and, the content of the "profile" element, if present, must be no longer than 4K octets in length and specifies an initialization message given to the channel as soon as it is created. To avoid conflict in assigning channel numbers when requesting the creation of a channel, BEEP peers acting in the initiating role use only positive integers that are odd-numbered; similarly, BEEP peers acting in the listening role use only positive integers that are even-numbered. The "serverName" attribute for the first successful "start" element received by a BEEP peer is meaningful for the duration of the BEEP session. If present, the BEEP peer decides whether to operate as the indicated "serverName"; if not, an "error" element is sent in a negative reply. When a BEEP peer receives a "start" element on channel zero, it examines each of the proposed profiles, and decides whether to use one of them to create the channel. If so, the appropriate "profile" element is sent in a positive reply; otherwise, an "error" element is sent in a negative reply. When creating the channel, the value of the "serverName" attribute from the first successful "start" element is consulted to provide configuration information, e.g., the desired server-side certificate when starting the TLS transport security profile.

For example, a successful channel creation might look like this: C: MSG 0 1 . 52 178 C: Content-Type: application/beep+xml C: C: <start number='1'> C: <profile uri='http://iana.org/beep/SASL/OTP' /> C: <profile uri='http://iana.org/beep/SASL/ANONYMOUS' /> C: </start> C: END S: RPY 0 1 . 221 87 S: Content-Type: application/beep+xml S: S: <profile uri='http://iana.org/beep/SASL/OTP' /> S: END

Similarly, an unsuccessful channel creation might look like this: C: MSG 0 1 . 52 120 C: Content-Type: application/beep+xml C: C: <start number='2'> C: <profile uri='http://iana.org/beep/SASL/OTP' /> C: </start> C: END S: ERR 0 1 . 221 127 S: Content-Type: application/beep+xml S: S: <error code='501'>number attribute S: in &lt;start&gt; element must be odd-valued</error> S: END

Finally, here's an example in which an initialization element is exchanged during channel creation: C: MSG 0 1 . 52 158 C: Content-Type: application/beep+xml C: C: <start number='1'> C: <profile uri='http://iana.org/beep/TLS'> C: <![CDATA[<ready />]]> C: </profile> C: </start> C: END S: RPY 0 1 . 110 121 S: Content-Type: application/beep+xml S: S: <profile uri='http://iana.org/beep/TLS'> S: <![CDATA[<proceed />]]> S: </profile> S: END

When a BEEP peer wants to close a channel, it sends a "close" element on channel zero, e.g., C: MSG 0 2 . 235 71 C: Content-Type: application/beep+xml C: C: <close number='1' code='200' /> C: END

The "close" element has a "number" attribute, a "code" attribute, an optional "xml:lang" attribute, and an optional textual diagnostic as its content: the "number" attribute indicates the channel number; the "code" attribute is a three-digit reply code meaningful to programs (c.f., ); the "xml:lang" attribute identifies the language that the element's content is written in (the value is suggested, but not mandated, by the "localize" attribute of the "greeting" element sent by the remote BEEP peer); and, the textual diagnostic (which may be multiline) is meaningful to implementers, perhaps administrators, and possibly even users, but never programs. Note that if the textual diagnostic is present, then the "xml:lang" attribute is absent only if the language indicated as the remote BEEP peer's first choice is used. If the value of the "number" attribute is zero, then the BEEP peer wants to release the BEEP session (c.f., ) — otherwise the value of the "number" attribute refers to an existing channel, and the remainder of this section applies. A BEEP peer may send a "close" message for a channel whenever all "MSG" messages it has sent on that channel have been acknowledged. (Acknowledgement consists of the first frame of a reply being received by the BEEP peer that sent the MSG "message".) After sending the "close" message, that BEEP peer must not send any more "MSG" messages on that channel being closed until the reply to the "close" message has been received (either by an "error" message rejecting the request to close the channel, or by an "ok" message subsequently followed by the channel being successfully started). NOTE WELL: until a positive reply to the request to close the channel is received, the BEEP peer must be prepared to process any "MSG" messages that it receives on that channel. When a BEEP peer receives a "close" message for a channel, it may, at any time, reject the request to close the channel by sending an "error" message in a negative reply. Otherwise, before accepting the request to close the channel, and sending an "ok" message in a positive reply, it must: finish sending any queued "MSG" messages on that channel of its own; await complete replies to any outstanding "MSG" messages it has sent on that channel; and, finish sending complete replies to any outstanding "MSG" messages it has received on that channel, and ensure that the final frames of those replies have been successfully delivered, i.e., for transport mappings that guarantee inter-channel ordering of messages, the replies must be sent prior to sending the "ok" message in a positive reply; otherwise, the replies must be sent and subsequently acknowledged by the underlying transport service prior to sending the "ok" message in a positive reply.

Briefly, a successful channel close might look like this: C: MSG 0 2 . 235 71 C: Content-Type: application/beep+xml C: C: <close number='1' code='200' /> C: END S: RPY 0 2 . 392 46 S: Content-Type: application/beep+xml S: S: <ok /> S: END

Similarly, an unsuccessful channel close might look like this: C: MSG 0 2 . 235 71 C: Content-Type: application/beep+xml C: C: <close number='1' code='200' /> C: END S: ERR 0 2 . 392 79 S: Content-Type: application/beep+xml S: S: <error code='550'>still working</error> S: END

When a BEEP peer agrees to close a channel (or release the BEEP session), it sends an "ok" element in a positive reply. The "ok" element has no attributes and no content.

When a BEEP peer declines the creation of a channel, it sends an "error" element in a negative reply, e.g., I: MSG 0 1 . 52 115 I: Content-Type: application/beep+xml I: I: <start number='2'> I: <profile uri='http://iana.org/beep/FOO' /> I: </start> I: END L: ERR 0 1 . 221 105 L: Content-Type: application/beep+xml L: L: <error code='550'>all requested profiles are L: unsupported</error> L: END

The "error" element has a "code" attribute, an optional "xml:lang" attribute, and an optional textual diagnostic as its content: the "code" attribute is a three-digit reply code meaningful to programs (c.f., ); the "xml:lang" attribute identifies the language that the element's content is written in (the value is suggested, but not mandated, by the "localize" attribute of the "greeting" element sent by the remote BEEP peer); and, the textual diagnostic (which may be multiline) is meaningful to implementers, perhaps administrators, and possibly even users, but never programs. Note that if the textual diagnostic is present, then the "xml:lang" attribute is absent only if the language indicated as the remote BEEP peer's first choice is used. In addition, a BEEP peer sends an "error" element whenever: it receives a "MSG" message containing a poorly-formed or unexpected element; it receives a "MSG" message asking to close a channel (or release the BEEP session) and it declines to do so; or a BEEP session is established, the BEEP peer is acting in the listening role, and that BEEP peer is unavailable (in this case, the BEEP acting in the listening role does not send a "greeting" element). In the final case, both BEEP peers terminate the session, and it is recommended that a diagnostic entry be logged by both BEEP peers.

When a BEEP session is established, each BEEP peer signifies its availability by immediately sending a positive reply with a message number of zero on channel zero that contains a "greeting" element, e.g., L: <wait for incoming connection> I: <open connection> L: RPY 0 0 . 0 110 L: Content-Type: application/beep+xml L: L: <greeting> L: <profile uri='http://iana.org/beep/TLS' /> L: </greeting> L: END I: RPY 0 0 . 0 52 I: Content-Type: application/beep+xml I: I: <greeting /> I: END

Alternatively, if the BEEP peer acting in the listening role is unavailable, it sends a negative reply, e.g., L: <wait for incoming connection> I: <open connection> L: ERR 0 0 . 0 60 L: Content-Type: application/beep+xml L: L: <error code='421' /> L: END I: RPY 0 0 . 0 52 I: Content-Type: application/beep+xml I: I: <greeting /> I: END I: <close connection> L: <close connection> L: <wait for next connection> and the "greeting" element sent by the BEEP peer acting in the initiating role is ignored. It is recommended that a diagnostic entry be logged by both BEEP peers.

Note that both of these examples imply that the BEEP peer in the initiating role waits until the BEEP peer in the listening role sends its greeting — this is an artifact of the presentation; in fact, both BEEP peers send their replies independently.

When a BEEP peer wants to release the BEEP session, it sends a "close" element with a zero-valued "number" attribute on channel zero. The other BEEP peer indicates its willingness by sending an "ok" element in a positive reply, e.g., C: MSG 0 1 . 52 60 C: Content-Type: application/beep+xml C: C: <close code='200' /> C: END S: RPY 0 1 . 264 46 S: Content-Type: application/beep+xml S: S: <ok /> S: END I: <close connection> L: <close connection> L: <wait for next connection>

Alternatively, if the other BEEP doesn't want to release the BEEP session, the exchange might look like this: C: MSG 0 1 . 52 60 C: Content-Type: application/beep+xml C: C: <close code='200' /> C: END S: ERR 0 1 . 264 79 S: Content-Type: application/beep+xml S: S: <error code='550'>still working</error> S: END If session release is declined, the BEEP session should not be terminated, if possible.

All transport interactions occur in the context of a session — a mapping onto a particular transport service. Accordingly, this memo defines the requirements that must be satisfied by any document describing how a particular transport service realizes a BEEP session.

A BEEP session is connection-oriented. A mapping document must define: how a BEEP session is established; how a BEEP peer is identified as acting in the listening role; how a BEEP peer is identified as acting in the initiating role; how a BEEP session is released; and, how a BEEP session is terminated.

A BEEP session is message-oriented. A mapping document must define: how messages are reliably sent and received; how messages on the same channel are received in the same order as they were sent; and, how messages on different channels are sent without ordering constraint.

BEEP accommodates asynchronous interactions, both within a single channel and between separate channels. This feature allows pipelining (intra-channel) and parallelism (inter-channel).

A BEEP peer acting in the client role may send multiple "MSG" messages on the same channel without waiting to receive the corresponding replies. This provides pipelining within a single channel. A BEEP peer acting in the server role must process all "MSG" messages for a given channel in the same order as they are received. As a consequence, the BEEP peer must generate replies in the same order as the corresponding "MSG" messages are received on a given channel. Note that in one-to-many exchanges (c.f., ), the reply to the "MSG" message consists of zero or more "ANS" messages followed by a "NUL" message. In this style of exchange, the "ANS" messages comprising the reply may be interleaved. When the BEEP peer acting in the server role signifies the end of the reply by generating the "NUL" message, it may then process the next "MSG" message received for that channel.

A BEEP peer acting in the client role may send multiple "MSG" messages on different channels without waiting to receive the corresponding replies. The channels operate independently, in parallel. A BEEP peer acting in the server role may process "MSG" messages received on different channels in any order it chooses. As a consequence, although the replies for a given channel appear to be generated in the same order in which the corresponding "MSG" messages are received, there is no ordering constraint for replies on different channels.

A BEEP peer acting in the server role may send a negative reply before it receives the final "MSG" frame of a message. If it does so, that BEEP peer is obliged to ignore any subsequent "MSG" frames for that message, up to and including the final "MSG" frame. If a BEEP peer acting in the client role receives a negative reply before it sends the final "MSG" frame for a message, then it is required to send a "MSG" frame with a continuation status of complete (".") and having a zero-length payload.

If the processing of a particular message has sequencing impacts on other messages (either intra-channel or inter-channel), then the corresponding profile should define this behavior, e.g., a profile whose messages alter the underlying transport mapping.

BEEP is peer-to-peer — as such both peers must be prepared to receive all messages defined in this memo. Accordingly, an initiating BEEP peer capable of acting only in the client role must behave gracefully if it receives a "MSG" message. Accordingly, all profiles must provide an appropriate error message for replying to unexpected "MSG" messages. As a consequence of the peer-to-peer nature of BEEP, message numbers are unidirectionally-significant. That is, the message numbers in "MSG" messages sent by a BEEP peer acting in the initiating role are unrelated to the message numbers in "MSG" messages sent by a BEEP peer acting in the listening role.

For example, these two messages I: MSG 0 1 . 52 120 I: Content-Type: application/beep+xml I: I: <start number='1'> I: <profile uri='http://iana.org/beep/SASL/OTP' /> I: </start> I: END L: MSG 0 1 . 221 116 L: Content-Type: application/beep+xml L: L: <start number='2'> L: <profile uri='http://iana.org/beep/APEX' /> L: </start> L: END refer to different messages sent on channel zero.

When a BEEP session is established, plaintext transfer, without privacy, is provided. Accordingly, transport security in BEEP is achieved using an initial tuning profile. This document defines one profile: the TLS transport security profile, based on TLS version one. Other profiles may be defined and deployed on a bilateral basis. Note that because of their intimate relationship with the transport service, a given transport security profile tends to be relevant to a single transport mapping (c.f., ). When a channel associated with transport security begins the underlying negotiation process, all channels (including channel zero) are closed on the BEEP session. Accordingly, upon completion of the negotiation process, regardless of its outcome, a new greeting is issued by both BEEP peers. (If the negotiation process fails, then either BEEP peer may instead terminate the session, and it is recommended that a diagnostic entry be logged.)

A BEEP peer may choose to issue different greetings based on whether privacy is in use, e.g., L: <wait for incoming connection> I: <open connection> L: RPY 0 0 . 0 110 L: Content-Type: application/beep+xml L: L: <greeting> L: <profile uri='http://iana.org/beep/TLS' /> L: </greeting> L: END I: RPY 0 0 . 0 52 I: Content-Type: application/beep+xml I: I: <greeting /> I: END I: MSG 0 1 . 52 158 I: Content-Type: application/beep+xml I: I: <start number='1'> I: <profile uri='http://iana.org/beep/TLS'> I: <![CDATA[<ready />]]> I: </profile> I: </start> I: END L: RPY 0 1 . 110 121 L: Content-Type: application/beep+xml L: L: <profile uri='http://iana.org/beep/TLS'> L: <![CDATA[<proceed />]]> L: </profile> L: END ... successful transport security negotiation ... L: RPY 0 0 . 0 221 L: Content-Type: application/beep+xml L: L: <greeting> L: <profile uri='http://iana.org/beep/SASL/ANONYMOUS' /> L: <profile uri='http://iana.org/beep/SASL/OTP' /> L: <profile uri='http://iana.org/beep/APEX' /> L: </greeting> L: END I: RPY 0 0 . 0 52 I: Content-Type: application/beep+xml I: I: <greeting /> I: END

Of course, not all BEEP peers need be as single-minded: L: <wait for incoming connection> I: <open connection> L: RPY 0 0 . 0 268 L: Content-Type: application/beep+xml L: L: <greeting> L: <profile uri='http://iana.org/beep/SASL/ANONYMOUS' /> L: <profile uri='http://iana.org/beep/SASL/OTP' /> L: <profile uri='http://iana.org/beep/APEX' /> L: <profile uri='http://iana.org/beep/TLS' /> L: </greeting> L: END I: RPY 0 0 . 0 52 I: Content-Type: application/beep+xml I: I: <greeting /> I: END I: MSG 0 1 . 52 158 I: Content-Type: application/beep+xml I: I: <start number='1'> I: <profile uri='http://iana.org/beep/TLS'> I: <![CDATA[<ready />]]> I: </profile> I: </start> I: END L: RPY 0 1 . 268 121 L: Content-Type: application/beep+xml L: L: <profile uri='http://iana.org/beep/TLS'> L: <![CDATA[<proceed />]]> L: </profile> L: END ... failed transport security negotiation ... L: RPY 0 0 . 0 268 L: Content-Type: application/beep+xml L: L: <greeting> L: <profile uri='http://iana.org/beep/SASL/ANONYMOUS' /> L: <profile uri='http://iana.org/beep/SASL/OTP' /> L: <profile uri='http://iana.org/beep/APEX' /> L: <profile uri='http://iana.org/beep/TLS' /> L: </greeting> L: END I: RPY 0 0 . 0 52 I: Content-Type: application/beep+xml I: I: <greeting /> I: END

contains the registration for this profile.

The TLS transport security profile is identified as: http://iana.org/beep/TLS in the BEEP "profile" element during channel creation.

During channel creation, the corresponding "profile" element in the BEEP "start" element may contain a "ready" element. If channel creation is successful, then before sending the corresponding reply, the BEEP peer processes the "ready" element and includes the resulting response in the reply, e.g., C: MSG 0 1 . 52 158 C: Content-Type: application/beep+xml C: C: <start number='1'> C: <profile uri='http://iana.org/beep/TLS'> C: <![CDATA[<ready />]]> C: </profile> C: </start> C: END S: RPY 0 1 . 110 121 S: Content-Type: application/beep+xml S: S: <profile uri='http://iana.org/beep/TLS'> S: <![CDATA[<proceed />]]> S: </profile> S: END

Note that it is possible for the channel to be created, but for the encapsulated operation to fail, e.g., C: MSG 0 1 . 52 173 C: Content-Type: application/beep+xml C: C: <start number='1'> C: <profile uri='http://iana.org/beep/TLS'> C: <![CDATA[<ready version="oops" />]]> C: </profile> C: </start> C: END S: RPY 0 1 . 110 193 S: Content-Type: application/beep+xml S: S: <profile uri='http://iana.org/beep/TLS'> S: <![CDATA[<error code='501'>version attribute S: poorly formed in &lt;ready&gt; element</error>]]> S: </profile> S: END In this case, a positive reply is sent (as channel creation succeeded), but the encapsulated response contains an indication as to why the operation failed.

defines the messages that are used in the TLS transport security profile.

The "ready" element has an optional "version" attribute and no content: the "version" element defines the earliest version of TLS acceptable for use. When a BEEP peer sends the "ready" element, it must not send any further traffic on the underlying transport service until a corresponding reply ("proceed" or "error") is received; similarly, the receiving BEEP peer must wait until any pending replies have been generated and sent before it processes a "ready" element.

The "proceed" element has no attributes and no content. It is sent as a reply to the "ready" element. When a BEEP peer receives the "ready" element, it must not send any further traffic on the underlying transport service until it generates a corresponding reply. If the BEEP peer decides to allow transport security negotiation, it implicitly closes all channels (including channel zero), and sends the "proceed" element, and awaits the underlying negotiation process for transport security. When a BEEP peer receives a "proceed" element in reply to its "ready" message, it implicitly closes all channels (including channel zero), and immediately begins the underlying negotiation process for transport security.

When a BEEP session is established, anonymous access, without trace information, is provided. Accordingly, user authentication in BEEP is achieved using an initial tuning profile. This document defines a family of profiles based on SASL mechanisms: each mechanism in the IANA SASL registry has an associated profile. Other profiles may be defined and deployed on a bilateral basis. Whenever a successful authentication occurs, on any channel, the authenticated identity is updated for all existing and future channels on the BEEP session; further, no additional attempts at authentication are allowed. Note that regardless of transport security and user authentication, authorization is an internal matter for each BEEP peer. As such, each peer may choose to restrict the operations it allows based on the authentication credentials provided (i.e., unauthorized operations might be rejected with error code 530).

contains the registration for this profile. Note that SASL may provide both user authentication and transport security. Once transport security is successfully negotiated for a BEEP session, then a SASL security layer must not be negotiated; similarly, once any SASL negotiation is successful, a transport security profile must not begin its underlying negotiation process. Section 4 of the SASL specification requires the following information be supplied by a protocol definition: "beep" Creating a channel using a BEEP profile corresponding to a SASL mechanism starts the exchange. An optional parameter corresponding to the "initial response" sent by the client is carried within a "blob" element during channel creation. "Challenges" and "responses" are carried in exchanges of the "blob" element. The "status" attribute of the "blob" element is used both by a server indicating a successful completion of the exchange, and a client aborting the exchange, The server indicates failure of the exchange by sending an "error" element. When a security layer starts negotiation, all channels (including channel zero) are closed on the BEEP session. Accordingly, upon completion of the negotiation process, regardless of its outcome, a new greeting is issued by both BEEP peers. If a security layer is successfully negotiated, it takes effect immediately following the message that concludes the server's successful completion reply. This is made available to all channels for the duration of the BEEP session.

Each SASL mechanism registered with the IANA is identified as: http://iana.org/beep/SASL/mechanism where "MECHANISM" is the token assigned to that mechanism by the IANA.

Note that during channel creation, a BEEP peer may provide multiple profiles to the remote peer, e.g., C: MSG 0 1 . 52 178 C: Content-Type: application/beep+xml C: C: <start number='1'> C: <profile uri='http://iana.org/beep/SASL/ANONYMOUS' /> C: <profile uri='http://iana.org/beep/SASL/OTP' /> C: </start> C: END S: RPY 0 1 . 221 87 S: Content-Type: application/beep+xml S: S: <profile uri='http://iana.org/beep/SASL/OTP' /> S: END

During channel creation, the corresponding "profile" element in the BEEP "start" element may contain a "blob" element. Note that it is possible for the channel to be created, but for the encapsulated operation to fail, e.g., C: MSG 0 1 . 52 183 C: Content-Type: application/beep+xml C: C: <start number='1'> C: <profile uri='http://iana.org/beep/SASL/OTP'> C: <![CDATA[<blob>AGJsb2NrbWFzdGVy</blob>]]> C: </profile> C: </start> C: END S: RPY 0 1 . 221 178 S: Content-Type: application/beep+xml S: S: <profile uri='http://iana.org/beep/SASL/OTP'> S: <![CDATA[<error code='534'>authentication mechanism is S: too weak</error>]]> S: </profile> S: END In this case, a positive reply is sent (as channel creation succeeded), but the encapsulated response contains an indication as to why the operation failed.

Otherwise, the server sends a challenge (or signifies success), e.g., C: MSG 0 1 . 52 183 C: Content-Type: application/beep+xml C: C: <start number='1'> C: <profile uri='http://iana.org/beep/SASL/OTP'> C: <![CDATA[<blob>AGJsb2NrbWFzdGVy</blob>]]> C: </profile> C: </start> C: END S: RPY 0 1 . 221 171 S: Content-Type: application/beep+xml S: S: <profile uri='http://iana.org/beep/SASL/OTP'> S: <![CDATA[<blob>b3RwLXNoYTEgOTk5NyBwaXh5bWlzYXM4NTgwNSBleHQ= </blob>]]> S: </profile> S: END Note that this example implies that the "blob" element in the server's reply appears on two lines — this is an artifact of the presentation; in fact, only one line is used.

If a challenge is received, then the client responds and awaits another reply, e.g., C: MSG 1 0 . 0 97 C: Content-Type: application/beep+xml C: C: <blob>d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n</blob> C: END S: RPY 1 0 . 0 66 S: Content-Type: application/beep+xml S: S: <blob status='complete' /> S: END Of course, the client could abort the authentication process by sending "<blob status='abort' />" instead.

Alternatively, the server might reject the response with an error: e.g., C: MSG 1 0 . 0 97 C: Content-Type: application/beep+xml C: C: <blob>d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n</blob> C: END S: ERR 1 0 . 0 60 S: Content-Type: application/beep+xml S: S: <error code='535' /> S: END

Finally, depending on the SASL mechanism, an initialization element may be exchanged unidirectionally during channel creation, e.g., C: MSG 0 1 . 52 125 C: Content-Type: application/beep+xml C: C: <start number='1'> C: <profile uri='http://iana.org/beep/SASL/CRAM-MD5' /> C: </start> C: END S: RPY 0 1 . 221 185 S: Content-Type: application/beep+xml S: S: <profile uri='http://iana.org/beep/SASL/CRAM-MD5'> S: <![CDATA[<blob>PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1 jaS5uZXQ+</blob>]]> S: </profile> S: END Note that this example implies that the "blob" element in the server's reply appears on two lines — this is an artifact of the presentation; in fact, only one line is used.

defines the messages that are used for each profile in the SASL family. Note that because many SASL mechanisms exchange binary data, the content of the "blob" element is always a base64-encoded string.

The "blob" element has an optional "status" attribute, and arbitrary octets as its content: the "status" attribute, if present, takes one of three values: used by a client to indicate that it is aborting the authentication process; used by a server to indicate that the exchange is complete and successful; or, used by either a client or server, otherwise. Finally, note that SASL's EXTERNAL mechanism works with an "external authentication" service, which is provided by one of: a transport security profile, capable of providing authentication information (e.g., ), being active on the connection; a network service, capable of providing strong authentication (e.g., IPSec), underlying the connection; or, a locally-defined security service. For authentication to succeed, two conditions must hold: an external authentication service must be active; and, if present, the authentication identity must be consistent with the credentials provided by the external authentication service (if the authentication identity is empty, then an authorization identity is automatically derived from the credentials provided by the external authentication service).

When a profile is registered, the following information is supplied: specify a URI that authoritatively identifies this profile. specify the datatypes that may be exchanged during channel creation. specify the datatypes that may be present when an exchange starts. specify the datatypes that may be present in a positive reply. specify the datatypes that may be present in a negative reply. specify the datatypes that may be present in a one-to-many exchange. specify the syntax of the datatypes exchanged by the profile. specify the semantics of the datatypes exchanged by the profile. specify the postal and electronic contact information for the author of the profile.

When a feature for the channel management profile is registered, the following information is supplied: specify a string that identifies this feature. Unless the feature is registered with the IANA, the feature's identification must start with "x-". specify the semantics of the feature. specify the postal and electronic contact information for the author of the feature.

not applicable not applicable "start" or "close" "greeting", "profile", or "ok" "error" none c.f., c.f., c.f., the "Author's Address" section of this memo

http://iana.org/beep/TLS "ready" "ready" "proceed" "error" none c.f., c.f., c.f., the "Author's Address" section of this memo

http://iana.org/beep/SASL/mechanism, where "mechanism" is a token registered with the IANA "blob" "blob" "blob" "error" none c.f., c.f., c.f., the "Author's Address" section of this memo

application beep+xml none charset (defaults to "UTF-8") This media type may contain binary content; accordingly, when used over a transport that does not permit binary transfer, an appropriate encoding must be applied none, per se; however, any BEEP profile which uses this media type must describe its relevant security considerations n/a This media type is a proper subset of the the XML 1.0 specification. Two restrictions are made. First, no entity references other than the five predefined general entities references ("&amp;", "&lt;", "&gt;", "&apos;", and "&quot;") and numeric entity references may be present. Second, nor the "DOCTYPE" declaration (e.g., <!DOCTYPE ...>) may be present. (Accordingly, if another character set other than UTF-8 is desired, then the "charset" parameter must be present.) All other XML 1.0 instructions (e.g., CDATA blocks, processing instructions, and so on) are allowed. any BEEP profile wishing to make use of this XML 1.0 subset none c.f., the "Author's Address" section of this memo limited use the IESG

<!-- DTD for BEEP Channel Management, as of 2000-10-29 Refer to this DTD as: <!ENTITY % BEEP PUBLIC "-//IETF//DTD BEEP//EN" "http://xml.resource.org/profiles/BEEP/beep.dtd"> %BEEP; --> <!-- DTD data types: entity syntax/reference example ====== ================ ======= a channel number CHAN 1..2147483647 1 authoritative profile identification URI c.f., [RFC-2396] http://invisible.net/ one or more feature tokens, separated by space FTRS NMTOKENS "magic" a language tag LANG c.f., [RFC-1766] "en", "en-US", etc. zero or more language tags LOCS NMTOKENS "en-US" a 3-digit reply code XYZ [1-5][0-9][0-9] 500 --> <!ENTITY % CHAN "CDATA"> <!ENTITY % URI "CDATA"> <!ENTITY % FTRS "NMTOKENS"> <!ENTITY % LANG "NMTOKEN"> <!ENTITY % LOCS "NMTOKEN"> <!ENTITY % XYZ "CDATA"> <!-- BEEP messages, exchanged as application/beep+xml role MSG RPY ERR ======= === === === I and L greeting error I or L start profile error I or L close ok error --> <!ELEMENT greeting (profile)*> <!ATTLIST greeting features %FTRS; #IMPLIED localize %LOCS; "i-default"> <!ELEMENT start (profile)+> <!ATTLIST start number %CHAN; #REQUIRED serverName CDATA #IMPLIED> <!-- profile element is empty if contained in a greeting --> <!ELEMENT profile (#PCDATA)> <!ATTLIST profile uri %URI; #REQUIRED encoding (none|base64) "none"> <!ELEMENT close (#PCDATA)> <!ATTLIST close number %CHAN; "0" code %XYZ; #REQUIRED xml:lang %LANG; #IMPLIED> <!ELEMENT ok EMPTY> <!ELEMENT error (#PCDATA)> <!ATTLIST error code %XYZ; #REQUIRED xml:lang %LANG; #IMPLIED>

<!-- DTD for the TLS Transport Security Profile, as of 2000-09-04 Refer to this DTD as: <!ENTITY % TLS PUBLIC "-//IETF//DTD TLS//EN" "http://xml.resource.org/profiles/TLS/tls.dtd"> %TLS; --> <!-- TLS messages, exchanged as application/beep+xml role MSG RPY ERR ====== === === === I or L ready proceed error --> <!ELEMENT ready EMPTY> <!ATTLIST ready version CDATA "1"> <!ELEMENT proceed EMPTY>

<!-- DTD for the SASL Family of Profiles, as of 2000-09-04 Refer to this DTD as: <!ENTITY % SASL PUBLIC "-//IETF//DTD SASL//EN" "http://xml.resource.org/profiles/sasl/sasl.dtd"> %SASL; --> <!-- SASL messages, exchanged as application/beep+xml role MSG RPY ERR ====== === === === I or L blob blob error --> <!ELEMENT blob (#PCDATA)> <!ATTLIST blob xml:space (default|preserve) "preserve" status (abort|complete|continue) "continue">

code meaning ==== ======= 200 success 421 service not available 450 requested action not taken (e.g., lock already in use) 451 requested action aborted (e.g., local error in processing) 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 (e.g., too weak, sequence exhausted, etc.) 535 authentication failure 537 action not authorized for user 538 authentication mechanism requires encryption 550 requested action not taken (e.g., no requested profiles are acceptable) 553 parameter invalid 554 transaction failed (e.g., policy violation)

The BEEP framing mechanism, per se, provides no protection against attack; however, judicious use of initial tuning profiles provides varying degrees of assurance: If one of the profiles from the SASL family is used, refer to 's Section 9 for a discussion of security considerations. If the TLS transport security profile is used (or if a SASL security layer is negotiated), then: A man-in-the-middle may remove the security-related profiles from the BEEP greeting or generate a negative reply to the "ready" element of the TLS transport security profile. A BEEP peer may be configurable to refuse to proceed without an acceptable level of privacy. A man-in-the-middle may cause a down-negotiation to the weakest cipher suite available. A BEEP peer should be configurable to refuse weak cipher suites. A man-in-the-middle may modify any protocol exchanges prior to a successful negotiation. Upon completing the negotiation, a BEEP peer must discard previously cached information about the BEEP session. As different TLS ciphersuites provide varying levels of security, administrators should carefully choose which ciphersuites are provisioned. As BEEP is peer-to-peer in nature, before performing any task associated with a message, each channel should apply the appropriate access control based on the authenticated identity and privacy level associated with the BEEP session.

Innosoft International, Inc.

1050 East Garvey Avenue South West Covina CA 91790 US +1 818 919 3600 +1 818 919 3614 ned@innosoft.com

First Virtual Holdings

25 Washington Avenue Morristown NJ 07960 US +1 201 540 8967 +1 201 993 3032 nsb@nsb.fv.com

STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for (1) textual message bodies in character sets other than US-ASCII, (2) an extensible set of different formats for non-textual message bodies, (3) multi-part message bodies, and (4) textual header information in character sets other than US-ASCII. These documents are based on earlier work documented in RFC 934, STD 11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822. This initial document specifies the various headers used to describe the structure of MIME messages. The second document, RFC 2046, defines the general structure of the MIME media typing system and defines an initial set of media types. The third document, RFC 2047, describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. The fourth document, RFC 2048, specifies various IANA registration procedures for MIME-related facilities. The fifth and final document, RFC 2049, describes MIME conformance criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography. These documents are revisions of RFCs 1521, 1522, and 1590, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC 2049 describes differences and changes from previous versions. World Wide Web Consortium

MIT Laboratory for Computer Science 545 Technology Square Cambridge MA 02139 US + 1 617 253 2613 + 1 617 258 5999 timbl@w3.org http://www.w3c.org

Certicom

tdierks@certicom.com

Certicom

callen@certicom.com

Open Market

treese@openmarket.com

Netscape Communications

Netscape Communications

freier@netscape.com

Independent Consultant

pck@netcom.com

This document specifies Version 1.0 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. Netscape Communications

501 E. Middlefield Road Mail Stop MV-029 Mountain View CA 94043-4042 jgmyers@netscape.com

Security authentication security Invisible Worlds, Inc.

131 Stony Circle Suite 500 Santa Rosa CA 95401 US +1 707 578 2350 mrose@invisible.net http://invisible.net/

Applications application protocols BEEP BXXP transport mapping This memo describes how a BEEP (Blocks Extensible Exchange Protocol) session is mapped onto a single TCP (Transmission Control Protocol) connection. Defense Advanced Research Projects Agency (DARPA), Information Processing Techniques Office

1400 Wilson Boulevard Arlington VA 22209 US

University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US

Internet Mail Consortium

675 Spruce Dr. Sunnyvale CA 94086 US +1 408 246 8253 +1 408 249 6205 dcrocker@imc.org

Demon Internet Ltd

Dorking Business Park Dorking Surrey England RH4 1HN UK paulo@turnpike.com

University of Melbourne, Computer Science

Parkville Victoria 3052 AU kre@munnari.OZ.AU

RGnet, Inc.

10361 NE Sasquatch Lane Bainbridge Island WA 98110 US randy@psg.com

This memo defines serial number arithmetic, as used in the Domain Name System. The DNS has long relied upon serial number arithmetic, a concept which has never really been defined, certainly not in an IETF document, though which has been widely understood. This memo supplies the missing definition. It is intended to update RFC1034 and RFC1035. World Wide Web Consortium

MIT Laboratory for Computer Science, NE43-356 545 Technology Square Cambridge MA 02139 +1(617)258-8682 timbl@w3.org

Department of Information and Computer Science

University of California, Irvine Irvine CA 92697-3425 +1(949)824-1715 fielding@ics.uci.edu

Xerox PARC

3333 Coyote Hill Road Palo Alto CA 94034 +1(415)812-4333 masinter@parc.xerox.com

Applications uniform resource URI A Uniform Resource Identifier (URI) is a compact string of characters for identifying an abstract or physical resource. This document defines the generic syntax of URI, including both absolute and relative forms, and guidelines for their use; it revises and replaces the generic definitions in RFC 1738 and RFC 1808. This document defines a grammar that is a superset of all valid URI, such that an implementation can parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier type. This document does not define a generative grammar for URI; that task will be performed by the individual specifications of each URI scheme. This paper describes a "superset" of operations that can be applied to URI. It consists of both a grammar and a description of basic functionality for URI. To understand what is a valid URI, both the grammar and the associated description have to be studied. Some of the functionality described is not applicable to all URI schemes, and some operations are only possible when certain media types are retrieved using the URI, regardless of the scheme used. Innosoft International, Inc.

1050 Lakes Drive West Covina CA 91790 USA chris.newman@innosoft.com

Security OTP authentication one-time password password OTP provides a useful authentication mechanism for situations where there is limited client or server trust. Currently, OTP is added to protocols in an ad-hoc fashion with heuristic parsing. This specification defines an OTP SASL mechanism so it can be easily and formally integrated into many application protocols. BBN Corporation

70 Fawcett Street Cambridge MA 02140 USA +1 (617) 873-3988 kent@bbn.com

@Home Network

425 Broadway Redwood City CA 94063 USA +1 (415) 569-5000 rja@corp.home.net

Security IP security protocol IPSEC internet protocol version 6 security Alis Technologies

100, boul. Alexis-Nihon Suite 600 Montreal Quebec H4M 2P2 CA +1 514 747 2547 +1 514 747 2561 fyergeau@alis.com

ISO/IEC 10646-1 defines a multi-octet character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. Multi-octet characters, however, are not compatible with many current applications and protocols, and this has led to the development of a few so-called UCS transformation formats (UTF), each with different characteristics. UTF-8, the object of this memo, has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo updates and replaces RFC 2044, in particular addressing the question of versions of the relevant standards. OpenVision Technologies

One Main St. Cambridge MA 02142 US +1 617 374 2245 John.Linn@ov.com

The Generic Security Service Application Program Interface (GSS-API), as defined in RFC-1508, provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. This specification defines GSS-API services and primitives at a level independent of underlying mechanism and programming language environment, and is to be complemented by other, related specifications: documents defining specific parameter bindings for particular language environments documents defining token formats, protocols, and procedures to be implemented in order to realize GSS-API services atop particular security mechanisms This memo revises RFC-1508, making specific, incremental changes in response to implementation experience and liaison requests. It is intended, therefore, that this memo or a successor version thereto will become the basis for subsequent progression of the GSS-API specification on the standards track.

The author gratefully acknowledges the contributions of: David Clark, Dave Crocker, Steve Deering, Wesley Michael Eddy, Huston Franklin, Marco Gazzetta, Danny Goodman, Steve Harris, Robert Herriot, Ken Hirsch, Greg Hudson, Ben Laurie, Carl Malamud, Michael Mealling, Keith McCloghrie, Paul Mockapetris, RL 'Bob' Morgan, Frank Morton, Darren New, Chris Newman, Joe Touch, Paul Vixie, Gabe Wachob, Daniel Woods, and, James Woodyatt. In particular, Dave Crocker provided helpful suggestions on the nature of segmentation in the framing mechanism.

The IANA registers "beep" as a GSSAPI service name, as specified in . The IANA maintains a list of: standards-track BEEP profiles, c.f., ; and, standards-track features for the channel management profile, c.f., . 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 BEEP profiles and channel management features, the mailing list bxxpwg@invisible.net may be used to solicit commentary. The IANA makes the registrations specified in and . It is recommended that the IANA register these profiles using the IANA as a URI-prefix, and populate those URIs with the respective profile registrations.