ACTION REQ: SOAP 1.2 part 1, "features" list.

The WG needs to decide which of any of the following are to be included in
Table 2, at [1]. Please review, and send feedback to this list in time for
the next XMLP telcon.

David C. Fallside, IBM
Ext Ph: 530.477.7169
Int  Ph: 544.9665

----- Forwarded by David Fallside/Santa Teresa/IBM on 07/12/2002 04:58 PM
|         |           Anish Karmarkar        |
|         |           <Anish.Karmarkar@oracle|
|         |           .com>                  |
|         |           Sent by:               |
|         |           w3c-xml-protocol-wg-req|
|         |             |
|         |                                  |
|         |                                  |
|         |           07/03/2002 12:45 PM    |
|         |                                  |
  |                                                                                                                         |
  |       To:                                                                              |
  |       cc:                                                                                                               |
  |       Subject:  SOAP 1.2 part 1, "features" list.                                                                       |
  |                                                                                                                         |
  |                                                                                                                         |

This document contains "features" in SOAP 1.2 Part 1 which are not
listed in
SOAP 1.2 Assertions and Test Collections document. The features listed
should be considered optional. Most of the "features" listed here use
keyword "MAY" and therefore are not part of the SOAP 1.2 Assertions and
Collection document. It seemed to me that there is a fine line in
whether certain text in the spec is an optional "feature" or an example.
I have used my best judgment in deciding whether certain text in the
was a optional "feature" or an example.

1.  Section 1.2

Specifications for the processing of application-defined data carried in
message but not defined by this specification MAY call for additional
of the SOAP message in conjunction with application-level processing.

2.  Section 1.2

The media type "application/soap+xml" [13] SHOULD be used for XML 1.0
serializations of the SOAP message infoset.

3.  Section 2.2

In addition to those described above, other roles MAY be defined as
to meet the needs of SOAP applications.

4.  Section 2.6

SOAP nodes MAY make reference to any information in the SOAP envelope
processing a SOAP body or SOAP header block.

5.  Section 2.6

The processing of one or more SOAP header blocks MAY control or
determine the
order of processing for other SOAP header blocks and/or the SOAP body.

6.  Section 2.6

Header blocks MAY be processed in arbitrary order. Header block
processing MAY
precede, MAY be interleaved with, or MAY follow processing of the body.

7.  Section 2.7.1

The semantics of one or more SOAP header blocks in a SOAP message, or
the SOAP
MEP used MAY require that the SOAP message be forwarded to another SOAP
on behalf of the initiator of the inbound SOAP message.

8.  Section 2.7.1

Such rules MAY describe placement of inserted or reinserted SOAP header
blocks.  Inserted SOAP header blocks might be indistinguishable from one
more of the header blocks removed above. Re-inserting processed SOAP
blocks in this manner effectively leaves them in place, but emphasizes
the need to process them at each SOAP node along the SOAP message path.

9.  Section 2.7.2

In addition to the processing performed by forwarding intermediaries,
intermediaries undertake additional processing that can modify the
message in ways not described in the inbound message. That is, they can
undertake processing not described by SOAP header blocks in the incoming

10.  Section 2.7.2

One mechanism by which an active intermediary can describe the
performed on a message is by inserting header blocks into the outbound
message. These header blocks can inform downstream SOAP nodes acting in
whose correct operation depends on receiving such notification. In this
the semantics of such inserted header blocks should also call for either
same or other header blocks to be (re)inserted at subsequent
as necessary to ensure that the message can be safely processed by nodes
further downstream.

11.  Section 3.3

A MEP MAY be supported by one or more underlying protocol binding

12.  Section 4.2

A binding, if using XML 1.0 serialization of the infoset, MAY mandate
that a
particular character encoding or set of encodings be used.

13.  Section 4.2

Bindings MAY depend on state that is modeled as being outside of the
Infoset (e.g. retry counts), and MAY transmit such information to

14.  Section 5

A SOAP intermediary MAY ignore such insignificant character information
when forwarding (see 2.7 Relaying SOAP Messages) a message.

15.  Section 5.2.2

If relaying a SOAP message, a SOAP intermediary MAY discard the SOAP
attribute information item for SOAP header blocks when the value of the
attribute information item is
(see 2.7 Relaying SOAP Messages).

16.  Section 5.2.3

If relaying the message, a SOAP intermediary MAY substitute "true" for
value "1", or "false" for "0". The SOAP mustUnderstand attribute
item MAY be omitted if its value would have been "false" or "0".

17.  Section 5.4

A SOAP Fault element information item MAY appear within a SOAP header
or as a descendant of a child element information item of the SOAP Body
in such cases, the element has no SOAP-defined semantics.

18.  Section 5.4.3
An ultimate SOAP receiver MAY include this element information item to
indicate explicitly that it generated the fault.

19.  Section 5.4.3

(should be in assertion doc - I will send an email to xmlp-comments)

The type of the Node element information item is anyURI in the
"" namespace.

20.  Section

Each detail entry:
        MAY be namespace qualified.
        MAY have any number of element information item children
        MAY have any number of character information item children.
            character information items whose character code is amongst
            whitespace characters as defined by [8] are considered
        MAY have an encodingStyle attribute information item.
        MAY have any number of other attribute information items from

21.  Section 6

URIs used as values in information items identified by the
"" and
"" XML namespaces can be either
relative or absolute.

22.  Section 6

The underlying protocol binding MAY define a base URI which can act as
base URI for the SOAP envelope (see 4. SOAP Protocol Binding Framework
Part 2 [1] section HTTP binding).



Received on Friday, 12 July 2002 20:02:11 UTC