RE: [TBTF] proposed edits for incorporating conneg feature for HT TP binding

Hi Chris et. al,

I have a number of concerns with the direction that this is now going. 

1) The original motivation for the discussion, as I recall, was directed at
the resolution of Issue #61 [1]. I think what is proposed in [2] is
no-longer focussed on that, indeed as far as I can tell it defines a binding
that is (possibly deliberately) incapable of supporting *any* attachment
scheme. If that's where this ends-up... I think I'd rather do nothing...
there really is no call for the abstraction of a content-negotiation
feature.

2) I think of content-negotiation as a mechanism provided by the underlying
protocol (HTTP in this case) that is available for use in
specifying/implementing other features. I don't think that it should itself
be exposed as a feature... particularly I as it has little applicability
outside of the HTTP case.

3) The conneg feature is described as a "binding specific feature". I take
that to mean that its use is specific to the particular binding being
defined (which I admit is a narrow view). It might be more appropriate to
regard it as a feature applicable to some 'family' of HTTP bindings, but
that is not how it is currently framed. This also gets back into the
question of quite what it is that we mean when we speak of a binding
specification to an underlying protocol - are bindings allowed to engage in
optional behaviour (eg support for attachments using DIME? using SwA? or not
- more below).

4) As far as I can tell, the conneg feature defined in 7.5.2 is *not* used
by the binding spec in which it is defined. As spec'ed here the MIME
content-type for both Request and Response message MUST always be
"application/soap+xml" - the defined binding makes *NO* reference to any of
the properties scoped by the definition of the feature - it might as well
not be there (at this time). Alternatively, one might view the operational
description of the feature (last two tables in 7.5.2) as describing how the
feature applies, but if the property "conneg:MediaType" is anything other
than "application/soap+xml" we establish something of a contradiction in our
HTTP binding spec.

5) I think that part of the motivation for the conneg feature was to provide
a more generic 'hook' to support things other than attachments. This is a
laudible goal, but... I think that this is more complicated than addressing
the top-level MIME content-type. If we're after something that supports
Henriks concept of nested bindings we potentially have a whole 'stack' of
possible transformation on the serialisation of a message any combination of
which are not well represented by the single top-level MIME content-type in
an HTTP exchange - if thats the goal (and at this time I'm not suggesting it
should be) then I think more thought is required.

I am also disapointed that our defintion of "context:CurrentMessage" has
collapsed such as to *not* include the concept of accompanying information
structures a.k.a attachments.

At a slight tangent, but firmly focussed on Issue #61, I have always been of
the opinion that we should define a means to serialise attachments into a
SOAP message envelope, brute-force base64 encoding. Admittedly ugly and
inefficient, *but* functionally it would mean that an application could
always rely on support for attachments. We might have to wiggle around our
conceptual view of whether a given binding spec states that it supports
attachments (by serialising them into the envelope), or whether the binding
says it does not support attachments and then knowing that the SOAP Node
would take responsibility for serialising attachments into the envelope.
That would give a base level of interoperable support for attachments,
whilst leaving bindings free to implement more efficient schemes and
potentially dynamically negotiate their use (with in-band mechanisms like
HTTP content negotiation [not itself exposed as a feature] and/or
out-of-band mechanisms such as WSDL).

Anyway, my feeling at the moment is that what's on the table in [2] at the
moment is not well directed at addressing Issue 61.

Best regards

Stuart
[1] http://www.w3.org/2000/xp/Group/xmlp-issues#x61
[2] http://lists.w3.org/Archives/Public/xml-dist-app/2002Apr/0021.html

> -----Original Message-----
> From: Christopher Ferris [mailto:chris.ferris@sun.com]
> Sent: 03 April 2002 03:29
> To: xml-dist-app@w3.org
> Subject: Re: [TBTF] proposed edits for incorporating conneg 
> feature for
> HTTP binding
> 
> 
> Following today's TBTF call, I took an AI to tweak the wording
> in my original proposed revision[1] to SOAP Part 2 for incorporation
> of the content negotiation feature.
> 
> The Note I added in section 7.1 of the SOAP HTTP Binding
> did not quite capture the consensus of the TBTF members as to
> the nature of the relationship of the SOAP HTTP Binding to other
> bindings that use HTTP.
> 
> I've attached the revised Part 2 HTML.
> 
> Cheers,
> 
> Chris
> 
> [1] http://lists.w3.org/Archives/Public/xml-dist-app/2002Apr/0006.html

Received on Wednesday, 3 April 2002 06:23:32 UTC