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

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