- From: Henrik Frystyk Nielsen <henrikn@microsoft.com>
- Date: Tue, 17 Jul 2001 19:25:49 -0700
- To: "Mark Nottingham" <mnot@mnot.net>
- Cc: "XML Distributed Applications List" <xml-dist-app@w3.org>
If nobody uses it then I have no problem removing it. If it is used then I prefer option iii. Henrik Frystyk Nielsen mailto:henrikn@microsoft.com >-----Original Message----- >From: Mark Nottingham [mailto:mnot@mnot.net] >Sent: Tuesday, July 17, 2001 17:07 >To: xmlp-comments@w3.org >Cc: XML Distributed Applications List >Subject: Re: HTTP Extension Framwork in SOAP 1.2 > > > >I would prefer option i (removal) or, failing that, option >iii (separation). > >Currently, the only way that SOAP uses the framework is >through the addition of the SOAPAction header; recent >discussions indicate that it may be removed. Even if it were >not, we believe the preferable mechanism for adding an HTTP >header is publication of an RFC-track document, as the P3P WG >has chosen to do. > >In the case that SOAPAction is not removed, use of the >Framework incurs a higher cost for HTTP implementations to >discover the 'intent' of the message (because the 'Opt' header >must be parsed for the appropriate namespace, a new header >name constructed, and that header parsed, for every message), >negating some of its value. > >As such, the framework provides no value to SOAP applications. >Additionally, there is little evidence of use of the >framework, and few HTTP implementations which enable it. > > > >On Tue, Jul 17, 2001 at 04:00:13PM -0700, David Fallside wrote: >> An issue[1] has been raised against the recently published SOAP 1.2 >> specification[2] regarding the reference to a normative >binding to the >> HTTP Extension Framework[3]. >> >> The issue relates to the fact that the HTTP Extension Framework >> specification has no standing within the IETF but as an Experimental >> RFC. >> >> This "experimental RFC" status has specific meaning[4] within the >> IETF. >> >From RFC2026 section 4.2.3: >> >> If (a) the IESG recommends that the document be brought within the >> IETF and progressed within the IETF context, but the >author declines >> to do so, or (b) the IESG considers that the document proposes >> something that conflicts with, or is actually inimical to, an >> established IETF effort, the document may still be published as an >> Experimental or Informational RFC. In these cases, >however, the IESG >> may insert appropriate "disclaimer" text into the RFC either in or >> immediately following the "Status of this Memo" section >in order to >> make the circumstances of its publication clear to readers. >> >> and indeed the IESG did insert such a disclaimer in [3]: >> >> IESG Note >> >> This document was originally requested for Proposed >Standard status. >> However, due to mixed reviews during Last Call and within the HTTP >> working group, it is being published as an Experimental document. >> This is not necessarily an indication of technical flaws in the >> document; rather, there is a more general concern about >whether this >> document actually represents community consensus regarding the >> evolution of HTTP. Additional study and discussion are >needed before >> this can be determined. >> >> Note also that when HTTP is used as a substrate for other >protocols, >> it may be necessary or appropriate to use other extension >mechanisms >> in addition to, or instead of, those defined here. This document >> should therefore not be taken as a blueprint for adding >extensions to >> HTTP, but it defines mechanisms that might be useful in such >> circumstances. >> >> Having this "normative" binding within the SOAP 1.2 >specification may >> be interpreted by some as W3C endorsement of this experimental RFC, >> encouraging its use. >> >> We would like to have your feedback/input as to whether the XMLP >> Working Group should preserve or remove the reference to the >normative >> HTTP Extension Framework binding in the SOAP 1.2 specification. >> >> The XMLP WG is considering several options: >> (i) removal of all references to HTTP Extension Framework binding >> (ii) preservation of status quo >> (iii) relocate the references to the HTTP Extension >Framework binding >> to a non-normative appendix or a separately published document >> >> Send formal comments to xmlp-comments@w3.org (archive available at >> [5]). >> >> [1] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x109 >> [2] http://www.w3.org/TR/2001/WD-soap12-20010709 >> [3] http://ietf.org/rfc/rfc2774.txt >> [4] http://ietf.org/rfc/rfc2026.txt >> [5] http://lists.w3.org/Archives/Public/xmlp-comments/ >> >> ............................................ >> David C. Fallside, IBM >> Chair, XML Protocol Working Group >> Ph: 530.477.7169 >> fallside@us.ibm.com >> >> > >-- >Mark Nottingham >http://www.mnot.net/ > >
Received on Wednesday, 18 July 2001 01:24:30 UTC