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

Stuart,

Please see below.

Cheers,

Chris
Williams, Stuart wrote:

> Hi Chris et. al,
> 
> I have a number of concerns with the direction that this is now going. 
> 
<snip/>
> 
> 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


I struggled with this aspect when drafting the proposed changes.
I actually think that the conneg feature s/b specific to the HTTP
protocol, not the binding per se. I just couldn't come up with
a good place to put such a feature. I'd be happy to see the feature
relocated to follow the MEP feature and be described in its introduction
as specific to the HTTP protocol and hence useable by other HTTP
bindings. As it is, technically, because it has its own URI, one
could conceivably adopt it directly by saying "I support the
http://www.w3.org/2002/soap/conneg feature (or whatever the
URI was;)


> 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


While it may not explicitly reference any of the properties, it does
already have the 415 Unsupported Media HTTP SRC and associated Accept
header which is what would be needed to interoperate with a binding
that say supported application/dime or multipart/related media types
in addition to application/soap+xml.


> 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


Quite possibly, but this at least allows for some latitude.


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


I think that the idea was that the feature that defines the ability
to carry attachments would define these properties.


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


True (ugly). Another approach would be to simply resolve the URIs
referenced via the protocol identified by the URI scheme. Inefficient,
but equivalent in function to resolving attachments by their URI from
the POV of that which does the resolving. In this case, the "additional
information structures" don't need to be called out as separate from the
SOAP message XML Infoset because they are implicit by means of their
reference. One could define the packaging/serialization of the SOAP
message such that any URI references contained within the SOAP envelope
infoset are resolved and inserted into the packaging media.


> 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 08:32:35 UTC