W3C home > Mailing lists > Public > xmlp-comments@w3.org > July 2001

RE: HTTP Extension Framwork in SOAP 1.2

From: David Fallside <fallside@us.ibm.com>
Date: Tue, 31 Jul 2001 10:08:06 -0700
To: xmlp-comments@w3.org
Message-ID: <OF29AE43A7.B4153CCE-ON88256A9A.005E1CFF@boulder.ibm.com>

David C. Fallside, IBM
Ext Ph: 530.477.7169
Int  Ph: 544.9665

----- Forwarded by David Fallside/Santa Teresa/IBM on 07/31/2001 10:07 AM
                    "Henrik Frystyk                                                                                   
                    Nielsen"                To:     "Mark Nottingham" <mnot@mnot.net>                                 
                    <henrikn@microsof       cc:     "XML Distributed Applications List" <xml-dist-app@w3.org>         
                    t.com>                  Subject:     RE: HTTP Extension Framwork in SOAP 1.2                      
                    Sent by:                                                                                          
                    07/17/2001 07:25                                                                                  

If nobody uses it then I have no problem removing it. If it is used then
I prefer option iii.

Henrik Frystyk Nielsen

>-----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
>>    it may be necessary or appropriate to use other extension
>>    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
>> 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
Received on Tuesday, 31 July 2001 14:55:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:16:58 UTC