OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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 <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]