- From: Doug Davis via cvs-syncmail <cvsmail@w3.org>
- Date: Tue, 18 Aug 2009 21:12:50 +0000
- To: public-ws-resource-access-notifications@w3.org
Update of /w3ccvs/WWW/2002/ws/ra/edcopies
In directory hutz:/tmp/cvs-serv29184
Modified Files:
wst.html wst.xml
Log Message:
7191
Index: wst.xml
===================================================================
RCS file: /w3ccvs/WWW/2002/ws/ra/edcopies/wst.xml,v
retrieving revision 1.46
retrieving revision 1.47
diff -u -d -r1.46 -r1.47
--- wst.xml 18 Aug 2009 20:54:31 -0000 1.46
+++ wst.xml 18 Aug 2009 21:12:48 -0000 1.47
@@ -98,39 +98,39 @@
<p>Specifically, it defines two operations for sending and receiving the
representation of a given resource and two operations for creating and
deleting a resource and its corresponding representation.</p>
- <p>It should be noted that the state maintenance of a resource is at most
+ <p>Note that the state maintenance of a resource is at most
subject to the "best efforts" of the hosting server. When a client receives
the server's acceptance of a request to create or update a resource, it can
reasonably expect that the resource now exists at the confirmed location and
with the confirmed representation, but this is not a guarantee, even in the
- absence of any third parties. The server may change the representation of a
- resource, may remove a resource entirely, or may bring back a resource that
+ absence of any third parties. The server MAY change the representation of a
+ resource, MAY remove a resource entirely, or MAY bring back a resource that
was deleted.</p>
- <p>For instance, the server may store resource state information on a disk
+ <p>For instance, the server might store resource state information on a disk
drive. If that drive crashes and the server recovers state information from a
backup tape, changes that occurred after the backup was made will be
lost.</p>
- <p>A server may have other operational processes that change resource state
- information. A server may run a background process that examines resources
+ <p>A server MAY have other operational processes that change resource state
+ information. A server might run a background process that examines resources
for objectionable content and deletes any such resources it finds. A server
- may purge resources that have not been accessed for some period of time. A
- server may apply storage quotas that cause it to occasionally purge
+ can purge resources that have not been accessed for some period of time. A
+ server could apply storage quotas that cause it to occasionally purge
resources.</p>
<p>In essence, the confirmation by a service of having processed a request to
create, modify, or delete a resource implies a commitment only at the instant
- that the confirmation was generated. While the usual case should be that
+ that the confirmation was generated. While the usual case is that
resources are long-lived and stable, there are no guarantees, and clients
- should code defensively.</p>
+ are advised to code defensively.</p>
<p>There is no requirement for uniformity in resource representations between
the messages defined in this specification. For example, the
- representations required by Create or Put may differ from the representation
+ representations required by Create or Put can differ from the representation
returned by Get, depending on the semantic requirements of the service.
Additionally, there is no requirement that the resource content is fixed for
- any given endpoint reference. The resource content may vary based on
+ any given endpoint reference. The resource content can vary based on
environmental factors, such as the security context, time of day,
configuration, or the dynamic state of the service.</p>
- <p>As per the SOAP processing model, other specifications may define SOAP
- headers which may be optionally added to request messages to require the
+ <p>As per the SOAP processing model, other specifications MAY define SOAP
+ headers which can be optionally added to request messages to require the
transfer of subsets or the application of transformations of the resource
associated with the endpoint reference. When the Action URIs defined by
this specification are used, such extension specifications must also allow
@@ -417,8 +417,8 @@
In cases where it is either desirable or necessary for the receiver
of a request that has been extended to indicate that it has
recognized and accepted the semantics associated with that extension,
- it is recommended that the receiver add a corresponding extension
- to the response message. The definition of an extension should clearly
+ it is RECOMMENDED that the receiver add a corresponding extension
+ to the response message. The definition of an extension SHOULD clearly
specify how the extension that appears in the response correlates
with that in the corresponding request.
</p>
@@ -906,7 +906,7 @@
<p>A Delete request MUST be targeted at the resource to be deleted as
described in <specref ref="Notations_and_Terminology"/> of this
specification.</p>
- <p>Implementations may respond with a fault message using the standard fault
+ <p>Implementations MAY respond with a fault message using the standard fault
codes defined in WS-Addressing (e.g., <code>wsa:ActionNotSupported</code>).
Other components of the outline above are not further constrained by this
specification.</p>
@@ -1004,11 +1004,11 @@
<p>This specification defines one Web service operation (Create) for creating
a resource and providing its initial representation. In some cases, the
initial representation MAY constitute the representation of a logical
- constructor for the resource and may thus differ structurally from the
+ constructor for the resource and can thus differ structurally from the
representation returned by Get or the one required by Put. This is because
the parameterization requirement for creating a resource is often distinct
from the steady-state representation of the resource. Implementations
- should provide metadata which describes the use of the representation and how
+ SHOULD provide metadata which describes the use of the representation and how
it relates to the resource which is created, but such mechanisms are beyond
the scope of this specification. The resource factory that receives a
Create request will allocate a new resource that is initialized from the
@@ -1448,7 +1448,7 @@
<p>
<emph>Invalid tokens</emph> - There are a number of token attacks
including certificate authorities, false signatures, and PKI attacks.
- Care should be taken to ensure each token is valid (usage window, digest,
+ Care SHOULD be taken to ensure each token is valid (usage window, digest,
signing authority, revocation, ...), and that the appropriate delegation
policies are in compliance.</p>
</item>
@@ -1456,7 +1456,7 @@
<p>
<emph>Man-in-the-middle</emph> - The message exchanges in this
specification could be subject to man-in-the-middle attacks so care
- should be taken to reduce possibilities here such as establishing a
+ SHOULD be taken to reduce possibilities here such as establishing a
secure channel and verifying that the security tokens user represent
identities authorized to speak for, or on behalf of, the desired resource
reference.</p>
@@ -1465,7 +1465,7 @@
<p>
<emph>Message alteration</emph> - Alteration is prevented by
including signatures of the message information using WS-Security. Care
- should be taken to review message part references to ensure they haven't
+ SHOULD be taken to review message part references to ensure they haven't
been forged (e.g. ID duplication).</p>
</item>
<item>
@@ -1502,7 +1502,7 @@
common attack and it is recommended that this be addressed by the
mechanisms described in WS-Security. Other attacks, such as network-level
denial of service attacks are harder to avoid and are outside the scope
- of this specification. That said, care should be taken to ensure that
+ of this specification. That said, care SHOULD be taken to ensure that
minimal state is saved prior to any authenticating sequences.</p>
</item>
</ulist>
@@ -1644,7 +1644,7 @@
<p>
A normative copy of the XML Schema <bibref ref='XmlSchemaPart1'/>,
- <bibref ref='XmlSchemaPart2'/> description for this specification may be
+ <bibref ref='XmlSchemaPart2'/> description for this specification can be
retrieved from the following address:
</p>
@@ -1750,7 +1750,7 @@
<div1 id="Appendix_II__E2_80_93_WSDL">
<head>WSDL</head>
<p>A normative copy of the WSDL <bibref ref="Wsdl11"/> description
- for this specification may be retrieved from the following address:</p>
+ for this specification can be retrieved from the following address:</p>
<example>
<eg><loc href="http://www.w3.org/2009/02/ws-tra/transfer.wsdl">http://www.w3.org/2009/02/ws-tra/transfer.wsdl</loc></eg>
</example>
@@ -1804,7 +1804,7 @@
<wsdl:portType name="Resource">
<wsdl:documentation>
- This port type defines a resource that may be read,
+ This port type defines a resource that can be read,
written, and deleted.
</wsdl:documentation>
<wsdl:operation name="Get">
@@ -2018,6 +2018,13 @@
<loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=7206">7206</loc>
</td>
</tr>
+ <tr>
+ <td> 2009/08/18 </td>
+ <td> DD </td>
+ <td> Added resolution of issue
+ <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=7191">7191</loc>
+ </td>
+ </tr>
</tbody>
</table>
</div1>
Index: wst.html
===================================================================
RCS file: /w3ccvs/WWW/2002/ws/ra/edcopies/wst.html,v
retrieving revision 1.50
retrieving revision 1.51
diff -u -d -r1.50 -r1.51
--- wst.html 18 Aug 2009 20:54:31 -0000 1.50
+++ wst.html 18 Aug 2009 21:12:48 -0000 1.51
@@ -70,34 +70,34 @@
provide an XML representation</p></li><li><p>Resource factories, which are Web services that can create a new
resource from an XML representation</p></li></ul><p>Specifically, it defines two operations for sending and receiving the
representation of a given resource and two operations for creating and
- deleting a resource and its corresponding representation.</p><p>It should be noted that the state maintenance of a resource is at most
+ deleting a resource and its corresponding representation.</p><p>Note that the state maintenance of a resource is at most
subject to the "best efforts" of the hosting server. When a client receives
the server's acceptance of a request to create or update a resource, it can
reasonably expect that the resource now exists at the confirmed location and
with the confirmed representation, but this is not a guarantee, even in the
- absence of any third parties. The server may change the representation of a
- resource, may remove a resource entirely, or may bring back a resource that
- was deleted.</p><p>For instance, the server may store resource state information on a disk
+ absence of any third parties. The server MAY change the representation of a
+ resource, MAY remove a resource entirely, or MAY bring back a resource that
+ was deleted.</p><p>For instance, the server might store resource state information on a disk
drive. If that drive crashes and the server recovers state information from a
backup tape, changes that occurred after the backup was made will be
- lost.</p><p>A server may have other operational processes that change resource state
- information. A server may run a background process that examines resources
+ lost.</p><p>A server MAY have other operational processes that change resource state
+ information. A server might run a background process that examines resources
for objectionable content and deletes any such resources it finds. A server
- may purge resources that have not been accessed for some period of time. A
- server may apply storage quotas that cause it to occasionally purge
+ can purge resources that have not been accessed for some period of time. A
+ server could apply storage quotas that cause it to occasionally purge
resources.</p><p>In essence, the confirmation by a service of having processed a request to
create, modify, or delete a resource implies a commitment only at the instant
- that the confirmation was generated. While the usual case should be that
+ that the confirmation was generated. While the usual case is that
resources are long-lived and stable, there are no guarantees, and clients
- should code defensively.</p><p>There is no requirement for uniformity in resource representations between
+ are advised to code defensively.</p><p>There is no requirement for uniformity in resource representations between
the messages defined in this specification. For example, the
- representations required by Create or Put may differ from the representation
+ representations required by Create or Put can differ from the representation
returned by Get, depending on the semantic requirements of the service.
Additionally, there is no requirement that the resource content is fixed for
- any given endpoint reference. The resource content may vary based on
+ any given endpoint reference. The resource content can vary based on
environmental factors, such as the security context, time of day,
- configuration, or the dynamic state of the service.</p><p>As per the SOAP processing model, other specifications may define SOAP
- headers which may be optionally added to request messages to require the
+ configuration, or the dynamic state of the service.</p><p>As per the SOAP processing model, other specifications MAY define SOAP
+ headers which can be optionally added to request messages to require the
transfer of subsets or the application of transformations of the resource
associated with the endpoint reference. When the Action URIs defined by
this specification are used, such extension specifications must also allow
@@ -203,8 +203,8 @@
In cases where it is either desirable or necessary for the receiver
of a request that has been extended to indicate that it has
recognized and accepted the semantics associated with that extension,
- it is recommended that the receiver add a corresponding extension
- to the response message. The definition of an extension should clearly
+ it is RECOMMENDED that the receiver add a corresponding extension
+ to the response message. The definition of an extension SHOULD clearly
specify how the extension that appears in the response correlates
with that in the corresponding request.
</p><p>
@@ -511,7 +511,7 @@
WS-Fragment <a href="#WsFrag">[WS-Fragment]</a> specification.
</p></dd></dl><p>A Delete request MUST be targeted at the resource to be deleted as
described in <a href="#Notations_and_Terminology"><b>2 Terminology and Notation</b></a> of this
-specification.</p><p>Implementations may respond with a fault message using the standard fault
+specification.</p><p>Implementations MAY respond with a fault message using the standard fault
codes defined in WS-Addressing (e.g., <code>wsa:ActionNotSupported</code>).
Other components of the outline above are not further constrained by this
specification.</p><p>A successful Delete operation invalidates the current representation
@@ -580,11 +580,11 @@
<h3><a name="Factory_Create" id="Factory_Create"/>4.1 Create</h3><p>This specification defines one Web service operation (Create) for creating
a resource and providing its initial representation. In some cases, the
initial representation MAY constitute the representation of a logical
- constructor for the resource and may thus differ structurally from the
+ constructor for the resource and can thus differ structurally from the
representation returned by Get or the one required by Put. This is because
the parameterization requirement for creating a resource is often distinct
from the steady-state representation of the resource. Implementations
- should provide metadata which describes the use of the representation and how
+ SHOULD provide metadata which describes the use of the representation and how
it relates to the resource which is created, but such mechanisms are beyond
the scope of this specification. The resource factory that receives a
Create request will allocate a new resource that is initialized from the
@@ -821,16 +821,16 @@
duplicate messages.
</p></li><li><p><em>Invalid tokens</em> - There are a number of token attacks
including certificate authorities, false signatures, and PKI attacks.
- Care should be taken to ensure each token is valid (usage window, digest,
+ Care SHOULD be taken to ensure each token is valid (usage window, digest,
signing authority, revocation, ...), and that the appropriate delegation
policies are in compliance.</p></li><li><p><em>Man-in-the-middle</em> - The message exchanges in this
specification could be subject to man-in-the-middle attacks so care
- should be taken to reduce possibilities here such as establishing a
+ SHOULD be taken to reduce possibilities here such as establishing a
secure channel and verifying that the security tokens user represent
identities authorized to speak for, or on behalf of, the desired resource
reference.</p></li><li><p><em>Message alteration</em> - Alteration is prevented by
including signatures of the message information using WS-Security. Care
- should be taken to review message part references to ensure they haven't
+ SHOULD be taken to review message part references to ensure they haven't
been forged (e.g. ID duplication).</p></li><li><p><em>Message disclosure</em> - Confidentiality is preserved by
encrypting sensitive data using WS-Security.</p></li><li><p><em>Key integrity</em> - Key integrity is maintained by using
the strongest algorithms possible (by comparing secured policies - see
@@ -847,7 +847,7 @@
common attack and it is recommended that this be addressed by the
mechanisms described in WS-Security. Other attacks, such as network-level
denial of service attacks are harder to avoid and are outside the scope
- of this specification. That said, care should be taken to ensure that
+ of this specification. That said, care SHOULD be taken to ensure that
minimal state is saved prior to any authenticating sequences.</p></li></ul></div><div class="div1">
<h2><a name="acks" id="acks"/>7 Acknowledgements</h2><p>
This specification has been developed as a result of joint
@@ -932,7 +932,7 @@
(See http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/.)</dd></dl></div></div><div class="back"><div class="div1">
<h2><a name="Appendix_I__E2_80_93_XSD" id="Appendix_I__E2_80_93_XSD"/>A XML Schema</h2><p>
A normative copy of the XML Schema <a href="#XmlSchemaPart1">[XML Schema, Part 1]</a>,
- <a href="#XmlSchemaPart2">[XML Schema, Part 2]</a> description for this specification may be
+ <a href="#XmlSchemaPart2">[XML Schema, Part 2]</a> description for this specification can be
retrieved from the following address:
</p><div class="exampleOuter"><div class="exampleInner"><pre><a href="http://www.w3.org/2009/02/ws-tra/transfer.xsd">http://www.w3.org/2009/02/ws-tra/transfer.xsd</a></pre></div></div><p>A non-normative copy of the XML schema is listed below for
convenience.</p><div class="exampleOuter"><div class="exampleInner"><pre><xs:schema
@@ -1026,7 +1026,7 @@
</xs:schema> </pre></div></div></div><div class="div1">
<h2><a name="Appendix_II__E2_80_93_WSDL" id="Appendix_II__E2_80_93_WSDL"/>B WSDL</h2><p>A normative copy of the WSDL <a href="#Wsdl11">[WSDL 1.1]</a> description
- for this specification may be retrieved from the following address:</p><div class="exampleOuter"><div class="exampleInner"><pre><a href="http://www.w3.org/2009/02/ws-tra/transfer.wsdl">http://www.w3.org/2009/02/ws-tra/transfer.wsdl</a></pre></div></div><p>A non-normative copy of the WSDL description is listed below for
+ for this specification can be retrieved from the following address:</p><div class="exampleOuter"><div class="exampleInner"><pre><a href="http://www.w3.org/2009/02/ws-tra/transfer.wsdl">http://www.w3.org/2009/02/ws-tra/transfer.wsdl</a></pre></div></div><p>A non-normative copy of the WSDL description is listed below for
convenience.</p><div class="exampleOuter"><div class="exampleInner"><pre><wsdl:definitions
targetNamespace="http://www.w3.org/2009/02/ws-tra"
xmlns:tns="http://www.w3.org/2009/02/ws-tra"
@@ -1074,7 +1074,7 @@
<wsdl:portType name="Resource">
<wsdl:documentation>
- This port type defines a resource that may be read,
+ This port type defines a resource that can be read,
written, and deleted.
</wsdl:documentation>
<wsdl:operation name="Get">
@@ -1144,4 +1144,5 @@
<a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=6975">6975</a>,
<a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=6413">6413</a></td></tr><tr><td> 2009/08/05 </td><td> DD </td><td> Added resolution of issue
<a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=7159">7159</a></td></tr><tr><td> 2009/08/18 </td><td> DD </td><td> Added resolution of issue
- <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=7206">7206</a></td></tr></tbody></table></div></div></body></html>
\ No newline at end of file
+ <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=7206">7206</a></td></tr><tr><td> 2009/08/18 </td><td> DD </td><td> Added resolution of issue
+ <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=7191">7191</a></td></tr></tbody></table></div></div></body></html>
\ No newline at end of file
Received on Tuesday, 18 August 2009 21:12:59 UTC