[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp-wsia] [I#97] Caching Mechanism
The Consumer should not be forced to keep you apart ... a good Producer
will.
Andre Kramer
<andre.kramer@eu. To: wsrp-wsia@lists.oasis-open.org
citrix.com> cc:
Subject: RE: [wsrp-wsia] [I#97] Caching Mechanism
10/24/2002 07:29
AM
What if the producer hosts both a myCitrx and a SAP application? I, for
myCitrix, would make all my validation keys be cryptographically strong. Or
should the spec enforce consumers to keep us apart? (not that we would ever
... ;)
regards,
Andre
-----Original Message-----
From: Tamari, Yossi [mailto:yossi.tamari@sap.com]
Sent: 24 October 2002 12:18
To: wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [I#97] Caching Mechanism
hi Andre,
I don't think there is a security issue here. Just like anything else
in its implementation, the consumer must be careful in what it allows
a producer to do.
Specifically, the validationTag should not be used as the primary key
to the cache, but rather as an index to the cache. This means
spoofing is not possible. Invalidation across producer would not be
allowed by a reasonable consumer. Whether invalidation across
portlets is allowed is a more difficult question.
However, I do agree that all of the caching mechanisms should be
optional. They are used to improve performance only.
Yossi.
-----Original Message-----
From: Andre Kramer [mailto:andre.kramer@eu.citrix.com]
Sent: Thursday, October 24, 2002 12:38 PM
To: wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [I#97] Caching Mechanism
One possible security issue I see is that the consumer may end
up trusting the producer or the entities in a producer as there
are no proposed security controls on what content can be
invalidated (Only from same producer? Or same application
groupID from that producer?) or on two entities specifying the
same validation key (should keys be unguessable unique
identifiers?). We do not want a hostile entity deleting or
spoofing another's content because of a trusting/open and
shared consumer-side cache. I'm sure sensible rules are
possible but we should make the validation caching mechanisms
optional if trust is an issue.
regards,
Andre
-----Original Message-----
From: Gil Tayar [mailto:Gil.Tayar@webcollage.com]
Sent: 23 October 2002 07:46
To: wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [I#97] Caching Mechanism
Caching has long been forgotten in these days of heated
discussions on initEnvironment and groupId :-). I would
like to return and discuss it.
There are two proposals on the table. One of them is
defined in the v0.8 spec, and the other is a mechanism
proposed by myself and extended by Yossi and Mike. Is
anybody interested in pursuing this mechanism, or should
we just leave the current one (defined in the spec)as it
is? The main difference between the two is that the
mechanism in the draft only includes expiration
semantics, but does not include validation/invalidation
semantics. Since most Web apps use
validation/invalidation and not expiration semantics
(because usually expiration time is never well defined
for most apps), I believe the validation/invalidation to
be important. The proposal (copied below), attempts to
address this.
Gil
P.S. For reference, here is the proposal (without Mike's
extensions, but with Yossi's)
6.1 Operations [getMarkup]
[instead of expires in markupResponse, add the following]
cacheControl: A data structure, defined in Section 11,
which includes information which CAN be used by the
Consumer to cache the markup. This structure includes:
validityPeriod: The number of seconds during which
the markup is valid. During that time the Consumer CAN
use its cache entry instead of calling getMarkup.
validationTag: The Consumer SHOULD store this tag
along with the markup while the markup is cached. This
enables the Producer to use this tag to invalidate the
cache entry by sending an invalidationTagPrefix in the
performInteraction operation. After the markup expires,
the Consumer CAN send the validationTag in the
markupResponse to indicate that it still has the markup
but would like to validate it. The Producer returns a
fault response [TBD] to indicate that the markup is still
valid, otherwise if it returns markup , the Consumer MUST
invalidate the old markup.
cachingScope: This is an enumeration field used by
the producer to tell the consumer what is the caching
scope of the markup. Possible values for this field are:
1 - session. The markup is invalid outside the scope of
the current client session.
2 - user. The markup is only valid for this user,
regardless of his session.
3 - producer. All requests for this resource can be
served by one valid cached markup.
While this is not an explicit part of the protocol, The
consumer SHOULD also not use a cached markup in any scope
that was generated for a different
locale/markupType/mode.
[add to markupContext the following field]
validationTag: This field CAN be sent to indicate that
the Consumer has cached markup (which was tagged by the
Producer with this value) and wishes to check whether it
is still valid. See validationTag in markupResponse for
more information.
6.1 Operations [performInteraction]
[add the following field to interactionResponse]
invalidationTagPrefix: If the Producer returned this
value, the Consumer MUST expire all markup-s who's
validationTag begins with this value. The Consumer MUST
not call getMarkup with these invalidationTag-s to
validate these expired markup-s.
Hopefully this proposal gives good coverage of different
caching scenarios for consumers/producers that make full
use of it, while degrading gracefully for those that make
use of only some of the elements. For example, many
producers will probably not use the validation tag, and
some consumers will probably only do per-user, per-URL
caching, but they can still make use of the more basic
parameters (like validity period). It may be a good idea
to also add some metadata describing these capabilities
in the producer and consumer metadata.
-----Original Message-----
From: Gil Tayar [mailto:Gil.Tayar@webcollage.com]
Sent: Wed, October 09, 2002 06:56
To: wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [I#97] Caching Mechanism
I totally agree with Rich's comments on Mike's email. The
first proposal
(array of invalidationTagPrefixes) is just a simple
extension. No questions.
The others raise some questions, and invalidate the
concept of a "simple"
caching mechanism.
Proposal: incorporate Yossi's extension, albeit using
strings and not
numbers, add an extension mechanism as per Mike's
proposal, and change the
returned invalidationPrefix to be an array of such, as
per Mike's proposal.
-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Mon, October 07, 2002 21:08
To: wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [I#97] Caching Mechanism
I would note that as Carsten's proposal was incorporated
in v0.7 that the
standard extensibility was added to CacheControl.
I would agree that we are using string arrays (maximizes
interoperability)
rather than enums throughout the protocol.
On the first (b) comment, are you proposing there be a
structure for the
invalidationTagPrefix or could this just use the fact the
InteractionResponse structure is already extensible?
From Yossi's original proposal, I would agree that the
invalidation
information in InteractionResponse would be better as an
array. While it
often would often be used with a size of one, this gives
significant power
to the entity at minimal cost to the Consumer.
The later three proposed extensions are quite specific to
how a cache might
be implemented. The extensibility of the data objects
certainly would allow
this information to be carried between end-points that
understand/support/exploit it.
More fundamentally, are we interested in getting the
validationTag concept
and its related semantic implications on the various
operations into v1?
"Tamari, Yossi"
<yossi.tamari@sap To:
wsrp-wsia@lists.oasis-open.org
.com> cc:
Subject:
RE: [wsrp-wsia]
[I#97] Caching Mechanism
10/07/2002 02:37
PM
Hi Mike,
I agree that my proposal missed the necessary
extensibility properties.
They should be added to all relevant objects.
I do not see a difference between enumeration and string
in your first c.
Both can be extended. We seem to be using strings with
predefined constants
elsewhere in the spec, so I agree with this remark as
well.
I don't think we should add the 4 extensions that you
offered (especially
the later two), because they seem to cross the line
between
simple-in-a-complex-way to complex-squared, and between
generic to
vendor-specific.
Yossi.
-----Original Message-----
From: MICHAEL.FREEDMAN [
mailto:MICHAEL.FREEDMAN@oracle.com]
Sent: Monday, October 07, 2002 6:04 PM
To: wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [I#97] Caching Mechanism
Yossi, your proposal is the best so far. It
provides a good
semantical framework for the type of caching we
have found useful in
our Portal. It also seems to draw a reasonable
line of being
"enough" function without getting overly expressive
and complex.
However, there are needs (by ourselves and I
suspect others) to at
times be overly expressive and complex. Hence we
would like to see
[more] extensibility built into the mechanism.
I.e. view the
semantics you have defined as "base" semantics but
allow for extended
support/semantics where applicable.
For extensibility, we need the proposal to:
a) Add an extension field in the cacheControl
structure to
carry additional information
b) Allow extended information to be returned
with the
invalidationTagPrefix from a processAction
c) define cachingScope in the getMarkup's
cacheControl return
structure in an extensible manner. A
suggestion is to define
cachingScope as a String. "session", "user",
and "producer"
would be predefined, well understood scopes.
However,
cooperating consumers and producers could
additionally use
vendor specific scopes.
By adding these to the proposal we would have both
a good basic
level/semantic of caching and allow vendors like us
to
support/express a greater level. A few specific
"extensions" that we
think it would be better if the base proposal
incorporated directly
would be:
a) you can return multiple [invalidation]
tags from a
processAction. Tags are still "prefixes",
however there is
value in returning multiple prefixes to
accurately prune a tree
whether at a leaf or higher up.
b) you can return multiple tags in a
cacheControl structure
from getMarkup. I.e. the validationTag field
is a list. The
semantic of this is each tag is a discrete
invalidation key for
the content returned from this getMarkup.
Supporting this give
a producer the flexibility to categorize
cache content along
different dimensions and invalidate
accordingly along a
dimension.
c) you can return an urgencyToExpire value
along with the
invalidation tags from processAction. This
field would express
how quickly the cache must attempt the
invalidation. I.e.
invalidate these keys but its okay if you are
busy to continue
serving "stale" data for a given duration.
There is one
field/value for the entire list of tags
returned.
d) you can return an urgencyToExpire value in
the cacheControl
structure from the getMarkup. Similar to the
function in (c),
this directs the cache as to the urgency of
invalidating the
cache if/when one goes "out of scope" where
scope is the cache
scope defined by cachingScope.
We strongly urge these "extensions" be considered
and added into the
proposal as they have good value and would be
somewhat clumsy to
express in the extension mechanism. However, if
that is not the
consensus of the group, as long as your proposal
carries at least the
minimal extensibility defined at the top we would
have enough
mechanism to express the above function.
-Mike-
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the
subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the
subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC