W3C home > Mailing lists > Public > www-archive@w3.org > September 2002

Re: Notes in part 2, section 7.1

From: Jean-Jacques Moreau <moreau@crf.canon.fr>
Date: Fri, 20 Sep 2002 11:53:01 +0200
Message-ID: <3D8AEFFD.2090605@crf.canon.fr>
To: noah_mendelsohn@us.ibm.com
CC: henrikn@microsoft.com, marc.hadley@sun.com, mgudgin@microsoft.com, www-archive@w3.org

I don't think we quite need this given the nature of the change, 
but since you insist I'll be sending a short note to dist-app.


noah_mendelsohn@us.ibm.com wrote:
> I agree this change is at least arguably within our discretion as editors, 
> but I think it's broader than many other such changes.  I suggest a quick 
> note to "distApp" saying that we did this.  I'd rather hear expressions of 
> concern now, than during a final read-through leading to Proposed Rec? 
> What think you all?
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
> "Jean-Jacques Moreau" <moreau@crf.canon.fr>
> 09/19/02 03:26 AM
>         To:     Marc Hadley <marc.hadley@sun.com>
>         cc:     Martin Gudgin <mgudgin@microsoft.com>, Henrik Frystyk Nielsen 
> <henrikn@microsoft.com>, noah_mendelsohn@us.ibm.com, W3C Archive 
> <www-archive@w3.org>
>         Subject:        Re: Notes in part 2, section 7.1
> Done.
> Added the following ednote:
>    <ednote>
>      <name>JJM/MJH</name>
>      <date>20020919</date>
>      <edtext>
> This section had grown over time into an unmanageable
> entity, with information spread over several paragraphs
> and notes in an organized manner. The editors felt that
> this situation could be remedied to easily by merely
> shuffling paragraphs around and by creating a clear and
> coherent structure with four new subsections. This
> revised section is the result of that change. Unless
> decorated in green or red (as a result of some other
> issue resolution) the text has otherwise NOT changed.    </edtext>
>    </ednote>
> Jean-Jacques.
> Marc Hadley wrote:
>>Looks good, I'd say go with what you have.
>>PS. it would appear that the charset you are using is 8859-1 rather 
>>than UTF-16. Looks like my browser believes the first meta header (or 
>>perhaps what the web server tells it) and uses UTF-16 to display the 
>>document - hence the garble.
>>On Wednesday, Sep 18, 2002, at 09:12 US/Eastern, Jean-Jacques Moreau 
>>>You're probably using Netscape 7.0 or Mozilla 1.1. It's a display 
>>>bug.  The message source is fine, and renders properly in Netscape 
>>>4.79 or  Outlook Express 6.0.
>>>Here it is inline anyway.
>>>Marc Hadley wrote:
>>>>Your ideas for further movement of text sound fine to me. 
>>>>Unfortunately  the attachment you sent out seems to be garbled. I 
>>>>checked in the  archives[1] and it comes out garbled there too. Can 
>>>>you resend.
>>><!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html 
>>><META http-equiv="Content-Type" content="text/html; charset=UTF-16">
>>><meta http-equiv="Content-Type" content="text/html; 
>>>charset=ISO-8859-1"><title>SOAP Version 1.2 Part 2: 
>>>Adjuncts</title><style type="text/css">
>>>code           { font-family: monospace; }
>>>div.notice     { margin-left: 2em; }
>>>dt.label       { display: run-in; }
>>>li, p           { margin-top: 0.3em;
>>>                 margin-bottom: 0.3em; }
>>>tr.diff-chg     { background-color: orange; }
>>>tr.diff-del     { background-color: red; text-decoration: 
> line-through;}
>>>tr.diff-add    { background-color: lime; }
>>>table          { empty-cells: show; }
>>>div.exampleInner pre { margin-left: 1em;
>>>                       margin-top: 0em; margin-bottom: 0em}
>>>div.exampleOuter {border: 4px double gray;
>>>                  margin: 0em; padding: 0em}
>>>div.exampleInner { background-color: #d5dee3;
>>>                   border-top-width: 4px;
>>>                   border-top-style: double;
>>>                   border-top-color: #d3d3d3;
>>>                   border-bottom-width: 4px;
>>>                   border-bottom-style: double;
>>>                   border-bottom-color: #d3d3d3;
>>>                   padding: 4px; margin: 0em }
>>>div.exampleWrapper { margin: 4px }
>>>div.exampleHeader { font-weight: bold;
>>>                    margin: 4px}
>>></style><link rel="stylesheet" type="text/css" 
>>><h1>SOAP Version 1.2 Part 2: Adjuncts</h1>
>>><h2>Editors Copy $Date: 2002/09/16 14:57:37 $ @@ @@ 
>>>@@</h2><dl><dt>This version:</dt><dd></dd><dt>Latest 
>>>versions:</dt><dd></dd><dt>Editors:</dt><dd>Martin Gudgin, 
>>>DevelopMentor</dd><dd>Marc Hadley, Sun Microsystems</dd><dd>Noah 
>>>Mendelsohn, IBM</dd><dd>Jean-Jacques Moreau, Canon</dd><dd>Henrik 
>>>Frystyk Nielsen, Microsoft</dd></dl><p class="copyright"><a 
>>>20000612#Copyright">Copyright</a>  @@ <a 
>>>href="http://www.w3.org/"><abbr title="World Wide Web 
>>>Consortium">W3C</abbr></a><sup></sup> (<a 
>>>href="http://www.lcs.mit.edu/"><abbr title="Massachusetts Institute 
>>>of  Technology">MIT</abbr></a>, <a href="http://www.inria.fr/"><abbr 
>>>lang="fr" title="Institut National de Recherche en Informatique et 
>>>Automatique">INRIA</abbr></a>, <a 
>>>href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a 
>>>20000612#Legal_Disclaimer">liability</a>, <a 
>>>20000612#W3C_Trademarks">trademark</a>, <a 
>>>19990405">document use</a>, and <a 
>>>19980720">software licensing</a> rules apply.</p></div><hr><div>
>>><h2><a name="abstract">Abstract</a></h2></div><div>
>>><h2><a name="status">Status of this Document</a></h2><p><strong>This 
>>>document is an editors' copy that has
>>>        no official standing.</strong></p><p></p></div><hr><div 
>>><h2><a name="shortcontents">Short Table of Contents</a></h2><p 
>>>class="toc">1. <a href="#soapinhttp">SOAP HTTP Binding</a><br>2. <a 
>>>href="#IDAELAW">Placeholder</a><br></p></div><hr><div class="toc">
>>><h2><a name="contents">Table of Contents</a></h2><p class="toc">1. <a 
>>>href="#soapinhttp">SOAP HTTP Binding</a><br>    1.1 <a 
>>>href="#http-intro">Introduction</a><br>        1.1.1 <a 
>>>href="#httpoptionality">Optionality</a><br>        1.1.2 <a 
>>>href="#httpuse">Use of HTTP</a><br>        1.1.3 <a 
>>>href="#httpinterop">HTTP Interoperability</a><br>        1.1.4 <a 
>>>href="#httpmediatype">HTTP Media-Type</a><br>    1.2 <a 
>>>href="#http-bindname">Binding Name</a><br>2. <a 
>>>href="#IDAELAW">Placeholder</a><br>    2.1 <a href="#ietf-draft">IETF 
>>>Draft</a><br>    2.2 <a href="#soap-media-type">SOAP Media 
>>>Type</a><br>    2.3 <a href="#soapresmep">SOAP Response 
>>>MEP</a><br>     2.4 <a href="#singlereqrespmep">Requet-Response 
>>>MEP</a><br>    2.5 <a  href="#soapfeatspec">SOAP Feature</a><br> 
>>>2.6 <a  href="#SOAP-PART1">SOAP Part1</a><br>    2.7 <a 
>>>href="#RFC2616">RFC2616</a><br></p></div><hr><div class="body"><div 
>>><h2><a name="soapinhttp"></a>1. SOAP HTTP Binding</h2><div 
> class="div2">
>>><h3><a name="http-intro"></a>1.1 Introduction</h3><p>The SOAP HTTP 
>>>Binding provides a binding of SOAP to HTTP. The
>>>    binding conforms to the SOAP Protocol Binding Framework (see <a 
>>>href="soap12-part1.html/#transpbindframew">SOAP Protocol Binding
>>>    Framework</a>). It uses abstract binding properties as a 
> descriptive
>>>    tool for defining the functionality of certain 
>>>features.</p><p>The  SOAP Protocol Binding Framework (see <a 
>>>href="soap12-part1.html/#transpbindframew">SOAP Protocol Binding
>>>    Framework</a>), the Message Exchange Pattern Specifications
>>>    (see <a href="#SOAP-PART1">[SOAP-PART1]</a><a 
>>>href="soap12-part1.html/#soapmep">SOAP Message Exchange
>>>    Patterns</a>) and Feature Specifications (see <a 
>>>href="#soapfeatspec"><b>2.5 SOAP Feature</b></a>) each describe the 
>>>properties they expect to be
>>>    present in a message exchange context when control of that context
>>>    passes between a local SOAP node and a binding 
>>>instance.</p><p>Properties are named with XML qualified names. > 
> Property
>>>    values are determined by the Schema type of the property, as 
> defined
>>>    in the specification which introduces the property.</p><div 
>>><h4><a name="httpoptionality"></a>1.1.1 Optionality</h4><p>The SOAP 
>>>HTTP Binding is optional and SOAP nodes are NOT
>>>        required to implement it. A SOAP node that correctly and
>>>        completely implements the SOAP HTTP Binding may to be said
>>>        to "conform to the SOAP 1.2 HTTP Binding."</p><p>The SOAP 
>>>version  1.2 specification does not preclude
>>>        development of other bindings to HTTP or bindings to other
>>>        protocols, but communication with nodes using such other
>>>        bindings is not a goal. Note that other bindings of SOAP
>>>        to HTTP MAY be written to provide support for SOAP Message
>>>        exchange patterns other than <a 
>>>href="#singlereqrespmep"><b>2.4  Requet-Response MEP</b></a> or the <a 
>>>href="#soapresmep"><b>2.3 SOAP  Response MEP</b></a>. Such alternate 
>>>bindings MAY therefore
>>>        make use of HTTP features and status codes not required
>>>        for this binding. For example, another binding might
>>>        provide for a 202 or 204 HTTP response status to be
>>>        returned in response to an HTTP POST or PUT (e.g. a
>>>        one-way "push" MEP with confirmation).</p></div><div 
>>><h4><a name="httpuse"></a>1.1.2 Use of HTTP</h4><p>This binding of 
>>>SOAP to HTTP is intended to make
>>>        appropriate use of HTTP as an application protocol. For
>>>        example, successful responses are sent with status code
>>>        200, and failures are indicated as 4XX or 5XX. This
>>>        binding is not intended to fully exploit the features of
>>>        HTTP, but rather to use HTTP specifically for the purpose
>>>        of communicating with other SOAP nodes implementing the
>>>        same binding. Therefore, this HTTP binding for SOAP does
>>>        not specify the use and/or meaning of all possible HTTP
>>>        methods, header fields and status responses. It specifies
>>>        only those which are pertinent to the <a 
>>>href="#singlereqrespmep"><b>2.4 Requet-Response MEP</b></a> or the <a 
>>>href="#soapresmep"><b>2.3 SOAP Response MEP</b></a>, or which are 
>>>likely to be introduced
>>>        by HTTP mechanisms (such as proxies) acting between the
>>>        SOAP nodes.</p><p>Certain
>>>        optional features provided by this binding depend on 
>>>capabilities  provided by
>>>        HTTP/1.1, for example content
>>>        negotiation. Implementations SHOULD thus use HTTP/1.1
>>>        <a href="#RFC2616">[RFC2616]</a> (or later compatible 
>>>versions  that share the
>>>        same major version number). Implementations MAY also be
>>>        deployed using HTTP/1.0, although in this case certain 
>>>optional  binding features
>>>        may not be provided.</p><div class="note"><p 
>>>class="prefix"><b>Note:</b></p><p>SOAP HTTP Binding implementations 
>>>need to account for the
>>>        fact that HTTP/1.0 intermediaries</p><p 
>>>class="diff-add">(which  may or may
>>>        not also be SOAP intermediaries)</p><p> may alter the 
>>>representation of
>>>        SOAP messages, even in situations where both the initial SOAP 
>>>sender and
>>>        ultimate SOAP receiver use HTTP/1.1.</p></div></div><div 
>>><h4><a name="httpinterop"></a>1.1.3 HTTP Interoperability</h4><p>
>>>        Particularly when used with the <a href="#soapresmep"><b>2.3 
>>>SOAP  Response MEP</b></a>, the HTTP messages
>>>        produced by this binding are likely to be
>>>        indistinguishable from those produced by non-SOAP 
> implementations
>>>        performing similar operations.
>>>        Accordingly, some degree of interoperation can be made 
>>>possible  between SOAP nodes and other HTTP
>>>        implementations when using this binding.
>>>        For example, a conventional Web server (i.e. one not
>>>        written specifically to conform to this specification) might 
>>>be used  to respond
>>>        to SOAP-initiated HTTP GET's with representations of
>>>        <code>Content-Type</code> "application/soap+xml".
>>>        Such interoperation is not a normative feature of this 
>>>        </p></div><div class="div3">
>>><h4><a name="httpmediatype"></a>1.1.4 HTTP 
>>>Media-Type</h4><p>Conforming implementations of this 
>>>binding:</p><ol><li><p>MUST be capable of sending and receiving 
> messages
>>>        serialized using media type "application/soap+xml" whose proper
>>>        use and parameters are described in </p><p 
>>>class="diff-add"><a href="#ietf-draft"><b>2.1 IETF 
>>>Draft</b></a></p><p>.</p></li><li><p>MAY send requests and responses 
>>>using other media types
>>>        providing that such media types provide for at least the
>>>        transfer of SOAP XML Infoset.</p></li><li><p>MAY, when 
>>>sending  requests, provide an HTTP Accept
>>>        header field. This header </p><p class="diff-add">field</p><p>:
>>>            <ul><li><p>SHOULD indicate an ability to accept at minimum
>>>                "application/soap+xml".</p></li><li><p>MAY 
>>>additionally indicate willingness to accept
>>>                other media types that satisfy 2 
>>>above.</p></li></ul></p></li></ol></div></div><div class="div2">
>>><h3><a name="http-bindname"></a>1.2 Binding Name</h3><p>The binding 
>>>is  identified with the 
>>>p></li></ul></div></div><div class="div1">
>>><h2><a name="IDAELAW"></a>2. Placeholder</h2><div class="div2">
>>><h3><a name="ietf-draft"></a>2.1 IETF Draft</h3></div><div 
> class="div2">
>>><h3><a name="soap-media-type"></a>2.2 SOAP Media Type</h3></div><div 
>>><h3><a name="soapresmep"></a>2.3 SOAP Response MEP</h3></div><div 
>>><h3><a name="singlereqrespmep"></a>2.4 Requet-Response 
>>>MEP</h3></div><div class="div2">
>>><h3><a name="soapfeatspec"></a>2.5 SOAP Feature</h3></div><div 
>>><h3><a name="SOAP-PART1"></a>2.6 SOAP Part1</h3></div><div 
> class="div2">
>>><h3><a name="RFC2616"></a>2.7 
>>Marc Hadley <marc.hadley@sun.com>
>>XML Technology Center, Sun Microsystems.
Received on Friday, 20 September 2002 05:52:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:31:53 UTC