RE: [wsrp-wsia] re: Issues for 10/7

[Rex Brooks <rexb@starbourne.com>]

Gil, Rich+Editors, all,

I appreciate the Herculean Task you've all been doing, but due to the 
fact that I am working hammer and tongs on another spec and trying to 
get it voted on by Oct. 31, I can't really follow this list well 
enough to keep track of these issues come Thursdays' meetings without 
a freshly revised overall list to which I can refer during the call. 
So, could you possibly update the whole list next week, with xls-2 as 
the identifier so I can find it in the seemingly miles long set of 
specs and spec issues in my WSIA directories? I would really 
appreciate it. It is a wee bit late to do so for today's meeting.

And, Rich, during the call, can you be doubly sure to announce the 
issue number, and perhaps even repeat it during the discussion 
because once I get behind while re-reading the relevant sections of 
the spec which is being discussed to make sure I'm reasonable clear 
what is being decided, I am well and truly.....well, you get the 
idea. Like many folks, when you discuss issues close to my interests 
I perk right up, but when you get out in the boonies (from my point 
of view) it is very easy to get lost in the deep dark woods.

Thanks,
Rex

At 10:27 AM +0200 10/17/02, Gil Tayar wrote:
>Mike, All,
>Below are the changes made to the issues list based upon Mike's email and
>the responses to it:
>
>#21 (initEnvironment verbiage) - left as tentatively resolved with the
>resolution now including the verbiage.
>
>#23 (clientParameters) - re-activated due to objections on resolution
>
>#31 (MINIMIZED state and markup) - left as tentatively resolved with the
>resolution now including more of the description of the resolution. As this
>is not in sync with JSR168, a new issue will probably be created on this
>out-of-syncness
>
>#34 (title to portal) - left as tentatively resolved, but with no resolution
>date. The resolution text states that we should wait for a
>rejection/confirmation from JSR168.
>
>#35 (URL encoding) - resolution moved back one week, per Mike's request.
>
>#43/#53/#82 (previous window state/mode) - re-activated. In the interest of
>sanity, I will remove these issues to "obsolete" mode and create _one_ issue
>that combines them all. (and in the darkness bind them? :->)
>
>#57 (refHandle unification) - re-activated.
>
>#74 (MAY or MUST releaseHandles) - re-activated. The two proposed
>resolutions are now in the "Description" part.
>
>#85 (sessionID expires MUST/MAY) - re-activated. The two proposed
>resolutions are now in the "Description" part.
>
>-----Original Message-----
>From: Michael Freedman [mailto:Michael.Freedman@oracle.com]
>Sent: Wed, October 16, 2002 00:53
>To: wsrp-wsia
>Subject: [wsrp-wsia] re: Issues for 10/7
>
>
>There are few issues this week that have been marked to move from
>tentative to resolved that I don't think are ready yet.  Here are the
>comments for those issues:
>
>Issue #21: More verbiage for initEnvironment().
>    Though draft .7 adds more words to clarify this it still has a
>placeholder for defining the fault that indicates the inited environment
>has expired.  Is there another issue open to address this?  If not
>should we leave this issue open until the verbiage is complete?
>
>Issue #23: Adding clientParameters to getMarkup
>    The resolution is too general.  I suggest we tighten the
>definition/usage of clientParameters to merely mean the non-query string
>data that qualifies the request.  I.e. the equivalent of what's carried
>in the http request headers (though because we are consumer mediated, it
>this information is client + consumer data).  What I object to in the
>resolution is that it carries query string data.  This is not
>information that portlets should encoding in their URLs. Finally, I
>think we should rename this field maybe to something like
>"qualifyingParameters".  This field carries more than client headers.
>
>Issue #31:  MINIMIZED state does not necessarily mean no markup.
>     The resolution suggests that its in sync with JSR 168.  However, the
>JSR has not synched with this resolution.  This should remain open until
>we can resolve with the JSR.
>
>Issue #34: Do we want to define how an entity sends a title to the
>portal?
>     The proposed solution doesn't match JSR semantics.  We should keep
>this issue open until this is resolved [or open a new issue].
>
>Issue #35:  URL encoding
>      I am still awaiting information from Sasha.  I suspect this won't
>be "resolved" by Thursday.  Can you move this back another week?
>
>Issue #43/#53/#82: previous window state/mode
>      I disagree with the resolution.  The resolution should be to remove
>entirely.
>
>Issue #57: unification of session handle and entity handle
>      I think this should stay "tentative".  The impacts of this decision
>are still being identified/discussed vis-a-vis cloneEntity/updating
>state etc.
>
>Issue #74: Should consumer MAY or MUST releasehandles
>     I disagree with the proposed resolution.  This isn't practical to
>implement/test for conformance.  Rather we should just say something
>like "a consumer must not consider its registration with a producer
>dissolved until it successfully releases the registration. Consumer
>should deregister producers as soon as such registration no longer makes
>sense.  Because of the distributed nature of such an operation,
>consumers should be prepared to detect releasehandle failures and to
>retry until successful or otherwise keep the current relationship open."
>
>Issue #85: sessionID expires MUST/MAY
>    I disagree with the proposed resolution.  MUST is too strong as a
>consumer needs to be free to manage its resources. Also, why can a a
>producer throw a fault indicating the entity session has expired?  I
>thought that is only for initEnvironment?  I suggest the following
>wording that excludes both the MUST and MAY words:
>"The Consumer uses this new value as the
>refHandle on subsequent invocations until either the Producer supplies
>another newRefHandle or the
>refHandleExpires duration indicates that the refHandle is no longer
>valid.
>Failure to pass this refHandle is analogous to prematurely terminating
>the session.  Doing so may lead to unexpected or undefined user
>interactions.  Consumers should only violate the above semantics  under
>exceptional circumstances.  Producers, however need to protect
>themselves and expect that an entity session may be "reset" on every
>request."
>
>     -Mike-
>
>
>
>
>
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>


-- 
Rex Brooks
Starbourne Communications Design
1361-A Addison, Berkeley, CA 94702 *510-849-2309
http://www.starbourne.com * rexb@starbourne.com