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

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
not 
> 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
debates 
> 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
registrant
and registrar have to check each other privacy policies based on their
preferences.
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
says
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
service) 
> 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
are 
> 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
XForms.

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

Another typo in the document:

Recipient Service (registry) 
A Web Service that offers an interface to registrars for registering and
maintaining 
domain name registrations. The registry is the participan responsible for
managing 
                                                         ^ *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,

Patrick.

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