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

Hi Chris,

<snip/>

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

:-)

I think if the 'feature' is protocol specific in needs to be bounded within
a section/chapter specific to that protocol. I suppose we might describe it
as a feature applicable to multiple HTTP protocol bindings... although if
I'm honest I also have a difficulty with thta concept to in that I would be
concerned about how HTTP binds implemented to different HTTP binding
specifications determined their mutual compatibility - maybe there's a
baseline for *all* http bindings, but we haven't said that AFAIK.

Also, i think that there may be things defined in a binding specification
that MAY be optionally present in an implementation (and that properties are
a why in which such capabilities may be (conceptually) communicated local to
a node) and that there MAY be some run-time mechanisms by which peer binding
implementations determine (locally within the bindings) what set of
optionally present capabilities they can each safely use.

That takes us down the path of some flexibility in a binding rather than
exploding the combinatorics by multiplying out supported features into
multiple distinct (but related) bindings.

<snip/>

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

Ok... but that's what I mean when I say that HTTP conneg is a protocol
mechanism that can be used to implement features rather than something that
*needs* to be exposed as a feature.

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

BTW: I don't think I was quite clear on the contractiction here. The
operational description of the conneg feature at a requesting node (client
side table) states that: "If conneg:MediaType property is present in the
message exchange context, its value is sent as the value of the Content-Type
HTTP header." Which seems to contradict the emerging view that
"application/soap+xml" is the only content-type compatible with *this*
binding specification - in the case where the conneg:MediaType property
carries a different value. The tables in the HTTP binding do make reference
to 7.5.2 in the rows that set the outbound Content-Type header *but* neither
requester nor receiver tables then discuss alternate serialisations of the
message (+attachments) trigger by a different content-type.

<snip/>

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

I think I could be happy with this... I think it would be for the feature
defn to define the properties, their usage and interpretations... but of a
binding that supports the feature to define *how* that feature is
implemented by that binding. 

<snip/>

Stuart

Received on Wednesday, 3 April 2002 09:57:40 UTC