📄 rfc3340.txt
字号:
o the "transID" attribute specifies the transaction-identifier
associated with this operation; and,
o the "option" elements, if any, specify additional processing
options (Section 5).
When a relay receives an "bind" element, it performs these steps:
1. If the transaction-identifier refers to a previous, non-terminated
operation on this BEEP channel, an "error" element having code 555
is returned.
2. If the application is not authorized to bind on behalf of this
administrative domain (c.f., Section 4.5.2), an "error" element
having code 537 is returned.
3. If any options are present, they are processed.
4. Otherwise, the application is accepted as serving this
administrative domain, and an "ok" element 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
Rose, et. al. Standards Track [Page 14]
RFC 3340 The Application Exchange Core July 2002
+-------+ +-------+
| | <-- 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:
o the "transID" attribute specifies the transaction-identifier
associated with this operation;
o the "code" attribute, if present, is a three-digit reply code
meaningful to programs (c.f., Section 10);
o the "xml:lang" attribute, if present, specifies the language that
the element's content is written in; and,
o 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
performs these steps:
1. 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 "ok" element is returned.
2. Otherwise, if the transaction-identifier does not refer to a
previous unterminated operation on this BEEP channel, an "error"
element having code 550 is returned.
3. Otherwise, the application is no longer bound as an endpoint or a
relay, and an "ok" element 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.,
Rose, et. al. Standards Track [Page 15]
RFC 3340 The Application Exchange Core July 2002
+-------+ +-------+
| | -- 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:
o the "content" attribute is a URI-reference that specifies the
contents of the data (c.f., Section 4.1);
o the "originator" element refers to the endpoint sending the data;
Rose, et. al. Standards Track [Page 16]
RFC 3340 The Application Exchange Core July 2002
o each "recipient" element refers to an endpoint destination for the
data;
o the "option" elements, if any, specify additional processing
options (Section 5), termed per-data options; and,
o the "data-content" element, if present, specifies a nested XML
entity that is referenced using a URI fragment-identifier as the
value of the "content" attribute.
The "originator" element has an "identity" attribute, and contains
zero or more option elements:
o the "identity" attribute specifies the sending endpoint; and
o the "option" elements, 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:
o the "identity" attribute specifies the destination endpoint; and
o the "option" elements, 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 performs these steps:
1. If the BEEP client is not authorized to originate or relay data on
behalf of the "originator" endpoint (c.f., Section 4.5), an
"error" element having code 537 is returned.
2. If any per-data options are present, they are processed.
3. An "ok" element is returned.
4. If any per-originator options are present, they are processed.
5. For each recipient:
1. If any per-recipient options are present, they are processed.
Rose, et. al. Standards Track [Page 17]
RFC 3340 The Application Exchange Core July 2002
2. 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 "data" element, containing that "recipient"
element 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.
3. 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:data"
token 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 performs these
steps:
1. If any per-data or per-originator options are present, they are
not processed (but may be noted).
2. For each recipient:
1. If any per-recipient options are present, they are not
processed (but may be noted).
2. If the application is not attached as the recipient endpoint,
then an error in processing has occurred.
Rose, et. al. Standards Track [Page 18]
RFC 3340 The Application Exchange Core July 2002
3. Otherwise, the "data" element is further processed in an
application-specific manner, and the recipient is considered to
be successfully processed.
3. If no recipients could be successfully processed, an "error"
element is returned; otherwise, an "ok" element is returned.
4.5 APEX Access Policies
Access to APEX is provided by the juxtaposition of:
o authenticating as a BEEP peer;
o attaching as an APEX endpoint or binding as an APEX relay; and,
o 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:
o each administrative domain is responsible for keeping its own
house in order through "local provisioning"; and,
o each administrative domain decides the level of trust to associate
with other administrative domains.
4.5.1 Access Policies in the Endpoint-Relay Mode
o 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,
e.g., an application authorized to attach as the APEX endpoint
"fred@example.com" is also authorized to attach as the APEX
endpoint "fred/appl=wb@example.com".
o 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).
Rose, et. al. Standards Track [Page 19]
RFC 3340 The Application Exchange Core July 2002
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 the same APEX endpoint.
However, other policies are permissible, for example, the
administrative domain may allow the application attached as the
APEX endpoint named as "wilma@example.com" to send data
originating as either "wilma@example.com" or "fred@example.com".
o 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
o 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".
o When a relay is sending data, no access policies, per se, are
applied.
o 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).
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -