RE: i028: Implications of the presence of ReplyTo

> > I really believe this would be a mistake. I really want a
> > world where the set of headers is NOT dependant on *how* the
> > message is transmitted ( or how some future message will be
> > transmitted ).

This is the kind of architectural view that sounds absolutely wonderful,
but it can get sub-optimal when actually enforced.  For example, if we end
up recreating all of HTTP as a set of SOAP headers, then we have
duplicated the protocol stack, and we'll actually hurt adoption -- HTTP
users wanting to send SOAP messages in a simple request/reply mode will
not want to deal with ReplyTo, since an HTTP post guarantees a response
comes back.  Similarly, looking at WS-Management, there's lots of things
being created (oh sorry, "leveraged") to re-create SNMP:  SOAP over UDP,
WS-Enumeration, Ws-Events (aka SOAP-Traps) and so on.

Layering and abstractions are great, but so is "optimize the common case."
After all, we want to end up like the IETF protocol suite, not the ISO
one.

	/r$

-- 
Rich Salz                  Chief Security Architect
DataPower Technology       http://www.datapower.com
XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html
XML Security Overview      http://www.datapower.com/xmldev/xmlsecurity.html