For Wednesday's concall...

[Michael Freedman <Michael.Freedman@oracle.com>]

Attached is a document enumerating the status of each active feature 
proposal.  As we set a goal at the last F2F to use this F2F to drive 
ourselves to make real progress on these features I would like to review 
[for each of these features]  where we are, where we want to be by the 
F2F, what we want to accomplish at the F2F, and how we hope to move 
forward. To structure/start the discussion I have included a 
proposal/answer for each feature and given a rationale.  Let's use the 
first part of the meeting tomorrow to discuss each of these and see if 
we can build a consensus plan for each.
     -Mike-

Title: Interfaces F2F

WSRP 2.0 Status/F2F Plans

The following lists the current state of the active feature proposals.  For
each it includes a proposal for moving forward both at the F2F and within
the context of 2.0.  A rationale is presented for each proposal.

1. Invalidation Caching:
   Status: Feature Proposal
   This feature adds invalidation caching as an extended mechanism to our existing caching model.  
   
   Proposal: Table this for August F2F.  Ask at August F2F if this should be tabled for 2.0 or not.
   
   Rationale:  I haven't and won't make any progress on this any time soon.
   
   
2. Import/Export:
   Status: Preliminary Strawman
   This feature adds ability for consumer to export and import portlets.
   
   Proposal:  Refine before F2F in subcomittee.  Send current version of strawman to overall committee prior to F2F.  During F2F walk through the proposal and refine.  Leave F2F with an open issues list to work on in subcommittee.
   
   
3. Leasing Handles:
   Status: Feature Proposal
   This feature allows various WSRP handles to be leased vs. needing explicit destruction.
   
   Proposal: Table this for August F2F.  Ask at August F2F if this should be tabled for 2.0 or not.
   
   Rationale:  No significant progress since March.  Doesn't seem to be recognized as a critical feature.  Need to wait for more real world experience to motivate group to spend time here?
   
   
4. Collaborative Customization:
   Status: Feature Proposal
   This feature allows consumers to [strongly] influence a portlet's look and feel [beyond simple styles].
   
   Proposal: Table this for August F2F.  Ask at August F2F if this should be tabled for 2.0 or not.
   
   Rationale:  No significant progress since March.  Doesn't seem to be recognized as a critical feature.  Need to wait for more real world experience to motivate group to spend time here?
   
   
5. Resources:
   Status: Feature Proposal
   This feature adds a method to our protocol to get a web resource directly from the producer.
   
   Proposal:  Either writeup a strawman and do one subcomittee review prior to F2F or table this for F2F and ask at the F2F whether this should be tabled from 2.0.
   
   Rationale: When Andre wrote the Feature proposal he seemed to have a strawman in mind.  We should either get a concrete expression of that strawman or table this issue dur to lack of interest/critical need.
   
   
6. Security
   Status: Feature Proposal
   This feature defines how secure portlets are supported.  It also defines how identities are propagated.
   
   Proposal:  Target no new security features for 2.0 .  Instead write a position paper outlining a roadmap for using WSS stack.  However, even though we add no new security features we still should still discuss adding 2.0 support for application level identity propagation.  For F2F motivate value/need for supporting protocol level application level identity propagation.  Goal is to vote at F2F on whether to pursue such support [though we should be prepared to delay such a vote so folks have time to reflect]. Provide a very preliminary strawman in case the discussion needs a concrete representation for folks to understand what this might mean.
   
   Rationale:  The only portion of the WS Security stack that seemingly will be interoperable by next year is XML-Signature and XML-Encryption.  However, without the ability for our producers to describe its needs/usage of these technologies all work related to its use appears to be out-of-band in relation to our protocol.  We should target producing a position paper to provide early guidance to those looking to use WS-Policy to convey such information in band.  However, we also need to recognize that the only feature not currently [partially] accounted for in the protocol is identity propagation.  [We support transport level security and profile propagation].  In the past we deferred from defining identity propagation hoping the WS stack would be realized in time.  Unfortunately, it doesn't look like these features will be widely available and interoperate by 2.0.  Nor are they self describing.  Because its critical for many producers to operate based on a trusted user identity we need to consider the value of directly supporting the notion of application level identity propagation.  [Basically, there are two types of  Identity: application level identity and [OS] system level identity. Application level identity is the identity used by application logic.  Though encouraged to rely on the [OS] system level identity for this, many applications bypass the system support and provide their own login/identity management. This works fine as long as identity is only needed at the application logic level. [OS] System level identity provides a uniform use of an identity for the [OS] subsystems and applications running on top of it.  From a system perspective this is the only identity that is considered secure.
   
   There is a straightforward path for us to extend WSRP to allow a producer to declare how it wants to receive identity [none, wsrp, wss, other].  There is also a straightforward path to representing/passing the identity [UserContext].  We need to decide as a committee whether to support application level identity propagation in addition to [OS] level identity propagation and if so, whether to include it in 2.0 before [OS] level identity propagation is solidified/supported.
   
   
