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.

[1] http://www.w3.org/2000/xp/Group/2/03/soap1.2implementation.html
............................................
David C. Fallside, IBM
Ext Ph: 530.477.7169
Int  Ph: 544.9665
fallside@us.ibm.com

----- 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|
|         |           uest@w3.org            |
|         |                                  |
|         |                                  |
|         |           07/03/2002 12:45 PM    |
|         |                                  |
|---------+---------------------------------->
  >-------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                         |
  |       To:       w3c-xml-protocol-wg@w3.org                                                                              |
  |       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
here
should be considered optional. Most of the "features" listed here use
the
keyword "MAY" and therefore are not part of the SOAP 1.2 Assertions and
Test
Collection document. It seemed to me that there is a fine line in
deciding
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
spec
was a optional "feature" or an example.


1.  Section 1.2

Specifications for the processing of application-defined data carried in
a SOAP
message but not defined by this specification MAY call for additional
validation
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
necessary
to meet the needs of SOAP applications.

4.  Section 2.6

SOAP nodes MAY make reference to any information in the SOAP envelope
when
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
node
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
or
more of the header blocks removed above. Re-inserting processed SOAP
header
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,
active
intermediaries undertake additional processing that can modify the
outbound
message in ways not described in the inbound message. That is, they can
undertake processing not described by SOAP header blocks in the incoming
message.

10.  Section 2.7.2

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

11.  Section 3.3

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

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
SOAP XML
Infoset (e.g. retry counts), and MAY transmit such information to
adjacent
nodes.

14.  Section 5

A SOAP intermediary MAY ignore such insignificant character information
items
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
role
attribute information item for SOAP header blocks when the value of the
role
attribute information item is
"http://www.w3.org/2002/06/soap-envelope/role/ultimateReceiver"
(see 2.7 Relaying SOAP Messages).

16.  Section 5.2.3

If relaying the message, a SOAP intermediary MAY substitute "true" for
the
value "1", or "false" for "0". The SOAP mustUnderstand attribute
information
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
block,
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
"http://www.w3.org/2001/XMLSchema" namespace.

20.  Section 5.4.5.1

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.
Child
            character information items whose character code is amongst
the
            whitespace characters as defined by [8] are considered
significant.
        MAY have an encodingStyle attribute information item.
        MAY have any number of other attribute information items from
any
            namespace

21.  Section 6

URIs used as values in information items identified by the
"http://www.w3.org/2002/06/soap-envelope" and
"http://www.w3.org/2002/06/soap-encoding" XML namespaces can be either
relative or absolute.

22.  Section 6

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


Thanks.

-Anish
--

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