Re: 4506 Addendum: HTTP Accept Header Value
Christopher B Ferris <[email protected]> Thu, 26 Jul 2007 07:44:35 -0400
| Newsgroups | gmane.text.xml.distributed |
|---|---|
| Message-ID | <OF906C4EB0.B770486B-ON85257324.00400EDF-85257324.00405928@us.ibm.com> |
This is a multipart message in MIME format. --=_alternative 004056C885257324_= Content-Type: text/plain; charset="US-ASCII" Mark, Thanks for your comment regarding the revised resolution of issue 4506. I have opened an issue [1] to reflect your comment. The WG discused this on the call yesterday and concluded that we would close with no further action. Here is the text of the issue resolution: WG resolved to open and close with no action. The WG felt that while Mark's point was possibly technically correct absent the context of the MTOM Policy assertion that using the application/xop+xml media type did not in fact represent an endpoint's ability to support MTOM, but rather the XOP media type, which is not what the MTOM policy assertion is about. The WG also noted that in fact the multipart/related; type=application/xop+xml did not technically represent support for MTOM, but could, in fact, represent another serialization of a multipart message that had, as its root body, an application/xop+xml serialized entity. However, in the context of use of the MTOM policy assertion, one could reasonably infer that it meant support for MTOM if the receiving endpoint of the ACCEPT header had exposed a policy that included the MTOM policy assertion. We hope you are ok with the WG's response. Cheers, [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4885 Christopher Ferris STSM, Software Group Standards Strategy email: [email protected] blog: http://www.ibm.com/developerworks/blogs/page/chrisferris phone: +1 508 234 2986 [email protected] wrote on 07/11/2007 11:01:22 PM: > > On 7/11/07, Pete Wenzel <[email protected]> wrote: > > > > The 6/27 minutes at > > http://www.w3.org/2007/06/27-xmlprotocol-minutes.html > > show that the WG agreed to the following text proposed by Anish: > > > > "For example, when using SOAP/HTTP binding, the 'Accept' HTTP header > > value of 'application/xop+xml' in the request message indicates that > > the response may be sent using MTOM encoding." > > > > When this had been discussed previously, I expressed concern, because > > the outermost wrapper is, of course, the multipart/related media type, > > not application/xop+xml. Fortunately, the HTTP Accept header allows > > parameter qualifications, so a value of > > > > multipart/related; type=application/xop+xml > > > > should accurately express what is intended. > > It seems to me that you'd want both, no? I'm assuming that > application/xop+xml can be used independently of the multipart MIME > solution. > > Mark. > -- > Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca > Coactus; Web-inspired integration strategies http://www.coactus.com > --=_alternative 004056C885257324_= Content-Type: text/html; charset="US-ASCII" <br><font size=2 face="sans-serif">Mark,</font> <br> <br><font size=2 face="sans-serif">Thanks for your comment regarding the revised resolution of issue 4506. I have opened an issue [1] to reflect</font> <br><font size=2 face="sans-serif">your comment. The WG discused this on the call yesterday and concluded that we would close with no</font> <br><font size=2 face="sans-serif">further action.</font> <br> <br><font size=2 face="sans-serif">Here is the text of the issue resolution:</font> <br> <br><tt><font size=3>WG resolved to open and close with no action. The WG felt that while Mark's<br> point was possibly technically correct absent the context of the MTOM Policy<br> assertion that using the application/xop+xml media type did not in fact<br> represent an endpoint's ability to support MTOM, but rather the XOP media type,<br> which is not what the MTOM policy assertion is about. The WG also noted that in<br> fact the multipart/related; type=application/xop+xml did not technically<br> represent support for MTOM, but could, in fact, represent another serialization<br> of a multipart message that had, as its root body, an application/xop+xml<br> serialized entity. However, in the context of use of the MTOM policy assertion,<br> one could reasonably infer that it meant support for MTOM if the receiving<br> endpoint of the ACCEPT header had exposed a policy that included the MTOM<br> policy assertion.</font></tt> <br> <br><font size=2 face="sans-serif">We hope you are ok with the WG's response.</font> <br> <br><font size=2 face="sans-serif">Cheers,</font> <br> <br><font size=2 face="sans-serif">[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4885</font> <br> <br><font size=2 face="sans-serif">Christopher Ferris<br> STSM, Software Group Standards Strategy<br> email: [email protected]<br> blog: http://www.ibm.com/developerworks/blogs/page/chrisferris<br> phone: +1 508 234 2986</font> <br> <br><tt><font size=2>[email protected] wrote on 07/11/2007 11:01:22 PM:<br> <br> > <br> > On 7/11/07, Pete Wenzel <[email protected]> wrote:<br> > ><br> > > The 6/27 minutes at<br> > > http://www.w3.org/2007/06/27-xmlprotocol-minutes.html<br> > > show that the WG agreed to the following text proposed by Anish:<br> > ><br> > > "For example, when using SOAP/HTTP binding, the 'Accept' HTTP header<br> > > value of 'application/xop+xml' in the request message indicates that<br> > > the response may be sent using MTOM encoding."<br> > ><br> > > When this had been discussed previously, I expressed concern, because<br> > > the outermost wrapper is, of course, the multipart/related media type,<br> > > not application/xop+xml. Fortunately, the HTTP Accept header allows<br> > > parameter qualifications, so a value of<br> > ><br> > > multipart/related; type=application/xop+xml<br> > ><br> > > should accurately express what is intended.<br> > <br> > It seems to me that you'd want both, no? I'm assuming that<br> > application/xop+xml can be used independently of the multipart MIME<br> > solution.<br> > <br> > Mark.<br> > -- <br> > Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca<br> > Coactus; Web-inspired integration strategies http://www.coactus.com<br> > <br> </font></tt> --=_alternative 004056C885257324_=--