Re: [TBTF] analysis of open/assigned TBTF issues

----- Original Message -----
From: "Christopher Ferris" <chris.ferris@sun.com>
To: <xml-dist-app@w3.org>
Sent: Tuesday, January 15, 2002 11:47 AM
Subject: [TBTF] analysis of open/assigned TBTF issues


> 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 Wednesday, 16 January 2002 12:27:19 UTC