📄 rfc3341.txt
字号:
RFC 3341 The Application Exchange (APEX) Access Service July 2002
Note that although the four default entries are always available, the
explicit entry for actor "*@*" overrides the corresponding default
entry.
3.2 Creating and Updating Access Entries
The get and set operations are provided as a basic mechanism for
creating and updating access rules, for which no special wildcard
processing is performed.
The actor value for an access entry may contain limited wildcard
characters which have special significance only when performing a
query operation (cf., Section 3.1). For the purposes of retrieving
and updating entries, actor values are treated simply as literal
names.
4. The Access Service
Section 5 contains the APEX service registration for the access
service:
o Within an administrative domain, the service is addressed using
the well-known endpoint of "apex=access".
o Section 6 defines the syntax of the operations exchanged with the
service.
o A consumer of the service initiates communications by sending data
containing a query, get, or set operation.
o The service replies to these operations.
o When an access entry is changed, the service sends a notification
to the owner associated with the changed entry.
An implementation of the service must maintain information about
access entries in persistent storage.
Consult Section 6.1.1 of [1] for a discussion on the properties of
long-lived transaction-identifiers.
Rose, et. al. Standards Track [Page 14]
RFC 3341 The Application Exchange (APEX) Access Service July 2002
4.1 Use of XML and MIME
Section 4.1 of [1] describes how arbitrary MIME content is exchanged
as a BEEP [2] payload. For example, to transmit:
<data content='...'>
<originator identity='fred@example.com' />
<recipient identity='apex=access@example.com' />
</data>
where "..." refers to:
<query owner='fred@example.com' transID='1'
actor='barney@example.com'
actions='core:data presence:subscribe' />
then the corresponding BEEP message might look like this:
C: MSG 1 2 . 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='apex=access@example.com' />
C: </data>
C: --boundary
C: Content-Type: application/beep+xml
C: Content-ID: <2@example.com>
C:
C: <query owner='fred@example.com' transID='1'
C: actor='barney@example.com'
C: actions='core:data presence:subscribe' />
C: --boundary--
C: END
Rose, et. al. Standards Track [Page 15]
RFC 3341 The Application Exchange (APEX) Access Service July 2002
or this:
C: MSG 1 1 . 42 267
C: Content-Type: application/beep+xml
C:
C: <data content='#Content'>
C: <originator identity='fred@example.com' />
C: <recipient identity='apex=access@example.com' />
C: <data-content Name='Content'>
C: <query owner='fred@example.com' transID='1'
C: actor='barney@example.com'
C: actions='core:data presence:subscribe' />
C: </data-content>
C: </data>
C: END
4.2 The Query Operation
When an application wants to see if a particular operation is
allowed, it sends a "query" element to the service.
The "query" element has an "owner" attribute, an "actor" attribute,
an "actions" attribute, a "transID" attribute, and no content:
o the "owner" attribute specifies the address associated with the
access entry;
o the "actor" attribute specifies the address (without wildcarding)
for which access permissions are queried;
o the "actions" attribute specifies one or more actions for which
permission is queried; and,
o the "transID" attribute specifies the transaction-identifier
associated with this operation.
When the service receives a "query" element, we refer to the "owner"
attribute as the "subject". The service performs these steps:
1. If the subject is outside this administrative domain, a "reply"
element having code 553 is sent to the originator.
2. If the subject does not refer to a valid address, a "reply"
element having code 550 is sent to the originator.
3. If the subject's access entry matching the originator does not
contain an "access:query" token, a "reply" element having code 537
is sent to the originator.
Rose, et. al. Standards Track [Page 16]
RFC 3341 The Application Exchange (APEX) Access Service July 2002
4. The subject's access entry matching the actor attribute of the
query element is selected (cf., Section 3.1).
5. If all of the permissions in the "actions" attribute of the query
element are contained in the selected access entry, then an
"allow" element is sent to the originator.
6. Otherwise, a "deny" element is sent to the originator.
Regardless of whether an "allow", "deny", or "reply" element is sent
to the originator, the "transID" attribute is identical to the value
found in the "query" element sent by the originator.
4.3 The Get Operation
Prior to creating or updating an access entry for some owner/actor
combination, an application will usually need to retrieve any
existing access entry. It does so by sending a "get" element to the
service. In particular, a successful response returns a "lastUpdate"
value that is necessary when sending a subsequent "set" element.
The "get" element has an "owner" attribute, an "actor" attribute, a
"transID" attribute, and no content:
o the "owner" attribute specifies the address associated with the
access entry;
o the "actor" attribute specifies the address (with possible
wildcarding) for which access permissions are retrieved; and,
o the "transID" attribute specifies the transaction-identifier
associated with this operation.
When the service receives a "get" element, we refer to the "owner"
attribute as the "subject". The service performs these steps:
1. If the subject is outside this administrative domain, a "reply"
element having code 553 is sent to the originator.
2. If the subject does not refer to a valid address, a "reply"
element having code 550 is sent to the originator.
3. If the subject's access entry matching the originator does not
contain an "access:get" token, a "reply" element having code 537
is sent to the originator.
4. The subject's access entry whose "actor" attribute identically
matches the "actor" attribute of the "get" element is selected.
Rose, et. al. Standards Track [Page 17]
RFC 3341 The Application Exchange (APEX) Access Service July 2002
5. If no such entry exists, a "reply" element having code 551 is sent
to the originator.
6. Otherwise, a "set" element corresponding to the selected access
entry is sent to the originator.
Regardless of whether a "set" or "reply" element is sent to the
originator, the "transID" attribute is identical to the value found
in the "get" element sent by the originator.
4.4 The Set Operation
When an application wants to modify (i.e., create, replace, or
delete) the access entry associated with an owner/actor combination,
it sends a "set" element to the service.
The "set" element has a "transID" attribute, and contains an "access"
element:
o the "transID" attribute specifies the transaction-identifier
associated with this operation; and,
o the "access" element contains the access entry to be created,
replaced, or deleted.
The "access" element has an "owner" attribute, an "actor" attribute,
an optional "actions" attribute, an optional "lastUpdate" attribute,
and no content:
o the "owner" attribute specifies the address associated with the
access entry;
o the "actor" attribute specifies the address (with possible
wildcarding) for which access permissions are specified;
o the "actions" attribute (present only to add or replace an entry)
specifies one or more actions for which permission is to be
determined; and,
o the "lastUpdate" attribute (present only to replace or delete an
entry) specifies the current timestamp of the access entry that is
to be replaced.
Rose, et. al. Standards Track [Page 18]
RFC 3341 The Application Exchange (APEX) Access Service July 2002
When the service receives a "set" element, we refer to the "owner"
attribute of the access element as the "subject". The service
performs these steps:
1. If the subject is outside this administrative domain, a "reply"
element having code 553 is sent to the originator.
2. If the subject does not refer to a valid address, a "reply"
element having code 550 is sent to the originator.
3. If the subject's access entry matching the originator does not
contain an "access:set" token, a "reply" element having code 537
is sent to the originator.
4. The subject's access entry whose "actor" attribute identically
matches the "actor" attribute of the "set" element is selected.
5. If no such entry exists and the "lastUpdate" attribute is present
in the supplied "set" element, a "reply" element having code 555
is sent to the originator.
6. If no such entry exists and the "lastUpdate" attribute is absent
in the supplied "set" element, then:
1. The access entry for the owner/actor combination is created
from the supplied "access" element.
2. The "lastUpdate" attribute of that access entry set to the
service's notion of the current date and time.
3. A "reply" element having code 250 is sent to the originator.
4. A "set" element corresponding to the newly-created access entry
is sent to the subject's address.
7. If the selected entry exists, but its "lastUpdate" attribute is
not semantically identical to the "lastUpdate" attribute of the
supplied "access" element, a "reply" element having code 555 is
sent to the originator.
8. If "actions" attribute of the supplied "access" element is not
present, then:
1. The selected entry is deleted.
2. A "reply" element having code 250 is sent to the originator.
Rose, et. al. Standards Track [Page 19]
RFC 3341 The Application Exchange (APEX) Access Service July 2002
3. A "set" element corresponding to the owner/actor combination,
but lacking an "actions" attribute is sent to the subject's
address.
9. Otherwise:
1. The access entry for the owner/actor combination is updated
from the supplied "access" element.
2. The "lastUpdate" attribute of the updated access entry is set
to the service's notion of the current date and time (which
should be different from the "lastUpdate" value associated with
any replaced entry).
3. A "reply" element having code 250 is sent to the originator.
4. A "set" element corresponding to the newly-updated access entry
is sent to the subject's address.
When sending the "reply" element, the "transID" attribute is
identical to the value found in the "set" element sent by the
originator.
4.5 The Reply Operation
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -