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: Tue, 20 May 2003 01:57:55 +1000
Message-ID: <754324CDE8E4EE4498D8E0357D913685016010B0@saab-bt.act.cmis.CSIRO.AU>
To: reagle@w3.org, public-p3p-spec@w3.org

Referring to my previous e-mail, here is my revision for those SOAP
messages. 

I removed the attribute env:relay="true" from the privacy element. Referring

to http://www.w3.org/TR/2003/PR-soap12-part0-20030507/:

"SOAP Version 1.2 defines another optional attribute for header blocks,
env:relay 
of type xs:boolean, which indicates if a header block targeted at a SOAP
intermediary 
must be relayed if it is not processed.
 
Thus, the header block does not have an env:relay attribute, which is
equivalent to 
having it with the value env:relay="false". Hence, this header is not
forwarded if 
it is not processed."

We may have to consider that all the intermediaries have to
"understand/agree with" and 
"process" the privacy policy if they handle the SOAP messages. Any comment?

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">
      <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">
      <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>

As there are three standardized roles defined (see SOAP Part 1, section
2.2), which are

"http://www.w3.org/2003/05/soap-envelope/role/none" (hereafter simply
"none") 
"http://www.w3.org/2003/05/soap-envelope/role/next" (hereafter simply
"next"), and 
"http://www.w3.org/2003/05/soap-envelope/role/ultimateReceiver" (hereafter
simply "ultimateReceiver"). 

Referring to http://www.w3.org/TR/2003/PR-soap12-part0-20030507/:

"Targeting the header block at the role "next" together with the env:relay
attribute set to "true" can 
always serve to ensure that each intermediary has a chance to examine the
header, because one of the 
anticipated uses of the "next" role is with header blocks that carry
information that are expected to 
persist along a SOAP message path. Of course, the application designer can
always define a custom role 
that allows targetting at specific intermediaries that assume this role.
Therefore, there is no 
restriction on the use of the env:relay attribute with any role except of
course the roles of "none" 
and "ultimateReceiver", for which it is meaningless."

I am also thinking whether we should create a special role that will
understand and process the
privacy policies. Any suggestion?
Received on Monday, 19 May 2003 11:58:45 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 17 March 2004 17:46:24 EST