Next in thread →
Next in month →
Re: [wsrp] [CR312] - Clarify InvalidSession fault description
The RFC definition for should is: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. I would like to stay away from a second conformance statement saying the same thing (we tried to eliminate such occurrences late in v1), but encouraged seems like a reasonable synonym for recommended. Rich Subbu Allamaraju <> 03/14/05 11:59 AM To cc Subject Re: [wsrp] [CR312] - Clarify InvalidSession fault description > Perhaps an additional phrase, ", though Consumers are encouraged to > reinvoke the operation such that the End-User receives a better > rendition of the current state of the Portlet"? This is a minor point, but isn't "encouraged to" weaker than "SHOULD"? Subbu Rich Thompson wrote: > > Yes, I thought the originally suggested change weakened this. It was > occuring in a different area of the spec than the conformance statement > and was suggesting, though not explicitly stating, that the Consumer > would retry. I would like the change in the advice to still carry the > flavor of the conformance statement ... Consumers are encouraged to > retry, but Producers should be aware that this will be governed by > Consumer policy as Consumers are not required to retry. > > Rich > > > *Subbu Allamaraju <>* > > 03/14/05 11:18 AM > > > To > > cc > > Subject > Re: [wsrp] [CR312] - Clarify InvalidSession fault description > > > > > > > > > I agree about the motivation, but I feel that original conformance > statement specifies the behavior more clearly. > > "If the Producer returns an InvalidSession fault message after returning > a sessionID, the Consumer MUST NOT resupply that sessionID on a > subsequent invocation and SHOULD reinvoke the operation that caused the > fault message without any sessionID and supply any data that may have > been stored in the session." > > Do you feel that the original change text weakens this? > > Subbu > > Rich Thompson wrote: > > > > Such a relaxation was not intended, but rather further motivating > > reinitializing the session whenever possible. > > > > Perhaps an additional phrase, ", though Consumers are encouraged to > > reinvoke the operation such that the End-User receives a better > > rendition of the current state of the Portlet"? > > > > Rich > > > > > > *Subbu Allamaraju <>* > > > > 03/14/05 09:46 AM > > > > > > To > > > > cc > > > > Subject > > Re: [wsrp] [CR312] - Clarify InvalidSession fault > description > > > > > > > > > > > > > > > > > > Per WSRP 1.0, the Consumer SHOULD reinvoke in case of this fault. The > > proposed language seems to relax this to a MAY. > > > > Regards, > > > > Subbu > > > > Rich Thompson wrote: > > > > > > While the proposed language does clarify the intent of the fault, it > > > does also make it sound like a requirement is being placed on the > > > Consumer to reinvoke the operation that caused the fault. We have in > > > general left such decisions to Consumer policy and so I would propose > > > the following refinement: > > > > > > New Text: > > > InvalidSession: Used only when a Producer session has expired *and* in > > > order to process the request, the Producer will need the Consumer to > > > *reinvoke the operation resending the user profile and URL templates > > > which may have been stored in the Producer session. If both > > > userContextStoredInSession and templatesStoredInSession fields of the > > > PortletDescription type are false, Producers are encouraged to > > > reinitialize the session in stead of returning the InvalidSession > > > fault.* Producers should note that whether or not the Consumer > actually > > > reinvokes the operation will be a matter of Consumer policy. > > > > > > > > > Rich > > > > > > > > > *Rich Thompson/Watson/IBM@IBMUS* > > > > > > 02/07/05 02:19 PM > > > > > > > > > To > > > > > > cc > > > > > > Subject > > > [wsrp] [CR312] - Clarify InvalidSession fault > > description > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Document: Specification > > > Requested by: Subbu Allamaraju > > > Section: Section 13 > > > Page: 76 > > > Old Text: > > > > > > InvalidSession: Used only when a Producer session has timed out > AND the > > > Producer needs the Consumer to invoke resend data that may have been > > > cached in the session. > > > > > > New Text: > > > > > > InvalidSession: Used only when a Producer session has expired > *and* the > > > Producer needs the Consumer to *reinvoke the operation resending user > > > profile and URL templates that may have been stored in the Producer > > > session. If both userContextStoredInSession and > templatesStoredInSession > > > fields of the PortletDescription type are false, Producers are > > > encouraged to reinitialize the session in stead of returning the > > > InvalidSession fault.* > > > > > > Compatibility Issues: None > > > > > > Reasoning: The original statement is not clear. The new text clarifies > > > the issue, and includes guidance. > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > > For additional commands, e-mail: > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > For additional commands, e-mail: > > --------------------------------------------------------------------- To unsubscribe, e-mail: For additional commands, e-mail:
Next in thread →
Next in month →