- From: Williams, Stuart <skw@hplb.hpl.hp.com>
- Date: Wed, 3 Apr 2002 16:28:32 +0100
- To: "'Christopher Ferris'" <chris.ferris@sun.com>, Marc Hadley <marc.hadley@sun.com>
- Cc: xml-dist-app@w3.org
Marc, Chris, +1 to the wording in quotes. > -----Original Message----- > From: Christopher Ferris [mailto:chris.ferris@sun.com] > > +1 > > I too would prefer if the para in 7.1 said something like: > > "Implementations of this binding MUST support, at a minimum, the media > type "application/soap+xml" according to [12] when transmitting SOAP > Requests or Responses. See [12] for parameters defined by this media > type and their recommended usage." > > I could also see adding a provision that REQUIRED the conneg > feature be implemented if additional media types are supported. > > This would allow conformance as well as extensibility. Personnally, I remain wary of exposing HTTP content negotiation as a feature. > Cheers, > > Chris Regards Stuart -- > Marc Hadley wrote: > > <snip/> > >> > > > > +1, mandating use of application/soap+xml as the only supported encoding > > prevents use of, e.g SOAP+attachements, with this binding. I brought > > this up on the latest TBTF call. I would prefer a more flexible approach > > where other content types may also be used with the content negotiation > > feature being used to reach agreement on a mutually supported encoding. > > > > > > Pretty much every SOAP implementation supports attachments. If we go > > with the proposed formulation then an implementation that supports > > attachements cannot be said to conform to our binding, only perhaps to > > interoperate with it. > > > > > > Regards, > > > > Marc.
Received on Wednesday, 3 April 2002 10:30:04 UTC