- From: <Patrick.Hung@csiro.au>
- Date: Sat, 17 May 2003 02:30:52 +1000
- 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
week.
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">
<env:Header>
<my:Privacy
xmlns:my="http://registry.example.com/2003/soap-header-p3p-extension.xsd"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true"
env:relay="true">
<my:rel>P3Pv1</my:rel>
<my:href>http://registry.example.com/P3P/PolicyReferences.xml</my:href>
</my:Privacy>
</env:Header>
<env:Body>
<p:OrderInfo
xmlns:p="http://registry.example.com/RegisterService/RegisterDomainName">
<p:PersonalInfo>
<p:Name>
<p:First>Joseph</p:First>
<p:Middle>M.</p:Middle>
<p:Last>Reagle Jr.</p:Last>
</p:Name>
<p:Address>
<p:Street>200 Tecnology Square</p:Street>
<p:City>Cambridge</p:City>
<p:State>MA</p:State>
<p:Zip>02139</p:Zip>
</p:Address>
</p:PersonalInfo>
<p:DomainInfo>
<p:TLD>com</p:TLD>
<p:DomainName>reagle.example</p:DomainName>
</p:DomainInfo>
</p:OrderInfo>
</env:Body>
</env:Envelope>
Registry2Registrar Response SOAP Message
========================================
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<my:Privacy
xmlns:my="http://registry.example.com/2003/soap-header-p3p-extension.xsd"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true"
env:relay="true">
<my:rel>P3Pv1</my:rel>
<my:href>http://registry.example.com/P3P/PolicyReferences.xml</my:href>
</my:Privacy>
</env:Header>
<env:Body>
<p:RegistrationStatus
xmlns:p="http://registry.example.com/RegisterService/RegisterDomainName">
OK
</p:RegistrationStatus>
</env:Body>
</env:Envelope>
Where the <Privacy /> element is specified in the
"http://registry.example.com/2003/soap-header-p3p-extension.xsd"
<schema
targetNamespace="http://registry.example.com/2003/soap-header-p3p-extension.
xsd"
xmlns="http://www.w3.org/2000/10/XMLSchema">
<complexType name="Privacy">
<attribute name="rel" type="string" use="required"/>
<attribute name="href" type="string" use="anyURL"/>
</complexType>
</schema>
> 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
1.0
> definitions.
Referring to http://www.w3.org/TR/2003/PR-soap12-part1-20030507/, we should
also
have to consider/take the forwarding intermediaries and active
intermediaries
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
SOAP MEP used
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
confident
> 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
with
> 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
descriptions:
"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
receiver.
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
message
path."
Any help? More thoughts are required...
> How's that sound? And yes, we've made great progress, we're approaching
the
> 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