Re: Comments on "[P3P]: Beyond HTTP"

* Patrick.Hung@csiro.au <Patrick.Hung@csiro.au> [2003-06-18 01:27+1000]
> >When using the http://www.w3.org/2003/05/soap/bindings/HTTP/ SOAP
> >HTTP/1.1 binding, the P3P feature is expressed as an HTTP header as
> >follows:
> >
> >  P3P: policy=" URI-Reference "
> 
> Based on your description, I believe that I have a picture of how
> to define a "feature." Assume my understanding is correct. Then,
> it seems that the "feature" is an independent structure that can
> be applied/attached into UDDI, SOAP or even WSDL, am I correct?

Hmmm... the concept of feature is something abstract which originated
in the SOAP Version 1.2 work and is in the process of being
generalized to the Web services architecture.

The definition of a SOAP feature is:

| An extension of the SOAP messaging framework (see 3. SOAP
| Extensibility Model). Examples of features include "reliability",
| "security", "correlation", "routing", and "Message Exchange Patterns"
| (MEPs).

More below.

> > A WSDL 1.2 description of a service with such a feature could be (this
> > may be slightly inaccurate, but you will get the idea):
> >
> >  <feature
> >     uri='http://example.org/2003/06/16-p3pf/'>
> >  <property
> >     uri='http://example.org/2003/06/16-p3pf/id'>
> >    <value>http://registry.example.com/P3P/Policy.xml</value>
> >  </property>
> >  </feature>
> 
> If I do not misunderstand it, how can I specify/attach the "feature" into 
> UDDI, SOAP or even WSDL? Sorry that I am lazy to check the related
> specifications.

Let's take another simple example to try and illustrate this.

Consider the simple "reliable" messaging. Its definition specifies
what is meant by simple "reliable" messaging, e.g. have the receiver
send a return receipt to the sender once it got the message, without
caring about this return receipt getting lost.

= SOAP 1.2

A SOAP module realizing the simple "reliable" messaging can then be
specified. A SOAP module is:

| A SOAP Module is a specification that contains the combined syntax and
| semantics of SOAP header blocks specified according to the rules in
| 3.3 SOAP Modules. A SOAP module realizes zero or more SOAP features.

So this specification would explain what SOAP header blocks would need
to be inserted in the message and how they would need to be processed
to implement this feature. I think that this answers your question
about the relationship with SOAP.

Note that this feature could be provided by a protocol binding. For
example, HTTP has responses and therefore the HTTP binding would
support this simple feature.

For more details about SOAP 1.2 and features:

  http://www.w3.org/TR/2003/PR-soap12-part1-20030507/#soapfeature

= WSDL 1.2

Then, for WSDL 1.2, a service may ask you to interact with it using
this feature. In this case, the WSDL 1.2 description of this service
would specify this with a piece of XML such as the one I showed for
the http://example.org/2003/06/16-p3pf/ feature, specifying the
associated properties.

This is how a feature would appear at the service description level.
For more details about WSDL 1.2 and features:

  http://www.w3.org/TR/2003/WD-wsdl12-20030611/#Feature

= Registry

If you were querying a registry, chances are that the registry was
populated directly from the WSDL 1.2 description. In this case, the
registry will tell you that the service support the simple "reliable"
messaging feature, since it found in the WSDL 1.2 description as
explained above.

I hope that this other simple example will shed more light on my more
relevant P3P feature example.

> > Hmmm... I think that I was confused. I think that a policy reference
> > file is fine as a child of wsdl:definitions, but a reference to a
> > policy file, i.e. a policy which would apply to an operation, would be
> > more specific.
> 
> In many cases, I do imagine that we may need a privacy policy at the
> <wsdl:definitions/>
> level and then with some other privacy policies at the <wsdl:operation/>
> level. Thus,
> we may have to do a logical "AND" between the privacy policies in two
> different abstraction
> levels.

Oh, I see.

Hope this helps.

Regards,

Hugo

-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/

Received on Wednesday, 18 June 2003 10:35:04 UTC