Resolving the ednote in part 1 section 5.1

The following note looks more complicated than it is. The reason is that
it tries to convey the discussion in the TBTF that led up to this mail.
If you don't care about the discussion then you can jump directly to the
PROPOSAL at the end.

DISCUSSION
----------

The ednote placed in section 5.1 of part 1 [0] has been the subject of
ongoing debate in the TBTF for a long time. It states that:

"Some discussion continues on how best to represent the balance of
responsibility between binding specifications in particular, vs. other
software at the SOAP node, when dealing with features that are
represented entirely within the SOAP envelope. The paragraph above may
need some additional work to clarify"

And is in response to the paragraph just above which says:

"The combination of the SOAP extensibility model and the SOAP binding
framework provides some flexibility in the way that particular features
can be expressed: they can be expressed entirely within the SOAP
envelope (as blocks), outside the envelope (typically in a manner that
is specific to the underlying protocol), or as a combination of such
expressions. It is up to the communicating nodes to decide how best to
express particular features; often when a binding-level implementation
for a particular feature is available, utilizing it when appropriate
will provide for optimized processing."

On Feb 8, Chris Ferris posted a proposal [2] for resolving issue 178 [1]
which is highly related. It proposes to add a note to the end of section
5.1 saying:

"Note: Certain features may require end-to-end as opposed to
hop-to-hop processing semantics. While the binding framework
provides for the possibility that such features may be expressed
outside the SOAP envelope, it does not define a specific
architecture for the processing or error handling of these externally
expressed features by a SOAP intermediary. A binding specification
that expresses such features external to the SOAP envelope should
define its own processing rules to which a SOAP node
is expected to conform (for example, describing what information
must be passed along with the SOAP message as it leaves
the intermediary). It is recommended that end-to-end
features should be expressed as SOAP header blocks so that
they may avail themselves of the SOAP processing rules [ref]."

During the discussion in the TBTF, it was argued that the existing
paragraph (for which the ednote is targeted) and Chris's note describe
very similar aspects but from slightly different viewpoints. The
existing note describes it from the point of view of who makes
decisions, whereas Chris's note describes it from the possible
difference in scope of features expressed in the binding vs. features
expressed in the SOAP envelope. Furthermore, it was argued that while
the first part of the original note was useful, it doesn't seem to be
within our scope to indicate who makes what decisions, and so we felt it
was appropriate to delete the last sentence of the original note.

PROPOSAL
--------

The TBTF therefore suggests that the way we discharge the ednote is by
deleting the last sentence of the original paragraph in part 1, section
5.1 and add Chris's note. The result is:

"The combination of the SOAP extensibility model and the SOAP binding
framework provides some flexibility in the way that particular features
can be expressed: they can be expressed entirely within the SOAP
envelope (as blocks), outside the envelope (typically in a manner that
is specific to the underlying protocol), or as a combination of such
expressions.

Note: Certain features may require end-to-end as opposed to hop-to-hop
processing semantics. While the binding framework provides for the
possibility that such features may be expressed outside the SOAP
envelope, it does not define a specific architecture for the processing
or error handling of these externally expressed features by a SOAP
intermediary. A binding specification that expresses such features
external to the SOAP envelope should define its own processing rules to
which a SOAP node is expected to conform (for example, describing what
information must be passed along with the SOAP message as it leaves the
intermediary). It is recommended that end-to-end features should be
expressed as SOAP header blocks so that they may avail themselves of the
SOAP processing rules [ref]."

Henrik Frystyk Nielsen
mailto:henrikn@microsoft.com

[0] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html#NA6A
[1] http://www.w3.org/2000/xp/Group/xmlp-issues#x178
[2] http://lists.w3.org/Archives/Public/xml-dist-app/2002Feb/0168.html

Received on Wednesday, 13 February 2002 14:01:41 UTC