7. WS-Resource
   Status: Feature Proposal
   This feature proposal seeks to recast WSRP using concepts/as a WS-Resource
   
   Proposal:  Table this for August F2F.  Ask at August F2F if this should be tabled for 2.0 or not.
   
   Rationale:  The implications of this feature seems to overhaul our protocol.  Rather then being a regular progression of our existing style it suggests we recast our interfaces to fit/align with this other model.  As we have only just released 1.0 its premature to drastically rework it/replace it.  Either we need to start a second track within this committee to support a second style of producers based on WS-Resource or discuss/propose a better stopping point for our current work before switching to something different.
   
   
8. getPortletDescription
   Status: Feature Proposal
   This feature proposal seeks to add a capability on the service description port type that allows a consumer to get a description of only a subset [even just 1] of the supported portlets.
   
   Proposal:  Either produce a strawman based on discussions last month for F2F or table at this F2F.  If the later this the case, don't yet table from 2.0.
   
   Rationale: Last months discussions raised concerns about whether such a feature is needed.  We asked if the feature could be reflected/expressed by extending the existing APIs vs adding new.  Either need to have something concrete for the F2F [that hopefully has been reviewed/discussed at least once in the subcommittee] or we should not spend time on it at the F2F.  However, because this is a new feature proposal and a small issue whether or not we make progress on it by this F2F shouldn't affect whether its in 2.0 or not.
   
   
9. XForms
   Status: Feature Proposal
   This feature proposal asks us to define standards/guidelines for using XForms in portlets
   
   Proposal: Table this for August F2F.  Ask at August F2F if this should be tabled for 2.0 or not.
   
   Rationale: No visible progress to date.  Doesn't seem to be recognized as a critical feature.  Need to wait for more real world experience or an expert to drive this to motivate group to spend time here?
   
   
10. PropertyUsageField
    Status: Feature Proposal
    This feature enhances our ability to describe properties to distinguish between whether they are informational only [read-only] or read-write.  
    
    Proposal: Either produce a strawman to discuss at F2F or table at this F2F.  If the later this the case, don't yet table from 2.0.
    
    Rationale: No progress since discussed at last F2F so either need new progress [a strawman to discuss] or defer from this F2F.  However, because its a minor feature even if we don't discuss in August shouldn't prevent us from doing so later in Aug/Sept.
    
    
11. Versioning
    Status: Feature Proposal
    This feature proposes we add versioning meta data to enhance ability of consumer to detect producer versions.
    
    Proposal: Proposal: Either produce a strawman to discuss at F2F or table at this F2F.  If the later this the case, don't yet table from 2.0.
    
    Rationale: No progress since discussed at last F2F so either need new progress [a strawman to discuss] or defer from this F2F.  However, because its a minor feature even if we don't discuss in August shouldn't prevent us from doing so later in Aug/Sept.