1.1 vs. 2.0 planning

Title: 

I thought it might be useful to begin discussing whether/how to differentiate
what goes into 1.1 vs. 2.0 ahead of our May to F2F.  To get the discussion
started I will reiterate my view which I outlined during our January F2F:

      Version 1.1 should contain only those enhancements that don't add or
alter the 1.0 API.  The exception to this rule would be an addition/alteration
to fix a bug in the 1.0 specification.  The version following 1.1 [Currently
called 2.0] becomes the first update where we change/alter the API.  

At the moment this would mean the focus of 1.1 would not be to added/extend
existing function.  Rather 1.1 would:

  
clarify the 1.0 specification where deemed necessary

  
define UDDI support [and any other registry we cared about]

  
define carrying markup over Soap with attachements/DIME.  

  
clarify interoperability and conformance

I think we should limit 1.1 by not altering the protocol/adding new function
for the following reasons:

  
1.1 should follow 1.0 reasonably quickly [Oct-Dec?].  Upgrading API/function
so quickly after releasing 1.0 will likely confuse the market and slow adoption.
 I.e. 1.0 consumers and producers are likely just coming to market during
this time period.

  
Our next API/functional release should include changes/function based
on real world/customer feedback not just our own ideas/experience.  Our likely
1.1 schedule precludes giving consumer/producers enough time to experience
WSRP and communicate true priorities for change.

  
Interoperability/Conformance is grunt work compared to defining new
function.  If both are a focus of a release  interoperability/conformance
is likely to suffer.

     -Mike-