RFC relevance of standards

As per Relevance of the word standards, we have this rfc below:

Network Working Group E. O'
Request for Comments: 3288 Clipcode.
Category: Standards Track M.
Dover Beach Consulting, Inc
June 2002

Using the Simple Object Access Protocol (SOAP
in Blocks Extensible Exchange Protocol (BEEP

Status of this

This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited

Copyright

Copyright (C) The Internet Society (2002). All Rights Reserved

This memo specifies a Simple Object Access Protocol (SOAP) binding
the Blocks Extensible Exchange Protocol core (BEEP). A SOAP
describes how SOAP messages are transmitted in the network

The SOAP is an XML-based (extensible markup language)
protocol used to implement a wide variety of distributed
models. It defines a message format and describes a variety
message patterns, including, but not limited to, RPC,
event notification, unacknowledged messages, and forwarding via
intermediaries

O'Tuathail & Rose Standards Track [Page 1]

RFC 3288 Using SOAP in BEEP June 2002

Table of

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

This memo specifies how SOAP 1.1 envelopes[1] are transmitted using
BEEP profile[2]. In the W3C, the XMLP effort is evolving SOAP
Accordingly, this memo provides a mechanism for negotiating the
of new features

Throughout this memo, the term "envelope" refers to the "SOAP
Env:Envelope" element defined in Section 4 of [1]. Further,
terms "peer", "client", "server", "one-to-one", and "one-to-many"
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

The BEEP profile for SOAP is identified

http://iana.org/beep/

in the BEEP "profile" element during channel creation

In BEEP, when the first channel is successfully created,
"serverName" attribute in the "start" element identifies the "
host" associated with the peer acting in the server role, e.g.,

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"
"ready":

o In the "boot" state, the peer requesting the creation of
channel sends a "bootmsg" (either during channel initialization
in a "MSG" message).

* If the other peer sends a "bootrpy" (either during
initialization or in a "RPY" message), then the "ready"
is

* Otherwise, the other peer sends an "error" (either
channel initialization or in a "ERR" message), then no
change occurs

o In the "ready" state, either peer begins a SOAP message pattern
sending a "MSG" message containing an envelope. The other
completes the message pattern either by

* sending back a "RPY" message containing an envelope; or

* sending back zero or more "ANS" messages, each containing
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

The boot message is used for two purposes

resource identification: each channel bound to the BEEP
for SOAP provides access to a single resource (a network
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

resource CDATA #
features NMTOKENS "">

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
feature tokens, each indicating an optional feature of the
profile for SOAP that is being requested for possible use over
channel

Section 6.1 defines a registration template for optional features

If the peer acting in the server role recognizes the
resource, it replies with the boot response that contains
optional attribute

o the "features" attribute, if present, contains a subset of
feature tokens in the boot message, indicating which features
be used over the channel. (If not present or empty, then
features may be used.)

Otherwise, if the boot message is improperly formed, or if
requested resource isn't recognized, the peer acting in the
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
channel initialization (c.f., Section 2.3.1.2 of [2]).

For example, here the boot message and its response are
during channel initialization

C:
C:
C: resource='/StockQuote' />]]>
C: C:
S:
S: ]]>
S:
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
unsuccessful

C:
C:
C: resource='/StockPick' />]]>
C: C:
S:
S: resource
S: supported]]>
S:
Although the channel was created successfully, it remains in
"boot" state

O'Tuathail & Rose Standards Track [Page 6]

RFC 3288 Using SOAP in BEEP June 2002

3. SOAP Message

The BEEP profile for SOAP transmits envelopes encoded as UTF-8
the media type "application/xml"[4], e.g.,

MSG 1 1 . 0 364
Content-Type: application/

xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

DIS Envelope

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
transmitted as the root part of a "multipart/related"[5] content,
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=""

--MIME_
Content-Type: application/
Content-ID:

xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
..

..
Envelope

--MIME_
Content-Type: image/
Content-Transfer-Encoding:
Content-ID:
...binary TIFF image...
--MIME_boundary--

Consistent with Section 2 of [6], it is strongly recommended that
multipart contain a "start" parameter, and that the root part
a "Content-ID:" header. However, because BEEP provides an 8bit-
path, a "transformative" Content-Transfer-Encoding (e.g., "base64"
"quoted-printable") should not be used. Further note that MIME[9]
requires that the value of the "Content-ID" header be
unique

O'Tuathail & Rose Standards Track [Page 8]

RFC 3288 Using SOAP in BEEP June 2002

4. SOAP Message

4.1 One-way

A one-way message involves sending a message without any
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,
the server immediately sends back a "NUL" message, before
the contents of the envelope

4.2 Request-Response

