RE: Representing Actions (was RE: AR023.7.1 (was Re: Dead trout

This is fascinating.

I have recently tried to bring to the TAG's attention -- and have been
completely ignored -- that in our turn the security people in our
company have been completely ignoring the TAG, or at least the sense of
what the TAG has been saying.  Our security people deprecate GET, across
the board, because of exactly the issue that you raise.  I have tried to
argue that a blanket deprecation of GET as a company policy is not
rational -- so far to no avail -- nobody seems to listen to me.  I have
tried to tell the TAG that people in business, at least in my sight, are
not paying attention to  their preference for GET in a variety of
circumstances -- ao far to no avail.

The disconnect here, which I have tried to raise as an issue, is
becoming painful.  To me, at least.

-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com] 
Sent: Wednesday, February 19, 2003 5:07 PM
To: 'Mark Baker'
Cc: www-ws-arch@w3.org
Subject: RE: Representing Actions (was RE: AR023.7.1 (was Re: Dead trout

[snip] ...

 ...

VARIANT 6 - SOAP Header

POST http://ecommerce.example.com
...
<SOAP:Envelope>
  <SOAP:Header role="messagehandler">
   <x.Actor>processorder</x.actor>
  </SOAP:Header>
  ...
</SOAP:Envelope>

[Snip] ...

MY PERSONAL PREFERENCES

My personal preference is for variant 6 (sorry Mark it's not URI's!) and
here's why ...

All the options that involve putting information in the URI (Variants 1
through 4) mean that the data is visible to anyone who sees the
information go over the net. While this might not often be a worry
sometimes it is. The simple fact, for example, that Microsoft was
placing an order with Sun (or vice versa), could be the basis of some
very interesting articles ... not that I am suggesting that either would
do such a thing ;)

On the other hand, if the data is recorded in the body of the message
somewhere then it can be encrypted which helps ensure privacy.

Received on Wednesday, 19 February 2003 22:40:15 UTC