Subject: RE: PaceBasicAtomID - maybe we're done

From: "David Orchard" <[email-masked]>
Date: Tue, 3 Aug 2004 02:09:44 -0700

So let me understand this.  You don't want to use HTTP URIs because
Verisign totally and royally screwed up one domain.  So throw out the
identification scheme of the widest deployed distributed computer system
ever because of 1 bad policy judgement.  Seems like baby/bathwater or
nose/spiting face kind of argument.

Dave

> -----Original Message-----
> From: Mark Pilgrim [mailto:[email-masked]]
> Sent: Saturday, July 31, 2004 3:47 AM
> To: David Orchard
> Cc: Atom-Syntax
> Subject: Re: PaceBasicAtomID - maybe we're done
> 
> On Fri, 30 Jul 2004 16:39:30 -0700, David Orchard <[email-masked]>
> wrote:
> >
> > I don't understand this argument.  An HTTP URI is owned by the
domain
> authority.  It's as persistent as that authority decides.
> 
> You say that like it's a good thing.
> 
> http://textism.com/article/494
> 
> --
> Cheers,
> -Mark

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 03 Aug 2004 11:05:20 +0100

> nose/spiting face kind of argument.

I think the issue is to do with domain names per say; specifically 
how they are distributed and that thye seem to be more transient 
than we would like. It's not clear in who's favour or how relevant 
it is that it's a widely deployed scheme. (widest? really?)

cheers
Bill

---

From: Sam Ruby <[email-masked]>
Date: Tue, 03 Aug 2004 07:58:19 -0400

> nose/spiting face kind of argument.

You are wildly overstating this.

Yes, there are people who feel that HTTP is the one true protocol and 
that every URI should use the HTTP scheme, and URIs should be permanent 
and all content once issued should never unchange.

And, yes, there are people who feel that anything but HTTP should be 
used instead for ids as there is an identifiable risk that the URI could 
change, and this risk is to be avoided at all costs.

For now, let's ignore both extremes.

  = = =

Instead lets look at the middle ground.  There is a need for something 
called an id.  In many cases (particularly ones in which you are the 
registered owner of the domain) where HTTP can serve this purpose well. 
  In cases where you are not the registered owner (either because you 
represent a product of larger corporation which could be viewed as an 
asset to be sold), or because your portion of the URL space is made 
available by the graciousness of others, HTTP isn't quite so good a fit.

There are other factors involved.  Look at Georgic [1] "Too bad, I’m not 
changing the title".  What would happen if Tim *did* change the title? 
Well the title is in the URI... from a locator perspective, this is not 
a big problem as you can set up redirection.  From an identifier 
perspective, this represents a problem.

And one other factor is that a culture has grown up around URIs whereby 
it is expected that the comparision between the two is to be "fuzzy". 
Case may change in some portions of the URI but not others.  Various 
characters can be escaped or not, and some can be escaped in multiple ways.

All these factors combined represent a very real problem.  You can see 
the joy in Dare's response[2] to PaceAtomIDIsNewsML.  Nothing to date 
has required rfd:about nor rss:guid to be the permalink, but it has been 
so widely assumed that making it so was a best practice, enough so that 
Dare sees enough the problems with the current assumptions and 
specification text that he states that it is actively "harmful to a 
positive user experience".[3]

So... what's this middle ground that I'm alluding to?  Let people use 
the URI scheme that they want; simply state the contract by which the 
URIs when used as ids must conform to.  And since HTTP is widely known, 
document at least one other scheme so that people can be aware of the 
tradeoffs.

And constrain the id to ensure interoperation when fuzzy comparisons are 
done.  I predict that if this is done for ids, those that want to 
conflate identity with location will ensure that their permalinks are 
canonicalized too.  And that would not be a bad thing.

So... feel free to use your permalinks as identifiers.  I suspect that 
you understand the identity contract better than most.

- Sam Ruby

[1] http://www.tbray.org/ongoing/When/200x/2004/07/31/Georgic
[2] http://www.imc.org/atom-syntax/mail-archive/msg07856.html
[3] http://www.imc.org/atom-syntax/mail-archive/msg07862.html

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 03 Aug 2004 15:06:22 +0100

> document at least one other scheme so that people can be aware of the 

+1. Well said.

cheers
Bill

---

From: Tim Bray <[email-masked]>
Date: Tue, 03 Aug 2004 07:56:42 -0700

On Aug 3, 2004, at 4:58 AM, Sam Ruby wrote:

> There are other factors involved.  Look at Georgic [1] "Too bad, I’m 
> not changing the title".  What would happen if Tim *did* change the 
> title? Well the title is in the URI... from a locator perspective, 
> this is not a big problem as you can set up redirection.  From an 
> identifier perspective, this represents a problem.

No, at ongoing, the title of the article and its URI are 100% 
decoupled.  I change titles all the time without breaking URIs.  The 
fact that in that entry they're the same is a coincidence, look at some 
others.  The auto-generation of URIs from titles is a filthy 
web-hostile practice that should be stopped. -Tim