A request/response exchange involves sending a request, which
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,
the server sends back a "RPY" message containing an envelope

Finally, the BEEP profile for SOAP does not use the "ERR" message
SOAP faults when performing one-to-one exchanges -- whatever
is generated by the server is always returned in the "RPY" message

4.3 Request/N-Responses

A request/N-responses exchange involves sending a request,
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,
the server sends back zero or more "ANS" messages, each containing
envelope, followed by a "NUL" message

O'Tuathail & Rose Standards Track [Page 9]

RFC 3288 Using SOAP in BEEP June 2002

5. URL

This memo defines two URL schemes, "soap.beep" and "soap.beeps",
which identify the use of SOAP over BEEP over TCP. Note that,
present, a "generic" URL scheme for SOAP is not defined

5.1 The soap.beep URL

The "soap.beep" URL scheme uses the "generic URI" syntax defined
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
message sent during profile initialization (if absent, it
to "/").

The values of both the scheme and authority components are case
insensitive

For example, the

soap.beep://stockquoteserver.example.com/

might result in the example shown in Section 2.1.

5.1.1 Resolving IP/TCP Address

The "soap.beep" URL scheme indicates the use of the BEEP profile
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
name, and the port number is used directly

O'Tuathail & Rose Standards Track [Page 10]

RFC 3288 Using SOAP in BEEP June 2002

If the authority component contains a domain name and no port number
e.g.,

soap.beep://stockquoteserver.example.

