Re: text/xml for SOAP is incorrect

On Wed, Sep 19, 2001 at 12:25:15PM -0700, Andrew Layman wrote:
> The goal sounds entirely reasonable, but how will we draw a firm
> line to avoid the slippery slope, because there will always be some
> peephole advantage to putting one more bit of information into the
> MIME type?

I don't know if that's our decision to make, or our problem; the HTTP
binding uses content-types, and we only need to decide if SOAP wishes
to define its own content-type, or use a generic one. Other people
may define their own bindings with their own content-types, and we
can't really stop them.


> Additionally, why is SOAP special?  If the goal is to have ignorant
> intermediaries avoid touching messages they should not, suppose
> that there is another subtype of XML doc that also should not be
> touched, e.g. "application/xyzzy+xml".  Of course, no intermediary
> is yet programmed to avoid messing with xyzzy subtype instances. 
> So, will they act any better than if we just said
> "application/xml"?  That is, are we solving the problem only for
> SOAP yet leaving the general problem unadressed?

It certainly is a problem. Unfortunately, the HTTP allows
intermediaries to transform messages, and to use arbitrary heuristics
to cache them. Even if the appropriate cache-control headers are
sent, I suspect that many implementations will still perform
processing based upon things like content-type.

We can take the moral high ground and say that it's not our problem
that these things happen. However, it will cause interoperability
problems and seriously piss of firewall operators, IMO.

In a world where an increasing number of formats of XML-based, it's
not too useful to call them all 'application/xml'. Content-type does
still have some utility, for all of its imperfections.

I'd reiterate that other W3C XML-based formats have chosen to define
their own content-type. Perhaps we should explore the reasoning of
those groups (SVG and SMIL, to start with).


> Another question, which may have been addressed in a message I
> overlooked, but what if a SOAP message per the application/soap+xml
> proposal were contained in a MIME multipart structure?  In this
> case, the top-level MIME type would make no mention of SOAP (or
> would it? How?) If so, how would a processor of the message make
> the correct and rapid messing-with or dispatching decisions?

I'd imagine that the Type parameter would be used (RFC2387, Section
3.1).


Regards,


