W3C home > Mailing lists > Public > public-ws-policy-eds@w3.org > November 2006

2006/ws/policy ws-policy-guidelines.xml,1.16,1.17

From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
Date: Thu, 30 Nov 2006 04:04:21 +0000
To: public-ws-policy-eds@w3.org
Message-Id: <E1Gpd9p-0002na-OG@lionel-hutz.w3.org>

Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv10608

Modified Files:
	ws-policy-guidelines.xml 
Log Message:
Editorial revision related to editorial actions 84 and 90

Index: ws-policy-guidelines.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.xml,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -d -r1.16 -r1.17
--- ws-policy-guidelines.xml	28 Nov 2006 23:05:15 -0000	1.16
+++ ws-policy-guidelines.xml	30 Nov 2006 04:04:19 -0000	1.17
@@ -87,26 +87,26 @@
       
         <p>The WS-Policy specification defines a policy to be a collection
         of policy alternatives with each policy alternative a
-        collection of policy assertions. Policy is a flexible framework to represent
-        consistent compinations of behaviors from a variety of domains.
-        A policy assertion is a machine readable metadata exxpression that 
+        collection of policy assertions. The &framework.title; provides a flexible framework to 
+        represent
+        consistent combinations of behaviors from a variety of domains.
+        A policy assertion is a machine readable metadata expression that 
         identifies behaviors  required for Web services interactions.
         <emph>&guideline.title;</emph>
-        is a resource primarily for assertion authors that provides
+        is a resource primarily for assertion authors and provides
         guidelines on the use of &framework.title; and
         &attachment.title; specifications to create and use domain specific
         assertions to enable interoperability.
         </p>
 	    <p>WS-Policy Assertions are XML expressions
         that communicate the requirements and capabilities of a web
-        service by adhering to the specification, WS-Policy Framework. It
-        was recognized that in order to enable interoperability of web
-        services, different sets of WS-Policy Assertions needed to be
-        defined by different communities based upon the requirements of
+        service by adhering to the specification, WS-Policy Framework. To enable interoperability of web
+        services different sets of WS-Policy Assertions need to be
+        defined by different communities based upon domain-specific requirements of
         the web service.
         </p>
 	    <p>The focus of these guidelines is to capture best practices
-        and usage patterns for practitioners to follow. It is a
+        and usage patterns for practitioners. It is a
         complementary guide to the Framework and Attachments
         specifications and primer. It is intended to provide
         non-normative guidelines for:
@@ -158,15 +158,14 @@
         <head>What is an Assertion? </head>
      
 		<p>An assertion is a piece of metadata that describes a
-      	capability of a specific WS-Policy domain. Sets of assertions
-      	are typically defined in a dedicated specification that describe
+      	capability related to a specific WS-Policy domain. Sets of domain-specific assertions
+      	are typically defined in a dedicated specification that describes
       	their semantics, applicability and scoping requirements as well
       	as their data type definition using XML Schema. 
       	</p>
       
-      	<p>Given that interoperability and automation are the motivations, policy assertions that
-        represent, shared and visible behaviors are useful pieces of metadata. Such
-        assertions enable tooling and improve interoperability. The key to understanding when to
+      	<p>Policy assertions representing shared and visible behaviors are useful pieces of metadata to enable 
+      	interoperability and tooling for automation. The key to understanding when to
         design policy assertions is to have clarity on the characteristics of a behavior
         represented by a policy assertion. Some useful ways to discover relevant behaviors are
         to ask questions like the following:
@@ -179,23 +178,26 @@
           <item>
             <p>Is the behavior visible?
             </p>
-            	<p>A visible behavior refers to a requirement that manifests on the wire. Web services
+            	<p>A visible behavior refers to a requirement that manifests itself on the wire. Web services
             	provide interoperable machine-to-machine interaction among disparate systems. Web
             	service interoperability is the capability of disparate systems to exchange data using
-            	common data formats and protocols such as messaging, security, reliability and
+            	common data formats and protocols supporting characteristics such as messaging, security, 
+            	reliability and
             	transaction. Such data formats and protocols manifest on the wire. Providers and
-            	requesters only rely on these wire messages that conform to such formats and protocols
-            	for interoperability. If an assertion describes a behavior that does not manifest on the
-            	wire then the assertion is not relevant to an interoperable interaction.
+            	requesters rely on wire messages conforming to such formats and protocols
+            	to achieve interoperability. 
             	</p>
-            	<p>For example, say an assertion describes the privacy notice information of a provider
-            	and there is an associated regulatory safeguard in place on the provider’s side. Such
+          	<p>If an assertion describes a behavior that does not manifest on the
+          		wire then the assertion is not relevant to an interoperable interaction.
+          		An example is an assertion that describes the privacy notice information of a provider
+            	and the associated regulatory safeguard in place on the provider’s side. Such
             	assertions may represent business or regulatory level metadata but do not add any value
             	to interoperability.
             	</p>
-            	<p>If an assertion has no wire- or message-level visible behavior, then the interacting
-            	participants may require some sort of additional non-repudiation mechanism to indicate
-            	compliance with the assertion. Introducing an additional non-repudiation mechanism adds
+            	<p>If an assertion has no wire or message-level visible behavior then the interacting
+            	participants may require some sort of additional mechanism to indicate
+            	compliance with the assertion and to enable dispute resolution. 
+            	Introducing an additional non-repudiation mechanism adds
             	unnecessary complexity to processing a policy assertion.
             	</p>
           </item>
@@ -208,9 +210,7 @@
             	relevant to an interoperable interaction. Non-shared behaviors do not add any value for
             	tooling or interoperability. An example of a non-shared behavior is the use of logging
             	or auditing by the provider.
-            	</p>
-            	
-          		<p>requesters may use the policy intersection to select a compatible policy alternative
+            	Requesters may use the policy intersection to select a compatible policy alternative
            		 for a Web service interaction. If an assertion only describes one participant’s behavior
             	then this assertion will not be present in the other participants’ policy and the policy
             	intersection will unnecessarily produce false negatives.
@@ -224,8 +224,8 @@
           	<item>
           		<p>Is there a requirement that a choice must be made for successful interaction?</p>
           		
-          		<p>Some behaviors refer to a requirement that providers and requesters must deliberately choose 
-          		to engage in. Examples, of such behaviors are the use of optimization, and reliable messaging.
+          		<p>Sometimes providers and requesters are required to engage in certain behaviors. 
+          			The use of optimization and reliable messaging are two examples.
           		</p>
           	</item>
         </ulist>
@@ -298,18 +298,17 @@
        			 a way that multiple WS-Policy domains can co-exist and
        			consumers and providers can utilize the framework consistently across domains.
 				</p>
-				<p>In order to take advantage of the WS-Policy Framework, any
-    	    	domain author attempting to define new WS-Policy assertions
-    	    	must adhere to the MUST's and SHOULD's in the specifications
+				<p>When using the WS-Policy Framework, any
+    	    	domain author defining new WS-Policy assertions
+    	    	must adhere to the MUST's and SHOULD's in the specification
     	    	and should review the conformance section of the specification. 
     	    	</p>
     	   		 <p>WS-Policy Domain authors must also specify how to associate
 				the assertions they have defined with the policy subjects
-				identified by the WS-PolicyAttachment specification
+				identified by the WS-PolicyAttachment specification.
 				</p>
-        		<p>An example of a domain specification that
-        		includes these properties can be seen in the WS-SecurityPolicy
-        		pecification [<bibref ref="WS-SecurityPolicy"/>]. The
+        		<p>An example of a domain specification that follows these practices is the WS-SecurityPolicy
+        		specification [<bibref ref="WS-SecurityPolicy"/>]. The
         		WS-SecurityPolicy authors have defined their scope as follows:
         		</p>
 				<p><emph>"This document [WS-SecurityPolicy] defines a set of
@@ -335,8 +334,8 @@
 				<head>Consumers</head>
 				<p>A consumer of WS-Policy
 				Assertions can be any entity that is capable of parsing a
-				WS-Policy xml element, and selecting one alternative from the
-				policy, that it then uses to govern the creation of a message
+				WS-Policy XML  element and selecting one alternative from the
+				policy. This selected alternative is then used to govern the creation of a message
 				to send to the subject to which the policy alternative was
 				attached.  The WS-Policy Attachment specification defines a
 				set of attachment models for use with common web service
