W3C home > Mailing lists > Public > public-p3p-spec@w3.org > May 2003

RE: [BH] First (Very Rought) Outline of Beyond HTTP

From: <Patrick.Hung@csiro.au>
Date: Sat, 17 May 2003 02:30:52 +1000
Message-ID: <754324CDE8E4EE4498D8E0357D91368501601090@saab-bt.act.cmis.CSIRO.AU>
To: reagle@w3.org, public-p3p-spec@w3.org

> Ok! Various tweaks to those files are now included in 
>  http://www.w3.org/P3P/2003/p3p-beyond-http/Overview.html
>  new revision: 1.12
> I've also done some re-org, and make sure that all XML is well-formed, and

> most all of it is valid as well -- just haven't check the SOAP messages.

Hi Joseph, Thanks a lot for your effort! Sorry to bother you... Would you 
please help me to change my name as "Patrick C. K. Hung" instead of 
"Patrick Hung" on the document? I just want to make my name to be consistent

in all places. Thanks for your help :-)

> Not sure, in your message I would read that header as the registrar 
> (service) representing the policy associated with data (*transfer* along 
> the SOAP exchange) to the registry (recipient service). (There's also a 
> question of how the registrar knows the registry's policy which I want to 
> explore a little further -- it can be out of band, I just want to document

> the issue)  

I think this should fall into the management issues. As one can imagine 
that a group of registries (Web services) can refer to one corporate 
privacy policy stored at a well-known place, the registrars should also
be able to know the location via the WSDL documents or UDDI.

> But in order.xml I included the Privacy element as a child of 
> the OrderInfo element, so it's like a "tag" associated with the data (at 
> the application layer) for clarity. What does it mean when such a tag is 
> provided in a SOAP header versus the actual application data? (We need to 
> dig into the semantics of a SOAP envelope.)

I checked the SOAP 1.2 http://www.w3.org/TR/soap12-part0/ and 
http://www.w3.org/TR/2003/PR-soap12-part1-20030507. I could not find any
specific topic about extending the SOAP schemas as we faced in the WSDL
schema... maybe I missed it??!! Anyway, I will do more studies next

In another case, we may have something like this:

Registrar2Registry Request SOAP Message

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> 

          <p:Last>Reagle Jr.</p:Last>
          <p:Street>200 Tecnology Square</p:Street>

Registry2Registrar Response SOAP Message

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> 


Where the <Privacy /> element is specified in the

           <complexType name="Privacy">
              <attribute name="rel" type="string" use="required"/>
              <attribute name="href" type="string" use="anyURL"/>

> From the reorg perhaps you can see that I wasn't planning on introducing 
> another party... Granted, the present scenario isn't a proper "SOAP 3-way 
> intermediary" because our first leg was mediated by XForms/HTTP, but I 
> think that's ok. The important thing for me is to explore the three 
> questions:
> 1. The Scope of the P3P Service Provider and Recipients (given their P3P
> definitions.

Referring to http://www.w3.org/TR/2003/PR-soap12-part1-20030507/, we should
have to consider/take the forwarding intermediaries and active
between the P3P Service Provider (Registrar) and Recipients (Registries):

forwarding intermediaries
"The semantics of one or more SOAP header blocks in a SOAP message, or the
MAY require that the SOAP message be forwarded to another SOAP node on
behalf of the 
initiator of the inbound SOAP message. In this case, the processing SOAP
node acts in 
the role of a SOAP forwarding intermediary."

active intermediaries
"In addition to the processing performed by forwarding SOAP intermediaries,
active SOAP 
intermediaries undertake additional processing that can modify the outbound
SOAP message 
in ways not described in the inbound SOAP message. That is, they can
undertake processing 
not described by SOAP header blocks in the incoming SOAP message. The
potential set of 
services provided by an active SOAP intermediary includes, but is not
limited to: security 
services, annotation services, and content manipulation services."

> 2. The Scope of Layers and Bindings (HTTP and SOAP) -- I'm pretty
> we've ruled WSDL and UDDI as orthogonal/optional.

Yes, I agree with you. Further, a SOAP header element is optional. If we
specify the 
privacy policy in the SOAP header, can we also say that the privacy policy
is also
optional. :-) It sounds pretty logically, right?

> 3. This question of should a privacy "taggit" be in the SOAP header, or
> the application data, or both? (I don't think "taggit" is a word, but a 
> while ago I heard that gunpowder has little identifying particles in it 
> that can be used with forensics, and I remembered someone proposing that 
> the policy should also "follow" the solicited data. I just can't remember 
> the name."

Referring to http://www.w3.org/TR/soap12-part0/, we can check these

"A SOAP header is an extension mechanism that provides a way to pass 
information in SOAP messages that is not application payload. Such 
"control" information includes, for example, passing directives or 
contextual information related to the processing of the message. 
This allows a SOAP message to be extended in an application-specific 
manner. The immediate child elements of the env:Header element are 
called header blocks, and represent a logical grouping of data which, 
as shown later, can individually be targeted at SOAP nodes that might 
be encountered in the path of a message from a sender to an ultimate 

SOAP headers have been designed in anticipation of various uses for SOAP, 
many of which will involve the participation of other SOAP processing nodes 
- called SOAP intermediaries - along a message's path from an initial SOAP 
sender to an ultimate SOAP receiver. This allows SOAP intermediaries to 
provide value-added services. Headers, as shown later, may be inspected, 
inserted, deleted or forwarded by SOAP nodes encountered along a SOAP

Any help? More thoughts are required... 

> How's that sound? And yes, we've made great progress, we're approaching
> point where it'd be good to explore the scenario with a web service guru 
> who could tell us how confused we are. <smile/>

All sound good. By the way, do you have a "roadmap" in your mind for this
task force? I believe that we do have to think something like a WS-P3P
policy such
as WS-Privacy for Web services after this framework is done.

Some very minor typos in the current version:
(1) There are two places "The the ..."
(2) The response SOAP message is same as the request SOAP message.

Have a nice weekend! Talk to you later. Patrick.
Received on Friday, 16 May 2003 12:31:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:02:17 UTC