- From: Ram Jeyaraman <Ram.Jeyaraman@microsoft.com>
- Date: Sat, 20 Feb 2010 00:11:37 +0000
- To: Gilbert Pilz <gilbert.pilz@oracle.com>
- CC: David Snelling <David.Snelling@UK.Fujitsu.com>, "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
- Message-ID: <503546C5699C1144BDEA0D0DFFE7F8811E6E39EE@TK5EX14MBXC110.redmond.corp.microsoft.>
I have opened a new issue http://www.w3.org/Bugs/Public/show_bug.cgi?id=9095 for this. Thanks. From: Gilbert Pilz [mailto:gilbert.pilz@oracle.com] Sent: Friday, February 19, 2010 3:44 PM To: Ram Jeyaraman Cc: David Snelling; public-ws-resource-access@w3.org Subject: amending a resolution after the fact (was Re: issue 8304: proposal 1) 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: Enumeration completed (i.e. an EndOfSequence has been returned in a Pull response) Enumeration released Enumeration expired Enumeration ended (i.e. ended via an EnumerationEnd message from data source 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> [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<mailto:public-ws-resource-access@w3.org> Subject: Re: issue 8304: proposal 1 Folks, In section 3.2 it reads: The consumer MUSTSHOULD 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 MUSTSHOULD 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 Saturday, 20 February 2010 00:32:25 UTC