@@ -347,7 +346,7 @@
 				References (EPR) [<bibref ref="WS-Addressing"/>].
        		 	</p>
 				<p> 
-				In the degenerate case, a human could read the xml and
+				In the degenerate case, a human could read the XML and
 				determine if a message could be constructed conformant to the
 				advertised policy.
         		</p>
@@ -362,7 +361,7 @@
 				<div3 id="providers">
 				<head>Providers</head>
 				<p>A provider of WS-Policy Assertions can be any web service implementation that can
-	   			specify its' on-the-wire message behavior as an XML
+	   			specify its on-the-wire message behavior as an XML
 	   			expression that conforms to the WS-PolicyFramework and
 	   			WS-Policy Attachment specifications. The
 	   			WS-PolicyAttachment specification has defined a set of
@@ -372,7 +371,7 @@
 	   			it may also need to conform to requirements of other policy
 	   			specifications it utilizes ( i.e., WS-SecurityPolicy).
            		</p>
-				<p>When deploying services with policies it is uesful for providers to anticipate how
+				<p>When deploying services with policies it is useful for providers to anticipate how
            		to evolve their services capabilities over time.  If
            		forward compatibility is a concern in order to accommodate
            		compatibility with different and potentially new clients,
@@ -387,10 +386,10 @@
 	<div1 id="general-guidelines">
 		<head>General Guidelines for WS-Policy Assertion Authors</head>
 		<p> As authors begin the task of inventing XML dialects to represent policy  assertions they can take
-		advantage of WS-Policy building on XML principles and XML Schema validation in their desgin. WS-Policy 
-		relies on the Qname of a policy assertion being an XML element but allows authors to optionally  
+		advantage of WS-Policy building on XML principles and XML Schema validation in their design. WS-Policy 
+		relies on the QName of a policy assertion being an XML element but allows authors to optionally  
 		provide additional semantics through nesting assertions, or specifying assertion parameters.
-		This section covers several aspects of assertion design and provides somes answers to the following questions:</p>
+		This section covers several aspects of assertion design and provides some answers to the following questions:</p>
       		<ulist>
        		 <item>
           		<p>What is the intended use of the policy assertion?</p>
@@ -399,7 +398,7 @@
           		<p>Which authoring style will be used?</p>
         	</item>
         	<item>
-         		 <p>Is this a new policy domain? does it need to compose with other domains?</p>
+         		 <p>Is this a new policy domain? Does it need to compose with other domains?</p>
         	</item>
         	<item>
           		<p>How complex are the assertions?</p>
@@ -439,7 +438,7 @@
            	stand alone client applications to "active" web service
            	requestors that are capable of modifying their own configurations dynamically.
 	  		</p>
-			<p> Once the range of policy subjects are identified, there are choices for ways of
+			<p> Once the range of policy subjects is identified, there are choices for ways of
 			attaching multiple instances of a simple policy
 			assertion to multiple subjects. One way is to utilize
 			the referencing mechanism that is present in the
@@ -447,7 +446,7 @@
 			in different policies (e.g. with different
 			alternatives) via reference, a policy assertion may be
 			associated with different alternatives and subjects. A
-			eferencing mechanism is very useful in a tooling
+			referencing mechanism is very useful in a tooling
 			environment; when creating a domain specific
 			attachment in multiple WSDL files or Endpoint
 			References in which the same set of policies are expected to be applied. 
@@ -491,7 +490,7 @@
 			
 			<div2 id="compact-full">
 			<head>Authoring Styles </head>
-			<p> WS-Policy supports 2 different authoring styles.  A compact form is one in which an expression consists of three
+			<p> WS-Policy supports two different authoring styles.  A compact form is one in which an expression consists of three
 	   		constructs: an attribute to decorate an assertion (to indicate whether it is required or optional), semantics for
 	   		recursively nested policy operators, and a policy reference/inclusion mechanism.
       		</p>
@@ -559,7 +558,7 @@
             in a policy, the normal form may express the choices more explicitly.
             On the other hand, the compact form is more
             readable for humans when an assertion is marked as optional
-            using the <code>@optional</code> attribute as our example illustrates above. 
+            using the <code>wsp:optional</code> attribute as our example illustrates above. 
            	</p>
            	
            	<p>Best practice: use the authoring style most appropriate for the target audience </p>
@@ -590,13 +589,13 @@
          			</p>
 					<p>It requires a good deal of effort to evaluate the
          			capabilities of a domain and capture them in a way that
-         			eflects the options of the domain if the domain has a lot of
+         			reflects the options of the domain if the domain has a lot of
          			assertions to define.  Interoperability testing of new policy
          			domains is recommended to ensure that consumers and providers
          			are able to use the new domain assertions.
          			</p>
 					<p>New authors are encouraged to look at <bibref ref="WS-RM-Policy"/> to see an example of a
-         			relatively simple domain that has defined 3 assertions. Domain authors are encouraged to look at <bibref
+         			relatively simple domain that has defined three assertions. Domain authors are encouraged to look at <bibref
          			ref="WS-SecurityPolicy"/> to see an example of a complex domain that has been decomposed into a set of policy expressions.
         			</p> 
           			<p>How big should an assertion be? How many assertion parameters should the assertion
@@ -605,7 +604,7 @@
             		design work progresses, you may add more parameters or nested policy assertions to meet
             		your interoperability needs. 
             		</p>
-          			<p>Best practice: start with a simple working assertion that allows extensibility.
+          			<p>Best practice: Start with a simple working assertion that allows extensibility.
           			</p>
         		</div3>
         		<div3 id="QName_and_XML_Information_Set_representation">
@@ -621,7 +620,7 @@
             		document). If the assertion has a nested policy expression then the assertion XML
             		outline can enumerate the nested assertions that are allowed.
             		</p>
-         			<p>Best practice: use a unique QName to identify the behavior and provide an XML outline
+         			<p>Best practice: Use a unique QName to identify the behavior and provide an XML outline
             		(plus an XML schema document) to specify the syntax of an assertion.
             		</p>
         		</div3>	
@@ -670,9 +669,9 @@
             		<p>Another approach is to use of the assertion to selectively apply to subjects. For example, a
     				dedicated endpoint may be allocated to ensure the engagement of a
     				behavior that is expressed by a policy assertion. This approach
-    				can be considered when messages can not be self describing. 
+    				can be considered when messages cannot be self describing. 
      				</p>
-     				<p>Best practice:Policy assertions should not be used to express the semantics of a message.
+     				<p>Best practice: Policy assertions should not be used to express the semantics of a message.
      				</p>
      			</div3>				
 				<div3 id="single-domains">
@@ -694,7 +693,7 @@
         			</p>
 					<p>The model advocated for new
 					assertion development is a cooperative marketplace
-					[some might say its an "opt-in" model]. The providers
+					[some might say it is an "opt-in" model]. The providers
 					of services need to find value in the set of
 					assertions or they will not include the assertions in
 					their service descriptions. 
@@ -808,25 +807,25 @@
 				</example>
 				
 						<p>The <code>sp:AlgorithmSuite</code> is a nested policy assertion of
-           				 the <code>sp:TransportBinding</code> policy assertion. The<code>sp:AlgorithmSuite</code>
+           				 the <code>sp:TransportBinding</code> policy assertion. The <code>sp:AlgorithmSuite</code>
           				assertion requires the use of the algorithm suite identified by its nested policy
           				assertion (<code>sp:Basic256Rsa15</code>
 						<emph>in the example above</emph>) and further qualifies the behavior of the
             			<code>sp:TransportBinding</code> policy assertion.
             			</p>
 						<p>Setting aside the details of using transport-level
-        				security,, a policy-aware client that recognizes this policy
+        				security, a policy-aware client that recognizes this policy
         				assertion can engage transport-level security and its
-       					dependent behaviors automatically. That is, the complexity of
+       					dependent behaviors automatically. This means the complexity of
         				security usage is absorbed by a policy-aware client and hidden
-        				from these Web service developers.
+        				from Web service application developers.
         				</p>
 				</div3>
 					
 				<div3 id="which-one-to-use">
                     <head>Considerations for choosing parameters vs nesting</head>
 					<p>The main consideration for selecting parameters or nesting
-					of assertions, is that <emph>the framework intersection
+					of assertions is that <emph>the framework intersection
 					algorithm processes nested alternatives, but does not consider
 					parameters in its algorithm</emph>. 
 					</p>
