W3C home > Mailing lists > Public > xml-dist-app@w3.org > January 2002

[TBTF] analysis of open/assigned TBTF issues

From: Christopher Ferris <chris.ferris@sun.com>
Date: Tue, 15 Jan 2002 14:47:38 -0500
Message-ID: <3C448759.3000900@sun.com>
To: xml-dist-app@w3.org
TBTFers,

I took an AI to do a rough review of each of the identified issues
assigned to the TBTF[1] (adding in #58 as per today's
call). For each outstanding issue, I looked at what it might
take to close the issue. In some cases, I've identified issues
that I believe can be closed based on work done to date and
reflected in the spec. In others, I've cited a need for some
discussion/work by the TF before the issue can be considered
closed.

TBTF Open/Assigned Issues

33[2] - may require some discussion. Suggest that it could
	be closed, but not being privvy to the requirements
	gathering exercise and the discussions around "layering"
	and modularity as referenced by this issue as not
	being addressed might suggest otherwise (MED)

50[3] - adoption of "lite" SMTP binding for Primer, based on
	our Framework should be sufficient to close. The fact
	that there has already been a binding defined for
	SOAP1.1 over BEEP, as well as ebXML's SMTP binding
	could also be taken as adequate evidence that the
	issue could be closed. (LOW)

57[4] - needs some discussion. If WG adopts the current
	ID for SOAP media type, which includes action
	parameter, then unless the transport was incapable
	of carrying MIME, there would be no loss of
	information as cited by Marwan (SOAPAction).
	Believe that the TBF addresses infoset and as such
	places onus on bindings to define how infoset
	is transferred from one node to another... (LOW/MED)

58[5] - believe we can close this citing the TBF "features"
	aspect of a binding. (LOW)

102[6] - may require some discussion. Current HTTP
	binding clearly specifies when to return a Fault
	(addressing is implicit because Fault returned on
	HTTP Response) however, it is not specific w/r/t
	the nature of the Fault to be returned. It could
	be argued that it should be more explicit in this
	regard.

103[7] - probably needs some discussion. We've defined MEP and TMEP
	but we really haven't (IMO) addressed "message path"
	sufficiently, esp as regards intermediaries. (MED)

105[8] - believe that our treatment of MEP and TMEP sufficient
	to close this issue. (LOW)

133[9] - needs some discussion (MED)

178[10] - needs some discussion (MED)

Cheers,

Chris

[1] http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2002Jan/0037.html
[2] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x33
[3] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x50
[4] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x57
[5] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x58
[6] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x102
[7] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x103
[8] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x105
[9] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x133
[10] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x178
Received on Tuesday, 15 January 2002 14:48:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:06 GMT