RFC3340 - The Application Exchange Core(2)

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.

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

Many APEX services make use of a reply operation. Although each
service defines the circumstances in which a "reply" element is sent,
the syntax of the "reply" element is defined in Section 9.1.

The "reply" element has a "code" attribute, a "transID" attribute, an
optional "xml:lang" attribute, and may contain arbitrary textual
content:

o the "code" element specifies a three-digit reply code (c.f.,
Section 10);

o the "transID" attribute specifies the transaction-identifier
corresponding to this reply;

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.

6.2 The Report Service

Section 8.5 contains the APEX service registration for the report
service:

o Within an administrative domain, the service is addressed using
the well-known endpoint of "apex=report".

o Section 9.2 defines the syntax of the operations exchanged with
the service.

o A consumer of the service does not initiate communications with
the service.

o The service initiates communications by sending data containing
the "statusResponse" operation.

If a relay processes a "statusRequest" option (Section 5.1), then it
sends data to the originator containing a "statusResponse" element
(Section 9.2).

The "statusResponse" element has a "transID" attribute and contains
one or more "destination" elements:

o the "transID" attribute specifies the value contained in the
"statusRequest" option; and,

o each "destination" element has an "identity" attribute and
contains a "reply" element:

* the "identity" attribute specifies the recipient endpoint that
is being reported on; and,

* the "reply" element (Section 6.1.2) specifies the delivery
status of that recipient.

7. Registration Templates

7.1 APEX Option Registration Template

When an APEX option is registered, the following information is
supplied:

Option Identification: specify the NMTOKEN or the URI that
authoritatively identifies this option.

Present in: specify the APEX elements in which the option may appear.

Contains: specify the XML content that is contained within the
"option" element.

Processing Rules: specify the processing rules associated with the
option.

Contact Information: specify the postal and electronic contact
information for the author of the profile.

7.2 APEX Service Registration Template

When an APEX service is registered, the following information is
supplied:

Well-Known Endpoint: specify the local-part of an endpoint identity,
starting with "apex=".

Syntax of Messages Exchanged: specify the elements exchanged with the
service.

Sequence of Messages Exchanged: specify the order in which data is
exchanged with the service.

Access Control Tokens: specify the token(s) used to control access to
the service (c.f., [10]).

Contact Information: specify the postal and electronic contact
information 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 an APEX endpoint application is registered, the following
information is supplied:

Endpoint Application: specify the subaddress used for an endpoint
application, starting with "appl=".

Application Definition: specify the syntax and semantics of the
endpoint application identified by this registration.

Contact Information: specify the postal and electronic contact
information for the author of the profile.

8. Initial Registrations

8.1 Registration: The APEX Profile

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

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

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

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

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



<!ENTITY % BEEP PUBLIC "-//IETF//DTD BEEP//EN" "">
%BEEP;



<!ENTITY % ENDPOINT "CDATA">
<!ENTITY % DOMAIN "CDATA">
<!ENTITY % SECONDS "CDATA">
<!ENTITY % TIMESTAMP "CDATA">
<!ENTITY % UNIQID "CDATA">
<!ENTITY % UNIZID "CDATA">



<!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>



<!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



<!ENTITY % APEXCORE PUBLIC "-//Blocks//DTD APEX CORE//EN" "">
%APEXCORE;



<!ELEMENT statusResponse
(destination+)>
<!ATTLIST statusResponse
transID %UNIQID; #REQUIRED>

<!ELEMENT destination (reply)>
<!ATTLIST destination
identity %ENDPOINT; #REQUIRED>

10. Reply Codes

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 progress

11. Security Considerations

Consult Section 3 and Section 4.5 for a discussion of security
issues, e.g., relaying integrity.

Although service provisioning is a policy matter, 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)

Further, APEX endpoint implementations may choose to offer MIME-based
security services providing message integrity and confidentiality,
such as OpenPGP [13] or S/MIME [14].

Regardless, since APEX is a profile of the BEEP, consult [1]'s
Section 9 for a discussion of BEEP-specific security issues.

Finally, the statusRequest option (Section 5.1) may be used to expose
private network topology. Accordingly, an administrator may wish to
choose to disable this option except at the ingress/egress points for
its administrative domain.

References

[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", RFC2234, November 1997.

[3] Klensin, J., "Simple Mail Transfer Protocol", RFC2821, April
2001.

[4] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
10646", RFC2044, October 1996.

[5] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC2782,
February 2000.

[6] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC2396, 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", RFC2392, August 1998.

[9] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC2045, November 1996.

[10] Rose, M., Klyne, G. and D. Crocker, "The Application Exchange
(APEX) Access Service", RFC3341, 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", RFC3339, July 2002.

[13] Elkins, M., Del Torto, D., Levien, R. and T. Roessler, "MIME
Security with OpenPGP", RFC3156, August 2001.

[14] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
2633, June 1999.

Appendix A. Acknowledgements

The authors gratefully acknowledge the contributions of: Jeffrey
Altman, Harald Alvestrand, Eric Dixon, Ronan Klyne, Darren New, Chris
Newman, Scott Pead, and Bob Wyman.

Appendix B. IANA Considerations

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:

o APEX options, c.f., Section 7.1;

o APEX services, c.f., Section 7.2; and,

o 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

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

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

Funding for the RFCEditor function is currently provided by the
Internet Society.

协议分析网

搜索

RFC3340 - The Application Exchange Core(2)