W3C home > Mailing lists > Public > public-ws-policy@w3.org > October 2006

RE: Policy Retrieval Algorithms

From: Daniel Roth <Daniel.Roth@microsoft.com>
Date: Wed, 11 Oct 2006 08:26:22 -0700
To: Paul Denning <pauld@mitre.org>, "public-ws-policy@w3.org" <public-ws-policy@w3.org>
Message-ID: <E2903CF1E4B5B144B559237FDFB291CE1816939E@NA-EXMSG-C117.redmond.corp.microsoft.com>
Hi Paul,

> there is no requirement that the IRI be resolvable

I would also note that the IRI CAN be resolvable.  Using resolvable IRIs seems like a natural and interoperable way of dealing with external references.

> defining a way to identify a retrieval mechanism could/should be in scope.

This seems unnecessary since IRI's already define a way to specify how to resolve them.  Supporting more creative resolution mechanisms seems like a Policy vNext feature.

Daniel Roth

From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of Paul Denning
Sent: Friday, October 06, 2006 12:47 PM
To: public-ws-policy@w3.org
Subject: Policy Retrieval Algorithms

[1] http://tinyurl.com/ot5x5#Policy_References

Section 4.3.4 states

"...there is no requirement that the IRI be resolvable; retrieval mechanisms are beyond the scope of this specification."

I would agree that defining various retrieval mechanisms would be out of scope, but defining a way to identify a retrieval mechanism could/should be in scope.

Perhaps adding



  This optional URI attribute specifies the Retrieval Algorithm being used to resolve an external policy expression identified by ./@URI.


Note that this is modeled after the DigestAlgorithm.  You would not provide @Digest without specifying the @DigestAlgorithm used to calculate it.

@Digest is opaque and you cannot determine the digest algorithm by looking at its value.

Likewise, we should treat @URI as opaque and provide an identifier for the algorithm that can be used to resolve the external policy expression.

Received on Wednesday, 11 October 2006 15:28:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:33:16 UTC