@@ -844,9 +843,15 @@
         			vs. the flexibility and complexity of the comparison expected for a domain. </p>
         			<p>
         			The following design questions below can help
-            		you to determine when to use nested policy expressions:</p>
+            		 to determine when to use nested policy expressions:</p>
+					<ulist>
+						<item>
          			 	<p>Are these assertions designed for the same policy subject? </p>
+							</item>
+						<item>
           				<p>Do these assertions represent dependent behaviors?</p>
+						</item>
+					</ulist>
           				<p>If the answers are yes to both of these questions then leveraging nested policy
            			expressions is something to consider. Keep in mind that a nested policy expression participates in
             		the policy intersection algorithm. If a requester uses policy intersection to select a
@@ -869,7 +874,7 @@
 				<head>Optional behavior in Compact authoring</head>
 					<p>Optional behaviors represent behaviors which may be engaged by a consumer. When using the
         			compact authoring form for assertions, behaviors are marked by
-        			using <code>wsp:optional</code> attribute that has a value,
+        			using <code>wsp:Optional</code> attribute that has a value,
         			"true". During the process of normalization, the runtime
         			behavior is indicated by two policy alternatives, one with and
         			one without the assertion. In a consumer/provider
@@ -894,7 +899,7 @@
 					<p>The semantics of this assertion declare that the behavior
         			is reflected in messages: they use an optimized wire format
         			(MIME Multipart/Related serialization). Note that in order for
-        			an optional behaviors to be engaged, the wire message that
+        			an optional behavior to be engaged, the wire message that
         			would utilize the specific assertion must be self
         			describing. For example, an inbound message to a web service
         			that asserts MTOM, must evaluate, the protocol format of the
@@ -961,12 +966,12 @@
             				when optional behaviors are specified for message
             				exchanges within a request response for response messages,
             				using message policy subject. Leaving the semantics
-            				undescribed may result in providers making assumptions
+            				not specified or incompletely specified may result in providers making assumptions
             				(i.e. if the incoming message utilized the optimization,
             				the response will be returned utilizing the MTOM
             				serialization). Similarly, if engagement of a behavior is
             				only specified for an outbound message, the policy
-            				assertion authors should consider to describe the
+            				assertion authors should consider  describing the
             				semantics if the incoming messages also utilized the
             				behavior. This is especially important if the assertion is
             				applicable to more than one specific policy subject. One
@@ -1005,7 +1010,7 @@
           		if an assertion is specific to a policy attachment
           		mechanism. An example could be identifying whether the
           		assertion expressed is associated with behaviors
-          		(endpoints) or artifacts ( messages) and then constraining
+          		(endpoints) or artifacts (messages) and then constraining
           		the use of an assertion to one of these subjects.
           		</p>
 				<p>Thus our example encryption assertion would have a
@@ -1020,7 +1025,7 @@
 				<p>Best Practice- To avoid confusion, assertion definitions should be
           		precise about their semantics and include information that
           		restricts their set of permissible policy subjects
-          		appropriately and indicates which Qnames are associated with
+          		appropriately and indicates which QNames are associated with
           		which subjects.</p>        
           		<olist>
           <item>
@@ -1081,10 +1086,11 @@
         		the domain authors chose to support certain capabilities at
         		the endpoint level. This resulted in the finer granularity of
         		the assertion to apply at the message policy subject, but the
-        		assertion semantics also indicates that the if the senders
-        		choose to engage RM semantics (although not specified via
-        		attachment in WSDL at incoming messages), the providers will
-        		honor the engagement of RM. This is illustrative of how the
+        		assertion semantics also indicates that the if 
+        		a sender chose to engage RM
+        		semantics (although not specified via attachment in WSDL at incoming
+        		messages), the providers will honor the engagement of RM.
+        		This is illustrative of how the
         		assertion author can specify additional constraints and
         		assumptions for attachment and engagement of behavior.
         		</p>
@@ -1219,7 +1225,7 @@
 						<p>ADD THE EXAMPLE HERE </p>
 					</example>
 					<p>Best practice: use independent assertions for modeling multiple equivalent behaviors. </p>
