- From: Umit Yalsinap via cvs-syncmail <cvsmail@w3.org>
- Date: Tue, 31 Oct 2006 04:04:13 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv15815
Modified Files:
ws-policy-guidelines.xml
Log Message:
Fixes based on PC's feedback on Oct 20th
Index: ws-policy-guidelines.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.xml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -d -r1.6 -r1.7
--- ws-policy-guidelines.xml 19 Oct 2006 23:52:51 -0000 1.6
+++ ws-policy-guidelines.xml 31 Oct 2006 04:04:10 -0000 1.7
@@ -42,14 +42,15 @@
</authlist>
<abstract>
<p>
- <emph>&guideline.title;</emph> is a
- guideline for assertion authors that will work with the
- &framework.title; and &attachment.title; specifications to
- create domain specific assertions. The focus of this document
- is to provide best practices and patterns to follow as well as
- illustrate the care needed in using WS-Policy to achieve the
- best possible results for interoperability. It is a
- complementary guide to using the specifications. </p>
+ <emph>&guideline.title;</emph> is a guideline for assertion
+ authors that will work with the &framework.title; [<bibref
+ ref="WS-Policy"/>] and &attachment.title; [<bibref
+ ref="WS-PolicyAttachment"/>] specifications to create domain
+ specific assertions. The focus of this document is to provide
+ best practices and patterns to follow as well as illustrate
+ the care needed in using WS-Policy to achieve the best
+ possible results for interoperability. It is a complementary
+ guide to using the specifications. </p>
</abstract> &status;
@@ -71,21 +72,22 @@
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-PolicyFramework. 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 the web service.
+ <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
+ the web service.
</p>
- <p>Some policy assertions specify traditional requirements and
- capabilities that will ultimately manifest on the wire (e.g.,
- authentication scheme, transport protocol selection). Other
- policy assertions have no wire manifestation yet are critical to
- proper service selection and usage (e.g., privacy policy, QoS
- characteristics). WS-Policy provides a single policy grammar to
- allow both kinds of assertions to be reasoned about in a
- consistent manner.
+ <p>Some policy assertions specify traditional
+ requirements and capabilities that will ultimately manifest on
+ the wire (e.g., authentication scheme, transport protocol
+ selection). Other policy assertions have no wire manifestation
+ yet are critical to proper service selection and usage (e.g.,
+ privacy policy, QoS characteristics). WS-Policy provides a
+ single policy grammar to allow both kinds of assertions to be
+ reasoned about in a consistent manner.
</p>
<p>The focus of these guidelines is to capture best practices
and usage patterns for practitioners to follow. It is a
@@ -120,14 +122,13 @@
</ulist>
<p>This document assumes a basic understanding of XML 1.0,
Namespaces in XML, WSDL 1.1 and SOAP.</p>
- <p>This is a non-normative document and does not provide a
- definitive specification of the Web Services Policy
- framework. <specref ref="xml-namespaces"/> lists all the that
- are used in this document. (XML elements without a namespace
- prefix are from the Web Services Policy XML Namespace.)</p>
- </div1>
- <div1 id="Assertions">
- <head>Basic Concepts: What is an Assertion</head>
+ <p>This is a non-normative document and does
+ not provide a definitive specification of the Web Services
+ Policy framework. <specref ref="xml-namespaces"/> lists all
+ the namespace prefixes that are used in this document. (XML
+ elements without a namespace prefix are from the Web Services
+ Policy XML Namespace.)</p> </div1> <div1 id="Assertions">
+ <head>Basic Concepts: 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
@@ -207,10 +208,10 @@
<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</p>
- <p>An example of a domain specificatin that includes these properties
- can be seen in the WS-SecurityPolicy
- specification. The WS-Security authors have defined their
- scope as follows: </p>
+ <p>An example of a domain specification that
+ includes these properties can be seen in 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
security policy assertions for use with the WS-Policy
@@ -233,14 +234,18 @@
</div3>
<div3 id="consumers">
<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 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 subjects: WSDL definitions, UDDI directory
- entries, and WS-Addressing endpoints.
+ <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
+ 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
+ subjects: WSDL definitions [<bibref ref="WSDL11" />, <bibref
+ ref="WSDL20" />], UDDI directory entries [<bibref
+ ref="UDDIAPI20" />, <bibref ref="UDDIDataStructure20" />,
+ <bibref ref="UDDI30" />], and WS-Addressing Endpoint
+ References (EPR) [<bibref ref="WS-Addressing"/>].
</p>
<p>
In the degenerate case, a human could read the xml and
@@ -257,26 +262,27 @@
</div3>
<div3 id="providers">
<head>Providers</head>
- <p>A provider of WS-Policy Assertions can be any web service
- implementation that can reflect its on the wire message
- behavior as an XML expression that conforms to the
- WS-PolicyFramework and WS-PolicyAssertions
- specifications. The WS-PolicyAttachment specification has
- defined a set of subjects and an extensible mechanism for
- attaching policies to web services subjects. When a web
- service provider chooses to make its capabilities and
- constraints available, it may also need to conform to
- requirements of other policy specifications it utilizes (
- i.e., WS-SecurityPolicy).
+ <p>A provider of WS-Policy
+ Assertions can be any web service implementation that can
+ reflect it's 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
+ subjects and an extensible mechanism for attaching policies
+ to web services subjects. When a web service provider
+ chooses to make its capabilities and constraints available,
+ it may also need to conform to requirements of other policy
+ specifications it utilizes ( i.e., WS-SecurityPolicy).
</p>
- <p>Whe deploying services with policies it is uesful for providers to anticipate how
- to evolve their services capabilities over time. If forward
- compatibility is a concern in order to accommodate
+ <p>When deploying services
+ with policies it is uesful 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,
providers should refer to <specref ref="lifecycle"/> and
<bibref ref="WS-Policy-Primer"/> that describes service and
policy assertion evolution.
- </p>
+ </p>
</div3>
</div2>
</div1>
@@ -311,17 +317,20 @@
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 attaching
- multiple instances of a simple policy assertion to multiple subjects. One way is to
- utilize the referencing mechanism that is present in the
- framework. By defining the assertion once and using it in
- different policies (e.g. with different alternatives) via
- reference, a policy assertion may be associated with
- different alternatives and subjects. A referencing
- mechanism is very useful in a tooling environment or when
- creating a domain specific attachment in multiple WSDL
- files, EPRs, in which the same set of policies are expected
- to be applied.
+ <p> Once the range of policy subjects
+ are 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
+ framework. By defining the assertion once and using it
+ in different policies (e.g. with different
+ alternatives) via reference, a policy assertion may be
+ associated with different alternatives and subjects. A
+ 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.
</p>
<p>In summary, WS-Policy domain authors should consider the following
factors when composing the set of domain assertions as it
@@ -441,7 +450,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
+ using the <code>@optional</code> attribute as our example
illustrates above.
</p>
</div1>
@@ -476,64 +485,65 @@
domains is recommended to ensure that consumers and providers
are able to use the new domain assertions.
</p>
- <p>New aurthors 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 ref="WS-SecurityPolicy"/> to see an example of a complex
+ <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
+ ref="WS-SecurityPolicy"/> to see an example of a complex
domain that has been decomposed into a set of policy
expressions.
</p>
</div2>
<div2 id="single-domains">
<head>Single Domains</head>
- <p>When considering the creation of a new domain of policy
- assertions, it is important to identify whether or not the domain is self containted
- or at least if a subset of the domain can be well defined. A domain
- that expresses a broad set of capabilities will also need to have
- community supportin implementation to provide value to the consumers.
- Ultimately it is the consumers and providers that will
- determine whether a particular set of assertions correctly
- characterize a domain. A new community should avoid duplicating
- assertions that have already been defined as this will create
- ambiguity not clarification. New WS-Policy authors should focus on creating assertions
- for those specific constraints and capabilities that do not
- overlap with other domains but that communicate new
- functionality. </p>
- <p>The model advocated for new assertion development is a cooperative marketplace
- [some might say its 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. </p>
- <p>A review by a broad community is the best way to ensure
- that the granularity of a set of domain assertions is
- appropriate. </p>
- </div2>
- <div2 id="nested-assertions">
- <head>Nested Assertions</head>
- <p>The framework provides the ability to "nest" policy
- assertions. For domains with a complex set of options, nesting
- provides one way to indicate dependent elements within a
- behavior. The granularity of assertions is determined by the
- authors and it is recommended that care be taken when defining
- nested policies to ensure that the options provided
- appropriately specify policy alternatives within a specific
- behavior.
+ <p>When considering the creation of a
+ new domain of policy assertions, it is important to identify
+ whether or not the domain is self-contained or at least if a
+ subset of the domain can be well defined. A domain that
+ expresses a broad set of capabilities will also need to have
+ community supporting implementations to provide value to the
+ consumers. Ultimately it is the consumers and providers that
+ will determine whether a particular set of assertions
+ correctly characterize a domain. A new community should avoid
+ duplicating assertions that have already been defined as this
+ will create ambiguity not clarification. New WS-Policy authors
+ should focus on creating assertions for those specific
+ constraints and capabilities that do not overlap with other
+ domains but that communicate new functionality. </p>
+ <p>The model advocated for new
+ assertion development is a cooperative marketplace
+ [some might say its 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. </p>
+ <p>A review by a broad community is
+ the best way to ensure that the granularity of a set of domain
+ assertions is appropriate. </p> </div2> <div2
+ id="nested-assertions"> <head>Nested Assertions</head>
+ <p>The framework provides the ability
+ to "nest" policy assertions. For domains with a complex set of
+ options, nesting provides one way to indicate dependent
+ elements within a behavior. The granularity of assertions is
+ determined by the authors and it is recommended that care be
+ taken when defining nested policies to ensure that the options
+ provided appropriately specify policy alternatives within a
+ specific behavior.
</p>
- <p>We will use the WS-SecurityPolicy to illustrate the use of
- nested assertions.
+ <p>We will use the WS-SecurityPolicy
+ to illustrate the use of nested assertions.
</p>
- <p>Securing messages is a complex usage scenario. The
- WS-SecurityPolicy authors have defined the sp:TransportBinding
- policy assertion to indicate the use of transport-level
- security for protecting messages. Just indicating the use of
- transport-level security for protecting messages is not
- sufficient. To successfully interact with a Web service, the
- consumer must know not only that transport-level security is
- required, but also the transport token to use, the secure
- transport to use, the algorithm suite to use for performing
- cryptographic operations, etc. The
- <code>sp:TransportBinding</code> policy assertion can
- represent these dependent behaviors.
+ <p>Securing messages is a complex
+ usage scenario. The WS-SecurityPolicy authors have defined the
+ <code>sp:TransportBinding</code> policy assertion to indicate
+ the use of transport-level security for protecting
+ messages. Just indicating the use of transport-level security
+ for protecting messages is not sufficient. To successfully
+ interact with a Web service, the consumer must know not only
+ that transport-level security is required, but also the
+ transport token to use, the secure transport to use, the
+ algorithm suite to use for performing cryptographic
+ operations, etc. The <code>sp:TransportBinding</code> policy
+ assertion can represent these dependent behaviors.
</p>
<p>A policy assertion like the <code>sp:TransportBinding</code>
identifies a visible behavior that is a requirement. A nested
@@ -545,9 +555,9 @@
</p>
<p>In the example below, the child Policy element is a nested
policy expression and further qualifies the behavior of the
- sp:TransportBinding policy assertion. The
+ <code>sp:TransportBinding</code> policy assertion. The
<code>sp:TransportToken</code> is a nested policy assertion of
- thesp:TransportBinding policy assertion. The
+ the <code>sp:TransportBinding</code> policy assertion. The
<code>sp:TransportToken</code> assertion requires the use of a
specific transport token and further qualifies the behavior of
the <code>sp:TransportBinding</code> policy assertion (which
@@ -572,7 +582,7 @@
</sp:TransportBinding></eg>
</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
@@ -585,7 +595,7 @@
from these Web service developers.
</p>
</div2>
- <div2 id="parametrized-assertions">
+ <div2 id="parameterized-assertions">
<head>Assertions with Parameters</head>
<p>The framework provides an alternative approach for
providing additional information for an assertion beyond its
@@ -604,7 +614,7 @@
</ulist>
</div2>
<div2 id="comparison">
- <head>Comparison of Nested and Parametrized Assertions</head>
+ <head>Comparison of Nested and Parameterized Assertions</head>
<p>The main consideration for selecting parameters or nesting
of assertions, is that <emph>the framework intersection
algorithm processes nested alternatives, but does not consider
@@ -666,7 +676,7 @@
inferred or indicated from a message. If there is a need for the
behavior to be represented in a persistent way or if there s a need for additional data
or metadata that is present in a message to be persisted, it should be incorporated
- into the assertion design or in the message iteself.
+ into the assertion design or in the message itself.
</p>
<p>As a result, Policy assertions should not be used to express
the semantics of a message. If a property is
@@ -742,7 +752,7 @@
targeted to the provider so that the provider can determine
that the optional behavior is engaged. In other words, the
requirement of self describing nature of messages in order
- to engage behaviors must not be forgotton with regard to
+ to engage behaviors must not be forgotten with regard to
the client's ability to detect and select the alternative if
it is to participate in the exchange. It is recommended that
authors not utilize optional assertions for outbound
@@ -919,7 +929,7 @@
</p>
<p>One approach is to specify a policy subject, choose the
most granular policy subject that the behavior applies to and
- specify a preferred attachment point in WSDL. Howeever, this
+ specify a preferred attachment point in WSDL. However, this
approach only works if the policy subject is a true WSDL
construct other than some other protocol concept that is
layered over WSDL message exchanges. For example, the WS-RM
@@ -961,7 +971,7 @@
within another expression but also allows specification of
additional policy subjects and their association to common
policy expressions that are identified. It also promotes
- managability of the expressions as they are uniquely
+ manageability of the expressions as they are uniquely
identified.
</p>
</div3>
@@ -971,18 +981,19 @@
</div3>
<div3 id="assertion-evolution">
<head>Evolution of Assertions (Versioning and Compatibility)</head>
- <p>4.4.7. Over time, there may be multiple equivalent
- behaviors emerging in the Web Service interaction
- space. Examples of such multiple equivalent behaviors are
- WSS: SOAP Message Security 1.0 vs. 1.1 and WS-Addressing
- August 2004 version vs. WS-Addressing W3C
- Recommendation. These equivalent behaviors are mutually
- exclusive for an interaction. Such equivalent behaviors can
- be modeled as independent assertions. The policy expression
- in the example below requires the use of WSS: SOAP Message
- Security 1.0. </p>
- <example>
- <head>Example 4-2. Message-level Security and WSS: SOAP Message Security 1.0 </head>
+ <p>4.4.7. Over time, there may
+ be multiple equivalent behaviors emerging in the Web
+ Service interaction space. Examples of such multiple
+ equivalent behaviors are WSS: SOAP Message Security 1.0
+ vs. 1.1 and WS-Addressing
+ August 2004 version vs. WS-Addressing W3C Recommendation
+ [<bibref ref="WS-Addressing"/>]. These equivalent behaviors
+ are mutually exclusive for an interaction. Such equivalent
+ behaviors can be modeled as independent assertions. The
+ policy expression in the example below requires the use of
+ WSS: SOAP Message Security 1.0. </p> <example>
+ <head>Example 4-2. Message-level Security and WSS: SOAP
+ Message Security 1.0 </head>
<p>ADD THE EXAMPLE HERE </p>
</example>
<p>The policy expression in the example below requires the
@@ -1063,7 +1074,7 @@
<div1 id="scenerio">
<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 fictitous company
+ 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,
WS-Addressing and WS-Reliable Messaging in all its new web
@@ -1105,7 +1116,7 @@
<head>Message with Security Headers</head>
<eg xml:space="preserve"><soap:Envelope>
<soap:Header>
- <wss:Security sopap:mustUnderstand ="1">
+ <wss:Security soap:mustUnderstand ="1">
<wsu:Timestamp u:Id=_0">
<wsu:Created> 20006-01-19T02:49:53.914Z </u:Created>
<wsu:Expires> 20006-01-19T02:54:53.914Z </u:Expires>
@@ -1131,10 +1142,10 @@
<eg xml:space="preserve">
<Policy URI=http://www.CompanyA.com/WebServicesProfileA.xml>
<wsa:UsingAddressing />
- <sp:TransportBinding>lt;/spTransportBinding>
+ <sp:TransportBinding></spTransportBinding>
</Policy></eg>
</example>
- <p>The <code>sp:TransportBinding</code> element is a policy assertion.The
+ <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
@@ -1153,31 +1164,26 @@
there were 3 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 X, CompanyA-ProfileA and
- it is the policy that is used 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 Y, CompanyA-ProfileB 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 xml:space="preserve">
-<Policy wsu:Id="CompanyA-ProfileB">
- <wsa:UsingAddressing />
- <ExactlyOne>
- <sp:TransportBinding></sp:TransportBinding>
- <sp:AsymmetricBinding></sp:AssymetricBinding>
- </ExactlyOne>
-</Policy> </eg>
- </example>
- <p>In the previous section CompanyA 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>
+ <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
+ 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
+ xml:space="preserve"> <Policy wsu:Id="CompanyA-ProfileB">
+ <wsa:UsingAddressing /> <ExactlyOne>
+ <sp:TransportBinding></sp:TransportBinding>
+ <sp:AsymmetricBinding></sp:AssymetricBinding>
+ </ExactlyOne> </Policy> </eg> </example>
+ <p>We have shown above that CompanyA 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>
<p>When WS-Policy authors create sets of Policy assertions, like
WS-Security Policy they need to consider expressing the semantics
of their domain in a way that policy consumers, like Company A,
@@ -1188,13 +1194,13 @@
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
- know what transport token, what algorithm suite, etc is
+ 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
assertions. </p>
<p>In the example below the child Policy element is a nested
policy behavior and further qualifies the behavior of the
- sp:TransportBinding policy assertion. </p>
+ <code>sp:TransportBinding</code> policy assertion. </p>
<example>
<head>CompanyA-ProfileB (fully expanded)</head>
<eg xml:space="preserve">
@@ -1435,6 +1441,18 @@
<titleref>Web Services Description Language (WSDL) 1.1</titleref>, E. Christensen, et al,
Authors. World Wide Web Consortium, March 2001. Available at
http://www.w3.org/TR/2001/NOTE-wsdl-20010315. </bibl>
+
+ <bibl key="WSDL 2.0 Core Language" id="WSDL20" href="http://www.w3.org/TR/2006/CR-wsdl20-20060327/">
+ <titleref>Web Services Description Language (WSDL) Version
+ 2.0 Part 1: Core Language</titleref>, R. Chinnici,
+ J. J. Moreau, A. Ryman, S. Weerawarana, Editors. World Wide
+ Web Consortium, 27 March 2006. This version of the WSDL 2.0
+ specification is
+ http://www.w3.org/TR/2006/CR-wsdl20-20060327. The <loc
+ href="http://www.w3.org/TR/wsdl20/">latest version of WSDL
+ 2.0</loc> is available at http://www.w3.org/TR/wsdl20.
+ </bibl>
+
<bibl id="WS-Policy" key="Web Services Policy Framework" href="http://www.w3.org/TR/ws-policy/">
<titleref>&framework.title;</titleref>, A. S. Vedamuthu, D. Orchard, M. Hondo, T.
Boubez and P. Yendluri, Editors. World Wide Web Consortium, &draft.day;,
@@ -1485,6 +1503,35 @@
Inc., RSA Security Inc., and VeriSign Inc., February
2005. Available at
http://schemas.xmlsoap.org/ws/2005/02/trust. </bibl>
+ <bibl id="UDDIAPI20" key="UDDI API 2.0" href="http://uddi.org/pubs/ProgrammersAPI-V2.04-Published-20020719.htm">
+ <titleref>UDDI Version 2.04 API</titleref>, T. Bellwood,
+ Editor. Organization for the Advancement of Structured
+ Information Standards, 19 July 2002. This version of UDDI
+ Version 2.0 API is
+ http://uddi.org/pubs/ProgrammersAPI-V2.04-Published-20020719.htm. The
+ <loc href='http://uddi.org/pubs/ProgrammersAPI_v2.htm'>latest
+ version of the UDDI 2.0 API</loc> is available at
+ http://uddi.org/pubs/ProgrammersAPI_v2.htm.
+ </bibl>
+ <bibl id="UDDIDataStructure20" key="UDDI Data Structure 2.0" href="http://uddi.org/pubs/DataStructure-V2.03-Published-20020719.htm">
+ <titleref>UDDI Version 2.03 Data Structure
+ Reference</titleref>, C. von Riegen, Editor. Organization for
+ the Advancement of Structured Information Standards, 19 July
+ 2002. This version of UDDI Version 2.0 Data Structures is
+ http://uddi.org/pubs/DataStructure-V2.03-Published-20020719.htm. The
+ <loc href='http://uddi.org/pubs/DataStructure_v2.htm'>latest
+ version of the UDDI 2.0 Data Structures</loc> is available at
+ http://uddi.org/pubs/DataStructure_v2.htm.
+ </bibl>
+ <bibl id="UDDI30" key="UDDI 3.0" href="http://uddi.org/pubs/uddi-v3.0.1-20031014.htm">
+ <titleref>UDDI Version 3.0.1</titleref>, L. Clément, et
+ al, Editors. Organization for the Advancement of Structured Information Standards, 14 October 2003. This version of the
+ UDDI Version 3.0 is
+ http://uddi.org/pubs/uddi-v3.0.1-20031014.htm. The <loc
+ href='http://uddi.org/pubs/uddi_v3.htm'>latest version of
+ the UDDI 3.0</loc> specification is available at
+ http://uddi.org/pubs/uddi_v3.htm.
+ </bibl>
</blist>
</div1>&acknowledgements; <inform-div1 id="change-description">
<head>Changes in this Version of
@@ -1527,6 +1574,11 @@
<td>MH</td>
<td>Editorial fixes for readability, added example for Encrypted parts</td>
</tr>
+<tr>
+ <td>20061030</td>
+ <td>UY</td>
+ <td>Fixes for Paul Cotton's editorial comments (20061020)</td>
+ </tr>
</tbody>
</table>
</inform-div1>
Received on Tuesday, 31 October 2006 04:04:35 UTC