TBTF: Analysis of feedback comments on Transport Binding material

TBTF'ers,

I took an AI to look over the feedback we received on the binding material.
I have done so below with some discussion and in most cases some suggested
action (up for discussion of course). It may be that we (David) would like
to track all of these through the Issues list although I think if there some
that we can reach agreement on quickly, then I think I'd rather not burden
the issues list with them, given is general tendency for the number of
unresolve issues to remain constant or possibly increase over time.

Regards

Stuart
--

> Doug Davies 
> [2] http://lists.w3.org/Archives/Public/xml-dist-app/2001Dec/0036.html
> 	- Definition of features has broader scope than binding framework

Don't think that the current WD addresess this. The term feature arises
first in Part 1 Section 5.1, the introduction to the SOAP Protocol Binding
Framework. It does not appear in the glossary nor is it introduced as a more
generally applicable concept the broader scope that Doug suggests.

Suggested Action: Need to decided where we want features/properties concepts
to be applied more generally through the spec. At present I think the
concepts are well bounded with the binding framework, with some questions
over the relationship between 'features' and modular extensions to SOAP. The
smallest thing to do is probably to clarify this relationship. A larger
thing to do would be to rework both concepts (features and modules) into
some unified concept that serves both purposes. Appealing though this is I
don't think we have the time available to do this.

> 	- Onus to decide how best to express a feature lies with binding
>       spec, not the communicating node.

This is the subject of an unresolved item within the TBTF and the target of
the ednote in Part 1 section 5.1. 
Suggested Action: Report back to Dug when we have resolved the ednote.

> Doug Davies
> [3] http://lists.w3.org/Archives/Public/xml-dist-app/2001Dec/0037.html
> 	- asks for clarifiaction on a reference.

Simple Response: ...its one of a number of pieces of text developed by the
TBTF that it will be drawing on in making its contribution to the WD. Its
probably too late already to provide much of a useful response.

> 
> Glyn Normington
> [4] http://lists.w3.org/Archives/Public/xml-dist-app/2001Dec/0048.html
> 	- Concern about the small repetoire of features.

It would be nice to have a broader repetoire of features. Eamon O'Tuathail
has generated a list [a] which I have been meaning to evaluate. Regardless,
I don't think we have signed up (yet) to produce any more features than
single-request-response MEP and possibly an one-way MEP, although I'm not
sure what commitment we actually have to the latter.

[a] http://www.clipcode.com/peer/soap_features.htm

Suggested Actions: Take a position that features, like SOAP modules are a
point of extensibility for SOAP and that our expectation is that the
repetoire of features will grow over time. Our current intend is to provide
a framework within which such features can be created and to use that
framework to provide the bare essentials for SOAP 1.2.

> 	- Detail comment on SRR MEP FSMs and diagram (consistency)

Mostly editorial. Bring make the FSMs and the diagrams consistent
(independent of tabular/algebraic presentation style).

> 	- HTTP versions and assumptions about protocol interop (presumably
>       HTTP 1.0/1.1 interop and SOAP).

Interesing question. Not clear whether our HTTP binding is tied to HTTP 1.1.
One would assume so... HTTP 1.1 preserves backward compatibility with 1.0,
so I'm guessing that HTTP itself takes care of this. If that is indeed the
case a note to that effect at start of the HTTP binding would probably cover
this issue. Henrik?

Suggested action: Get an HTTP guru's (HFN, MB,...?)opinion on this question.
Possibly log as an Issue.

> Eamon O'Tuathail
> [5] http://lists.w3.org/Archives/Public/xml-dist-app/2001Dec/0038.html
> 	- Comment that intro material from earlier versions appears to have
been lost.

The 'missing' material propagated into part 2 section 6
http://www.w3.org/TR/2001/WD-soap12-part2-20011217/#soapfeatspec

Suggested action: Respond to Eamon indicating where this material appears in
the current WD.

> 	- Detailed comment on SRR MEP FSM, temporal overlap of request and
response.
>

Suggested action: Fix the FSMs and their descriptions to allow overlapping
request and response (independent of tabular/algebraic presentation style).
The FSM encapsulated in the algebraic expressions does allow the overlap and
could be presented in tabular style instead.
 
> 
> Glen Daniels
> [6] http://lists.w3.org/Archives/Public/xml-dist-app/2001Dec/0031.html
> 	- Don't repeat the state diagrams (editorial)

Editorial

 	- Suggest illustrative examples of what goes on the wire for HTTP?

Seek contributions... but not too many :-)

> 	- Editorial comments on 'currentMessage', infoset and attachments.

Editorial

> 	- framing should be clear that this is a work in progress

I/We think that that is clear from the existing ed-notes and the fact that
the document is a WD.

> Kumeda-san
> [7] http://lists.w3.org/Archives/Public/xml-dist-app/2001Dec/0121.html
> 	- Positioning of status code listings

[Discussion - well my viewpoint really :-)]

Simply, the significance attributed to HTTP status codes by a requester and
the specification of the generation of HTTP status codes by a responder are
two different things. Consistent with the protocol designers mantra of "be
conservative in what you generate and liberal with what you accept",
discussion of the significance attributed to response codes by a requester
covers a broader range of response codes than those that we proscribe to be
generated by a responder.  As a consequence HTTP status codes are presented
from both points-of-view at a the appropriate points within the WDs.

Suggested action: skw (or another volunteer :-)) pick's up this discussion
with Kumeda-san so see if we can reach a point of agreement.

> 	- HTTP Status code 202 useful and required.

Discussion Needed:

It's not clear to me that we can use 202 - 204 No Content may be a better
response for the circumstances that Kumeda describes. 202 may not be
appropriate because the RFC 2616 description of 202 states : "The entity
returned with this response SHOULD include an indication of the request's
current status and either a pointer to a status monitor or some estimate of
when the user can expect the request to be fulfilled."

Current WD (part 2) does provide a place for interpreting the receipt of
both 202 and 204 at a requester. It does not detail specific circumstances
under which 202 and 204 are generated by a responder.

Suggested action: Consult HTTP guru's, discuss on email and hopefully
conclude. Log as an Issue? 


> 	- 204 response require no message body (per RFC 2616)... current
text implies empty envelope.

The HTTP (2616) requirement is for no entity body to be present on the wire.
The suggested interpretation given in the WD is to treat this as if an empty
SOAP envelope had been received. Alternate would be to just say the the
response message is null, void, nil... whatever.

Suggested action: TBTF decide which is the most appropriate interpretation
of 204 and report back to Kumeda-san either indicating the change we will
make or clarifying as above.

> 	- Request more guidance on the use of 4xx and 5xx series HTTP status
codes.

This is something we need to do... fill in more detail on the status codes -
under what circumstances particular codes are generated and significance to
a SOAP requester upon receipt. Resolution to Issue 12 will probably help
firming up some of this.

Suggested Action: AI to TBTF to more fully populate status code tables and
to review design consistency of the HTTP binding's use of HTTP status codes
with resolutions to date.

> 
> Raj Nair [recorded as Issue 178]
> [8] http://lists.w3.org/Archives/Public/xml-dist-app/2001Dec/0104.html
> [9] http://lists.w3.org/Archives/Public/xml-dist-app/2001Nov/0248.html
> 	- Requirements on bindings imposed by end-to-end features.

Now recorded as Issue 178... CF's disposition is MED: Needs some discussion.

Received on Friday, 18 January 2002 09:59:25 UTC