-					<!-- EDS TO DO REconcile from Primer. GET THE REST FROM DAVE and Umit -->
+					<!-- EDS TO DO reconcile from Primer. GET THE REST FROM DAVE and Umit -->
 			</div2>	      
 		</div1>
 		
@@ -1231,8 +1237,8 @@
          modeling protocol assertions may appear to be an independent behavior,
          protocol assertions and security assertions affect transport
          bindings and their interactions must be considered. For
-         example, utilization of WS-Security Policy with other
-         protocols affect transport binding and would result in nested
+         example utilization of WS-Security Policy with other
+         protocols affects transport bindings and would result in nested
          policy assertions when additional protocols are composed with
          <bibref ref="WS-Security2004"/>. Thus, domain authors should
          be aware of the compositional semantics with other related
@@ -1279,17 +1285,17 @@
 	   mechanisms should make it possible to clearly identify the
 	   source of a poly assertion both for debugging and for
 	   verification. This could take several forms: it could be
-	   assumed ( in WSDL, the source of the assertion is the same
-	   as the WSDL provider) or it could be proven ( using
+	   assumed (in WSDL, the source of the assertion is the same
+	   as the WSDL provider) or it could be proven (using
 	   <bibref ref="WS-Trust"/>).  </p>
 			</div2>
 		</div1>
-		<div1 id="scenerio">
+		<div1 id="scenario">
 			<head>Scenario and a worked example</head>
 			<p>To illustrate the topics explored in this document, we
        include an example of a web service and how a fictitious company
        might utilize the WS-Policy Framework to enable Web Service
-       interoperability. CompanyA has determined to utilize WS-Security,
+       interoperability. Company A has determined to utilize WS-Security,
        WS-Addressing and WS-Reliable Messaging in all its new web
        service offerings and has instructed its developers to use the
        policy assertions defined by the following documents: </p>
@@ -1304,11 +1310,11 @@
 					<p>Web Services Addressing WSDL Binding</p>
 				</item>
 			</ulist>
-			<p>The application developers at CompanyA are instructed to
-      review the current web services at CompanyA and propose a plan
+			<p>The application developers at Company A are instructed to
+      review the current web services at Company A and propose a plan
       for adding policy assertions. </p>
 			<p>The application developers collect information about web
-      services within CompanyA and determine that all of the web
+      services within Company A and determine that all of the web
       services already have a WSDL 1.1 description. The developers
       have determined that Company A's web services fall into two
       types of web services. There are those that fall into the
@@ -1322,7 +1328,7 @@
       or message exchange. </p>
 			<p>Service A is a WSDL 1.1 conformant web service and requires
       the use of transport-level security for protecting messages as
-      well as including addressing headers. Employees of CompanyA have
+      well as including addressing headers. Employees of Company A have
       already incorporated <code>wss:Security</code> headers into their
       messages. </p>
 			<example>
@@ -1343,7 +1349,7 @@
 			</example>
 			<p>The SOAP message in the example above includes security
      timestamps that express creation and expiration times of this
-     message. CompanyA requires the use of these security timestamps
+     message. Company A requires the use of these security timestamps
      and transport-level security, such as HTTPS for protecting
      messages. </p>
 			<p>The example below illustrates a policy expression that
@@ -1361,7 +1367,7 @@
 			<p>The <code>sp:TransportBinding</code> element is a policy assertion. The
      assertion identifies the use of transport-level-security - such
      as HTTPS for protecting messages at the transport
-     level. CompanyA's policy aware clients can now recognize this
+     level. Company A's policy aware clients can now recognize this
      policy assertion and if they support it, engage in transport
      level security for protecting messages and providing security
      timestamps in SOAP envelopes for any WSDL with this policy
@@ -1374,26 +1380,26 @@
      alternatives rather than forcing a single client
      configuration. </p>
 			<p>The developers read the WS-Policy specification and noted that
-     there were 3 ways to express combinations of behaviors. The three
-     policy operators, ( Policy, All and ExactlyOne) were considered
+     there were three ways to express combinations of behaviors. The three
+     policy operators, (Policy, All and ExactlyOne) were considered
      and the result was the creation of two policy elements. </p>
 			<p>The first policy is shown in Figure
      <emph>CompanyA-ProfileA</emph> and it is the policy that is used
-     by many web services at Company A that rely on https to provide
+     by many web services at Company A that rely on HTTPS to provide
      transport level protection of messages. </p>
 			<p>The second policy is shown in Figure
      <emph>CompanyA-ProfileB</emph> and it offers requestors of a
      service the ability to provide additional integrity protection by
      including WS-Security Headers to protect the message content
      after it is processed by the transport.  The additional security
-     processing is not required by all CompanyA web services. </p>
-     <example> <head>CompanyA-ProfileB ( not expanded)</head> <eg
+     processing is not required by all Company A web services. </p>
+     <example> <head>CompanyA-ProfileB (not expanded)</head> <eg
      xml:space="preserve"> &lt;Policy wsu:Id="CompanyA-ProfileB"&gt;
      &lt;wsa:UsingAddressing /&gt; &lt;ExactlyOne&gt;
      &lt;sp:TransportBinding&gt;&lt;/sp:TransportBinding&gt;
      &lt;sp:AsymmetricBinding&gt;&lt;/sp:AssymetricBinding&gt;
      &lt;/ExactlyOne&gt; &lt;/Policy&gt; </eg> </example>
-			<p>We have shown above that CompanyA offered a
+			<p>We have shown above that Company A offered a
     second profile that included two security options.  The details of
     the Bindings, requires a more detailed exploration of some of the
     other features of the WS-Policy Framework. </p>
@@ -1406,7 +1412,7 @@
     an <code>sp:TransportBinding</code> assertion, just indicating the use of
     transport-level security for protecting messages is not
     sufficient. For a consumer of a web service provided by a company,
-    like CompanyA, to successfully interact, the consumer must also
+    like Company A, to successfully interact, the consumer must also
     know what transport token, what algorithm suite, etc. is
     required. The <code>sp:TransportBinding</code> assertion, can (and has)
     represent (ed) these dependent behaviors as "nested" policy
@@ -1447,24 +1453,24 @@
      indicates the use of a specific type of token, in this case an
      HttpsToken. </p>
 			<p>It should be noted that each policy has an Identifier.  In the
-     case of the default policy expression, CompanyA has decided that
+     case of the default policy expression, Company A has decided that
      this policy expression should be broadly available via a URI.
      There are advantages and disadvantages to using each type of
      identifier.  For URI's there is the issue of maintaining the
-     policy expression when it may no longer be used ( CompanyA gets
-     bought by CompanyB and starts using the policies of Company B,
+     policy expression when it may no longer be used (Company A gets
+     bought by Company B and starts using the policies of Company B,
      but some "old" consumers may still try to reference the
      URI). </p>
 			<p> For the second type of web services, which may be used only
-     by certain of CompanyA's business partners, the id is an XML ID.
+     by certain of Company A's business partners, the id is an XML ID.
      The relative URI for referencing this within the same WSDL
      document is #CompanyA-ProfileB. This can be useful for company's
      when the policy expressions are agreed to between partners but
      may be changed as the business agreements change. But the
      disadvantage is that the policy expression must be included in
      each WSDL document. </p>
-			<p>Since CompanyA has decided to use well known policy
-     expressions that are themselves part of a specification, they
+			<p>Since Company A has decided to use well known policy
+     expressions that are part of a specification, they
      adhere to the guidance given in the WS-SecurityPolicy
      specification and attach the policies to the web service endpoint
      policy subject as recommended by the WS-SecurityPolicy
@@ -1480,7 +1486,7 @@
 &lt;/wsdl:binding&gt; </eg>
 			</example>
 			<p>The partner specified policy is included in the beginning of
-    the wsdl 1.1document and referenced by the binding for the service
+    the WSDL 1.1 document and referenced by the binding for the service
     as in the example below.</p>
 			<example>
 				<head/>
@@ -1828,7 +1834,13 @@
 						<td>MH</td>
 						<td>Replaced section in Lifecycle with pointer to the text in the primer: related to action 77 
 						</td>
-					</tr>					
+					</tr>	
+					<tr>
+						<td>20061129</td>
+						<td>FH</td>
+						<td>Editorial revision (editorial actions 84 and for action 90) 
+						</td>
+					</tr>				
 				</tbody>
 			</table>
 		</inform-div1>
Received on Thursday, 30 November 2006 04:04:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:20:59 GMT