the SRV algorithm[11] is used with a service parameter of "soap-beep
and a protocol parameter of "tcp" to determine the IP/TCP
information. If no appropriate SRV RRs are found (e.g., for "_soap
beep._tcp.stockquoteserver.example.com"), then the DNS is queried
the A RRs corresponding to the domain name and the port number
is assigned by the IANA for the registration in Section 7.4.

If the authority component contains an IP address, e.g.,

soap.beep://10.0.0.2:1026

then the DNS is not queried, and the IP address is used directly.
a port number is present, it is used directly; otherwise, the
number used is assigned by the IANA for the registration in
7.4.

While the use of literal IPv6 addresses in URLs is discouraged, if
literal IPv6 address is used in a "soap.beep" URL, it must conform
the syntax specified in [12].

5.2 The soap.beeps URL

The "soap.beeps" URL scheme is identical, in all ways, to
"soap.beep" URL scheme specified in Section 5.1, with the
that prior to starting the BEEP profile for SOAP, the BEEP
must be tuned for privacy. In particular, note that both URL
use the identical algorithms and parameters for address resolution
specified in Section 5.1.1 (e.g., the same service name for
lookups, the same port number for TCP, and so on).

There are two ways to perform privacy tuning on a BEEP session
either

o a transport security profile may be successfully started; or

o a user authentication profile that supports transport security
be successfully started

Regardless, upon completion of the negotiation process, a
reset occurs in which both BEEP peers issue a new greeting.
Section 3 of [2] for an example of how a BEEP peer may choose
issue different greetings based on whether privacy is in use

O'Tuathail & Rose Standards Track [Page 11]

RFC 3288 Using SOAP in BEEP June 2002

6. Registration

6.1 SOAP Profile Feature Registration

When a feature for the BEEP profile for SOAP is registered,
following information is supplied

Feature Identification: specify a string that identifies
feature. Unless the feature is registered with the IANA,
feature's identification must start with "x-".

Feature Semantics: specify the semantics of the feature

Contact Information: specify the electronic contact information
the author of the feature

O'Tuathail & Rose Standards Track [Page 12]

RFC 3288 Using SOAP in BEEP June 2002

7. Initial

7.1 Registration: The SOAP

Profile Identification: http://iana.org/beep/

Messages exchanged during Channel Creation: bootmsg,

Messages starting one-to-one exchanges: bootmsg, SOAP-Env:

Messages in positive replies: bootrpy, SOAP-Env:

Messages in negative replies:

Messages in one-to-many exchanges: SOAP-Env:

Message Syntax: SOAP-Env:Envelope as defined in Section 4 of [1]
[6]

Message Semantics: c.f., [1]

Contact Information: Eamon O'Tuathail ,
Marshall Rose

O'Tuathail & Rose Standards Track [Page 13]

RFC 3288 Using SOAP in BEEP June 2002

7.2 Registration: The soap.beep URL

URL scheme name: soap.

URL scheme syntax: c.f., Section 5.1

Character encoding considerations: c.f., the "generic URI"
defined in Section 3 of [10]

Intended usage: identifies a SOAP resource made available using
BEEP profile for

Applications using this scheme: c.f., "Intended usage",

Interoperability considerations: n/

Security Considerations: c.f., Section 8

Relevant Publications: c.f., [1], [6], and [2]

Contact Information: Eamon O'Tuathail ,
Marshall Rose
Author/Change controller: the

O'Tuathail & Rose Standards Track [Page 14]

RFC 3288 Using SOAP in BEEP June 2002

7.3 Registration: The soap.beeps URL

URL scheme name: soap.

URL scheme syntax: c.f., Section 5.2

Character encoding considerations: c.f., the "generic URI"
defined in Section 3 of [10]

Intended usage: identifies a SOAP resource made available using
BEEP profile for SOAP after the BEEP session has been tuned

Applications using this scheme: c.f., "Intended usage",

Interoperability considerations: n/

Security Considerations: c.f., Section 8

Relevant Publications: c.f., [1], [6], and [2]

Contact Information: Eamon O'Tuathail ,
Marshall Rose
Author/Change controller: the

7.4 Registration: The System (Well-Known) TCP port number for SOAP

Protocol Number:

Message Formats, Types, Opcodes, and Sequences: c.f., Section 2.1

Functions: c.f., [1]

Use of Broadcast/Multicast:

Proposed Name: SOAP over

Short name: soap-

Contact Information: Eamon O'Tuathail ,
Marshall Rose

O'Tuathail & Rose Standards Track [Page 15]

RFC 3288 Using SOAP in BEEP June 2002

8. Security

Although service provisioning is a policy matter, at a minimum,
implementations must provide the following tuning profiles

for authentication: http://iana.org/beep/SASL/DIGEST-MD

for confidentiality: http://iana.org/beep/TLS (using
TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher

for both: http://iana.org/beep/TLS (using
TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting client-
certificates

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

Regardless, consult [2]'s Section 9 for a discussion of BEEP-
security issues

O'Tuathail & Rose Standards Track [Page 16]

RFC 3288 Using SOAP in BEEP June 2002

[1] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn
N., Nielsen, H., Thatte, S. and D. Winer, "Simple Object
Protocol (SOAP) 1.1", May 2000, NOTE-SOAP-20000508>.

[2] Rose, M., "The Blocks Extensible Exchange Protocol Core",
3080, March 2001.

[3] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.

[4] Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types",
3023, January 2001.

[5] Levinson, E., "The MIME Multipart/Related Content-type",
2387, August 1998.

[6] Barton, J., Thatte, S. and H. Nielsen, "SOAP Messages
Attachments", December 2000, SOAP-attachments-20001211>.

[7] Levinson, E., "Content-ID and Message-ID Uniform
Locators", RFC 2392, August 1998.

[8] Palme, F., Hopmann, A., Shelness, N. and E. Stefferud, "
Encapsulation of Aggregate Documents, such as HTML (MHTML)",
RFC 2557, March 1999.

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

[10] Berners-Lee, T., Fielding, R. and L. Masinter, "
Resource Identifiers (URI): Generic Syntax", RFC 2396,
1998.

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

[12] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472,
December 1998.

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

O'Tuathail & Rose Standards Track [Page 17]

RFC 3288 Using SOAP in BEEP June 2002

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

IANA

The IANA has registered the profile specified in Section 7.1 as

http://iana.org/beep/

The IANA has registered "soap.beep" and "soap.beeps" as URL schemes
as specified in Section 7.2 and Section 7.3, respectively

The IANA has also registered "SOAP over BEEP" as a TCP port number
as specified in Section 7.4.

Finally, the IANA maintains a list of SOAP profile features, c.f.,
Section 6.1. The IESG is responsible for assigning a
expert to review the specification prior to the IANA making
assignment. Prior to contacting the IESG, developers of SOAP
features must use the mailing list beepwg@lists.beepcore.org
solicit commentary

The authors gratefully acknowledge the contributions of:
Ferris, Huston Franklin, Alexey Melnikov, Bill Mills, and Roy T
Fielding

O'Tuathail & Rose Standards Track [Page 18]

RFC 3288 Using SOAP in BEEP June 2002

Authors'

Eamon O'
Clipcode.
24 Thomastown
Dun

Phone: +353 1 2350 424
EMail: eamon.otuathail@clipcode.
URI: http://www.clipcode.com

Marshall T.
Dover Beach Consulting, Inc
POB 255268
Sacramento, CA 95865-5268

Phone: +1 916 483 8878
EMail: mrose@dbc.mtview.ca.

O'Tuathail & Rose Standards Track [Page 19]

RFC 3288 Using SOAP in BEEP June 2002

Full Copyright

Copyright (C) The Internet Society (2002). All Rights Reserved

This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English

The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns

This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE

Funding for the RFC Editor function is currently provided by
Internet Society

O'Tuathail & Rose Standards Track [Page 20]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX