WEBI Issues List
Last update: '$Date: 2002/03/18 22:04:59 $'
-------------------------------------------------------------------
1 - Cache coherence examples
Created: 2002-02-20
Locus: RUP-REQS
Topic: General
Priority: Editorial
Status: New
Originator(s):
- Ian Cooper <mailto:ian@the-coopers.org>
Owner(s):
Description:
Introduction includes references to cache invalidation
or cache coherence protocols (WCIP, PSI, DOCP).
--
Should we give examples at all? If so are there other
references that need to be given?
-------------------------------------------------------------------
2 - CONSISTENCY GUARANTEE has no definition
Created: 2002-02-25
Locus: RUP-REQS
Topic: Term
Priority: Editorial
Status: New
Originator(s):
- Ian Cooper <mailto:ian@the-coopers.org>
Owner(s):
Description:
The term CONSISTENCY GUARANTEE is used within the body
of the document but there is no description of this
term.
-------------------------------------------------------------------
3 - RESOURCE GROUP has no definition
Created: 2002-02-25
Locus: RUP-REQS
Topic: Term
Priority: Editorial
Status: New
Originator(s):
- Ian Cooper <mailto:ian@the-coopers.org>
Owner(s):
Description:
The term RESOURCE GROUP is used within the body of the
document but there is no description of this term.
-------------------------------------------------------------------
4 - Design Guidelines necessary?
Created: 2002-02-25
Locus: RUP-REQS
Topic: General
Priority: Editorial
Status: New
Originator(s):
- Ian Cooper <mailto:ian@the-coopers.org>
Owner(s):
Description:
Is the Design Guidelines section necessary? Most of
these guidelines should be common sense to designers
of candidate protocols (e.g. if it won't scale then
it doesn't belong on the Internet).
-------------------------------------------------------------------
5 - RUP CLIENT invalidation examples
Created: 2002-02-25
Locus: RUP-REQS
Topic: Usecase
Priority: Editorial
Status: New
Originator(s):
- Ian Cooper <mailto:ian@the-coopers.org>
Owner(s):
Description:
In the RUP CLIENT driven invalidation text, is it
appropriate to give examples upon which the RUP SERVER
basis its decisions? E.g. should we mention Etag,
timestamp etc.?
-------------------------------------------------------------------
6 - Content location update analagous to HTTP 30x?
Created: 2002-02-25
Locus: RUP-REQS
Topic: Usecase
Priority: Editorial
Status: New
Originator(s):
- Ian Cooper <mailto:ian@the-coopers.org>
Owner(s):
Description:
Is a content location update analagous to an HTTP 30x
response?
--
If so is it useful to indicate this in section Content
location update (6.3)?
-------------------------------------------------------------------
7 - Content location update analagous to RFC3143 A.1.1?
Created: 2002-02-25
Locus: RUP-REQS
Topic: General
Priority: Editorial
Status: New
Originator(s):
- Ian Cooper <mailto:ian@the-coopers.org>
Owner(s):
Description:
Is content location update analagous to the archived
Known Problem presented in section A.1.1 of RFC3143?
-------------------------------------------------------------------
8 - Content location update temporary?
Created: 2002-02-26
Locus: RUP-REQS
Topic: Requirement
Priority: Design
Status: New
Originator(s):
- Ian Cooper <mailto:ian@the-coopers.org>
Owner(s):
Description:
How temporary is a content location update?
-------------------------------------------------------------------
9 - Content location update granularity
Created: 2002-02-26
Locus: RUP-REQS
Topic: Requirement
Priority: Design
Status: New
Originator(s):
- Ian Cooper <mailto:ian@the-coopers.org>
Owner(s):
Description:
What is the level of granularity of a content location
update?
--
Current wording suggests a per-entity basis, but if a
reasonable encoding could be provided it may be more
beneficial to enable a resource group to have its
location updated.
-------------------------------------------------------------------
10 - Metadata updates section needed
Created: 2002-02-26
Locus: RUP-REQS
Topic: Requirement
Priority: Editorial
Status: New
Originator(s):
- Ian Cooper <mailto:ian@the-coopers.org>
Owner(s):
Description:
No text for metadata updates. Do we need this
section? If so we need text describing what metadata
updates are, even if we say they SHOULD NOT be
implemented.
-------------------------------------------------------------------
11 - Loose consistency?
Created: 2002-02-26
Locus: RUP-REQS
Topic: Requirement
Priority: Design
Status: New
Originator(s):
- Ian Cooper <mailto:ian@the-coopers.org>
Owner(s):
Description:
Does this section belong in the requirements and
guidelines?
--
It's not clear how this RUP metadata would be
communicated or how it would interact with CLIENT and
SERVER invalidations. It sounds like it's a way of
overriding HTTP's Cache-Control directives while
allowing consistency of 0 to n second resolution on a
group of entities or a resource group.
-------------------------------------------------------------------
12 - HTTP Warning codes?
Created: 2002-02-26
Locus: RUP-REQS
Topic: General
Priority: Editorial
Status: New
Originator(s):
- Ian Cooper <mailto:ian@the-coopers.org>
Owner(s):
Description:
Which HTTP warning code should be used to indicate
content is being served in a manner HTTP says is stale
but which is indicated as fresh due to RUP control?
--
(draft-01 mentioned 110/111, but should we register a
new warning code?)
-------------------------------------------------------------------
13 - Limit on only announcing updates to subscribed groups unworkable
Created: 2002-02-27
Locus: RUP-REQS
Topic: Requirement
Priority: Design
Status: Active
Originator(s):
- Ian Cooper <mailto:ian@the-coopers.org>
Owner(s):
Description:
(draft-02) 6.2 item 1 stated that RUP SERVERs must only send
notifications about resources to RUP CLIENTs that
have requested notifications for that group.
--
RUP CLIENTs (that have not yet seen entities within a
group) cannot, therefore, benefit from content
location updates [which could be used in the future]
or content prefect hints [the RUP Server may know that
there is anticipated demand].
--
Changing MUST to SHOULD (or even including the words
in non-RFC2119 form) does not seem to work.
-------------------------------------------------------------------
14 - Option acknowledgement a problem with relays
Created: 2002-02-27
Locus: RUP-REQS
Topic: Requirement
Priority: Design
Status: New
Originator(s):
- Ian Cooper <mailto:ian@the-coopers.org>
Owner(s):
Description:
Option acknowledgement of operations seems impossible
in a situation where a relay is in use unless
communication between RUP SERVER and the relay
contains additional information, and is actually a
different or superset of the protocol.
-------------------------------------------------------------------
15 - Security considerations needs major work
Created: 2002-02-27
Locus: RUP-REQS
Topic: Security
Priority: Editorial
Status: New
Originator(s):
- Ian Cooper <mailto:ian@the-coopers.org>
Owner(s):
Description:
Security considerations is still in note form and the
editor needs some help in fleshing this out.
-------------------------------------------------------------------
16 - References
Created: 2002-02-27
Locus: RUP-REQS
Topic: General
Priority: Editorial
Status: New
Originator(s):
- Ian Cooper <mailto:ian@the-coopers.org>
Owner(s):
Description:
References [10] - [17] are never used, and I suspect
serve "reading list" purposes as a couple of others in
the list do. Do we need these references? Do we need
all the other references for this document to make
sense?
-------------------------------------------------------------------
17 - Issues list being ignored
Created: 2002-03-18
Locus: RUP-REQS
Topic: General
Priority: Editorial
Status: New
Originator(s):
- Ian Cooper <mailto:ian@the-coopers.org>
Owner(s):
Description:
No-one is commenting on any of the issues.
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:23:01 MST