Re: 8283 discussion

I like the general direction.  I'm a bit worried that the proposed text, 
when read by a non-ws* geek, will be interpreted too loosely.  The current 
text, to me, can be read to imply that faults can always be trashed w/o 
the need for any reason at all (basically hardcoding wsa:faultTo = 
/dev/null). I think all of us understand that implementations are supposed 
to transmit the fault under normal situations and its only due to special 
reasons (like security concerns) that would prevent it from being sent. 
So, I'd prefer if we made that sentiment clear. 

Also, to address Dave's question - what if we followed WS-I BP's lead?  It 
says:
        When a fault is generated, no further processing should be 
performed. 

How about something like:

The term "generate" is used in relation to the various faults defined by 
this specification to imply that a fault is produced, no further 
processing SHOULD be performed, and the fault would normally be 
transmitted. However, there might be reasons why a compliant implement 
might choose not to transmit the fault - for example, security concerns - 
in these situations the fault MAY NOT be transmitted.

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog.



David Snelling <David.Snelling@UK.Fujitsu.com> 
Sent by: public-ws-resource-access-request@w3.org
01/15/2010 06:16 AM

To
Ram Jeyaraman <Ram.Jeyaraman@microsoft.com>
cc
Gilbert Pilz <gilbert.pilz@oracle.com>, "public-ws-resource-access@w3.org" 
<public-ws-resource-access@w3.org>
Subject
Re: 8283 discussion






Ram,

The first "in" in your statement should be "is". Generally I like this 
approach.

But my real question. The generation of a fault should also imply the 
processing/side effects etc didn't or may have occurred. Can we capture 
this semantic as well, or is this behavior too operation specific?


On 14 Jan 2010, at 22:51, Ram Jeyaraman wrote:

It may be useful to state that a fault that is generated may be 
transmitted. But whether an implementation persists the fault or some 
information about it in some form is a design choice.  For example, it is 
possible to have compliant implementations that never persist state.
 
How about this proposal:
 
·       Include changes to fault definitions as proposed to all WS-RA 
specifications.
·       Add [1] to the compliance section.
 
Thanks.
 
[1] Add to the compliance section of all WS-RA specifications
 
The term ?generate? in used relation to the various faults defined by this 
specification. This term implies that a fault is produced but does not 
necessarily imply that it is transmitted. When a fault is generated, a 
compliant implementation MAY transmit the fault.
 
From: Gilbert Pilz [mailto:gilbert.pilz@oracle.com] 
Sent: Tuesday, January 05, 2010 10:41 AM
To: Ram Jeyaraman
Cc: public-ws-resource-access@w3.org
Subject: Re: 8283 discussion
 
I don't want to get into how faults are recorded but it seems to me that 
an implementation must at least allow for the recording of faults. Whether 
such logging is enabled or not is a configuration issue.

- gp

On 1/5/2010 9:53 AM, Ram Jeyaraman wrote:
I am fine with clarifying this from a protocol standpoint without getting 
into implementation details. For example, from a protocol standpoint, a 
fault is generated due to a failure of the request. But how the 
implementation handles the failure (such as whether/how it records that 
information) is an implementation detail. Thanks.
 
From: public-ws-resource-access-request@w3.org [
mailto:public-ws-resource-access-request@w3.org] On Behalf Of Gilbert Pilz
Sent: Tuesday, January 05, 2010 9:31 AM
To: Ram Jeyaraman
Cc: public-ws-resource-access@w3.org
Subject: Re: 8283 discussion
 
That's not what I asked. "Request failure" and "processing cessation" are 
two different things. I assert that our definition of "generate a fault" 
should state that when a fault is generated (a) processing of the request 
in which the fault occurs ceases (b) some record of this fault is produced 
and possibly recorded (depending on log/trace config) (c) a fault message 
is optionally transmitted (if a response was expected this fault is 
transmitted in lieu of the response or no response is transmitted).

- gp

On 12/31/2009 3:46 PM, Ram Jeyaraman wrote:
Is it fair to assume that the act of generating a fault will halt the 
processing of the request in who's context the fault was generated?
 
Yes, readers familiar with general fault semantics would conclude that the 
corresponding request failed when a fault is generated.
 
From: Gilbert Pilz [mailto:gilbert.pilz@oracle.com] 
Sent: Friday, December 18, 2009 1:42 PM
To: Ram Jeyaraman
Cc: public-ws-resource-access@w3.org
Subject: Re: 8283 discussion
 
Do we need to say anything about what effect generating a fault has on the 
processing of requests? Is it fair to assume that the act of generating a 
fault will halt the processing of the request in who's context the fault 
was generated?

- gp

On 12/15/2009 10:46 AM, Ram Jeyaraman wrote:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8283
 
Pursuant to the action I took from last meeting, I suggest adding a 
definition [1] of  what ?generate? means in the context of faults.
 
Thus, to resolve this issue, I suggest:
Include changes to fault definitions as proposed in the issue.
Add [1] to the compliance section.
 
Thanks.
 
[1] Add to the compliance section of all WS-RA specifications
 
The term ?generate? in used relation to the various faults defined by this 
specification. This term implies that a fault is produced but does not 
necessarily imply that it is transmitted.

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 and McAfee Groupshield 
does
not guarantee that it has not been intercepted or amended nor that it is
virus-free.