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: Fri, 2 May 2003 19:39:16 +1000
Message-ID: <754324CDE8E4EE4498D8E0357D91368501600F93@saab-bt.act.cmis.CSIRO.AU>
To: reagle@w3.org, public-p3p-spec@w3.org

Hi Joseph,

I am still catching up with you guys' accent in this research area. :-)

> Hi Patrick, I think I have the gist of your scenario though I'm a little ?
> confused by some of the terminology. For example, I would think that the 
> "requestor" would have privacy *preferences" and the others would have 
> *policies*. This has caused me to work some more on the definitions 
> (including looking at [1]) and perhaps we could speak in terms of User 
> (registrant), Soliciting Service (registrar), and a Recipeint Service 
> (registry)?

Oops... Yes, you are correct. I was thinking those issues NOT based in the 
context of the Domain Name Service (DNS) registration example described in 
this document. I have to switch my mind to this example only... :-)

> I think a UDDI scenario is useful, but it's not my top priority and I'm
> quite sure how to include with sensible motivation in our present DNS 
> registry scenario. But that can change!

Yes, I agree with you. Referring to this DNS registration scenario, the UDDI

issues are not in the top priority.

> If an endpoint can advertise its privacy policy and presume any message 
> transmitted to it will have seen that policy, I presume it could accept 
> such a message without sending a response. (This is akin to earlier
> in P3P as to whether a unique policy identifier could be associated with a

> request in order to avoid a round trip I think...) 

I was thinking a scenario of mutual privacy validation process, e.g., both
and registrar have to check each other privacy policies based on their
Anyway, this is not the scenario as discussed here.

> No. I'm a big fan of "not precluded"; it means that while authenticated 
> interactions are possible, and even encouraged, it should be *possible* 
> architecturally for someone to not be authenticated.

Referring to this DNS registration scenario, "not precluded" is fine. I am
thinking that it may not be ok in other scenario.

> What do you mean by "browser-interfaced" and why is that necessary?

Referring to "2.8 S030 Third party intermediary - 2.8.2 Description," it
that "The buyer may be as simple as a browser or as complex as a procurement

application." In this DNS registration scenario, most likely, the registrant

is using a browser to interact with the registrar. Thus, "using cookies" is
definitely feasible and applicable.

> Yes, but the adopting application (e.g., DNS registration) has the ability

> to profile it's dependencies. So it could say, "the only normative P3P 
> semantics associated with *this* application (DNS registration web
> are those associated with the SOAP binding." 
> One might be able to say a number of things:
> 1. the SOAP transport MUST be HTTP "origin server" and the SOAP "ultimate 
> receiver" (the service receiving the data) are one and the same so:
> a. the P3P policy must only be bound to the SOAP message.
> b. a P3P policy will be bound to the message and its transport and both
> normative policies on behalf of the "origin server"/"ultimate receiver"
> 2. the SOAP transport is unspecified (HTTP or SMTP)
> a ...
> b ...
> ...

Yep, I got what you mean.

> Please do! I'm going to try to put together an XML instance/example of 
> associating a the P3P policy with the actual user solicitation via

I will start to write up the chunks in the context of DNS registration

Another typo in the document:

Recipient Service (registry) 
A Web Service that offers an interface to registrars for registering and
domain name registrations. The registry is the participan responsible for
                                                         ^ *participant*
the database for a DNS Top-Level Domain (TLD) such as ".com". This service
has privacy 
policies as well.

Do you have any timeline for this document? Maybe, we should have a
conference call
for this task force after we have more content in those chunks.

Thanks and talk to you later,

Received on Friday, 2 May 2003 05:39:33 UTC

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