Subject: PaceBasicAtomID - maybe we're done

From: Tim Bray <[email-masked]>
Date: Wed, 28 Jul 2004 16:43:47 -0700

I just went back and revisited a *lot* of email and Wiki text on the 
subject of atom:id, and I think that a fairly clear rough consensus 
emerges from that.  I've published what I think it is at 
http://intertwingly.net/wiki/pie/PaceBasicAtomID

Bearing in mind the amount of work we've already put into this, and the 
fact that debate on this subject is apt to create permathreads, please 
seriously consider, if you think you could live with this language, 
resisting the urge to launch a debate about one phrase or another.

  -Tim

---

From: Ken MacLeod <[email-masked]>
Date: 28 Jul 2004 19:00:32 -0500

> http://intertwingly.net/wiki/pie/PaceBasicAtomID

+1.  I very much like the wording on this one.

  -- Ken

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 29 Jul 2004 02:27:06 +0200

> http://intertwingly.net/wiki/pie/PaceBasicAtomID

+0.05. I don't have much faith in that readers of the Atom specification  
will be able to pick a good URI scheme themselves, and thus would like the  
specification to explicitly name a scheme that conforms to all of  
atom:id's requirements.

I like PaceRecommendIdScheme[1] better.

____
[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: James M Snell <[email-masked]>
Date: Wed, 28 Jul 2004 18:29:55 -0600

+1 this works for me

- James M Snell
  [email-masked]
  http://www.ibm.com
  (877) 511-5082 / Office
  930-1979 / Tie Line

Tim Bray <[email-masked]> 
Sent by: [email-masked]
07/28/2004 04:43 PM

To
Atom Syntax <[email-masked]>
cc

Subject
PaceBasicAtomID - maybe we're done

  -Tim

---

From: Walter Underwood <[email-masked]>
Date: Wed, 28 Jul 2004 17:30:19 -0700

Is there a recommendation for how to generate feeds from databases
that cannot provide repeatable unique IDs? Specifically, people are
building RSS feeds from search results. That will not be possible
with Atom. Search indexes do not contain unique IDs.

Here is one example:

  <http://weblog.infoworld.com/udell/2003/08/01.html>

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: Sam Ruby <[email-masked]>
Date: Wed, 28 Jul 2004 20:44:36 -0400

> resisting the urge to launch a debate about one phrase or another.

IMHO, this does not fully solve the original problem that Dare was 
trying to express... I see this as primarily because the discussion 
wandered off into permathread land and what Dare was trying to express 
was lost.

Dare touched on the concern a bit here:

   http://www.imc.org/atom-syntax/mail-archive/msg07870.html

And then more fully explained it here:

   http://www.imc.org/atom-syntax/mail-archive/msg07877.html

I believe that what Dare really wants captured in the spec is what is 
expressed in tutorial terms here:

   http://diveintomark.org/archives/2004/05/28/howto-atom-id#multiple

Note: this one section has nothing to do with the scheme chosen.  And 
perhaps an example would help... take a look at the guids chosen in the 
following feed:

   http://feedster.com/search.php?q=atom&type=rss

Of course, Dare could tell me that I got all this wrong.

- Sam Ruby

---

From: Tim Bray <[email-masked]>
Date: Wed, 28 Jul 2004 17:51:06 -0700

> wandered off into permathread land and what Dare was trying to express 

OK... although the language in the Pace about dupe detection is pretty 
well straight from Dare.  So concretely, you're suggesting that we beef 
up the draft with some language explaining the use-case of the same 
entry in multiple different feeds. -Tim

---

From: Elias Torres <[email-masked]>
Date: Wed, 28 Jul 2004 20:55:33 -0400

+0

I like the wording also, but if we vote yes on this pace we are
agreeing on giving up forever in making atom:id useful to most
applications because:

- Applications will not be able to see an atom:id and know it's one
- atom:ids will not be comparable in any way, except for strcmp()
- Versioning will be almost impossible to deduce from atom:id
- can't think of any more at this moment.

Tim, you are right that given the amount of time we gave this issue, I
think we should not revisit everything again, but first, I see no
major argument against picking a scheme, except for "best practices"
to use a generic URI on things that don't even relate to identifiers
and the fact that some people just don't like URNs, but besides that I
have not heard a real show stopper if we were to use ONE scheme.

I don't think any wording can satisfy what some of us are asking. We
want a format that people can count on when looking an ID, this needs
to be identifiable, comparable, immutable, universal, dereferencable
and include versioning and the current pace does not reflect that. If
no one else speaks up, then let's leave it as is and move on. Else I
would suggest you compromise with us unless again, someone finds a
real problem with restricting.

Regards,

Elias Torres

---

From: Ken MacLeod <[email-masked]>
Date: 28 Jul 2004 20:02:45 -0500

Tim Bray <[email-masked]> writes:

> > trying to express... I see this as primarily because the
> > discussion wandered off into permathread land and what Dare was
> > trying to express was lost.
> 
> OK... although the language in the Pace about dupe detection is
> pretty well straight from Dare.  So concretely, you're suggesting
> that we beef up the draft with some language explaining the use-case
> of the same entry in multiple different feeds.

I think the messages that Sam points to are ones where Dare is
discussing the symptoms of IDs changing (which isn't inherent to the
scheme used), where the Pace refers to a message from Dare that
addresses the root cause: that publishers don't do anything to prevent
the IDs from changing, regardless of scheme used.

Adding language explaining the "multiple places" use-case is good.

Here's the test cases I suggested, which includes the "multiple
places" assertion that can be added to the spec text:

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

  -- Ken

---

From: Elias Torres <[email-masked]>
Date: Wed, 28 Jul 2004 21:19:12 -0400

Well it depends on what we decide ID means. But if the ID should be
mapped to the content then something like that would work:

urn:aURN_NS:feedster.org:search:atom:DATETIME

That would make unique and the contents of that entry should never
change, since it was a t the momment in time.

If the ID is a moving target, meaning that whatever it represents can
be always changing then:

urn:aURN_NS:feedster.org:search:atom would suffice. But I would
disagree. An atom:id should be unique and map always to the same
content it was generated for in the first place.

Elias Torres

---

From: Bill de hÓra <[email-masked]>
Date: Thu, 29 Jul 2004 02:24:35 +0100

> resisting the urge to launch a debate about one phrase or another.

+0.

Here's why. Regarding the text, I could definitely live without the 
retrieval discussion, as I'm not sure we're not confusing 
correlation with cause - the problem is not that http: URLs have 
retrieval semantics, but that http: URLs (which happen to have 
retrieval semantics) are more transient in the wild than many of us 
would wish.

Good job, thanks for doing this.

cheers
Bill

---

From: Tim Bray <[email-masked]>
Date: Wed, 28 Jul 2004 19:37:56 -0700

On Jul 28, 2004, at 5:55 PM, Elias Torres wrote:

> first, I see no
> major argument against picking a scheme,

I do.  Having reviewed all the arguments and re-read the suggestions 
and proposals, I think it is quite unlikely that this group will 
achieve consensus on any one scheme.

Of course, you can prove me wrong.  Pick a scheme, publish a proposal, 
and gather consensus behind it.  This has been attempted a couple of 
times and so far it hasn't worked.  But if it does, of course it would 
go in the draft. -Tim

---

From: Graham <[email-masked]>
Date: Wed, 28 Jul 2004 22:53:04 -0400

> http://intertwingly.net/wiki/pie/PaceBasicAtomID

You haven't actually mentioned whether it's a URI or not, and also 
[therefore] whether relative values are allowed.

(Also the idea that it's meant to be applied to different versions of 
the same entry isn't conveyed very well - some conceptual definition of 
an "entry" elsewhere might do that though)

Graham

---

From: Ken MacLeod <[email-masked]>
Date: 28 Jul 2004 22:16:16 -0500

Graham <[email-masked]> writes:

> > I just went back and revisited a *lot* of email and Wiki text on
> > the subject of atom:id, and I think that a fairly clear rough
> > consensus emerges from that.  I've published what I think it is at

D'oh!  I missed that!

> (Also the idea that it's meant to be applied to different versions
> of the same entry isn't conveyed very well - some conceptual
> definition of an "entry" elsewhere might do that though)

Asbjørn, Arve, and I have been discussing different version schemes
with respect to the atom:entry identifier.  I think we have a proposal
ready to be put into a Pace that has minimal impact on the current
semantics and usage.

The gist is that the atom:entry/atom:id identifies the entry as whole
(all of its versions).  Each version may have a separate identifier
that identifies the version, located elsewhere in a non-core element.
Consumers should use the most current version of an entry from a feed
or other source with the same atom:id, where "current" will be based
on the outcome of the date discussion.

  -- Ken

---

From: Mark Baker <[email-masked]>
Date: Wed, 28 Jul 2004 23:34:56 -0400

I have to give it a -1 primarily for the "SHOULD consider another URI
scheme" statement, since that's strongly recommending what I consider to
be bad practice; having important identifiers which aren't
dereferencable.  I'd be content with "MAY".

FWIW, I looked up what the TAG had to say on this subject, and found;

"A URI owner SHOULD provide representations of the identified resource."
 -- http://www.w3.org/TR/webarch/#pr-describe-resource

Mark.

---

From: Tim Bray <[email-masked]>
Date: Wed, 28 Jul 2004 20:40:49 -0700

> [therefore] whether relative values are allowed.

Oops, thinko, cut-&-paste error.  Heh, everyone else was so used to 
reading it that they missed the absence, as I did.  Off to fix it.  As 
for whether it's relative, I think we're still arguing about that.  
-Tim

---

From: Eric Scheid <[email-masked]>
Date: Thu, 29 Jul 2004 15:13:17 +1000

> on the outcome of the date discussion.

+1

this fits well with the idea "feed of versions of an entry" too

e.

---

From: Sam Ruby <[email-masked]>
Date: Thu, 29 Jul 2004 01:27:31 -0400

Tim Bray wrote:
> well straight from Dare.

Yes... after Dare was lead into the http vs non-http URI scheme 
discussion.  So I claim that you only captured a portion of his original 
concern.

> So concretely, you're suggesting that we beef 

Yes.

- Sam Ruby

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 29 Jul 2004 08:35:14 +0200

On Wed, 28 Jul 2004 20:55:33 -0400, Elias Torres <[email-masked]> wrote:

> and include versioning and the current pace does not reflect that.

+1. I think, however, PaceRecommendIdScheme[1], reflects this, and at the  
same time allows for atom:id to be an HTTP URI. Thus, it doesn't leave  
anyone out in the cold, but for Bob and his friends, it explicitly names a  
scheme.

____

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 29 Jul 2004 08:46:49 +0200

> dereferencable.  I'd be content with "MAY".

In any case, you cannot expect atom:id to be dereferencable. Ever. So  
what's the real point of it being so in perhaps 33% of the cases? (Or  
more. Or less.)

