Subject: Re: Distinguishing features and feature sets

From: Graham Klyne <[email-masked]>
Date: Thu, 04 Feb 1999 18:30:59 +0000

At 07:05 04/02/99 -0800, Bill Newman wrote:
>I'm still a skeptic on using hash codes to stand for for feature sets.
>I still prefer using URLs, and letting high-performance servers do
>their own hashing/caching as necessary (through ordinary HTTP caching
>control).

Noted;  with the right components, I don't think the outcome has to
preclude this approach.  Maybe.

>> One motivation I see is that if SONY-GIZMO and ACME-COMMUNICATOR have the
>> same hash value, then they can be reasonably assumed to be the same feature
>> expression without actually knowing what that feature set is.
> 
>I'm not sure this is an important benefit.

I won't argue that this (alone) is of great importance.

>> Another motivation is that if a recipient's characteristics change, the
>> change can be detected without sending the entire feature set.
>
>I'm not convinced this is better than just having users set their own
>expiration times through HTTP cache control.

I have always felt that the idea of cache-timeouts is a slightly
unsatisfactory solution.  It works, most of the time, but an administrator
is left with a choice between setting a long timeout and sacrificing
responsiveness to change, or setting a short timeout and (potentially)
sacrificing bandwidth.  Hashes can overcome this by forcing a cache refresh
exactly when it is needed.

I observe:

(a) in the scheme of things, I think a 20-byte hash is quite small --
smaller than most URLs.  If a given hash is used more than once in a
message, and associated just once with a URL, the result might actually be
shorter.   (I am assuming a different approach here to that in some of my
recent postings.)

(b) despite the extra size, the use of hashes *might* actually decrease
network bandwidth usage through reduced cache refresh.  I do believe it is
more likely to reduce extra round-trips (see next point).

(c) I don't believe that any of what is being proposed here excludes the
use of HTTP caches in the way you suggest.  It may actually improve their
effectiveness by allowing longer cache timeouts to be set and reducing the
cache refresh rate when feature sets do not change.  Using hashes, any
change is detected immediately, so cache response to change is not an issue.

>... It also occurs to me that
>using a hash as an abbreviation to mess up the design goal you
>mentioned at one point, of supporting indirection to a central
>corporate profile which might change with time.

If true, I believe this would be a serious drawback.  I would like to
understand why you think this happens.

#g

------------
Graham Klyne
([email-masked])

---

From: Bill Newman <[email-masked]>
Date: Thu, 4 Feb 1999 12:51:00 -0800 (PST)

Graham wrote, quoting me

> understand why you think this happens.

Perhaps I'm confused. After all, I certainly feel confused about some
of the hash-as-primary-identifier proposals.  However, it seems
inevitable to me that this would happen, given that you also wrote

> sacrificing bandwidth.  Hashes can overcome this by forcing a cache refresh
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> exactly when it is needed.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^

Imagine that I have a company policy,
  (& (paper-size=letter))
which hashes to 0x1234, and which is stored at
  <http://my-company/policy.conneg>
On my birthday, the US passes the Privacy Assurance Act to make it
completely illegal for me to use cryptography, and my corporate policy
changes to
  (& (paper-size=A4))
which hashes to 0x4422 (and is stored at the same URL). Since
I use CONNEG indirection to propagate changes in corporate policy,
I figure that I don't need to update the mobile devices, only
the contents of the resource stored at the URL.

As in my original message, I see two possible modes for using hashes
as abbreviations in content negotiation:
  (1) Every time one of my company's devices opens negotiation,
      it sends both the hash and the URL. In that case, after
      my birthday, my mobile devices keep sending in the hash 
      code 0x1234, and the URL. The servers could check the URL,
      but they don't, because they use the hash value to decide
      when a cache refresh is needed, and the hash value 
      hasn't change. So they continue to use paper-size=letter.
  (2) Every time one of my company's devices opens negotiation,
      it sends only the hash. Again, after the changeover, the
      devices still send the hash code 0x1234, and the servers
      fetch the old paper-size=letter properties from their
      caches and use that.
Given that you want to use hash values to force cache refresh
exactly when needed so that there don't need to be cache timeouts,
it seems to me that unless you modify the hash values stored in
every individual client device, you will end up with stale hash
values being used to retrieve stale cached values, not the true
indirection which is needed in order to centrally control policy.

  Bill Newman
  [email-masked]

---

From: Bill Newman <[email-masked]>
Date: Thu, 4 Feb 1999 12:58:24 -0800 (PST)

Graham wrote

> shorter.   (I am assuming a different approach here to that in some of my

I consider the two to be roughly the same size, because a
cryptographically secure hash is not compressible, while a URL
is. There's considerable uncertainty in the "roughly", since URLs vary
in size, and since there's some possibility of specifically choosing a
short name for a heavily-used URL (e.g. the description of
capabilities for a standard mobile device) in order to conserve
bandwidth.

I don't think that length is a real problem either for
URL-as-description or hash-as-description schemes. The factor-of-2
cost of sending both a URL and a hash on every single request would be
a drawback of any scheme that required that, though.

  Bill Newman
  [email-masked]

---

From: "Larry Masinter" <[email-masked]>
Date: Thu, 4 Feb 1999 15:49:05 PST

>              Since

This is an unreasonable application of CONNEG indirection.
The purpose of the syntax is to represent the capabilities
of a recipient. It sounds like you're trying to use indirection to
solve a very different problem than the one initially proposed,
which is to compactly represent what otherwise would be a large
capability expression.

It sounds like your goal is to reflect a centralized policy
maintained by a policy service, in a regime where the content server
obtains the policy from the centralized policy service but
the client does not!

If this is really what you want to do, then the hash isn't
needed at all, you just want the URL. However, it's a little
odd to posit that the client doesn't actually find out the
capabilities that it's requesting!

It would seem more reasonable, in your scenario, for the client
to retrieve the policy with whatever frequency the client
wants (from the central policy server) and then send the
hash of the actual policy it knows about.

It's unreasonable to expect that a mobile device would ask for
a set of capabilities without actually knowing what they are.

--------------

---

From: Bill Newman <[email-masked]>
Date: Thu, 4 Feb 1999 17:01:55 -0800 (PST)

Larry Masinter wrote, quoting me

> [etc.]

This isn't actually *my* goal, it's my understanding (and quite
possibly my mistaken understanding) of a scenario from Graham Klyne's
"Common feature sets (V2)" posting of February 1:

+ (S3) Providing an expression of corporate policy with respect to
+ media capabilities.  For example, an organization might declare a common
+ capability for incoming Internet faxes, so that detailed capabilities of
+ each internal system do not have to be published.

My story was only intended to show why I think this scenario is not
very consistent with the use of the hash both as an abbreviation for
the feature set and as notification when to flush the cache.  I wrote
the story in the first person, but I didn't intend any special
significance to that -- certainly not that I have a pressing need to
have a corporate fax policy. My primary interest is in saving
bandwidth on slow mobile links; if corporate policy can be expressed
by indirection, too, that's nice, but I don't consider it of primary
importance. Sorry about the confusion..

  Bill Newman
  [email-masked]