- From: Walden Mathews <waldenm@optonline.net>
- Date: Thu, 09 Jan 2003 22:24:20 -0500
- To: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>, www-ws-arch@w3.org
Mike, > > You want to have that discussion again? 8-) XML is just syntax. > > There's nothing in XML+namespaces that a firewall can use to make a > > security decision. It needs application level knowledge (see the > > message to Miles). > > Whatever. All I know is that every day I see another article in the trade > press about this; today's is > http://www.networkmagazine.com/article/NMG20021223S0005 Are you familiar with the term 'marketecture'? > > I presume that admins can configure the firewall to reject all messages they > don't recognize the application semantics of, and use various rules to > control the processing of messages they do recognize. From the second page of the article above: "However, those who may want to take action on XML content-such as read the identity of an XML object or encrypt a specific XML field-will require additional XML capabilities. "It's like the difference between C and assembler," says Kerry Champion, president of Westbridge Technology (www.westbridgetech.com). "Sure, I can do everything in assembler that I can in C, but it's a question of time and resources."" What does this say to you, in practical terms? > > Roy's quote says nothing about using only HTTP headers to monitor, cache, > etc. the information. If an intermediary understands XML and SOAP, in can > be configured to use XPath or whatever to peek into messages and make such > decisions. Thus, *XML* allows "visibility". In order to perform a security function, wouldn't it have to "understand" more than XML and SOAP syntax, though? How would it arrive at that (higher) level of understanding? Walden
Received on Thursday, 9 January 2003 22:25:37 UTC