W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1997

RE: Globally unique e-tags, if-match on content-ID, etc.

From: Phillip Hallam-Baker <hallam@ai.mit.edu>
Date: Sun, 14 Sep 1997 22:25:38 -0400
Message-Id: <01BCC15D.229412A0.hallam@ai.mit.edu>
To: 'Larry Masinter' <masinter@parc.xerox.com>, "http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com" <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4399
On Saturday, September 13, 1997 10:57 AM, Larry Masinter [SMTP:masinter@parc.xerox.com] wrote:
> One of the technical issues that came up in recent discussions
> about "Push" technology is the usefulness, for some applications,
> for a globally unique content-ID. While "content-ID" might be
> a useful header in a response, there's no corresponding request
> header, since the etag is only guaranteed unique relative to 
> the given URL.

I've been thinking about this problem for a week and I don't think 
GUIDs raise any HTTP issues but there is an opportunity to make
steps towards what the URN group thinks they are doing.

Many of the characteristics desired for URNs can be achieved by 
embedding a globally unique ID into each document. This could be
simply a Microsoft GUID and I'm told there is already a de-facto
GUID scheme. 

If search engines like Alta-Vista recorded GUIDs as resource
identifiers they could provide a referal service. So if a link breaks 
they help you to fix it by giving a list of locations where the same
page be found today. They also get to slap an advert on the referal
page so the business model for the infrastructure works. 

No extension to HTTP is needed for this, simply present the server
with a search URL giving the broken URL. The server then searches
its database to find a match...

I would personally prefer a much more complex representation 
however, a base64 encoding means that a GUID need take 
no more than 32 characters. This could then be embedded in
HTML documents as 'hardening'. These would attach to the
urn attribute of the <A> tag and allow a much more robust method
of link repair that would work even for relative links in a document
that has been moved from its original location.

There are more issues to consider of course. For example a
CD of Pavarotti performing in Motzart's Don Govani would need
unique ids for the CD itself (ISBN), the performer, composer
and work at the very least.

This does not belong in the HTTP group but it is not what the current
URN working group is working on. Anyone want to join an ad-hoc
working group and finish off the spec? I don't think its a huge problem
to implement and the corner cases I've been made aware of so far
look like they have reasonable solutions. (because any URL that bears
a one-to-one relationship to a GUID is also unique one can incorporate
all other URN schemes via an SHA hash...)

Received on Sunday, 14 September 1997 19:29:36 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:21 UTC