- From: <noah_mendelsohn@us.ibm.com>
- Date: Thu, 19 Sep 2002 09:33:29 -0400
- To: "Jean-Jacques Moreau" <moreau@crf.canon.fr>
- Cc: henrikn@microsoft.com, marc.hadley@sun.com, mgudgin@microsoft.com, www-archive@w3.org
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.
>
> Marc.
>
> 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
> wrote:
>
>> Marc,
>>
>> 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.
>>
>> Jean-Jacques.
>>
>> 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
>> lang="en"><head>
>> <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.constraint,
>> div.issue,
>> div.note,
>> div.notice { margin-left: 2em; }
>>
>> dt.label { display: run-in; }
>>
>> li, p { margin-top: 0.3em;
>> margin-bottom: 0.3em; }
>>
>> p.diff-chg,
>> li.diff-chg,
>> h1.diff-chg,
>> h2.diff-chg,
>> h3.diff-chg,
>> h4.diff-chg,
>> h5.diff-chg,
>> h6.diff-chg,
>> td.diff-chg,
>> tr.diff-chg { background-color: orange; }
>> p.diff-del,
>> li.diff-del,
>> h1.diff-del,
>> h2.diff-del,
>> h3.diff-del,
>> h4.diff-del,
>> h5.diff-del,
>> h6.diff-del,
>> td.diff-del,
>> tr.diff-del { background-color: red; text-decoration:
line-through;}
>> p.diff-add,
>> p.diff-add,
>> h1.diff-add,
>> h2.diff-add,
>> h3.diff-add,
>> h4.diff-add,
>> h5.diff-add,
>> h6.diff-add,
>> td.diff-add,
>> 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"
>> href="http://www.w3.org/StyleSheets/TR/base.css"></head><body><div
>> class="head">
>> <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
>> version:</dt><dd></dd><dt>Previous
>> 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
>> href="http://www.w3.org/Consortium/Legal/ipr-notice-
>> 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
>> href="http://www.w3.org/Consortium/Legal/ipr-notice-
>> 20000612#Legal_Disclaimer">liability</a>, <a
>> href="http://www.w3.org/Consortium/Legal/ipr-notice-
>> 20000612#W3C_Trademarks">trademark</a>, <a
>> href="http://www.w3.org/Consortium/Legal/copyright-documents-
>> 19990405">document use</a>, and <a
>> href="http://www.w3.org/Consortium/Legal/copyright-software-
>> 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
>> class="toc">
>> <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
>> class="div1">
>> <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="#SOAP-PART1">[SOAP-PART1]</a><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="#SOAP-PART1">[SOAP-PART1]</a><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
>> class="div3">
>> <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
>> class="div3">
>> <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
>> class="div3">
>> <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
>> specification.
>> </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-del"><a
>> href="#soap-media-type">[soap-media-type]</a></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
>> URI:</p><ul><li><p>"http://www.w3.org/2002/06/soap/bindings/HTTP/"</
>> 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
>> class="div2">
>> <h3><a name="soapresmep"></a>2.3 SOAP Response MEP</h3></div><div
>> class="div2">
>> <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
>> class="div2">
>> <h3><a name="SOAP-PART1"></a>2.6 SOAP Part1</h3></div><div
class="div2">
>> <h3><a name="RFC2616"></a>2.7
>> RFC2616</h3></div></div></div></body></html>
>>
>>
> --
> Marc Hadley <marc.hadley@sun.com>
> XML Technology Center, Sun Microsystems.
>
Received on Thursday, 19 September 2002 09:35:26 UTC