---

From: Mark Baker <[email-masked]>
Date: Thu, 29 Jul 2004 09:47:47 -0400

> what's the real point of it being so in perhaps 33% of the cases? (Or  

The point is that there are those who wish to *demonstrate* that their
identifiers are persistent, and making them dereferencable is the lowest
cost, pervasively deployed means that exists for doing that.

Mark.

---

From: Mark Pilgrim <[email-masked]>
Date: Thu, 29 Jul 2004 10:12:19 -0400

> cost, pervasively deployed means that exists for doing that.

I'm not sure how making an ID dereferenceable demonstrates its persistence.

http://www.hoopla.com/500/paddock/00000002.html

-- 
Cheers,
-Mark

---

From: Martin Duerst <[email-masked]>
Date: Thu, 29 Jul 2004 17:26:57 +0900

>have not heard a real show stopper if we were to use ONE scheme.

Independence of different specs, flexibility for future developments,
and the possibility for people to choose something that suits their
needs don't count as arguments for you?

Regards,    Martin.

---

From: Mark Baker <[email-masked]>
Date: Thu, 29 Jul 2004 11:04:44 -0400

> http://www.hoopla.com/500/paddock/00000002.html

Picky, picky!

Of course, making the URI dereferencable isn't a sufficient condition
for persistence.  You also need to ensure that what it dereferences to
represents the resource it identifies.

