W3C home > Mailing lists > Public > public-ws-resource-access@w3.org > February 2010

amending a resolution after the fact (was Re: issue 8304: proposal 1)

From: Gilbert Pilz <gilbert.pilz@oracle.com>
Date: Fri, 19 Feb 2010 15:44:17 -0800
Message-ID: <4B7F2251.2040403@oracle.com>
To: Ram Jeyaraman <Ram.Jeyaraman@microsoft.com>
CC: David Snelling <David.Snelling@UK.Fujitsu.com>, "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
This (amending a resolution to an issue after the fact) is the kind of 
shortcut that ends up causing more work than it saves. If people think 
the paragraph in question should be removed (a position that I 
tentatively agree with), they should raise an issue to that effect.

-  gp

On 2/19/2010 3:14 PM, Ram Jeyaraman wrote:
>
> I agree with Dave's comment below.
>
> WS-Enumeration already states [1] in section 3. The context will 
> become invalid once EndOfSequence is issued. Given that, I see no harm 
> in removing [2].
>
> Suggest treating this as an amendment to the resolution (that was 
> already approved).
>
> Thanks.
>
> [1] http://www.w3.org/2002/ws/ra/edcopies/wsenum.html#EnumMsgs
>
> An enumeration context can become invalid for any reason including:
>
> 1. Enumeration completed (i.e. an EndOfSequence has been returned in a 
> Pull response)
>
> 2. Enumeration released
>
> 3. Enumeration expired
>
> 4. Enumeration ended (i.e. ended via an EnumerationEnd message from 
> data source
>
> 5. Enumeration context replaced in the response to another Pull request
>
> In addition, the data source MAY invalidate an enumeration context at 
> any time, as necessary.
>
> When processing a Pull, Renew, GetStatus or Release operation, a data 
> source MUST generate an wsen:InvalidEnumerationContext fault if it 
> determines that the enumeration context supplied by the consumer in 
> the request is invalid.
>
> [2] http://www.w3.org/2002/ws/ra/edcopies/wsenum.html#Pull
>
> The consumer MUST NOT issue additional Pull request messages after a 
> Pull response containing a wsen:EndOfSequence element has been 
> received. Similarly, upon receipt of a Pull response containing a 
> wsen:EndOfSequence element, the consumer MUST NOT issue a Release 
> operation to signal that the enumeration context is no longer needed.
>
> *From:* public-ws-resource-access-request@w3.org 
> [mailto:public-ws-resource-access-request@w3.org] *On Behalf Of *David 
> Snelling
> *Sent:* Friday, February 12, 2010 4:44 AM
> *To:* Gilbert Pilz
> *Cc:* public-ws-resource-access@w3.org
> *Subject:* Re: issue 8304: proposal 1
>
> Folks,
>
> In section 3.2 it reads:
>
> The consumer _MUST_SHOULD NOT issue additional Pull request messages 
> after a Pull response containing a wsen:EndOfSequence element has been 
> returned. Similarly, upon receipt of a Pull response containing a 
> wsen:EndOfSequence element, the consumer _MUST_SHOULD NOT issue a 
> Release operation to signal that the enumeration context is no longer 
> needed.
>
> This is a change that I think is significant. As a SHOULD I could 
> ignore it, but as a MUST in make me think we should delete the whole 
> paragraph. If the consumer wants to fire off a message to test the 
> error processing of the service, why not? So I would propose we delete 
> the paragraph.
>
> Otherwise this is OK with me.
>
> On 08 Feb 2010, at 00:16, Gilbert Pilz wrote:
>
>
>
> Change-tracked version of proposal to resolve RFC2119 issues in 
> WS-Enumeration.
>
> - gp
>
> <wsenum-8304.zip>
>
> Take care:
>
>     Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
>
>     Fujitsu Laboratories of Europe Limited
>
>     Hayes Park Central
>
>     Hayes End Road
>
>     Hayes, Middlesex  UB4 8FE
>
>     Reg. No. 4153469
>
>     +44-7590-293439 (Mobile)
>
> ______________________________________________________________________
>
> Fujitsu Laboratories of Europe Limited
> Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE
> Registered No. 4153469
>
> This e-mail and any attachments are for the sole use of addressee(s) and
> may contain information which is privileged and confidential. Unauthorised
> use or copying for disclosure is strictly prohibited. The fact that this
> e-mail has been scanned by Trendmicro Interscan does not guarantee that
> it has not been intercepted or amended nor that it is virus-free.
>



Received on Friday, 19 February 2010 23:45:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 18:18:23 GMT