WSRP draft .9 comments

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

I have made it through section 6.4.  Here are my comments so far:

1. supportedFeatures in serviceDescription:  should we prefix these with wsrp: thereby allowing non-standard features to referenced [aka extensions].
2. Lifetime in both RegistrationState and RegistrationContext.  This sticks out like a sore thumb.  It seems to be there so ModifyRegistration can continue to return a RegistrationState.  I suggest instead it return a ModifyRegistrationResult that contains both a RegistrationState and a Lifetime.  If we do this should each be optional and signify that that omission means no changes?  Or does the producer have to explicitly return items because omission means null?
3. ClientData Type section.  First sentence is:  "The MarkupParams structure carries information concerning the user agent using this type."  This seems out of date.  Suggest a better introduction to what the clientdata structure is about.
4. HandleEventsFailed is inconsistent with our CopyPortlets/Import/ExportsFailed structures.  Should we reconsider and have the structure return the QNames of the events that failed [and mutliple for any given reason].  Do we really care to handle the odd situation that the array contains teh same events twice?  We could always tell the Consuemr that if it is bothered by this to send them in different requests.  Another possibility is that the Event type get a new field to carry a consumer supplied ID that can be used to reference in the subsequent failed array.
5. Section 6.1.23 EventParams Type -- description of portletStateChange:  reference that this impacts processing of an event needs to be updated to reflect that handleEvents is now a bulk operation.  Second sentence seems to have a misplaced semicolon.
6. Can someone clarify the use case for resource form submission/file upload?  Is this merely because we didn't prohibit it in 1.0?  Should we be more restrictive in our API?  Part of my objection is this gives the portlet a loophole to change state during render but without access to navigational state updates.
   
7. Section 6.3 Getresource:  sentence [line 2253] "This operation is used whenever the URL activated has ..."  would be better as "This operation is used whenever the activated URL has ..."