[Issue-6413] Summary of what I heard and straw man proposal

Several have argued for inclusion of frag support within WS-T
Others have argued against it.
Issues as I hear them:

1. Composability.
It is probably better (in my opinion) of doing nothing that would  
hinder alternative frag support mechanisms in WS-T
In this regard, a proposal that gave frag support an independent  
namespace and used traditional composition mechanisms would make it  
clear.

2. Defining a clear direction.
Inclusion of frag support in T does establish a clear direction.  It  
is argued that it is more clear to be contained within the WS-T spec  
(and namespace?)

3. Adoption.
This is a bit unclear. Certainly a good frag spec would encourage  
adoption.  If composability with alternative frag support specs were  
discouraged, on the other hand, then adoption of WS-T might be reduced.
There is one known implementation of frag support in another spec,  
that is the version defined in WS-Man.  It currently exists by  
composing with an underlying WS-T.
it is not clear to me that including this frag proposal in WS-T would  
encourage or discourage them from using their own.  They are an  
independent minded group.

Proposal: (a bit of a cuisinart approach to be sure)
1. Include the frag support spec within WS-T
2. Compose it with traditional mechanisms
3. Give it its own namespace


Does this cut the baby in half well enough?
thanks
-bob