wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp] [CR312] - Clarify InvalidSession fault description
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp@lists.oasis-open.org
- Date: Mon, 14 Mar 2005 12:54:25 -0500
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 <subbu@bea.com>
03/14/05 11:59 AM
|
To
| wsrp@lists.oasis-open.org
|
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 <subbu@bea.com>*
>
> 03/14/05 11:18 AM
>
>
> To
> wsrp@lists.oasis-open.org
> 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 <subbu@bea.com>*
> >
> > 03/14/05 09:46 AM
> >
> >
> > To
> >
wsrp@lists.oasis-open.org
> > 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
> > >
wsrp@lists.oasis-open.org
> > > 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: wsrp-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail: wsrp-help@lists.oasis-open.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wsrp-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: wsrp-help@lists.oasis-open.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wsrp-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: wsrp-help@lists.oasis-open.org
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]