W3C home > Mailing lists > Public > www-ws-arch@w3.org > December 2002

Message Expiry & the WS Architecture

From: Burdett, David <david.burdett@commerceone.com>
Date: Sun, 15 Dec 2002 11:51:15 -0800
Message-ID: <C1E0143CD365A445A4417083BF6F42CC053D1531@C1plenaexm07.commerceone.com>
To: www-ws-arch@w3.org

I want to start a new thread on an Architectural issue and use the idea of
Message Expiry to illustrate it. Note that I could just as easily have used
other concepts as it is the principle that I want to bring out.

Recently there has been a lot of discussion on Reliable Messaging. One of
the ideas in LEVEL 1 of Reliable Messaging that I described, was the idea
that a message expired and should not be processed after a certain point in

Now the obivous way to identify when a message expires is to include an
"ExiresAt" header in a SOAP Feature/Module in a message that contains the
time after which the message must not be processed - this is what ebXML
Messaging did with its TimeToLive header.

Now for some questions ...
QUESTION 1. Is the idea of Message Expiry **exclusive** to Reliable
If the answer is yes, then you can easily include how Message Expiry works
in the RM spec. But I don't think so this is likely. I can quite imagine
sending a message that has an expiry time, but not care if the message was
delivered. So there is another question ...

QUESTION 2.  If the definition of Message Expiry is not in the RM spec, then
where should it be defined and who should define it?
You *might* argue that some very basic headers like MesssageId goes in the
XMLP spec to support some of the ideas that Assaf has been putting forward,
but should Message Expiry be included in XMLP as well? If it does not go in
the XMLP spec, then it must go somewhere else, but where and what group
should be responsible for defining it. Some options include:
1. It's own spec, developed by a separate group - which one
2. It's own spec developed as part of RM
3. Part of the RM spec 

This doesn't just apply to Message Expiry and Message Id, it applies to many
other areas as well such as:
1. Message Routing & Addressing
2. Message Content lists
3. Choreography Managment
etc, etc ...

I could go on, but I would like other people's views.


Director, Product Management, Web Services
Commerce One
4440 Rosewood Drive, Pleasanton, CA 94588, USA
Tel/VMail: +1 (925) 520 4422; Cell: +1 (925) 216 7704
mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com
Received on Sunday, 15 December 2002 14:50:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:01 UTC