rfc3288.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,124 行 · 第 1/2 页
TXT
1,124 行
Network Working Group E. O'Tuathail
Request for Comments: 3288 Clipcode.com
Category: Standards Track M. Rose
Dover Beach Consulting, Inc.
June 2002
Using the Simple Object Access Protocol (SOAP)
in Blocks Extensible Exchange Protocol (BEEP)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This memo specifies a Simple Object Access Protocol (SOAP) binding to
the Blocks Extensible Exchange Protocol core (BEEP). A SOAP binding
describes how SOAP messages are transmitted in the network.
The SOAP is an XML-based (extensible markup language) messaging
protocol used to implement a wide variety of distributed messaging
models. It defines a message format and describes a variety of
message patterns, including, but not limited to, RPC, asynchronous
event notification, unacknowledged messages, and forwarding via SOAP
intermediaries.
O'Tuathail & Rose Standards Track [Page 1]
RFC 3288 Using SOAP in BEEP June 2002
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. BEEP Profile Identification . . . . . . . . . . . . . . . . 4
2.1 Profile Initialization . . . . . . . . . . . . . . . . . . . 5
3. SOAP Message Packages . . . . . . . . . . . . . . . . . . . 7
4. SOAP Message Patterns . . . . . . . . . . . . . . . . . . . 9
4.1 One-way Message . . . . . . . . . . . . . . . . . . . . . . 9
4.2 Request-Response Exchange . . . . . . . . . . . . . . . . . 9
4.3 Request/N-Responses Exchange . . . . . . . . . . . . . . . . 9
5. URL Schemes . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1 The soap.beep URL Scheme . . . . . . . . . . . . . . . . . . 10
5.1.1 Resolving IP/TCP Address Information . . . . . . . . . . . . 10
5.2 The soap.beeps URL Scheme . . . . . . . . . . . . . . . . . 11
6. Registration Templates . . . . . . . . . . . . . . . . . . . 12
6.1 SOAP Profile Feature Registration Template . . . . . . . . . 12
7. Initial Registrations . . . . . . . . . . . . . . . . . . . 13
7.1 Registration: The SOAP Profile . . . . . . . . . . . . . . . 13
7.2 Registration: The soap.beep URL Scheme . . . . . . . . . . . 14
7.3 Registration: The soap.beeps URL Scheme . . . . . . . . . . 15
7.4 Registration: The System (Well-Known) TCP port number for
SOAP over BEEP . . . . . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . 16
References . . . . . . . . . . . . . . . . . . . . . . . . . 17
IANA Considerations . . . . . . . . . . . . . . . . . . . . 18
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19
Full Copyright Statement . . . . . . . . . . . . . . . . . . 20
O'Tuathail & Rose Standards Track [Page 2]
RFC 3288 Using SOAP in BEEP June 2002
1. Introduction
This memo specifies how SOAP 1.1 envelopes[1] are transmitted using a
BEEP profile[2]. In the W3C, the XMLP effort is evolving SOAP.
Accordingly, this memo provides a mechanism for negotiating the use
of new features.
Throughout this memo, the term "envelope" refers to the "SOAP-
Env:Envelope" element defined in Section 4 of [1]. Further, the
terms "peer", "client", "server", "one-to-one", and "one-to-many" are
used in the context of BEEP. In particular, Sections 2.1 and 2.1.1
of [2] discuss BEEP roles and exchange styles.
O'Tuathail & Rose Standards Track [Page 3]
RFC 3288 Using SOAP in BEEP June 2002
2. BEEP Profile Identification
The BEEP profile for SOAP is identified as
http://iana.org/beep/soap
in the BEEP "profile" element during channel creation.
In BEEP, when the first channel is successfully created, the
"serverName" attribute in the "start" element identifies the "virtual
host" associated with the peer acting in the server role, e.g.,
<start number='1' serverName='stockquoteserver.example.com'>
<profile uri='http://iana.org/beep/soap' />
</start>
The "serverName" attribute is analagous to HTTP's "Host" request-
header field (c.f., Section 14.23 of [3]).
There are two states in the BEEP profile for SOAP, "boot" and
"ready":
o In the "boot" state, the peer requesting the creation of the
channel sends a "bootmsg" (either during channel initialization or
in a "MSG" message).
* If the other peer sends a "bootrpy" (either during channel
initialization or in a "RPY" message), then the "ready" state
is entered
* Otherwise, the other peer sends an "error" (either during
channel initialization or in a "ERR" message), then no state
change occurs.
o In the "ready" state, either peer begins a SOAP message pattern by
sending a "MSG" message containing an envelope. The other peer
completes the message pattern either by:
* sending back a "RPY" message containing an envelope; or,
* sending back zero or more "ANS" messages, each containing an
envelope, followed by a "NUL" message.
Regardless, no state change occurs.
O'Tuathail & Rose Standards Track [Page 4]
RFC 3288 Using SOAP in BEEP June 2002
2.1 Profile Initialization
The boot message is used for two purposes:
resource identification: each channel bound to the BEEP profile
for SOAP provides access to a single resource (a network data
object or service).
feature negotiation: if new features of SOAP (such as compression)
emerge, their use can be negotiated.
The DTD syntax for the boot message and its response are:
<!ELEMENT bootmsg EMPTY>
<!ATTLIST bootmsg
resource CDATA #REQUIRED
features NMTOKENS "">
<!ELEMENT bootrpy EMPTY>
<!ATTLIST bootrpy
features NMTOKENS "">
The boot message contains a mandatory and an optional attribute:
o the "resource" attribute, which is analagous to HTTP's "abs_path"
Request-URI parameter (c.f., Section 5.1.2 of [3]); and,
o the "features" attribute, which, if present, contains one or more
feature tokens, each indicating an optional feature of the BEEP
profile for SOAP that is being requested for possible use over the
channel.
Section 6.1 defines a registration template for optional features.
If the peer acting in the server role recognizes the requested
resource, it replies with the boot response that contains one
optional attribute:
o the "features" attribute, if present, contains a subset of the
feature tokens in the boot message, indicating which features may
be used over the channel. (If not present or empty, then no
features may be used.)
Otherwise, if the boot message is improperly formed, or if the
requested resource isn't recognized, the peer acting in the server
role replies with an error message (c.f., Section 7.1 of [2]).
O'Tuathail & Rose Standards Track [Page 5]
RFC 3288 Using SOAP in BEEP June 2002
Typically, the boot message and its response are exchanged during
channel initialization (c.f., Section 2.3.1.2 of [2]).
For example, here the boot message and its response are exchanged
during channel initialization:
C: <start number='1' serverName='stockquoteserver.example.com'>
C: <profile uri='http://iana.org/beep/soap'>
C: <![CDATA[<bootmsg resource='/StockQuote' />]]>
C: </profile>
C: </start>
S: <profile uri='http://iana.org/beep/soap'>
S: <![CDATA[<bootrpy />]]>
S: </profile>
The channel bound to the BEEP profile for SOAP is now in the "ready"
state.
Alternatively, here is an example in which the boot exchange is
unsuccessful:
C: <start number='1' serverName='stockquoteserver.example.com'>
C: <profile uri='http://iana.org/beep/soap'>
C: <![CDATA[<bootmsg resource='/StockPick' />]]>
C: </profile>
C: </start>
S: <profile uri='http://iana.org/beep/soap'>
S: <![CDATA[<error code='550'>resource not
S: supported</error>]]>
S: </profile>
Although the channel was created successfully, it remains in the
"boot" state.
O'Tuathail & Rose Standards Track [Page 6]
RFC 3288 Using SOAP in BEEP June 2002
3. SOAP Message Packages
The BEEP profile for SOAP transmits envelopes encoded as UTF-8 using
the media type "application/xml"[4], e.g.,
MSG 1 1 . 0 364
Content-Type: application/xml
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:GetLastTradePrice xmlns:m="Some-URI">
<symbol>DIS</symbol>
</m:GetLastTradePrice>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
END
O'Tuathail & Rose Standards Track [Page 7]
RFC 3288 Using SOAP in BEEP June 2002
In addition, the BEEP profile for SOAP also allows envelopes to be
transmitted as the root part of a "multipart/related"[5] content, and
with subordinate parts referenced using the rules of Section 3 of [6]
(i.e., using either the "Content-ID:"[7] or "Content-Location:"[8]
headers), e.g.,
MSG 1 2 . 364 668
Content-Type: multipart/related; boundary="MIME_boundary";
type=application/xml;
start="<claim061400a.xml@claiming-it.com>"
--MIME_boundary
Content-Type: application/xml
Content-ID: <claim061400a.xml@claiming-it.com>
<?xml version='1.0' ?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
..
<theSignedForm href="cid:claim061400a.tiff@claiming-it.com" />
..
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
--MIME_boundary
Content-Type: image/tiff
Content-Transfer-Encoding: binary
Content-ID: <claim061400a.tiff@claiming-it.com>
...binary TIFF image...
--MIME_boundary--
END
Consistent with Section 2 of [6], it is strongly recommended that the
multipart contain a "start" parameter, and that the root part contain
a "Content-ID:" header. However, because BEEP provides an 8bit-wide
path, a "transformative" Content-Transfer-Encoding (e.g., "base64" or
"quoted-printable") should not be used. Further note that MIME[9]
requires that the value of the "Content-ID" header be globally
unique.
O'Tuathail & Rose Standards Track [Page 8]
RFC 3288 Using SOAP in BEEP June 2002
4. SOAP Message Patterns
4.1 One-way Message
A one-way message involves sending a message without any response
being returned.
The BEEP profile for SOAP achieves this using a one-to-many exchange,
in which the client sends a "MSG" message containing an envelope, and
the server immediately sends back a "NUL" message, before processing
the contents of the envelope.
4.2 Request-Response Exchange
A request/response exchange involves sending a request, which results
in a response being returned.
The BEEP profile for SOAP achieves this using a one-to-one exchange,
in which the client sends a "MSG" message containing an envelope, and
the server sends back a "RPY" message containing an envelope.
Finally, the BEEP profile for SOAP does not use the "ERR" message for
SOAP faults when performing one-to-one exchanges -- whatever response
is generated by the server is always returned in the "RPY" message.
4.3 Request/N-Responses Exchange
A request/N-responses exchange involves sending a request, which
results in zero or more responses being returned.
The BEEP profile for SOAP achieves this using a one-to-many exchange,
in which the client sends a "MSG" message containing an envelope, and
the server sends back zero or more "ANS" messages, each containing an
envelope, followed by a "NUL" message.
O'Tuathail & Rose Standards Track [Page 9]
RFC 3288 Using SOAP in BEEP June 2002
5. URL Schemes
This memo defines two URL schemes, "soap.beep" and "soap.beeps",
which identify the use of SOAP over BEEP over TCP. Note that, at
present, a "generic" URL scheme for SOAP is not defined.
5.1 The soap.beep URL Scheme
The "soap.beep" URL scheme uses the "generic URI" syntax defined in
Section 3 of [10], specifically:
o the value "soap.beep" is used for the scheme component; and,
o the server-based naming authority defined in Section 3.2.2 of [10]
is used for the authority component.
o the path component maps to the "resource" component of the boot
message sent during profile initialization (if absent, it defaults
to "/").
The values of both the scheme and authority components are case-
insensitive.
For example, the URL
soap.beep://stockquoteserver.example.com/StockQuote
might result in the example shown in Section 2.1.
5.1.1 Resolving IP/TCP Address Information
The "soap.beep" URL scheme indicates the use of the BEEP profile for
SOAP running over TCP/IP.
If the authority component contains a domain name and a port number,
e.g.,
soap.beep://stockquoteserver.example.com:1026
then the DNS is queried for the A RRs corresponding to the domain
name, and the port number is used directly.
O'Tuathail & Rose Standards Track [Page 10]
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?