Re: 8283 discussion

+1

On 18 Jan 2010, at 19:14, Doug Davis wrote:

>
> I believe the complete proposal is now:
> - modify all faults, in the "faults" section of each spec, to have 
> text of the form:
>         "This fault MUST be generated when . . ."
> - Add, to the "Notational Convention" section of each spec (I think 
> this is a better place than "Compliance"):
> 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 
> implemention might choose not to transmit the fault - for example, 
> security concerns - in these situations the fault MAY NOT be 
> transmitted.
>
> MEX doesn't define any faults so this doesn't apply to MEX.
>
> 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.
>
>
> Ram Jeyaraman <Ram.Jeyaraman@microsoft.com>
> 01/18/2010 05:56 PM
>
> To
> Doug Davis/Raleigh/IBM@IBMUS, "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org
> >
> cc
> Subject
> RE: 8283 discussion
>
>
>
>
>
> Dave said:
>
> Ø  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?
>
> Describing the processing semantics from a protocol point of view is 
> useful.
>
> Doug said:
>
> Ø  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.
>
> This looks good. Here is an updated version with minor wording 
> changes:
>
> 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.
>
> This seems reasonable.
>
> Thanks.
>
> From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org
> ] On Behalf Of Doug Davis
> Sent: Friday, January 15, 2010 4:47 AM
> To: public-ws-resource-access@w3.org
> Subject: 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.
>
>
>

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.