W3C home > Mailing lists > Public > xml-dist-app@w3.org > July 2001

RE: HTTP Extension Framwork in SOAP 1.2

From: Henrik Frystyk Nielsen <henrikn@microsoft.com>
Date: Tue, 17 Jul 2001 19:25:49 -0700
Message-ID: <79107D208BA38C45A4E45F62673A434D03441D48@red-msg-07.redmond.corp.microsoft.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:02 GMT