> -----Original Message-----
> From: Mark Nottingham [mailto:mnot@mnot.net] 
> Sent: Wednesday, September 19, 2001 12:13 PM
> To: Andrew Layman
> Cc: xml-dist-app@w3.org; dave@scripting.com
> Subject: Re: text/xml for SOAP is incorrect
> 
> 
> 
> 
> Ah, that's not it at all (well, at least from my standpoint). The
> motivation isn't to enable *SOAP* intermediaries to identify messages
> that they should touch, it's to avoid *HTTP* (and other
> application-layer) intermediaries from messing with SOAP messages that
> they shouldn't.
> 
> In other words, the concern is not to identify the message's type with
> any granularity as a hint; it's to assure that the message isn't
> confused with other XML content types, which some devices (for better or
> worse) may make assumptions about. 
> 
> It may be helpful for us to consider typing (through content-type) and
> hinting (through SA or Content-Features) separately; typing (being able
> to recognize a SOAP message as such) is defensive, and IMHO should be
> mandatory; hinting is application-specific, and is optional.
> 
> 
> Cheers,
> 
> 
> 
> On Wed, Sep 19, 2001 at 10:55:39AM -0700, Andrew Layman wrote:
> > But if intermediaries are going to distinguish SOAP from non-SOAP xml,
> 
> > would not some intermediaries need to further distinguish among 
> > classes of SOAP messages?  Suppose that facilities are invented that 
> > add digital signatures or encryption, for example.  Might not some 
> > intermediaries desire to distinguish such secured SOAP messages from 
> > other SOAP messages?  If so, do we end up with 
> > "application/crypto+dsig+soap+xml"?
> > This seems like a very slippery slope we are setting out on.
> > 
> > And, if we embark on names such as "application/crypto+dsig+soap+xml",
> > then how do we designate which crypto spec is being referenced?  Which
> 
> > dsig spec?  This is contrary to the decentralized naming in URLs that 
> > made the web grow so fast and successfully.
> > 
> > 
> > -----Original Message-----
> > From: Mark Nottingham [mailto:mnot@mnot.net]
> > Sent: Wednesday, September 19, 2001 9:42 AM
> > To: Jacek Kopecky
> > Cc: christopher ferris; Henrik Frystyk Nielsen; christopher ferris;
> > xml-dist-app@w3.org
> > Subject: Re: text/xml for SOAP is incorrect
> > 
> > 
> > 
> > I think that's the intent of the '+xml' - to allow MIME processors 
> > identify it as an XML format.
> > 
> > My concern is not so much dispatch - which is what the request-uri 
> > should be used for, at any rate - but for identifying the messages as 
> > being formatted to the SOAP conventions for those that will casually 
> > handle them, such as intermediaries.
> > 
> > We've decided to run the HTTP binding on port 80, and to use HTTP 
> > status codes to indicate SOAP semantics. SOAPAction is optional. If 
> > SOAP 1.2 messages use application/xml, there is no easy way to 
> > identify a message as SOAP. As a result, parts of the Web 
> > infrastructure may treat SOAP messages as any old XML, performing 
> > transforms, etc. Additionally, firewall vendors won't even have a 
> > stop-gap means of controlling the flow of SOAP messages.
> > 
> > Is our intent to effectively hide the use of SOAP? Doing so seems to 
> > risk both interoperability problems and the appearance that we're 
> > antagonistic to firewalls, etc.
> > 
> > 
> > 
> > 
> > On Wed, Sep 19, 2001 at 02:55:26PM +0200, Jacek Kopecky wrote:
> > >  Chris,
> > >  To explain my position: I am wary of application/soap and
> > > application/soap+xml because it won't usually allow generic
> processing
> > 
> > > as if it were XML. It's true that the usability of such generic
> > > processing is debatable, but I don't immediately see the advantages
> of
> > 
> > > application/soap...  either (when I strike out what I feel is misuse
> 
> > > -
> > 
> > > that would be the dispatching usecase).
> > > 
> > >                             Jacek Kopecky
> > > 
> > >                             Idoox
> > >                             http://www.idoox.com/
> > > 
> > > 
> > > P.S: 21st century started on Sep 11, 2001
> > > 
> > > 
> > > 
> > > On Wed, 19 Sep 2001, christopher ferris wrote:
> > > 
> > >  > Henrik,
> > >  >
> > >  > Certainly you agree that SOAP is it's own thing.
> > >  > It just happens to also be XML. SOAP has its own process  > 
> > > model. Why the resistance to a soap-specific  > media type? 
> > > Certainly seems mostly harmless to me.  >
> > >  > Cheers,
> > >  >
> > >  > Chris
> > >  >
> > >  > Henrik Frystyk Nielsen wrote:
> > >  > >
> > >  > > >Sure, why not? You can reflect the SOAP version in a MIME  > >
> 
> > > >"version" parameter on the Content-Type header. Dispatchers  > > 
> > > >>can
> > 
> > > choose whether to use this (or not) as they see fit. A  > > >SOAP
> > > processor can make the determination as to support of the  > > 
> > > >namespace by inspecting the namespace and further dispatching  > >
> > > >as needed (or loading the right modules, schema, whatever).  > >
> > >  > > How is this different from regular XML processing to the degree
> > that it
> > >  > > requires a special content type?
> > >  > >
> > >  > > Henrik
> > > 
> > 
> > --
> > Mark Nottingham
> > http://www.mnot.net/
> >  
> > 
> 
> -- 
> Mark Nottingham
> http://www.mnot.net/
>  
> 

-- 
Mark Nottingham
http://www.mnot.net/

Received on Wednesday, 19 September 2001 16:04:45 UTC