[Fwd: Fwd: failure notice]

[Tom Rutt <tom@coastin.com>]

I forward this for Paolo
-- 
----------------------------------------------------
Tom Rutt		email: tom@coastin.com; trutt@fsw.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

---

• From: Paolo Romano <Paolo.Romano@dis.uniroma1.it>
• To: tom@coastin.com
• Date: Mon, 26 May 2003 18:42:16 -0000

Hello Tom,

I am experiencing some troubles with e-mails. If the following mail has not been
delivered, may you please forward it to the list?

Thank you and see you soon,


Paolo

Inoltrato da: MAILER-DAEMON@mail.oasis-open.org

> Hi. This is the qmail-send program at mail.oasis-open.org.
> I'm afraid I wasn't able to deliver your message to the following addresses.
> This is a permanent error; I've given up. Sorry it didn't work out.
>
> <wsrm@lists.oasis-open.org>:
> Sorry, only contributing members may post. If you are a contributing member,
please forward this message to administration@lists.oasis-open.org to get your new
address included (#5.7.2)
>
> --- Below this line is a copy of the message.
>
> Return-Path: <Paolo.Romano@dis.uniroma1.it>
> Received: (qmail 1891 invoked by uid 60881); 26 May 2003 18:20:43 -0000
> Received: from Paolo.Romano@dis.uniroma1.it by hermes by uid 0 with
qmail-scanner-1.15
>  (spamassassin: 2.43.  Clear:SA:0(1.1/8.0):.
>  Processed in 0.496218 secs); 26 May 2003 18:20:43 -0000
> X-Spam-Status: No, hits=1.1 required=8.0
> Received: from unknown (HELO webmail.dis.uniroma1.it) (151.100.59.69)
>   by mail.oasis-open.org with SMTP; 26 May 2003 18:20:42 -0000
> Received: from 127.0.0.1 (localhost [127.0.0.1])
> 	by dummy.domain.name (Postfix on UnitedLinux (i386)) with SMTP id B0FD418E2
> 	for <wsrm@lists.oasis-open.org>; Mon, 26 May 2003 20:30:24 +0200 (CEST)
> Received: from dis.uniroma1.it (localhost [127.0.0.1])
> 	by webmail.dis.uniroma1.it (Postfix on UnitedLinux (i386)) with SMTP id 7D86C1870
> 	for <wsrm@lists.oasis-open.org>; Mon, 26 May 2003 20:30:24 +0200 (CEST)
> Date: Mon, 26 May 2003 18:30:24 -0000
> To: wsrm@lists.oasis-open.org
> Subject: Crash Tolerance Definition + Multicast
> From: Paolo Romano <Paolo.Romano@dis.uniroma1.it>
> X-Mailer: twiggi 2.0.1a
> Reply-To: Paolo.Romano@dis.uniroma1.it
> Message-ID: <20030526203024.4crhxbgwwqphq8@webmail.dis.uniroma1.it>
> MIME-Version: 1.0
> Content-Disposition: inline
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
>
>  I tried to write down some definitions related to Crash Tolerance (Rel 5). As I
>  said during the teleconf, I think we should be as formal and precise
>  as possible when we define the guarantees people can expect when using
>  WS-RM. Unfortunately the definitions grew quite long...
>
>
>  Rel 5: Crash Tolerance Definitions
>  ___________________________________
>
>  In order to clarify the following definitions, I think it's
>  worthy introducing some fundamental fault folerance terminology
>  (reference: "Faul Tolerant Computer System Design" Dhiraj K. Pradhan).
>
>  Fault: A fault is a physical defect, imperfection, or flaw that occurs
>  within some hardware or software component.
>
>  Error: An error is the manifestation of a fault. Specifically, an error is
>  a deviation from accuracy or correctness.
>
>  Failure: If an error results in the system performing one of its functions
>  incorrectly then a system failure has occured.
>
>   _________________________________________________________________
>  Next before defining Crash Tolerance, I think we should formalize what is
>  a Crash failure.
>
>  Crash failure (or simply Crash): Any failure that is consequence of a
>  fail-stop fault.
>
>  Fail-stop fault model: A fault is said to be fail-stop if whenever it
>  occurs, the only visible effect is that the affected component stops
>  functioning. Thus, any component affected by a fail-stop failure can show
>  no incorrect or arbitrary behavior.
>
>  Byzantine fault model: A failure is said to be byzantine if whenever it
>  occurs, the affected component can show any arbitrary, thus possibly
>  malicious, behavior.
>
>  Crash Tolerance: Crash Tolerance is the ability of a system (either only
>  specified or a software/hardware implementation) to ensure predetermined
>  properties despite the occurence of any unpredictable crash failure.
>
>  Non destructive crash (failure): Any crash, which does not
>  compromise the persistent state ( i.e. the state of an application stored
>  on a persistent storage) of an application.
>
>  Definition of Reliable Messaging: (freely inspired and rearranged from
>  WS-Glossary of W3C...)
>
>  The ability:
>
>  1. of the intended receiver of the message to be assured that it receives
>  and delivers a given message once and only once, i.e. exactly one time.
>
>  2. of a sender of a message to be able to determine whether a given
>  message has been already received by its intended receiver.
>
>  3. of a sender to be assured that the messages are received and delivered
>  by the intended receiver in the same order in which they were sent.
>
>  4. of both sender and receiver of a message to carry out (1), (2) and (3)
>  in the face of inevitable, yet often unpredictable, non-destructive
>  crashes which are eventually recovered.
>
>  Failure Recovery: Failure recovery is the process of regaining operational
>  status or restoring the system's integrity after the occurance of a
>  failure.
>
>   ___________________________________________________________________
>
>  I am also not fully satisfied by the current persistent storage
>  definition.
>
>  I hope I'll find the time to reword the current definition before the F2F
>  meeting.
>
>  Apart from the above considerations, as I wrote in one of my past mails, I
>  believe that WS-RM suffers from the lack of multi-cast features. I can
>  imagine several important use cases where such a feature would be useful
>  (in general every time that some data has to be reliably exchanged between
>  more than two endpoints). Practically, WS-RM may either directly exploit
>  the multi-cast ability of multi-cast enabled transport protocols like
>  SMTP, or for the common case of HTTP binding, WS-RM should take care of
>  managing the correct data exchange over several TCP connections carrying
>  the HTTP POST requests and corresponding responses.
>
>  I want to make a motion to include multicast support in the requirements
>  list, but I would appreciate any idea/comments from you.
>
>  Looking forward to meeting you all at the F2F,
>
>  				Paolo
>
>
>
> --
> Paolo Romano
>
>
>




--
Paolo Romano

---