- From: Chou, Wu (Wu) <wuchou@avaya.com>
- Date: Tue, 31 Mar 2009 12:25:01 -0400
- To: "Katy Warr" <katy_warr@uk.ibm.com>
- Cc: "Gilbert Pilz" <gilbert.pilz@oracle.com>, "Doug Davis" <dug@us.ibm.com>, "Asir Vedamuthu" <asirveda@microsoft.com>, "Bob Freund" <bob.freund@hitachisoftware.com>, "Li, Li (Li)" <lli5@avaya.com>, <public-ws-resource-access@w3.org>
- Message-ID: <F81BDFA28AE48D4793E253362D1F7A740112AAFA@300813ANEX2.global.avaya.com>
Katy,
wse:Mode attribute in WS-E is just an extension point to allow a
subscriber to specify the required type of the push mode event delivery.
The importance of having Mode attribute in Delivery of WS-E is that the
event source have to fully understand/support the extension in the Mode
attribute; otherwise it must fault the event subscription with a
standard wse:DeliveryModeRequestedUnavailable fault. These are semantics
defined in WS-E specs, not from EPR.
I am not convinced that EPR solves everything, including Internet
routing, etc. Removing Mode attribute is going to fundamentally change
the semantics of event delivery in WS-E. This is a protocol change that
can impact many applications and implementations. This is not a case of
removing redundancy in the specs.
- Wu Chou
________________________________
From: Katy Warr [mailto:katy_warr@uk.ibm.com]
Sent: Tuesday, March 31, 2009 9:43 AM
To: Chou, Wu (Wu)
Cc: Gilbert Pilz; Doug Davis; Asir Vedamuthu; Bob Freund; Li, Li (Li);
public-ws-resource-access@w3.org
Subject: Fw: [Bug 6692] New: Remove Mode from the specification
Wu
I agree with Gil's point below.
Also, using a wse:Mode to indicate the proxy is a horrible design.
There are a number of ways that an EPR could be targeted at an address
through a proxy. Typically, the EPR's <address> might be that of the
proxy and the proxy itself would perform a mapping to the target. If
the proxy didn't hold this mapping, you could also embed the real EPR
within the proxy one so it flowed as a reference parameter for the proxy
to process. That would be a non-standard solution but no less standard
than the 'wse:Mode=urn:push_thru_proxy' that you are advocating as an
alternative. And at least it the EPR solution solves the problem for all
EPRs (and not just WS-Eventing NotifyTos).
As has been stated already - the addressing layer deals with delivery of
messages and we don't need to re-invent this function. Why would we
want to duplicate this in the Eventing spec (and not in others)? And if
we duplicate this function, what happens if the wse:mode contradicts
what's in the notifyTo EPR?
Katy
----- Forwarded by Katy Warr/UK/IBM on 31/03/2009 13:59 -----
From: Gilbert Pilz <gilbert.pilz@oracle.com>
To: "Chou, Wu (Wu)" <wuchou@avaya.com>
Cc: Doug Davis <dug@us.ibm.com>, Asir Vedamuthu
<asirveda@microsoft.com>, Bob Freund <bob.freund@hitachisoftware.com>,
"Li, Li (Li)" <lli5@avaya.com>, member-ws-resource-access@w3.org,
public-ws-resource-access@w3.org,
public-ws-resource-access-request@w3.org
Date: 31/03/2009 07:15
Subject: Re: [Bug 6692] New: Remove Mode from the specification
________________________________
Wu,
I'm confused by your "out-of-band-proxy" use case. If the agreement to
use a proxy is truly "out of band", how can it appear in the
wse:Subscribe message which is, be definition, a message sent from the
Subscriber to the Event Source?
- gp
Chou, Wu (Wu) wrote:
Doug,
Many thanks for your comments. Let's separate the concerns and focus on
each thread.
1) Keep Mode attribute of Delivery in WS-E: The use case is to establish
legitimate critical applications based on Mode attribute of Delivery
in WS-Eventing. It should not remove Mode from the WS-E specs, because
it will affect and break the protocol used by existing applications and
implementations.
2) EPR usage patterns: Let's definitely find sometime to discuss EPR
extensions, and I will follow up with you on that.
My thinking is: EPR can do many things but not everything. In our
"out-of-band proxy" use case, the NotifyTo EPR is exactly the same for
both cases, no matter it needs to go through the proxy or not, e.g. "
http://avaya.com <http://avaya.com/> " . The out-of-band proxy can be
opaque to the subscriber, e.g. a between enterprise IT 's agreement.
The event source cannot differentiate two different event delivery modes
just from the EPR in NotifyTo. And this is where the Mode attribute of
Delivery in WS-E becomes critical.
It is possible to put <ext:Proxy> as part of the NotifyTo EPR. But it is
not all clear what event source should do to it. EPR alone does not
provide the declarative semantics to event source on how it should
treat <ext:Proxy>. For example, <ext:Proxy> should not be interpreted as
reference parameters of the sink, because it is the EPR of the routing
proxy which is a separate resource entity.
By the opaque rule recommendation of EPR, event source should copy
NotifyTo EPR and send the event back. But this will not work here. In
order to deliver event correctly, the event source must do some "deep"
semantic analysis of the EPR , and derive from the EPR the semantic
action that it has to perform - must deliver the events through
<ext:Proxy> to the sink. If it cannot do that, it must fault the
subscription. This is where the Mode attribute of Delivery in WS-E is
needed as described in our use case.
Regards,
- Wu Chou
________________________________
From: Doug Davis [mailto:dug@us.ibm.com <mailto:dug@us.ibm.com> ]
Sent: Monday, March 30, 2009 2:45 PM
To: Chou, Wu (Wu)
Cc: Asir Vedamuthu; Bob Freund; Li, Li (Li);
member-ws-resource-access@w3.org
<mailto:member-ws-resource-access@w3.org> ;
public-ws-resource-access@w3.org
<mailto:public-ws-resource-access@w3.org> ;
public-ws-resource-access-request@w3.org
<mailto:public-ws-resource-access-request@w3.org>
Subject: RE: [Bug 6692] New: Remove Mode from the specification
Wu,
your use-case is a very interesting one. It shows one of the key
points that I've been trying to make - this isn't specific to
WS-Eventing. The need to send a message through a proxy (and have that
proxy be defined by someone other than the sending endpoint - the
subscriber in your case) could be just as meaningful to any EPR. For
example, this could be needed for uses of wsa:ReplyTo, or the
registrationEPR in WSTX, or the AcksTo EPR in RM. In all of these cases
I believe this can be done by doing pretty much what you've done below.
That is, provide the ultimate destination within the NotifyTo EPR but
then use some extension mechanism to say "use a proxy". In this
particular case I would suggest that you define an extension for the EPR
structure - then this can be reused in _all_ WS-* specs. For example:
<wse:NotfyTo>
<wsa:Address> http://avaya.com <http://avaya.com/> </wsa:Address>
<ext:Proxy> http://myproxy.com <http://myproxy.com/> </ext:Proxy>
</wse:NotifyTo>
You can then also define a mU header that would require it to verify
that it will adhere to the extension. IMO, this will not only satisfy
your WS-Eventing needs but allow for this useful extension to be reused
in lots of places. I'm not keen on creating one-off type of solutions
just for certain WS-* specs - I think its a much better design to create
reusable components. For example, should RM create a "use a proxy"
extension too for its EPRs? Probably not when the above seems to work
just fine for both specs.
Its also worth pointing out that reusing the extensibility points of
EPRs is actually a far cleaner design. In the example you gave it looks
like the pub/sub code will need to understand this extension. While that
is a valid choice, it would be much less work for developers to have
this information encapsulated within the EPR itself. Then as this
information is moved through a system only one data structure needs to
be passed around - the EPR - and the pub/sub code might never actually
need to know about this extension at all. In your model below they
would need to pass around an EPR as well as the proxy information. And
then when the next extension comes along they'll need to add yet
another. That a potentially large code change each time. If, instead,
they just knew about the EPR structure then no code changes will be
needed except down at the transport layer of the product - where it
should be. At that point they can examine all of the bits of the EPR
(including the proxy info) and take whatever steps are necessary. This
allows for an implementation to be designed such that it isolates itself
from areas of concern that are of no consequence to it.
thanks
-Doug
______________________________________________________
STSM | Standards Architect | IBM Software Group
(919) 254-6905 | IBM 444-6905 | dug@us.ibm.com
<mailto:dug@us.ibm.com>
The more I'm around some people, the more I like my dog.
"Chou, Wu (Wu)" <wuchou@avaya.com> <mailto:wuchou@avaya.com>
Sent by: public-ws-resource-access-request@w3.org
<mailto:public-ws-resource-access-request@w3.org>
03/30/2009 02:12 PM
To
<public-ws-resource-access@w3.org>
<mailto:public-ws-resource-access@w3.org> ,
<member-ws-resource-access@w3.org>
<mailto:member-ws-resource-access@w3.org>
cc
"Asir Vedamuthu" <asirveda@microsoft.com>
<mailto:asirveda@microsoft.com> , "Bob Freund"
<bob.freund@hitachisoftware.com> <mailto:bob.freund@hitachisoftware.com>
, "Li Li" <lli5@avaya.com> <mailto:lli5@avaya.com>
Subject
RE: [Bug 6692] New: Remove Mode from the specification
+1
Asir: Many thanks for sharing your thoughts on this issue. And I attach
one of our use cases of Mode in WS-E Delivery below.
- Wu Chou
Wu Chou, IEEE Fellow, Ph.D. | Director |Avaya Labs Research | AVAYA |
233 Mt. Airy Road| Rm. 2D48 | Basking Ridge, NJ 07920 | Voice/Fax:
908-696-5198 / 908-696-5401 | wuchou@avaya.com
<blocked::mailto:wuchou@avaya.com>
------Use Case of MODE in WS-E Delivery -----
Here is a concrete use case where the subscriber requests the event
source to push the event notifications through a proxy, obtained
either through an out-of-band channel (not specified in the Subscribe
request, e.g. the enterprise registers a special event notification
proxy with the service provider) or dynamically specified in the
Subscribe request. Certainly this behavior cannot be conveyed by the
wse:NotifyTo. This critical use case thus justifies the need for the
Mode attribute in WS-E Delivery.
To indicate the use of an out-of-band proxy, the Subscribe request body
looks like this:
<wse:Subscribe>
<wse:Delivery Mode="urn:push_thru_proxy" >
<wse:NotifyTo>...</wse:NotifyTo>
</wse:Delivery>
</wse:Subscribe>
To indicate the use of a dynamic proxy, the Subscribe request body
looks like this:
<wse:Subscribe>
<wse:Delivery Mode="urn:push_thru_proxy" >
<wse:Notifyto>...</wse:Notifyto>
<ext:Proxy>...</ext:Proxy>
</wse:Delivery>
</wse:Subscribe>
"Mode=urn:push_thru_proxy" cannot be put into the Delivery extension.
This is because if the source cannot support "push_thru_proxy", it must
fault as defined by Mode in Delivery, and the subscriber expects a
standard wse:DeliveryModeRequestedUnavailable fault. And there is no
standard WS-E fault for items in the Delivery extension.
----------
From: Asir Vedamuthu <asirveda@microsoft.com
<mailto:asirveda@microsoft.com?Subject=RE%3A%20%5BBug%206692%5D%20New%3A
%20Remove%20Mode%20from%20the%20specification&In-Reply-To=%253CD46B7A44F
5BD0C4A96D7D69E31C51D6B5098DCF4A7%40NA-EXMSG-C118.redmond.corp.microsoft
.com%253E&References=%253CD46B7A44F5BD0C4A96D7D69E31C51D6B5098DCF4A7%40N
A-EXMSG-C118.redmond.corp.microsoft.com%253E> >
Date: Sun, 29 Mar 2009 19:59:23 -0700
To: "public-ws-resource-access@w3.org
<mailto:public-ws-resource-access@w3.org?Subject=RE%3A%20%5BBug%206692%5
D%20New%3A%20Remove%20Mode%20from%20the%20specification&In-Reply-To=%253
CD46B7A44F5BD0C4A96D7D69E31C51D6B5098DCF4A7%40NA-EXMSG-C118.redmond.corp
.microsoft.com%253E&References=%253CD46B7A44F5BD0C4A96D7D69E31C51D6B5098
DCF4A7%40NA-EXMSG-C118.redmond.corp.microsoft.com%253E> "
<public-ws-resource-access@w3.org
<mailto:public-ws-resource-access@w3.org?Subject=RE%3A%20%5BBug%206692%5
D%20New%3A%20Remove%20Mode%20from%20the%20specification&In-Reply-To=%253
CD46B7A44F5BD0C4A96D7D69E31C51D6B5098DCF4A7%40NA-EXMSG-C118.redmond.corp
.microsoft.com%253E&References=%253CD46B7A44F5BD0C4A96D7D69E31C51D6B5098
DCF4A7%40NA-EXMSG-C118.redmond.corp.microsoft.com%253E> >
Message-ID:
<D46B7A44F5BD0C4A96D7D69E31C51D6B5098DCF4A7@NA-EXMSG-C118.redmond.corp.m
icrosoft.com>
<mailto:D46B7A44F5BD0C4A96D7D69E31C51D6B5098DCF4A7@NA-EXMSG-C118.redmond
.corp.microsoft.com>
Last week, on the WG conference call, I mentioned that we will provide
some clarity on the concept of delivery mode (in WS-Eventing) and
related use cases.
Delivery mode [1] provides a subscriber with a mechanism to specify the
means by which an event is delivered. Delivery mode is represented as a
URI in a Subscribe message [2]. The semantics indicated by a delivery
mode are:
1) Rules for the delivery of events
a) Semantics and lifecycle of a Notification delivery
b) Message Exchange Pattern used (One-way, Request-Response, etc.) and
how the delivery mode binds to those Message Exchange Patterns
c) Format of a response (if any)
d) Configuration parameters or context data (if any) to support the
Message Exchange Pattern
e) Rules for the delivery or other disposition of faults generated
during a Notification delivery
2) Delivery mode specific protocol information (if any) to guarantee
interop
3) Supported delivery formats.
Some portion of the above semantics are captured by an EPR, in a
machine-readable form, but certainly not all. So, there is value added
by a formal mechanism to indicate a delivery mode.
The delivery mode is an extension point in WS-Eventing. The WS-Eventing
specification defines a single built-in delivery mode, Push Mode. Other
delivery modes may be important for external groups or other W3C Working
Groups and are delegated to those groups. This is similar to SOAP
Bindings. The W3C XML Protocol WG defined SOAP Protocol Binding
Framework as an extension point and a concrete binding, SOAP HTTP
Binding (is also identified using a URI [3]). Other groups defined SOAP
bindings such as SOAP-over-JMS and SOAP-over-UDP.
The DMTF WS-Management WG defined three new delivery modes [4] and these
delivery modes have been widely adopted.
Furthermore, based on the WS-RA WG charter [5], the WG deliverables need
to satisfy the following requirements as well:
1) Charter scope - "Mechanisms to allow a subscriber to specify the
means by which an event is delivered and the definition of a push-based
delivery mode".
2) Charter scope - "In order to avoid disrupting the interoperability
of existing implementations,
WS-MetadataExchange<http://www.w3.org/Submission/2008/SUBM-WS-MetadataEx
change-20080813/
<http://www.w3.org/Submission/2008/SUBM-WS-MetadataExchange-20080813/>
>,
WS-Transfer<http://www.w3.org/Submission/2006/SUBM-WS-Transfer-20060927/
<http://www.w3.org/Submission/2006/SUBM-WS-Transfer-20060927/> >,
WS-Eventing<http://www.w3.org/Submission/2006/SUBM-WS-Eventing-20060315/
<http://www.w3.org/Submission/2006/SUBM-WS-Eventing-20060315/> > and
WS-Enumeration<http://www.w3.org/Submission/2006/SUBM-WS-Enumeration-200
60315/ <http://www.w3.org/Submission/2006/SUBM-WS-Enumeration-20060315/>
> should remain compatible with protocols and formats that depend on
them, and offer a smooth migration path from the submission to the
standard." We are aware of two dependant protocols - DPWS [6] (uses Push
Mode) and WS-Management [4] (uses Push Mode and, as mentioned before,
defines three new delivery modes).
[1] http://www.w3.org/Submission/WS-Eventing/#Delivery_Modes
<http://www.w3.org/Submission/WS-Eventing/#Delivery_Modes>
[2] http://www.w3.org/Submission/WS-Eventing/#Subscribe
<http://www.w3.org/Submission/WS-Eventing/#Subscribe>
[3] http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#http-bindname
<http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#http-bindname>
[4] http://www.dmtf.org/standards/published_documents/DSP0226.pdf
<http://www.dmtf.org/standards/published_documents/DSP0226.pdf> -
Section 7
[5] http://www.w3.org/2008/11/ws-ra-charter.html#scope
<http://www.w3.org/2008/11/ws-ra-charter.html#scope>
[6] http://specs.xmlsoap.org/ws/2006/02/devprof/
<http://specs.xmlsoap.org/ws/2006/02/devprof/>
We hope this helps.
Regards,
Asir S Vedamuthu
Microsoft Corporation
-----Original Message-----
From: public-ws-resource-access-notifications-request@w3.org
<mailto:public-ws-resource-access-notifications-request@w3.org?Subject=R
E%3A%20%5BBug%206692%5D%20New%3A%20Remove%20Mode%20from%20the%20specific
ation&In-Reply-To=%253CD46B7A44F5BD0C4A96D7D69E31C51D6B5098DCF4A7%40NA-E
XMSG-C118.redmond.corp.microsoft.com%253E&References=%253CD46B7A44F5BD0C
4A96D7D69E31C51D6B5098DCF4A7%40NA-EXMSG-C118.redmond.corp.microsoft.com%
253E> [mailto:public-ws-resource-access-notifications-request@w3.org
<mailto:public-ws-resource-access-notifications-request@w3.org?Subject=R
E%3A%20%5BBug%206692%5D%20New%3A%20Remove%20Mode%20from%20the%20specific
ation&In-Reply-To=%253CD46B7A44F5BD0C4A96D7D69E31C51D6B5098DCF4A7%40NA-E
XMSG-C118.redmond.corp.microsoft.com%253E&References=%253CD46B7A44F5BD0C
4A96D7D69E31C51D6B5098DCF4A7%40NA-EXMSG-C118.redmond.corp.microsoft.com%
253E> ] On Behalf Of bugzilla@wiggum.w3.org
<mailto:bugzilla@wiggum.w3.org?Subject=RE%3A%20%5BBug%206692%5D%20New%3A
%20Remove%20Mode%20from%20the%20specification&In-Reply-To=%253CD46B7A44F
5BD0C4A96D7D69E31C51D6B5098DCF4A7%40NA-EXMSG-C118.redmond.corp.microsoft
.com%253E&References=%253CD46B7A44F5BD0C4A96D7D69E31C51D6B5098DCF4A7%40N
A-EXMSG-C118.redmond.corp.microsoft.com%253E>
Sent: Thursday, March 12, 2009 8:37 AM
To: public-ws-resource-access-notifications@w3.org
<mailto:public-ws-resource-access-notifications@w3.org?Subject=RE%3A%20%
5BBug%206692%5D%20New%3A%20Remove%20Mode%20from%20the%20specification&In
-Reply-To=%253CD46B7A44F5BD0C4A96D7D69E31C51D6B5098DCF4A7%40NA-EXMSG-C11
8.redmond.corp.microsoft.com%253E&References=%253CD46B7A44F5BD0C4A96D7D6
9E31C51D6B5098DCF4A7%40NA-EXMSG-C118.redmond.corp.microsoft.com%253E>
Subject: [Bug 6692] New: Remove Mode from the specification
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6692
<http://www.w3.org/Bugs/Public/show_bug.cgi?id=6692>
Summary: Remove Mode from the specification
Product: WS-Resource Access
Version: CR
Platform: PC
OS/Version: All
Status: NEW
Severity: major
Priority: P2
Component: Eventing
AssignedTo: public-ws-resource-access-notifications@w3.org
<mailto:public-ws-resource-access-notifications@w3.org?Subject=RE%3A%20%
5BBug%206692%5D%20New%3A%20Remove%20Mode%20from%20the%20specification&In
-Reply-To=%253CD46B7A44F5BD0C4A96D7D69E31C51D6B5098DCF4A7%40NA-EXMSG-C11
8.redmond.corp.microsoft.com%253E&References=%253CD46B7A44F5BD0C4A96D7D6
9E31C51D6B5098DCF4A7%40NA-EXMSG-C118.redmond.corp.microsoft.com%253E>
<mailto:public-ws-resource-access-notifications@w3.org
<mailto:public-ws-resource-access-notifications@w3.org?Subject=RE%3A%20%
5BBug%206692%5D%20New%3A%20Remove%20Mode%20from%20the%20specification&In
-Reply-To=%253CD46B7A44F5BD0C4A96D7D69E31C51D6B5098DCF4A7%40NA-EXMSG-C11
8.redmond.corp.microsoft.com%253E&References=%253CD46B7A44F5BD0C4A96D7D6
9E31C51D6B5098DCF4A7%40NA-EXMSG-C118.redmond.corp.microsoft.com%253E> >
ReportedBy: david.Snelling@UK.Fujitsu.com
<mailto:david.Snelling@UK.Fujitsu.com?Subject=RE%3A%20%5BBug%206692%5D%2
0New%3A%20Remove%20Mode%20from%20the%20specification&In-Reply-To=%253CD4
6B7A44F5BD0C4A96D7D69E31C51D6B5098DCF4A7%40NA-EXMSG-C118.redmond.corp.mi
crosoft.com%253E&References=%253CD46B7A44F5BD0C4A96D7D69E31C51D6B5098DCF
4A7%40NA-EXMSG-C118.redmond.corp.microsoft.com%253E>
<mailto:david.Snelling@UK.Fujitsu.com
<mailto:david.Snelling@UK.Fujitsu.com?Subject=RE%3A%20%5BBug%206692%5D%2
0New%3A%20Remove%20Mode%20from%20the%20specification&In-Reply-To=%253CD4
6B7A44F5BD0C4A96D7D69E31C51D6B5098DCF4A7%40NA-EXMSG-C118.redmond.corp.mi
crosoft.com%253E&References=%253CD46B7A44F5BD0C4A96D7D69E31C51D6B5098DCF
4A7%40NA-EXMSG-C118.redmond.corp.microsoft.com%253E> >
QAContact: public-ws-resource-access-notifications@w3.org
<mailto:public-ws-resource-access-notifications@w3.org?Subject=RE%3A%20%
5BBug%206692%5D%20New%3A%20Remove%20Mode%20from%20the%20specification&In
-Reply-To=%253CD46B7A44F5BD0C4A96D7D69E31C51D6B5098DCF4A7%40NA-EXMSG-C11
8.redmond.corp.microsoft.com%253E&References=%253CD46B7A44F5BD0C4A96D7D6
9E31C51D6B5098DCF4A7%40NA-EXMSG-C118.redmond.corp.microsoft.com%253E>
<mailto:public-ws-resource-access-notifications@w3.org
<mailto:public-ws-resource-access-notifications@w3.org?Subject=RE%3A%20%
5BBug%206692%5D%20New%3A%20Remove%20Mode%20from%20the%20specification&In
-Reply-To=%253CD46B7A44F5BD0C4A96D7D69E31C51D6B5098DCF4A7%40NA-EXMSG-C11
8.redmond.corp.microsoft.com%253E&References=%253CD46B7A44F5BD0C4A96D7D6
9E31C51D6B5098DCF4A7%40NA-EXMSG-C118.redmond.corp.microsoft.com%253E> >
The concept of Mode is redundant in the current version of the
specification.
All events can be thought of as being delivered. There is no actual
definition
of "Push Mode" and no other recommended modes. We even have a
MakeConnection
strategy to allow clients behind NATs to fetch events. Likewise,
strategies for
complex queuing and distribution are supportable without adding
additional
modes and are outside the scope of this specification.
Proposal: Remove /s:Envelope/s:Body/*/wse:Delivery/@Mode from the
specification
and all references to Push Mode. A simple explanation of the delivery
idea and
a pointer to some of the techniques available will be needed.
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
<http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email>
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
Wu Chou, IEEE Fellow, Ph.D. | Director |Dialogue System Research | AVAYA
| 233 Mt. Airy Road| Rm. 2D48 | Basking Ridge, NJ 07920 | Voice/Fax:
908-696-5198 / 908-696-5401 | wuchou@avaya.com
<blocked::mailto:wuchou@avaya.com>
________________________________
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
Received on Tuesday, 31 March 2009 16:26:02 UTC