Mark.

---

From: Mark Pilgrim <[email-masked]>
Date: Thu, 29 Jul 2004 11:11:01 -0400

> represents the resource it identifies.

It used to.

http://www.textism.com/article/494

-- 
Cheers,
-Mark

---

From: Mark Baker <[email-masked]>
Date: Thu, 29 Jul 2004 11:28:20 -0400

> http://www.textism.com/article/494

Sh*t happens.  Luckily, it doesn't happen very often.  For every example
like that, there's thousands of others who've had no problems.

I don't believe that's sufficient evidence to warrant SHOULD-strength
language against using dereferencable atom:ids.

Mark.

---

From: Elias Torres <[email-masked]>
Date: Thu, 29 Jul 2004 11:34:14 -0400

Very important issues you bring up. But let's look at an anology:

In databases we have primary keys, why are there different types of
primary keys? integers, guids, etc. Why not a VARCHAR(2048)? That for
sure will suit everone's needs. We're talking about an optional
element (atom:id) in a feed. If it doesn't suit "your" personal needs,
don't use it. What I'm try to suggest is that we find a scheme that
suits "80%" of the world, so those 80% can do really useful stuff with
those IDs.

If you don't like NewsML, tag, publicid, LSID don't use the field, its
optional. Why does one person want to impose on others what they
personally want to use for an id? Remember the id is only an id to the
public, not to their private systems. If you want to use an HTTP
URI/URL, hash it and make it urn:lsid:martinduerst:HASH:1 for us who
need something consistent. Internally or might as well through an
extension add your HTTP URI (which we could get already from the
atom:link elements, anyways.

If this is not reason enough and people feel I'm wasting the WG times,
I'll desist from pushing this scheme and we can move on, but I'm still
not technically convinced I'm wrong.

Regards,

Elias Torres

---

From: Robert Sayre <[email-masked]>
Date: Thu, 29 Jul 2004 11:43:28 -0400

> language against using dereferencable atom:ids.

The Pace says

"...implementors SHOULD consider using another URI scheme ... which does 
not imply information-retrieval semantics."

While that wording is certainly diplomatic, I'm not sure it's a good use 
of RFC2119 terms.

Does it mean "SHOULD adopt"?

Robert Sayre

---

From: Antone Roundy <[email-masked]>
Date: Thu, 29 Jul 2004 10:19:09 -0600

On Thursday, July 29, 2004, at 09:34  AM, Elias Torres wrote:
> sure will suit everone's needs.
I'm either not following your analogy, or I disagree. VARCHAR(2048) 
would NOT be suitable for everyone's needs. First, it would cause 
sortability issues for people who want to do numeric sorts on their 
primary key. Does record 20 sort before or after record 100? In a text 
sort, it sorts after. Second, doing joins on VARCHAR(2048) would 
require a tremendous amount of memory--at least on some systems.  
Third, VARCHAR(2048) would be impossible on any system that uses a 
single byte to indicate the length of the data.  There are plenty of 
reasons of various kinds for using different kinds of primary keys. 
Relating that to atom:id, are we confident that some particular scheme 
for generating ID's will work fine for virtually everyone?  Though on 
its face it may seems like a simple question, like VARCHAR(2048), there 
may be drawbacks that aren't immediately apparent.

> We're talking about an optional
Feed id's are optional, but entry id's are mandatory, so we'd best not 
pick a scheme that's too burdensome or unsuitable for a large number of 
people.

---

From: Mark Pilgrim <[email-masked]>
Date: Thu, 29 Jul 2004 12:22:09 -0400

> like that, there's thousands of others who've had no problems.

...Yet.

Look, so far I've heard many outrageous claims from the "http:// URIs
to rule them all" camp.  That they're dereferenceable.  (Sometimes,
but there's no way to tell without trying.)  That they're "supported"
by applications that are installed on my computer.  (Only if they're
dereferenceable.)  That they're persistent.  (Not all the time, and
it's not always your fault.)  That they're persistent *because*
they're dereferenceable.  (Provably false.)

I think the major obstacle to our understanding each other is the
first one.  Sometimes, http:// URIs are dereferenceable.  Sometimes
they're not.  You point at that as if it were a feature and say,
"Look, they're a floor wax *and* a dessert topping, isn't that great?"
 And I say, "Um, no, that sucks."  Anything else we say to each other
is really beside the point; we're already talking past each other.

If you want to use "http://" URIs as IDs, I think Atom should let you.
 I don't want to, and I think Atom should let me too.  Stating the
requirements (globally unique, unchanging even under all the
conditions which Ken listed out) is enough; mandating or even
recommending one scheme over another does not advance our goals.

-- 
Cheers,
-Mark

---

From: Mark Baker <[email-masked]>
Date: Thu, 29 Jul 2004 12:55:26 -0400

On Thu, Jul 29, 2004 at 12:22:09PM -0400, Mark Pilgrim wrote:
>  I don't want to, and I think Atom should let me too.

Great, me too!  I want equal treatment for all schemes.  And to me, that
means not recommending for or against a scheme just because it happens
to be associated with an application protocol, as the pace currently
does by using "SHOULD" against the use of http URIs.  Hence my
suggestion to change it to "MAY".

So, I think that brings us full-circle.  I don't expect I'll have
anything more to say on this subject.

Cheers,

Mark.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 29 Jul 2004 18:53:21 +0200

On Thu, 29 Jul 2004 11:28:20 -0400, Mark Baker <[email-masked]> wrote:

> Sh*t happens.

Well, it proves that dereferencability of ID breaks either the  
dereferencability or the ID itself when something moves. And both entries  
and feedsw will move. All the time. Changing the ID to reflect the new  
location of the entry is a critical break of the specification (and of any  
idea of persistent ID's), and not changing it breaks dereferencibility.

How is dereferencable ID's good, when it only takes one relocation of an  
entry to break everything?

> Luckily, it doesn't happen very often.

Uhm. Okay? Entries doesn't move often? Not as often as they don't move,  
but that's not a part of the equation either. Proof that entries move,  
which they do, should be enough to discourage dereferencable ID's.

> For every example like that, there's thousands of others who've had
> no problems.

That only proves that these thousands of users never have moved their  
entries. Everyone that ever moves anything will eventually get themselves  
into serious trouble. They can of course do HTTP redirects from the old  
location to the new one, but that requires the user to have 100% control  
over the old location for the lifetime of the ID of the entry. And that's  
not feasible. For anyone.

> language against using dereferencable atom:ids.

I disagree.

---

From: James M Snell <[email-masked]>
Date: Thu, 29 Jul 2004 11:01:03 -0600

> recommending one scheme over another does not advance our goals.

+1 on not picking one scheme.  +1 on stating that ID's may be ANY URI 
syntax that meets the requirements of being unique and unchanging. 

- James M Snell
  [email-masked]
  http://www.ibm.com
  (877) 511-5082 / Office
  930-1979 / Tie Line

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 29 Jul 2004 13:45:37 -0700 (PDT)

+1 

I'd like to see something akin to Ken's tests in the
Atom specification although written in a more scenario
oriented and user friendly manner. 

Besides that I think the language in Tim's draft is
fine. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #25
No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot.

		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail

---

From: Eric Scheid <[email-masked]>
Date: Fri, 30 Jul 2004 11:01:35 +1000

> While that wording is certainly diplomatic, I'm not sure it's a good use

Disagree. SHOULD is used for situations where you MAY, but only if you think
really carefully about what you are doing lest you break something; (or
situations where you will break something so you better be darn sure).

e.

---

From: Robert Sayre <[email-masked]>
Date: Thu, 29 Jul 2004 21:22:04 -0400

> situations where you will break something so you better be darn sure).

What does the Pace say implementors SHOULD do?

Robert Sayre

---

From: Martin Duerst <[email-masked]>
Date: Fri, 30 Jul 2004 13:01:23 +0900

>like that, there's thousands of others who've had no problems.

And I very much hope that this one gets figured out in a way that
makes it clear to all the registries and registrars and whoever
else involved that that's not something that's allowed to happen.

>language against using dereferencable atom:ids.

And it's possible to construct similar problems with other schemes.
Many id-only schemes rely on DNS. So if there is a dispute about
who owns a DNS name at a certain time, both sides may be minting
ids from this name. Some other id-only schemes rely on explicit
assignement, and of course there it's also possible that the
assignement authority messes up things.

And of course with any kind of scheme, it's always possible that
somebody completely unrelated attacks you by using exactly the
same ids that you use. In that case, the resolvability may provide
an easy way for people to test who really is in controll (assuming
that IP routing isn't messed up at the same time).

Regards,    Martin.

---

From: Martin Duerst <[email-masked]>
Date: Fri, 30 Jul 2004 14:45:24 +0900

>sure will suit everone's needs.

Well, this is a very nice analogy, but it's probably backwards.
What we are asking is that everybody can select the scheme they
want, the scheme they think they understand best, and know best
how to create and maintain ids with a high chance of persistency.
Being able to chose different schemes is like being able to
chose different primary keys.

>personally want to use for an id?

I have never said that everybody should use http:, and I haven't
seen anybody else on this list proposing that http: should be the
only scheme that should be allowed, or even the recommended one.
So I'm not sure whom you are criticising with the sentence above.

Also, people have already expressed their likes for NewsML,
tag, lsid, and so on, and your proposal to limit things to
a single scheme would mean that most of these people couldn't
use their favorite scheme.

>Remember the id is only an id to the
>need something consistent.

If I think that on the system I'm setting up, I can guarantee
persistence of http: as well or better than persistence of some
other scheme, why do you think you can tell me that it will
not be consistent? How do you know? Why do you think that you
know better than me? Why do you think you need to tell me
(and others) what will work best for me?

Regards,   Martin.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 31 Jul 2004 01:04:43 +0200

On Fri, 30 Jul 2004 14:45:24 +0900, Martin Duerst <[email-masked]> wrote:

> not be consistent?

HTTP URI's are by default transient in that they aren't owned by an  
entity, but just rented. HTTP URI's would only be stable identifiers if  
they could just be bought once by one entity, and if the exipry of that  
entity also expired the URI.

That doesn't mean that an HTTP URI can be sufficiently stable and unique,  
though. An HTTP URI containing the date a given resource was issued would  
most certainly be glboally unique at the time of creation, and almost  
certainly be universally unique for the future, even if the domain would  
be taken over by another entity.

The problem with HTTP URI's in this respect is not what they're not  
capable of providing, but what they're capable of not providing. A NewsML  
URI is actually invalid if it doesn't contain a date for when a resource  
was issued at a given internet domain.

This is not the case for HTTP URI's. Both  
'http://example.com/2004/07/31/23212.html' and  
'http://example.com/23212.html' are perfectly valid HTTP URI's. The former  
is very likely to be universally unique, the latter is very unlikely to  
be. The latter URI would be impossible to express in a NewsML URN.

---

From: Bill de hÓra <[email-masked]>
Date: Sat, 31 Jul 2004 17:37:36 +0100

Asbjørn Ulsberg wrote:

> 'http://example.com/23212.html' are perfectly valid HTTP URI's. The 
> former  is very likely to be universally unique, the latter is very 
> unlikely to  be.

Nit: you can't make that claim by looking at URIs alone; you have to 
know something about policy and algorithms underpinning their 
generation.

cheers
Bill