RE: FW: draft findings on Unsafe Methods (whenToUseGet-7)

That is a possible approach.  Also, I think encouraging a 
clear distinction is the right thing to do simply from an 
engineering documentation perspective if no other in order 
to clarify what is and is not and can and cannot be warrantied.  

When this topic originally came up on XML-Dev, I responded 
with the following suggestions:

1. Training before development of web services. 
2. Inspection prior to deployment of web services. 
3. Security testing suites. 
4. Properly constructed contracts for web services that include 
   security provisions and remediation clauses. 

This does not address issues before the TAG at this time, 
but it may be good advice at this time to those who want 
to work with SOAP and need to do the right things to do that. 
At the very least, vendors of SOAP products must understand 
clearly their responsibilities to their customers.

How hard will it be for a proxy listening for SOAP messages 
to inspect them to ensure they are appropriate?  Is authentication 
of source of request sufficient?  I understand the requests 
to minimize traffic here.  If 
this is an improper question for this list, and there are 
responses, perhaps this is best answered on XML-Dev.

len


-----Original Message-----
From: Keith Moore [mailto:moore@cs.utk.edu]

> A system that
> does not correspond to an architecture operates outside
> that architectural scope and that may be all that needs
> to be said.

that, and the system may not interoperate well with things that
were designed to be compatible with the architecture...and to 
minimize confusion it may be desirable to encourage a visible 
distinction between the two.

for example, if if is the case that SOAP breaks assumptions made by
things that listen on port 80, perhaps it's better if people are 
encouraged to run SOAP on another port.  that way, SOAP-aware things 
need not fight with HTTP-aware things.

Received on Wednesday, 24 April 2002 13:57:06 UTC