Re: CTG: non-traditional browsing applications

> I agree but note this particular case would 
> not be covered by your proposal.

For a good reason: there is little we can do.
Type application/xhtml+xml is used both for
browsing (XHTML, recommended type), and for
some AJAX applications (possible, though not
the most recommended type).

We cannot distinguish one usage from the
other (at least, I see no straightfoward way
to do it).

> AFAICT, the section creates an analogy to 
> HTTP proxies at the SOAP level, where
> forwarding and active intermediaries
> for SOAP messages roughly tranlate into 
> transparent and non-transparent proxies for
> HTTP messages. Section 2.7.3 contains 
> warnings about side-effects active 
> intermediaries may have but does not forbid
> them.

Section 2.7 defines forwarding intermediaries,
which have a well-defined behaviour and are
conformant SOAP processing entities (with 
plenty of MUST and SHOULD they must fulfil).

The "active" parts of active intermediaries
do not have any formally defined behaviour, 
are not subject to any conformance criteria
(no MUST or SHOULD); I do not know what was 
the rationale to have entities whose
behaviour is open-ended and whose conformance
cannot be assessed -- the background of this 
small section must be curious.

> If the SOAP spec itself does not forbid 
> active intermediaries at the SOAP level, 
> why should we globally forbid non-
> transparent proxies operations on SOAP
> content?

Because we are already restricting such 
behaviour in the comparable, though perhaps
more general case of browsing over HTTP (where
the original RFC2616 mentions, and does not
prohibit non-transparent proxies), notably
with restrictions over transformation of
mobile-optimized content or "conversion" of
HTTP methods, for instance.

Besides, the SOAP specifications state:

"It is strongly recommended that SOAP
features provided by active SOAP 
intermediaries be described in a manner that 
allows such modifications to be detected by 
affected SOAP nodes in the message path."

In other words, clients and servers should get
a formal description of the modifications 
performed by such intermediaries. The current
CTG do not even go as far as that; I would
gladly accept inclusion of a comparable
requirement into the document.

> I do not see a role either and don't
> remember people mentioning true use cases,
> but I do not think no immediate role and 
> potential danger translte into "we must 
> prevent".

The past experience with CT proxies has been
traumatic enough that we should err on the
side of caution.


E.Casais

Received on Monday, 2 November 2009 19:34:29 UTC