Subject: RE: SOAP/XML Protocol and filtering, etc.

From: Vernon Schryver <[email-masked]>
Date: Mon, 7 May 2001 23:20:46 -0600 (MDT)

>>> Only if the application (e.g., protocol) is signed and cross-certified by a
>> trusted CA could I see this occurring.
>>
>> Yeah, like a Microsoft certificate from Verisign.  NOT!

> Hey, could be a BEA, Computer Assoc., IBM; pick your poison!

Some of us choose not to drink whatever poison causes people to say
that authentication is the same as authorization or that any authentication
you are likely to be able to buy for the $250/year that Verisign/Thwate
apparently found to be the price point will be better than the FAX's of
a local DBA license that Verisign/Thwate accepts as incontrovertible.
(With or without working CRL's, that foolishness will continue to be a
joke waiting for more punch lines.)

What does SOAP have to do with the IETF?  The recent WWW references
seem to point outside the IETF.  Judging from the breathless article
in a hardware trade rag that arrived with this afternoon's post, SOAP
is the latest in the lineage of embraces and extensions that includes
VMRL, ActiveX, and WAP.  This trade article explained it as binary
mode FTP for embedded applications (but of course did not mention
FTP).  If it gets enough marketing muscle and is not quite as silly
as VRML and WAP, then it might survive.  But can the IETF affect it?
If not (and the signs are clear), then why worry about it?

It's fun to joke about people who think that bits that proclaim their own
good intentions are necessarily from the good guys and must be allowed
free reign, but it's probably not something we should be doing in public.

Vernon Schryver    [email-masked]

---

From: Keith Moore <[email-masked]>
Date: Tue, 08 May 2001 02:52:40 -0400

> What does SOAP have to do with the IETF?

apparently they want to make incompatible changes to HTTP, and IETF
has change control over that protocol.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 08 May 2001 07:46:57 -0500

> has change control over that protocol.

Also because we are the organisation worrying about middleboxes
such as firewalls, and therefore about their interaction with
SOAP and/or XML Protocol.

Also because we do have liaison with the W3C, intended to avoid
incompatibilities between what they do and what we do.

  Brian

---

From: Keith Moore <[email-masked]>
Date: Tue, 08 May 2001 08:58:21 -0400

> SOAP and/or XML Protocol.

intermediaries *always* break when the endpoint protocols change.  that's 
not the fault of SOAP - that's entirely due to the failure of firewall
vendors and network admins to understand and apply the end-to-end argument.

ironically it's this very property that causes the SOAP people to try
to subvert HTTP to their needs.   we need to fix the real problem -
which is that we have these boxes in the interior of our network
that think that they know what our end-to-end protocols look like
(even though these protocols change, and need to be able to change,
independently of those boxes) and think they have the license to alter them.

the layering violations caused by such intermediaries are far worse than
anything that SOAP is proposing.  that doesn't justify more bad design on 
SOAP's part - but recent IETF efforts toward actually encouraging such 
intermediaries are far worse.

Keith