- From: <noah_mendelsohn@us.ibm.com>
- Date: Fri, 20 Sep 2002 09:52:14 -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 certainly don't insist, but I note that we took some heat from David on
the last concall for checking in at least one change that he thought went
past editors' discretion, so I think it can only help to point out areas
where what we've done may go beyond the obvious. I do agree that this one
is within our mandate, but I can see where others might appreciate the
early heads up. In any case, thanks for doing it.
------------------------------------------------------------------
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/20/02 05:53 AM
To: noah_mendelsohn@us.ibm.com
cc: henrikn@microsoft.com, marc.hadley@sun.com, mgudgin@microsoft.com,
www-archive@w3.org
Subject: Re: Notes in part 2, section 7.1
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.
Jean-Jacques.
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.
>>
>>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 Friday, 20 September 2002 09:54:15 UTC