---

From: Sam Ruby <[email-masked]>
Date: Tue, 03 Aug 2004 11:16:24 -0400

Tim Bray wrote:

> others.  The auto-generation of URIs from titles is a filthy web-hostile 
> practice that should be stopped. -Tim

Perhaps a better way to put it is that they tend to be derived from the 
same common source - and that source is prone to error.

On my weblog, the title and link are theoretically 100% decoupled too - 
as long as you don't consider the desire to pick a URI which contains 
some of the same elements as the title.  In legal terms, I think this is 
referred to as an attractive nuisance[1].

-Sam Ruby

[1] http://insurance.cch.com/rupps/attractive-nuisance-doctrine.htm

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Tue, 03 Aug 2004 18:00:50 +0200

On Tue, 03 Aug 2004 07:58:19 -0400, Sam Ruby <[email-masked]>  
wrote:

> Let people use the URI scheme that they want; simply state the contract
> by which the URIs when used as ids must conform to.  And since HTTP is
> widely known, document at least one other scheme so that people can be
> aware of the tradeoffs.

I'm +1 on this, which is what I have tried to capture in  
PaceRecommendIdScheme[1].

____
[1] <url: http://intertwingly.net/wiki/pie/PaceRecommendIdScheme>

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»

---

From: Mark Pilgrim <[email-masked]>
Date: Tue, 3 Aug 2004 12:19:58 -0400

On Tue, 03 Aug 2004 07:56:42 -0700, Tim Bray <[email-masked]> wrote:
> The auto-generation of URIs from titles is a filthy

Are you suggesting that Atom should contain spec text to recommend a
URI structure for resources created by Atom-enabled applications? 
Does this have anything to do with Atom at all?  If not, please
consider a more appropriate venue for such passionate statements.

-- 
Cheers,
-Mark

---

From: Tim Bray <[email-masked]>
Date: Tue, 03 Aug 2004 09:31:47 -0700

> URI structure for resources created by Atom-enabled applications?

I think it would be entirely appropriate for one of our drafts to point 
out the advantages of stable URIs since, on the evidence, a lot of the 
blogging infrastructure is unaware of them.  A pointer to 
http://www.w3.org/TR/webarch/#URI-persistence would probably suffice. 
-Tim

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 03 Aug 2004 17:40:58 +0100

> practice that should be stopped. -Tim

Nonetheless, a marked improvement from "Cool URIs don't contain 
autoincrementing  (probably from the database) integer keys" :)

cheers
Bill

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Tue, 03 Aug 2004 19:21:36 +0200

> http://www.w3.org/TR/webarch/#URI-persistence would probably suffice.

Reference added to PaceRecommendIdScheme.

---

From: Dave Pawson <[email-masked]>
Date: Tue, 03 Aug 2004 19:12:52 +0100

> http://www.w3.org/TR/webarch/#URI-persistence would probably suffice. 

+1, with rationale please?
  How to hack it if you do have a domain (whatever Tim means by
separating a title from its uri)
  How to hack it if you don't hold a domain name.

And why its important/
  What happens if you ignore this bit
  etc.

I still haven't heard a compelling rationale for 'making my ID's
different from yours'

As for testing it? Forget it.
  24 hour challenge.
   Here's a URI (you make it up). tell me if its unique in TimBL's net?
   I guess even TAG would scratch their heads over that.

-- 
Regards DaveP.
XSLT&Docbook  FAQ
http://www.dpawson.co.uk/xsl

---

From: Ken MacLeod <[email-masked]>
Date: 03 Aug 2004 14:17:15 -0500

Dave Pawson <[email-masked]> writes:

> > I think it would be entirely appropriate for one of our drafts to
> > point out the advantages of stable URIs since, on the evidence, a
> > lot of the blogging infrastructure is unaware of them.  A pointer
> > to http://www.w3.org/TR/webarch/#URI-persistence would probably
> > suffice.

>   What happens if you ignore this bit

This is important.  I suggested some test case for this for the
publishing side[1], but there should also be spec text and tests for
the consumer side as well.

> I still haven't heard a compelling rationale for 'making my ID's

1) republishers will aggregate entries from multiple sources into
   common feeds.  It's easier to distinguish entries based on their
   unique identifier than the tuple of the origin feed and a "local"
   entry identifier.  Essentially, that's still a global identifier.

2) in the near future (maybe not Atom 1.0, but there's been proposals
   for it) entries will make references to entries from other sites.
   Those references will be made based on the URI.  If two sites don't
   have unique IDs for their entries, the references will be garbled.

>    I guess even TAG would scratch their heads over that.

You're correct.  We can only state the properties for uniqueness,
suggest best practices for creating them, and "test in the large" for
collisions, and hope for the best.  Without an alternate proposal on
the table to compare it to, I don't see that as a fatal flaw.

  -- Ken

[1] http://imc.org/atom-syntax/mail-archive/msg07923.html