Subject: Re: Propose partial consensus on dates

From: "Arve Bersvendsen" <[email-masked]>
Date: Thu, 22 Jul 2004 12:03:26 +0200

* Bob Wyman:

>	Your database key would have to be a compound key built from
> "atom:id + atom:updated". Of course, to be really precise you should make
> the key "atom:id + atom:modified", but, it doesn't look like folk are
> supporting atom:modified...

Replying twice, because I need to explain why "modified" is terrible for
recognizing revisions:

1. Joe Blogger writes an entry in his BlogToolGT.  BlogToolGT has a complete
revisioning mechanism, which only not does let him issue new revisions, it
also lets him roll back to previous versions. This entry is last modified on
2005-01-01T00:00:01Z

2. Joe Blogger writes a new entry.

3. Joe Blogger rewrites his entire entry (a Major revision), which is last
modified on 2005-01-01T12:00:01Z

4. Jane Bloggers aggregator pulls Joe Bloggers feed and sees the entry for
the first time.

5. Joe Blogger decides that his Major revision was no good after all, and he
performs a rollback to the 2005-01-01T00:00:01Z-version. In essence: the
revision he rolls back to hasn't been modified since that date, and that's
what goes into "modified".

6. Jane Blogger pulls Joes feed again. Her aggregator now has two entries
with the same id. One written right after midnight, and one written at noon. 

7. At this time, Jane starts reading her newsfeeds. Which of Joes entries is
Jane going to see?

---

From: Elias Torres <[email-masked]>
Date: Thu, 22 Jul 2004 08:32:09 -0400

I'm glad people are bringing up this point relating to ids. I have a
proposition maybe we can change the subject of this email.

Currently the norm has been to use tag URIs like this:

tag:www.virtuelvis.com,2003:1192312312

Here at IBM, my dept was one of the creators of a new standard called
LSID. (LS) we still thinking of it's meaning, but it started as "Life
Sciences", but ID is for identifier :-) This standard was started
because there was a need for a naming specification of biological
entities, but we are finding its applications to be broader than that.
Let me show you an example LSID.

urn:lsid:yourdomain.com:namespace:uniqueID[:version]

urn:lsid:www.virtuelvis.com:myblog-entries-2003:1192312312
urn:lsid:www.virtuelvis.com:myblog-entries-2003:1192312312:1
urn:lsid:www.virtuelvis.com:myblog-entries-2003:1192312312:3

This scheme has many advantages:

- We've registered lsid for resolution (I'll double check, opposed to tag). 
- There's standard scheme for the URI, which is much more unclear of
the usage for tag URIs.
- This LSID urls are resolvable, mainly by pure DNS lookups. 
- NS, UNIQUEID and VERSION are completely freeform for anyone to use
anyway they want to. You may use versions as 1.1, 1.2 or AA, BB, etc.
for example.

The most important function of the spec is that from now til eternity
when you resolve a LSID and fetch the data behind it, you will ALWAYS
get returned the same exact bytes. That's was the standard was meant
to address, because when you go to an HTTP url, you always end up
getting different data. If you pass the optional version attribute you
may get that, if you don't it's up to the resolving authority to
decide whether returning the first or the latest (need to double check
this). Anyways, I'm extremely interested in people being aware of this
because I think it will of great value to Atom spec.

Remember, you are only using ID tags as a string, if we recommend it
we don't have to implement anything related to LSID, it's just a way
to guide people creating a URI that's consistent and that has been
carefully thought out. It's completely optional if people wanted to
host a resolver to LSID-aware apps could resolve their posts that way
as well.

Let me know what you think,

Elias Torres (eliast at us.ibm.com)

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 22 Jul 2004 07:59:06 -0700 (PDT)

--- Arve Bersvendsen <[email-masked]> wrote:
> performs a rollback to the
> 2005-01-01T00:00:01Z-version. In essence: the

That sounds like a pretty dumb tool. Too external
entities the entry has been modified. Ignore feeds and
imagine you were visiting a website. If the first
entry a user sees on the website was the one written
at midnight and then they show up a few days later
only to see a different one, do you really think it
makes sense to tell the user the last modified date of
the entry was BEFORE the last modified date they saw
previously even though the entry has obviously been
modified AFTER that date from the user's perspective? 

=====
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: Tim Bray <[email-masked]>
Date: Thu, 22 Jul 2004 09:56:21 -0700

> tag:www.virtuelvis.com,2003:1192312312

On which planet?

> urn:lsid:www.virtuelvis.com:myblog-entries-2003:1192312312
...
> - This LSID urls are resolvable, mainly by pure DNS lookups.

Not by any software on my computer.

> getting different data.

There seems to a recurrent persistent mania that infects otherwise 
reasonable people with the belief that by registering a URI scheme they 
are going to impose changes on fundamental human nature or management 
practice.  Whether nor not the contents of whatever a URI points at 
change is a matter of policy and management, not of technology.

So... you have repealed the second law of thermodynamics and the basic 
propensity of humans to screw up such that you can be sure that the 
bytes will never change?  I congratulate you.  I know using "http:..." 
is nowhere near as glamorous as inventing your own coolio neato URI 
scheme, but you know, if you have a management policy that the 
representation of some resource will never change, and if you enforce 
that policy, then it doesn't make a damn bit of difference what the 
characters before the colon are.  Oh, unless of course you actually 
want to use the URI to retrieve data or bookmark it or expose it to a 
search engine or any of the other things that "http:" URIs are useful 
for.  -Tim

- Tim Bray, Director of Web Technologies, Sun Microsystems
   +1-877-305-0889 Sun ext. 60561
   http://www.tbray.org/ongoing/  AIM: MarkupPedant

---

From: Tim Bray <[email-masked]>
Date: Thu, 22 Jul 2004 12:50:53 -0700

>> tag:www.virtuelvis.com,2003:1192312312

Sigh, that was rude, sorry.  Also, it was entirely off-topic for Atom.  
-Tim

---

From: Eric Scheid <[email-masked]>
Date: Fri, 23 Jul 2004 09:44:03 +1000

> modified AFTER that date from the user's perspective?

I'm seeing a use case for almost that exact behaviour ... wikis are getting
hammered by wiki spam, and by their nature pretty much always will be. Some
wikis already have built in capability for "one click revert", and I'm
working on some code for my wiki to do exactly that. In this situation I
would want to re-set the updated date back to what it was, but set the
modified date to now().

How would RSS Bandit react to that?

e.

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 22 Jul 2004 17:47:57 -0700 (PDT)

> How would RSS Bandit react to that?

RSS Bandit always replaces the stored content with the
most recent content from the RSS feed. However it
doesn't indicate to the user that any changes have
occured to the feed. 

If Atom shipped with date fields to indicate every
time a typo was fixed in the content I still don't
think RSS Bandit would do anything different. At best
I'd consider moving to a model like NetNewsWire that
shows the differences using an HTML diff. 

=====

__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

---

From: Elias Torres <[email-masked]>
Date: Thu, 22 Jul 2004 21:53:16 -0400

Tim,

How would you suggest people use IDs in Atom? What about the case when
multiple feeds display the same entry (categories, site-aggregators,
etc) and multiple versions of the same entry as well?

I have a personal blog but I've already switched from MT to Wordpress
once and I already have to deal with all of the headaches of creating
enough Rewrite rules to support my old and future urls. I'm not sure
how many applications I will have to go through by the time I'm >= 50.
But if I start using lsid for example, my entries would be as follow:

urn:lsid:torrez.us:blog:4871231:2.4

First of all, this is a unique identifier to a specific entry and I
have the option to install a resolver (which could be self-hosted or a
service in the future) that I can adjust to fetch the data from
whatever CMS system I could be using at the time.

Again, all I proposed was a suggestion for URI scheme (purely as a
string) in the ID attribute, which at this point our spec does not
give much to people except for another "scheme" to come up with when
setting up their blog: an ID and a URI.

I guess with blogs maybe we won't have as many versions per entry, but
I sure think we will in Wikis. Wikis already have a way for pointing
to the specific version of a page. Will we tell them to add several
link tags that we will then have to process to figure out what entry
this page is a version of according to Atom?

Anyways, I guess I must have struck a nerve or something, but I'll be
more careful when suggesting anything from now on. Instead I'll let
people discuss more important things like "display" date and so forth.

Elias

---

From: Sam Ruby <[email-masked]>
Date: Fri, 23 Jul 2004 07:38:19 -0400

> would want to re-set the updated date back to what it was, but set the

Clearly we have to nail down some definitions, because my initial 
instincts would have been the reverse of yours.

As I see it,

<updated> == "hey, if you last fetched this feed before this date, you 
probably have missed something important"

<modified> == "the time this particular sequence of bytes became this 
entry's content."

As I see it, modified is probably only something of interest to an 
obsessive pedant.  Something a content management system may (and 
perhaps even should) track, but not something that routinely needs to be 
shared with others.

- Sam Ruby

---

From: Sam Ruby <[email-masked]>
Date: Fri, 23 Jul 2004 07:38:19 -0400

As I see it,

- Sam Ruby

---

From: Sam Ruby <[email-masked]>
Date: Fri, 23 Jul 2004 07:57:14 -0400

> shows the differences using an HTML diff. 

Consider:

http://www.tbray.org/ongoing/When/200x/2004/02/20/GenxStatus

Since this feed does not contain guids, I presume that RSS Bandit users 
would see every update as a new entry.

If this feed were updated to contain guids, I presume that RSS Bandit 
would quietly update the stored content, but would not otherwise 
highlight to the user that this entry had been modified.  For typos, I 
think this is appropriate.  For significant updates, like the ones that 
Tim had made, less so.

I want a way to distinguish between these two case.  I want that even 
though I know that some people who produce feeds will get this wrong.  I 
want this even though I know that some aggregators will ignore this 
information.

I want aggregator authors to be able to answer the question "but why 
did/did not you show my this change" with something other than "I 
guessed wrong".

And I want to do it in a way that you, Dave Obasanjo, don't go around 
telling everybody that "see, I told them that this was a bad idea".

Suggestions welcome.

- Sam Ruby

---

From: David Powell <[email-masked]>
Date: Fri, 23 Jul 2004 13:09:52 +0100

> obsessive pedant.

I agree that "modified" is of little interest to humans, but it is of
interest to machines.

For example, a web-based aggregator, could
preformat Atom entries using XSLT, but only recalculate this
transformation if the underlying entry had been modified.

Also search engines only need reindex an entry if it has been
modified.

I have used this aggregator for the Pocket PC:
http://www.viksoe.dk/code/rsssync.htm It does the XML processing on
the PC and then synchronizes the entries to the Pocket PC. I'm not
sure exactly how it works, but I'd imagine it would be a lot easier if
it could tell whether an entry had changed by looking at its modified
date.

Any application that does any kind of synchronization benefits from
"modified" dates.

-- 
Dave

---

From: Janne Jalkanen <[email-masked]>
Date: Fri, 23 Jul 2004 15:29:47 +0300

> <modified> == "the time this particular sequence of bytes became this 

A wiki would probably change the <modified> -date each time someone made 
an edit, but the <updated> -date only if it was not marked as a "minor 
edit", which is a very common wiki functionality.

Just my 2c, noting that this would fit well in a wiki model.

/Janne, who goes now off to holidays :-D

---

From: Sam Ruby <[email-masked]>
Date: Fri, 23 Jul 2004 08:35:49 -0400

David Powell wrote:
> [snip]

That makes sense to me.

- Sam Ruby

---

From: "Bill Kearney" <[email-masked]>
Date: Fri, 23 Jul 2004 09:04:57 -0400

> people discuss more important things like "display" date and so forth.

It seems several people have a grave aversion to URN usage.  It's a shame really
as there are potentially a number of handy things that could be done with them.

Meanwhile, what's the name of the law to invoke when a URL vs URI permathread is
about to erupt?

---

From: Norman Walsh <[email-masked]>
Date: Fri, 23 Jul 2004 14:37:06 -0400

/ Elias Torres <[email-masked]> was heard to say:
| How would you suggest people use IDs in Atom?

I think the suggestion would be http[1].

| What about the case when
| multiple feeds display the same entry (categories, site-aggregators,

As long as the ID is unique, you'll get the properties you want in
these cases.

| etc) and multiple versions of the same entry as well?

When does this occur? What are "multiple versions" of an entry?

To my mind, if two entries have the same ID, they're the same thing.
If there are differences, the fact that they have the same ID is an
assertion from the author that those differences are not significant
(and you can pick one at random, though I suggest you pick the one
with the most recent atom:modified date, if you can).

                                        Be seeing you,
                                          norm

[1] http://norman.walsh.name/2004/03/03/266NorthPleasant

-- 
Norman Walsh <[email-masked]> | A great deal may be done by severity,
http://nwalsh.com/            | more by love, but most by clear
                              | discernment and impartial
                              | justice.--Goethe

---

From: Mark Pilgrim <[email-masked]>
Date: Fri, 23 Jul 2004 15:12:59 -0400

> I think the suggestion would be http[1].

There are things you can do, and things that people expect to be able
to do, with HTTP URIs that you can not in fact do with IDs.  For
example, http://fishbowl.pastiche.org/2004/05/31/jroller_does_it_again

> As long as the ID is unique, you'll get the properties you want in

No, as long as the ID is unique and unchanging, you'll get the
properties you want.

> To my mind, if two entries have the same ID, they're the same thing.

Paging Mr. Theseus, your ship is ready...

-- 
Cheers,
-Mark

---

From: Tim Bray <[email-masked]>
Date: Fri, 23 Jul 2004 12:57:01 -0700

> example, http://fishbowl.pastiche.org/2004/05/31/jroller_does_it_again

"Doctor, it hurts when I do this!"

> Paging Mr. Theseus, your ship is ready...

Good point.  There will be no black sails used on board any 
Atom-powered ship.  -Tim

---

From: Norman Walsh <[email-masked]>
Date: Fri, 23 Jul 2004 16:07:44 -0400

/ Mark Pilgrim <[email-masked]> was heard to say:
| On Fri, 23 Jul 2004 14:37:06 -0400, Norman Walsh <[email-masked]> wrote:
|> / Elias Torres <[email-masked]> was heard to say:
|> | How would you suggest people use IDs in Atom?
|> 
|> I think the suggestion would be http[1].
|
| There are things you can do, and things that people expect to be able
| to do, with HTTP URIs that you can not in fact do with IDs.  For
| example, http://fishbowl.pastiche.org/2004/05/31/jroller_does_it_again

I did say it was a suggestion. I'm not happy about it, I just decided
to admit defeat on names and addresses and move on.

In the case of the jroller example, I don't think the use of http is
the problem, dynamically generating the ID values from the web server
name is the problem.

|> | What about the case when
|> | multiple feeds display the same entry (categories, site-aggregators,
|> 
|> As long as the ID is unique, you'll get the properties you want in
|> these cases.
|
| No, as long as the ID is unique and unchanging, you'll get the
| properties you want.

Unchanging, yes. Unless, of course, you hold the view that IDs cannot
change, their one defining characteristic is that they provide
identity. An entry with a "changed" ID is a different entry, by
definition.

|> When does this occur? What are "multiple versions" of an entry?
|> 
|> To my mind, if two entries have the same ID, they're the same thing.
|
| Paging Mr. Theseus, your ship is ready...

Yes. And the one that has the same ID painted on its bow is the same
one, irrespective of what it's composed of. And if two ships sail into
the harbor and they both have the same ID painted on their bow, then
there is only one ship. And there are no spoons on any of them.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | We dance around in a ring and suppose,
http://nwalsh.com/            | but the Secret sits in the middle and
                              | knows.--Robert Frost

---

From: Dare Obasanjo <[email-masked]>
Date: Fri, 23 Jul 2004 13:36:24 -0700 (PDT)

> would see every update as a new entry.

No. The most recent version of RSS Bandit uses the
combination of link + title to act as identifiers for
feeds without guids. We did this because some feeds
such as the one at http://www.ibiblio.org/xml/ use the
same link for different items. This turns out to have
been a mistake since every time a typo is fixed in a
title our users see a new item in their feed that is a
duplicate. 

In the next version, we'll go back to using links as
guids in RSS feeds without guids. 

> think this is appropriate.  For significant updates,

Sure. My worry is that the difference between
significant update and minor update will differ to
widely from site to site for us to give users a
consistent user experience. You could argue that the
benefit of being able to make the distinction is worth
the added complexity it brings to the format and the
potential user irritation when <updated> is misused. 

> did/did not you show my this change" with something

That's a worthy goal. 

> telling everybody that "see, I told them that this

My name isn't Dave. :)

=====

__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail

---

From: Robert Sayre <[email-masked]>
Date: Fri, 23 Jul 2004 17:04:52 -0400

> potential user irritation when <updated> is misused.

My worry is that we're inventing this practice. What's the precedent here?
Other formats seem to tackle this problem with changes to content structure
and/or distinct but related resources.

Robert Sayre

---

From: Bill de hÓra <[email-masked]>
Date: Fri, 23 Jul 2004 23:23:20 +0100

> "Doctor, it hurts when I do this!"

See a psychiatarist, not a doctor. The web has naming and name 
distribution policies that are clearly delusional. As are all the 
others.

cheers
Bill

---

From: Mark Pilgrim <[email-masked]>
Date: Fri, 23 Jul 2004 18:25:52 -0400

> "Doctor, it hurts when I do this!"

"Doctor, it hurts when I miss the point."  There are things you can do
with "http://" URIs when they're URLs served up over HTTP, that you
can't do when they're in an <id> element.  One of them is HTTP-level
redirects.  Another is actually doing an HTTP GET and expecting
something useful.  (See also: permathreads on using "http://" URIs for
namespaces, RDF predicates, etc.)

You and I have battled over this before, and I'm still right, and you
still don't have any response except "Doctor, it hurts when I do
this."  Stop fighting long enough to acknowledge the consensus around
you.

-- 
Cheers,
-Mark

---

From: Greg Stein <[email-masked]>
Date: Fri, 23 Jul 2004 18:09:11 -0700

I'm agreeing with Mark on this one. His example:

    http://fishbowl.pastiche.org/2004/05/31/jroller_does_it_again

That URI is fixed and unchanging. It is JUST FINE as an identifier.

The fact that you can feed it into a HTTP client, have it run off and
fetch content for you, and the fact that the content might change... has
NOTHING to do with the fact that that URI is a constant. And, thus, more
than suitable as an identifier.

My ID is "Greg Stein". That's awfully constant. I'm always changing, but
my identifier is not.

In short, people are conflating two concepts, and using that as an
argument that an HTTP URI is unusable as an identifier. Whoops. Keep 'em
separate, people...

Cheers,
-g

---

From: James M Snell <[email-masked]>
Date: Fri, 23 Jul 2004 19:38:47 -0600

> argument that an HTTP URI is unusable as an identifier. Whoops. Keep 'em

I personally feel that ID should be allowed to be ANY type of URI, 
independent of scheme.  It simply does not matter if you can DO anything 
with it, it just has to be unique.  If you can actually DO something with 
the URI that is used as the ID, then great, wonderful, bonus... but that's 
not a requirement. HTTP URI's work great to meet this requirement, LSID's 
could also... the scheme used in the URI simply doesn't matter.

> > > > example, 
> > this."  Stop fighting long enough to acknowledge the consensus around

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

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 24 Jul 2004 14:51:04 +0200

> That URI is fixed and unchanging. It is JUST FINE as an identifier.

That exact URL is probably just fine, yes. But many other URL's are not.  
E.g.:

   http://home.example.com/~bob/blog/012231.html

Is _not_ a good «URL as ID». What can and will happen with such a URL is  
that this Bob Z will move to another location, and thus change the ID of  
his entries. What may also happen is that Bob X registers at example.com  
and receives the same account as Bob Z. Bob X can then publish entries  
with the exact same ID as Bob Z did. Then we're in a situation where:

   - The original 'http://home.example.com/~bob/blog/012231.html' entry
     is unretrievable, because it has changed location _and_ ID.

   - The new 'http://home.example.com/~bob/blog/012231.html' has nothing
     to do with the first one, and people retrieving it will be very
     confused.

   - If 'http://home.example.com/~bob/blog/012231.html' isn't ever
     overwritten by a new entry, it will still be impossible to force Bob
     X to always do an HTTP redirect Bob Z's entry location.

This is not an edge case. It is extremely common that people don't have  
their own domains to set up blogs on. And the URI they are expected to  
choose for their entry ID's is the one their blog resides on. And that  
blog both can and will move. That's when we have problems, by the single  
fact that URL's are expected to be _directly_ resolvable.

If we, however, have a URI scheme that isn't expected to be directly  
retrievable, we will mitigate or kill the scenarios where ID's are changed  
when entries move. If this scheme also contains good ways to create an ID  
that will stay unique over time, by e.g. containing the date of when the  
entry was published at that domain, it will mitigate or kill scenarios  
where ID's are reused by different authors.

> NOTHING to do with the fact that that URI is a constant.

People expect it to be. HTTP URI's is per def directly resolvable. It is  
impossible to change that perception. Also, not all Atom entries may be  
directly retrievable over HTTP, and thus will an HTTP URI scheme for ID's  
be very awkward for some publishers.

I don't mind people using URL's as identifiers when they know what they're  
doing (e.g. will never change the ID of their entries), and when they know  
that the URL's they create won't ever be reused if they somehow loose  
their domain in the future. But for everyone else, LSID's or tag URI's  
should be the recommended ID scheme.

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

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 24 Jul 2004 14:55:54 +0200

On Fri, 23 Jul 2004 19:38:47 -0600, James M Snell <[email-masked]>  
wrote:

> independent of scheme.

+1. The recommended scheme should, however, be one that we are almost 100%  
certain won't make people want to change the ID's of their entries in the  
future, and that stays unique over time as well (e.g. isn't reused). The  
ID MUST be universally unique[1], no matter what scheme it is based on.

> It simply does not matter if you can DO anything with it, it just
> has to be unique.

+1.

____
[1] From <url: http://intertwingly.net/wiki/pie/AtomTerminology>: «An  
identifier that is unique across all time, by use of data/time in addition  
to any other global naming system or registration, in contrast to a  
globally unique identifier which is only known to be unique when it is  
created.»

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 24 Jul 2004 15:04:06 +0200

On Fri, 23 Jul 2004 17:04:52 -0400, Robert Sayre <[email-masked]>  
wrote:

> My worry is that we're inventing this practice.

We are. 'updated' will, if it makes its way into Atom, be 100%  
Atom-specific.

> What's the precedent here?

In other areas and formats, superseding is the number one way to deal with  
this.

> Other formats seem to tackle this problem with changes to content  
> structure and/or distinct but related resources.

Yep. Of some reason I'm not familiar with, that is too complex for Atom to  
adopt, even if it is the most widespread solution to this problem. :-\

I'd be perfectly fine with an optional superseding mechanism. But Atom  
should not propose two alternative ways to signify major modifications.  
Therefore should Atom core only contain an 'modified' element that doesn't  
say anything about what the modification was, and a superseding extension  
to the core that allows for versioning.

If people want to ignore supersedings, they can, both on the consumer and  
producer side. If they want a way to separate minor from major changes,  
they must use the superseding mechanism, which is an extension to the  
core. Atom core will then have a required, immutable 'issued', and will  
not have 'updated'.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 24 Jul 2004 15:08:19 +0200

> edit", which is a very common wiki functionality.

Since most Wikis do versioning, I think it would be pretty bad not to  
reflect this in Atom. An extension to Atom core that allowed for  
superseding would easilly fix this.

Eric Scheid's proposal of having feeds of revisions is also a great way to  
follow up on changes on one particular Wiki page. That would also make it  
easy to revert changes whenever spam or such occurs, because the revision  
feed would contain all changes to the Wiki page.

> /Janne, who goes now off to holidays :-D

See you in Helsinki in a couple of weeks, hopefully! :-)

---

From: Sam Ruby <[email-masked]>
Date: Sat, 24 Jul 2004 09:21:04 -0400

Asbjørn Ulsberg wrote:
> +1. The recommended scheme should, however, be one that we are almost 
> 100%  certain won't make people want to change the ID's of their entries 
> in the  future, and that stays unique over time as well (e.g. isn't 
> reused). The  ID MUST be universally unique[1], no matter what scheme it 
> is based on.
> 

I agree with this, except for the word "The" in front of the word 
"recommended" above.

My belief is that if, and only if, you own your own domain name, then 
making the id match the permalink is a good idea.

- Sam Ruby

---

From: Bill de hÓra <[email-masked]>
Date: Sat, 24 Jul 2004 14:40:52 +0100

Sam Ruby wrote:

>> 100%  certain won't make people want to change the ID's of their 
>> entries in the  future, and that stays unique over time as well (e.g. 
>> isn't reused). The  ID MUST be universally unique[1], no matter what 
>> scheme it is based on.
>>

And I agree with that except for the word "own" - "lease" is more 
accurate wrt such issues.

cheers
Bill

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sat, 24 Jul 2004 07:55:56 -0700

At 2:40 PM +0100 7/24/04, Bill de hÓra wrote:
>Sam Ruby wrote:
>
>>
>>Asbjørn Ulsberg wrote:
>>
>>>
>>>+1. The recommended scheme should, however, be one that we are 
>>>almost 100%  certain won't make people want to change the ID's of 
>>>their entries in the  future, and that stays unique over time as 
>>>well (e.g. isn't reused). The  ID MUST be universally unique[1], 
>>>no matter what scheme it is based on.
>>>
>>My belief is that if, and only if, you own your own domain name, 
>>then making the id match the permalink is a good idea.
>

And I agree with that chain of agrees. (Does that make it a +4?)

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Eric Scheid <[email-masked]>
Date: Sun, 25 Jul 2004 01:11:12 +1000

> making the id match the permalink is a good idea.

assuming they're wise enough to avoid having the URL polluted with
implementation specific bits, like ".php" or "blog.cgi?..." and such.

e.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 24 Jul 2004 17:59:05 +0200

> implementation specific bits, like ".php" or "blog.cgi?..." and such.

It wouldn't hurt if the specification gave some examples to how such ID's  
could look like, and not leave everything up to both interpretation and  
implementation, as I feel it does for too many issues, now.

Many other specifications are springled with examples. The Atom format  
specification has _one_. Even though this format is a simple one, and  
unarguably simpler than e.g. HTML, I see no reason to not have more  
examples in it.

Would it be too much to require, that future (and existing) paces should  
have at least one example in them, which will be included as a  
non-normative example in the specification?

---

From: Mark Pilgrim <[email-masked]>
Date: Sat, 24 Jul 2004 11:52:39 -0400

> accurate wrt such issues.

That's one problem (of many) with using "http://" URLs are unique
identifiers -- they're not guaranteed to *remain* unique over time,
because nobody owns their domain forever.

If only there were some way to create an identifier that combined a
domain name with, say, a date on which you controlled that domain.

-- 
Cheers,
-Mark

---

From: Greg Stein <[email-masked]>
Date: Sat, 24 Jul 2004 09:16:32 -0700

> domain name with, say, a date on which you controlled that domain.

What are the temporal constraints? Does it really need to be unique for
all time, or simply within a given feed?

Or maybe only as long as the entry it is matched up with? Why should an ID
outlive the entry itself?

In any case, I believe the spec should simply specify "a URI" as the
identifier. I don't think it needs to recommend any particular scheme (as
recommendations are generally non-normative), though a companion "best
practices" document certainly could.

Cheers,
-g

---

From: Tim Bray <[email-masked]>
Date: Sat, 24 Jul 2004 09:39:20 -0700

> domain name with, say, a date on which you controlled that domain.

I assume Mark is being ironic, but whatever, he's entirely correct.  I 
am increasingly convinced of the virtue of putting dates in URIs, as in 
http://www.tbray.org/ongoing/When/200x/2004/07/24/WillYou [<== just an 
example, no Atom-related content here].

  --Tim

---

From: Tim Bray <[email-masked]>
Date: Sat, 24 Jul 2004 09:37:09 -0700

> unarguably simpler than e.g. HTML, I see no reason to not have more 

+1.  I think it is essential that the atom RFCs-to-be have lots of 
examples, and in general should provide an example of something before 
they try to explain/specify it. -Tim

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 24 Jul 2004 19:21:46 +0200

On Sat, 24 Jul 2004 09:37:09 -0700, Tim Bray <[email-masked]> wrote:

> they try to explain/specify it.

Would it be too much to require future and existing paces to include at  
least one example that will be a part of the specification, then? It  
wouldn't take much time to write one for each Pace's author, I think.

For future pace's, it's just to add an 'Examples' section to the pace  
template.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 25 Jul 2004 00:43:57 +0200

> example, no Atom-related content here].

+1. If one uses HTTP URI's as the atom:id scheme, the template one uses  
should be just as universally unique as 'tag' and LSID URI's, yes. Thus  
must dates be a part of the URI. If one don't want dates in the publicly  
available URI's, one should probably not use that as the atom:id, or at  
least provide two; one for atom:id that does a 303 to the other, which is  
the publicly available URI.

---

From: Walter Underwood <[email-masked]>
Date: Sat, 24 Jul 2004 18:09:48 -0700

> making the id match the permalink is a good idea.

That isn't sufficient. Infoseek owned it's own domain, but
http://software.infoseek.com/ no longer points to Ultraseek.
Disney bought Infoseek, renamed it, sold our bits to Inktomi,
who sold them to Verity. Six years, four domains.

Luckily, search engines usually don't care about IDs that
are unique for 10,000 years. They are more concerned with
keeping up with the current state of the universe. If you
want history, you have to keep your own archive.

Hmm, time to invite Brewster Kahle to chime in?

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: "Raymond Hsieh" <[email-masked]>
Date: Sun, 25 Jul 2004 09:53:13 +0800

Hi, 

I have a question regarding getting feed with Atom. 

I want to fetch all blog entries ever published on my blogspot, including
those archived. However, when I get feed with Atom, it only gave me a few,
not including the older entries (like those published in 2003). 

Any idea how I could get all the entries from my blogspot? 

Thanks, 
Raymond

---

From: Mark Pilgrim <[email-masked]>
Date: Sat, 24 Jul 2004 22:28:05 -0400

> example, no Atom-related content here].

"Doctor, it hurts when I miss the point over and over."

If you lose the tbray.org domain, what then?  The new owner could
legitimately reuse this ID at any time to mean something else.  The
entire namespace belongs to them now; they can map it any way they
want without violating the http:// URI scheme.

urn: solves this by registering namespaces permanently.  (This
statement applies to informal and formal URNs.  Ad-hoc x- URNs have no
insurance against collision.)

tag: solves this by combining a domain name and a date to create a
namespace.  The date is a date on which you controlled the domain.

if http:// has a way of solving this that I'm missing, I would
appreciate being enlightened.

-- 
Cheers,
-Mark

---

From: Mark Baker <[email-masked]>
Date: Sun, 25 Jul 2004 01:15:24 -0400

On Sat, Jul 24, 2004 at 10:28:05PM -0400, Mark Pilgrim wrote:
> urn: solves this by registering namespaces permanently.

I don't think so.  There's nothing more permanent about URN namespace
registration than DNS name registration.  It might appear that way,
but that's illusory; should somebody register a namespace which uses
somebody else's trademark, you can guarantee that the courts would be
brought in - just as they would be with the DNS - and that there'd be a
chance that the name would be reassigned.

The problem is registries in general, not DNS in particular.

> namespace.  The date is a date on which you controlled the domain.

Well - and this argument applies to URNs too - I suppose one way to
solve the problem of a new owner reusing the URI, is to make sure
that nobody, including the current owner, can use (read; dereference)
it.  Bah, sorry, that's not my idea of solution.  Important identifiers
should be dereferencable.

> appreciate being enlightened.

It doesn't solve it either.  It's just the best you can do with both a
name registry *and* dereferencability, IMO.

The fact is that persistence costs, you can't just institute it.
Registrants need to do the upfront legwork to ensure they're not using
somebody else's trademark.  They need to adopt careful policies. etc..
... which reminds me that I've written about this before;

http://www.markbaker.ca/2002/09/draft-connolly-w3c-accessible-registries-00.txt

Mark.

---

From: Tim Bray <[email-masked]>
Date: Sat, 24 Jul 2004 22:52:58 -0700

On Jul 24, 2004, at 7:28 PM, Mark Pilgrim wrote:

>>   I

It seems to me that the identifier remains valid as an identifier even 
if someone else owns the namespace, particularly if there's a lot of 
software out there that knows it.  The identifier's function as an 
identifier does not, in any protocol we're likely to design, have any 
dependency on what you might get when you dereference it.  For example, 
I'm quite sure that the character string 
"http://www.w3.org/XML/1998/namespace" (the URI for the "xml:" prefix) 
will remain widely recognized in software long after the W3C has faded 
away and w3.org is owned by Wholesale Wolves and Weasels, Inc.  It's 
just a character string and the character string need not change.  As 
long as I own the namespace, the identifier will be potentially more 
useful because you might be able to dereference it to get some 
explanatory/supporting material.  A URN or tag: or whatever removes the 
possibility of direct dereference by ubiquitous software, thus 
buying... uh, what?  I've never understood.  The most typical use case 
of an identifier is as an input to a call like strcmp(), which doesn't 
care in the slightest about URI schemes.

But can we please stop arguing?  Because it doesn't matter, I REALLY 
THINK it doesn't matter.  In Atom, there are going to be places where 
it says "this identifier should be a URI".  Those who really believe in 
a useful distinction between naming and location, or who believe that 
the URN registration process really produces longer-lived identifiers, 
can use that kind of URI.  Those of us who think that identifiers are 
made more useful by being potentially dereferencable will use HTTP 
URIs.   In a few decades we'll know who was right. -Tim

---

From: Eric Scheid <[email-masked]>
Date: Sun, 25 Jul 2004 16:44:59 +1000

> should be dereferencable.

A tag URI could be dereferenced, given a register with historical records.
Although tag base domains could be reassigned, they can't rewrite history
That is: stating that the domain name was under the control of some other
than the person who actually had that domain name under their control
(rightly or wrongly) at that time.

Given the rise of über-aggregators like syndic8, bloglines, technorati, etc
... it wouldn't be difficult for them to provide a dereferencing interface,
providing the last known URL for any given URI (tag, urn, LSID, etc).

e.

---

From: Bill de hÓra <[email-masked]>
Date: Sun, 25 Jul 2004 13:19:18 +0100

Tim Bray wrote:

> THINK it doesn't matter.  In Atom, there are going to be places where it 
> says "this identifier should be a URI".  Those who really believe in a 
> useful distinction between naming and location, or who believe that the 
> URN registration process really produces longer-lived identifiers, can 
> use that kind of URI.  Those of us who think that identifiers are made 
> more useful by being potentially dereferencable will use HTTP URIs.   In 
> a few decades we'll know who was right.

Yes. Aside from striking me as BCP material, the architecture [1] 
and means[2] to let everyone have their cake and eat it (modulo some 
crumbs) exists. Otherwise the philosophers are better qualified to 
deal with this problem and are approximately a century ahead of us.

cheers
Bill

[1] http://www.ietf.org/rfc/rfc3401.txt
[2] http://www.ietf.org/rfc/rfc3404.txt

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sun, 25 Jul 2004 07:58:40 -0700

At 1:20 PM +0200 7/25/04, Asbjørn Ulsberg wrote:
>Wouldn't we be better off recommending Bob and his friend a scheme 
>we knew were safer against future modifications, universally 
>uniqueness, etc?

No. Trying to teach Bob and his friends why URNs are better than URLs 
is futile, and that's OK. He shouldn't have to worry about it.

>  Or do you have faith in that Bob, although he doesn't know anything 
>(he has no idea what the difference between URI, URL or URN is, and 
>he has only seen URL's «live»), will pick a scheme that is 
>universally unique «enough»?

Yes. If he is hand-coding, he has probably read enough of the RFC to 
get it right. If he is using a tool, the tool will probably get it 
right.

If we're going by the 80/20 rule (heck, the 99/1 rule), entries and 
feeds will be software-generated. It is completely trivial for 
software to generate IDs that won't get re-used except in the most 
extreme cases, such as a domain name turnover. In those very rare 
cases, there is nothing we can do. We live with it. We sleep anyway.

--Paul Hoffman, Director

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 25 Jul 2004 13:20:10 +0200

On Sat, 24 Jul 2004 22:52:58 -0700, Tim Bray <[email-masked]> wrote:

> Those who really believe in a useful distinction between naming and
> location, or who believe that the URN registration process really
> produces longer-lived identifiers, can use that kind of URI.  Those
> of us who think that identifiers are made more useful by being
> potentially dereferencable will use HTTP URIs.

What about those who _just_don't_know_anything_? That is, Bob and his  
friends, which thinks all HTTP URI's are resolvable from now until  
forever, that they are dynamic (if a resource move, the resource's URI  
changes) and not «just a string».

Wouldn't we be better off recommending Bob and his friend a scheme we knew  
were safer against future modifications, universally uniqueness, etc? Or  
do you have faith in that Bob, although he doesn't know anything (he has  
no idea what the difference between URI, URL or URN is, and he has only  
seen URL's «live»), will pick a scheme that is universally unique «enough»?

---

From: Tom Myers <[email-masked]>
Date: Sun, 25 Jul 2004 13:01:36 -0400

Paul Hoffman / IMC wrote:
> feeds will be software-generated. It is completely trivial for software 
> to generate IDs that won't get re-used except in the most extreme cases, 
> such as a domain name turnover. In those very rare cases, there is 
> nothing we can do. We live with it. We sleep anyway.

Is it absotively posilutely definite that "there is nothing we can do"
about domain name turnovers? Suppose the spec said that IDs, if done as
retrievables, SHOULD or even MUST be of a form such as A/B/C  where

   A= a base URI, http://www.example.com:8765/stuff/JoeSchmoe/blog
   B= date info,  2004-07-26
   C= something to make it unique for that date, My_Funny_Story.html

Now, it may well be that example.com will get sold out from under dear
old JoeSchmoe, but the URI A/B/C will never be reused because you'll have
new dates for B. An aggregator seeks an old A/B/C and finds that it's not
there, there isn't even any Atom data there. The aggregator will then
ask technorati or somebody

   is there any replacement baseURI for
      A = http://www.example.com:8765/stuff/JoeSchmoe/blog

and it will be told, perhaps, that one has been seen, namely

      A' = http://www.JoeSchmoe.net/blog

and a few milliseconds later it will retrieve the entry from Joe's new
place for it, A'/B/C, having noted the baseURI replacement for future usage.

Now, maybe most aggregators will not want to support this, but I don't
see why it couldn't work, and it could give some competitive advantage
to those that did support it. (And maybe a further competitive advantage
to those that correctly handle the .001 case where the new domain owner
publishes, using an identical baseURI.)

  All the spec would have to do is push the use of decomposable URIs in
some format like A/B/C as described...right?

You could go further, of course, saying that Joe's new blog could claim

   <atom:prevBase baseURI="prevA" from="yyyy-mm-dd" to="yyyy-mm-dd"/>

once for each previous baseURI Joe has used. That would make the
technorati (or whoever) end of it easy, too. And then you would have
people trying to use this to hijack instapundit, or whatever, and
getting themselves banned. There are lots of aspects that might be
worth thinking through, for core or extensions, and I've probably
made a fool of myself sufficiently for now, so I'll go back to lurking....

Tom Myers

---

From: Dare Obasanjo <[email-masked]>
Date: Sun, 25 Jul 2004 10:57:05 -0700 (PDT)

--- Tim Bray <[email-masked]> wrote:
> For example, 
> away and w3.org is owned by Wholesale Wolves and
> Weasels, Inc.  

Will it still the mean the same thing? There was a
time one could have made the same statement about
http://www.w3.org/TR/SOAP and SOAP 1.1. That turns out
to not have been true.  

> It's 
> explanatory/supporting material. 

How does one 'own a namespace'? 

> A URN or tag: or
> whatever removes the 
> buying... uh, what?  I've never understood. 

Then you don't use the technologies that have had this
mess foisted on them. The two primary places URIs as
identifiers have been deployed have been a royal mess
of ambiguity; XML namespaces and RDF. 

See http://www.kuro5hin.org/story/2003/2/5/11349/85355
for one of my rants about this from last year. 

> THINK it doesn't matter. 

That's unfortunate. As an aggregator author, the
screwed up nature of identifiers is one of my biggest
problems with RSS. In fact, that and the optionality
of a date field. If the folks working on Atom screw
this two thing up to since "it doesn't really matter"
then Atom would stand as an example of how to reinvent
the wheel but only worse. 

> In Atom, there are going
> to be places where 
> URIs.   In a few decades we'll know who was right.

We already have examples from RSS, XML namespaces and
RDF that using HTTP URLs as URIs causes problems. What
other proof do you need? 

=====

__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail

---

From: Elias Torres <[email-masked]>
Date: Sun, 25 Jul 2004 14:08:58 -0400

> care in the slightest about URI schemes.

I agree with Tim here. As a matter of fact this was the reason why I
suggested LSID. Although part of the LSID spec is about resolving and
fetching the data/metadata about an entry regardless of the protocol,
my recommendation was purely from an Identifier-only perspective.
Something that readers/applications/etc can use it to do strcmp()
with. At first, I thought Tim wanted HTTP URL/URIs because they were
resolvable etc, but I think the danger with it is that it will be
redundant. For example, why would we want to use the HTTP URL to the
entry as a unique identifier, when that URL is already available as
part of the feed in possible several other fields. It seems that every
RSS reader in the world uses the permalink (and maybe other things to
make an unique identifier). So what's the point of an ID field? I
would say that it's only for advanced users or applications that know
what they are doing and are really creating something unique and
durable.

I think through the excellent discussion everyone has had on the
subject, I see a concensus on dates playing an extremely important
role in identifiers so we can avoid GUIDs. For example, this URIs are
great examples of perfectly fine IDs.

urn:lsid:fishbowl.pastiche.org:2004.05.31:jroller_does_it_again

urn:lsid:fishbowl.pastiche.org:2004.05.31:jroller_does_it_again:21

I would also love to end this long thread, but not without a
conclusion. I cannot leave this topic with an atom:id that only says
"it must an URI". I think we would be doing a disservice to our users
if we did so.

I state that if you are going to use the same URL as the entry itself
whether is "good" or "bad" according to Tim Berners Lee, then might as
well not add extra bytes. If you are, we should have an excerpt on
suggested schemes. If we do, I'd rather use something that has been
spec'd out, such as LSID. Why? Because just like we suggest a specific
ISO format for date, we should do the same for IDs. The fishbowl
example is only useful to us in strcmp() and a browser, but nothing
else. On the other hand, the LSID URI has parts that need to be
conformant, such as authority (i.e. domain), namespace (i.e. a year),
object (i.e an entry ID) and optionally a version. Again, I strongly
believe we would get more benefit out of that , than just saying "use
an URI".

I'm really excited to be part of this mailing list. The diversity in
intellect and experience is so diverse that gives me hope that Atom
will be an excellent standard and addition to the Internet and if we
get lucky it will be as simple as C, HTTP, XML and others.

Elias

---

From: Dare Obasanjo <[email-masked]>
Date: Sun, 25 Jul 2004 11:47:51 -0700 (PDT)

--- Elias Torres <[email-masked]> wrote:
>
>  For example, why would we want to use the
> HTTP URL to the
> make an unique identifier). So what's the point of
> an ID field? 

Because using the permalink as a unique identifier is
a FUCKING HACK!!!!

Every aggregator author I have talked to wants a
unique identifier that is guaranteed to be relatively
stable. HTTP URLs are not. 

Excuse my language but this discussion along with the
one about dates implies to me that lots of the people
debating on this list aren't very knowledgeable about
technologies related to sydnication and are just
arguing based on assumption and suppositions. And you
know what they say about assumptions...

=====

__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 25 Jul 2004 21:41:58 +0200

On Sun, 25 Jul 2004 07:58:40 -0700, Paul Hoffman / IMC <[email-masked]>  
wrote:

> No. Trying to teach Bob and his friends why URNs are better than URLs is  
> futile, and that's OK. He shouldn't have to worry about it.

So you think it's more feasible for the few of those who actually know the  
difference between URN's and URL's to use the rest of the remaing days of  
their lives to go around preaching, writing articles, how-to's and so on  
about these differences, than to add a couple of sentences about it in the  
specification?

>> (he has no idea what the difference between URI, URL or URN is, and he  
>> has only seen URL's «live»), will pick a scheme that is universally  
>> unique «enough»?
>
> Yes. If he is hand-coding, he has probably read enough of the RFC to get  
> it right. If he is using a tool, the tool will probably get it right.

If he is hard-coding, and the specification is completely silent on what  
scheme he should use, he will probably think «URI? What's that?», do some  
searching, and after having read a couple of pages about «Uri Geller»,  
«United Religions Initiative» and «Uniform Resource Identifiers» it's  
possible that he finally finds out that URI's are a superset for URL's.

«Oh, URL's! I know URL's», he will think, and just copy + paste the URL's  
of his entries into the atom:id element. Okay, the specification says that  
atom:id is globally unique («But my domain is my domain», Bob thinks) and  
MUST NOT change over time («But I'm not going to move my blog», Bob  
thinks), but that will not stop him from using his very non-universally  
unique URL's as identifiers for his entries.

May I remind you, this is not an exaggerated edge case. Many users are  
dumber than Bob, many users don't even read the specification, and many  
users read specifications and don't understand a crap of what it's saying,  
because their native language isn't english, because the specification is  
in hostile plain text, because specifications in general are hard to read,  
etc.

Instead of having so high thoughts about what Bob and his friends is able  
to think, find out and accomplish, just out of the blue, I would be more  
comfortable with making the specification as thorough and examplified as  
possible. Adding a couple of sentences about 'tag' and LSID URI's (if  
those schemes are final by the time Atom 1.0 ships) in section 4.2.6 and  
5.5, would do nothing but good.

> In those very rare cases, there is nothing we can do.

If everyone used a tag or LSID URI scheme, because the specification  
recommended everyone to do so, domain turnovers wouldn't be a problem  
either.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 25 Jul 2004 22:14:47 +0200

> "it must an URI". I think we would be doing a disservice to our users

I agree. LSID's or 'tag' URI's should be recommended as URI schemes in the  
specification. Something in the line of:

   atom:id MAY be a resolvable HTTP URI, but MUST NOT be expected to be
   one. The recommended URI schemes for atom:id is [...]

> If we do, I'd rather use something that has been spec'd out, such as
> LSID. Why? Because just like we suggest a specific ISO format for
> date, we should do the same for IDs.

Well put. +1.

---

From: "Bill Kearney" <[email-masked]>
Date: Sun, 25 Jul 2004 16:05:22 -0400

> providing the last known URL for any given URI (tag, urn, LSID, etc).

Yep, on Syndic8 we do this already for the source URL of an RSS feed.  When we
find a feed's moved we mark it as such and note the new location.  To resolve an
entry in a feed, however, is nearly impossible at this point in time.  There's
no consistent way to 'ask' for an instance of an item.  Mainly due to the
ambiguity of specs and the lack of useful data in the feeds themselves.

-Bill Kearney
Syndic8.com

---

From: "Bill Kearney" <[email-masked]>
Date: Sun, 25 Jul 2004 17:00:31 -0400

> want without violating the http:// URI scheme.

So who the hell cares?  If someone doesn't care enough to 'maintain stewardship'
over a URL space then what's the f'ing point?  They're just as likely to be
derelict in their stewardship of any other form of identifier.

There are distinct differences on why something needs the ability to be
"identified".  Perhaps a discussion about that would be more useful than just
sniping at one specific form of identifier vs another.

-Bill Kearney

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 25 Jul 2004 18:58:22 -0400

Mark Pilgrim wrote:
> If only there were some way to create an identifier that 
> combined a domain name with, say, a date on which you
> controlled that domain.
	That's exactly what is done in:

RFC-3085 URN Namespace for NewsML Resources. A. Coates, D. Allen, D.
     Rivers-Moore. March 2001. (Format: TXT=10016 bytes) (Status:
     INFORMATIONAL)
See: http://www.ietf.org/rfc/rfc3085.txt

	It might be nice to have a similar, if not almost identical,
scheme for "atomid"...

		bob wyman

---

From: Tim Bray <[email-masked]>
Date: Sun, 25 Jul 2004 16:24:22 -0700

On Jul 25, 2004, at 1:14 PM, Asbjørn Ulsberg wrote:

> I agree. LSID's or 'tag' URI's should be recommended as URI schemes in 
> the specification.

For the record, I strongly disagree.  If it turns out that I'm a tiny 
minority, we'll recognize consensus the other way.  However, it will be 
unacceptable to reference an unregistered URI scheme.

BTW, consider http://www.w3.org/TR/webarch/#generic-uri

>  Something in the line of:
>
>   one.

I agree with that part.  Anyone have a problem with that?  -Tim

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 25 Jul 2004 19:31:43 -0400

Elias Torres wrote:
> we should have an excerpt on suggested schemes. If we do, I'd 
> rather use something that has been spec'd out, such as LSID.
> Why? Because just like we suggest a specific ISO format for
	As far as I can see, LSID offers nothing over what is provided
by the NewsML URN scheme[1]. In fact, I would suggest that the NewsML
scheme is better since it is more strongly specified. (i.e. the "date
field" must really be a date while LSID apparently only requires a
"unique id" such as the "myblog-entries-2003" that Elias provided in one
of his examples.) Given that LSID offers nothing new and given that it
appears less rigorously specified, I would strongly suggest that any new
standard should be based on NewsML, not the later and weaker LSID. As
Elias points out, it is sensible to base practices on things that are
already "spec'd out." NewsML has been in use in the field for quite a
few years and was made an RFC back in 2001. It has history and it was
designed to address the problem of "news syndication" -- which is
precisely the same problem, but in a different realm, that Atom is
attempting to address.

	Apparently, the LSID scheme is:
urn:lsid:yourdomain.com:namespace:uniqueID[:version]

	The NewsML scheme can be summarized as:
urn:newsml:domain:date:itemId[:RevisionId][Update]

	Note: Update is specific to "News" items and is probably
relevant to syndication usage (no surprise since NewsML was generated by
news syndicators). The value of update is "U" if the referenced item is
an update to a previous item, "A" if it is a replacement for a previous
item and suppressed in all other cases.
	The sample urns from RFC 3085 are:
   urn:newsml:iptc.org:20001006:NewsMLv1.0:1
 
urn:newsml:reuters.com:20000206:IIMFFH05643_2000-02-06_17-54-01_L0615658
4:1U

		bob wyman

[1] http://www.ietf.org/rfc/rfc3085.txt

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 25 Jul 2004 19:51:25 -0400

Dare Obasanjo wrote:
> [passionate expressions censored...]
	+1. I would like to strongly support Dare's comments (although
not his language...) on this subject. It is critical for aggregators and
services like PubSub.com's that we get as close to unique, stable, entry
identifiers as we can. Experience with RSS and Atom indicates clearly
that URL's just don't do the job. I appreciate all the arguments that
say that they *could* do the job -- however, experience processing over
1.5 million entries every day culled from several million RSS and Atom
files indicates that they don't. i.e. theory and reality don't match in
this case. 
	The problem here may be that people have traditionally been very
relaxed about assigning URL's. Support for and reliance on HTTP's
redirection may be the root of this problem... Nonetheless, there is
very little rigor involved in creating and maintaining URL's -- even
though there *could* be. But, it is clear that we're not going to be
able to get people to change the way they work today. Thus, the best
argument for insisting that atom:id *not* be an URL may be simply to get
people to treat atom:id's differently then they do URLs. By declaring
atom:id to be a different "type" we can also encourage a different set
of practices around it.

> this discussion along with the one about dates implies
> to me that lots of the people debating on this list
> aren't very knowledgeable about technologies related
> to sydnication and are just arguing based on assumption
> and suppositions.
	I fear that I have to support Dare on the above comment as well.
I hate to do a "call to authority" but the truth is that it seems clear
that the problems related to consuming massive quantities of Atom feeds
just aren't as obvious as they might be. For folk that *aren't* actually
building aggregators or feed processors, I think it would be good from
time to time if you gave a little weight to those of us who are doing
this things. Yes, we should probably be doing a better job of explaining
what the issues are, however, when many of us have the same
complaint/request, it should at least indicate that a real problem
exists. Also, please note that is is very clear that the issues related
to generating feeds are very different from those related to consuming
them.

		bob wyman

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Dare Obasanjo
Sent: Sunday, July 25, 2004 2:48 PM
To: [email-masked]; Tim Bray
Cc: Mark Pilgrim; Bill de hXra; Sam Ruby; Atom-Syntax
Subject: Re: URI scheme delusions

Excuse my language but this discussion along with the
one about dates implies to me that lots of the people
debating on this list aren't very knowledgeable about technologies
related to sydnication and are just arguing based on assumption and
suppositions. And you know what they say about assumptions...

=====
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.

---

From: Dare Obasanjo <[email-masked]>
Date: Sun, 25 Jul 2004 16:51:02 -0700 (PDT)

--- Bob Wyman <[email-masked]> wrote:
> standard should be based on NewsML, not the later
> and weaker LSID. 

+1 

I definitely would be love to see an addition to the
Atom spec encouraging the use of NewsML URNs as
identifiers in Atom feeds. 

> item and suppressed in all other cases.

I seem to remember reading somewhere that the Web
Architecture is for URIs to be opaque. I feel a little
uncomfortable with the idea of storing change tracking
and revision information as part of the identifier.
But not that uncomfortable as to prevent me from
adding my +1 to using NewsML URNs in Atom. 

=====

---

From: Elias Torres <[email-masked]>
Date: Sun, 25 Jul 2004 19:56:02 -0400

You are correct, Bob. Just looking at the URN schemes I think either
way is better than just recommending URIs w/o any extra specification.
Although, I must say LSID is more than just a URN scheme but a
protocol for resolving and fetching data associated with whatever it
is you named with the LSID.

Although, I think we need to focus the energy of this discussion into
what needs to come out of it:

Leave the spec as it with just a URI? 
Is it a "recommendation" of several schemes that would serve good to
both readers and publisher of atom feeds?
Come up with an atom scheme for IDs? 

What will it be? There's no right or wrong, but what we can agree
would help most Atom users.

Elias

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 26 Jul 2004 01:42:58 +0100

> I agree with that part.  Anyone have a problem with that?  -Tim

Other than wondering if "resolvable" is introducing new terminology 
where "dereferencable" would do, no.

cheers
Bill

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 26 Jul 2004 01:50:42 +0100

> atom:id to be a different "type" we can also encourage a different set

I'm more curious about the requirements in Atom for identifiers 
rather than the technology/policy used, so I can figure out if folks 
are getting testy for interesting reasons. My /impression/ is that 
what's driving this is the implicit requirement, "all Atom entries 
must have unique (space and time) surrogate keys to support 
aggregation use-cases". Is that right?

Also, does anyone think that specifying that atom:id not contain 
HTTP (or some broader subset of) URIs is baking bad practice into 
the spec? For example, as one might argue that not speccing 
PUT/DELETE is baking in the bad practice of subsetting HTTP.

cheers
Bill

---

From: Dare Obasanjo <[email-masked]>
Date: Sun, 25 Jul 2004 17:57:50 -0700 (PDT)

> aggregation use-cases". Is that right?

As long as I've followed Atom this has been the
driving use case. 

> PUT/DELETE is baking in the bad practice of

What is the bad practice? Don't believe in the
delusion that URLs and URNs are equal? Quite frankly,
the bad practice was foisted on us by the IETF and W3C
when they created the mess that are URIs instead of
leaving URLs and URNs seperate. 

As I mentioned before, everywhere I have seen HTTP
URLs used as URIs (i.e. identifiers instead of
locations) it has lead to confusion, ambiguity and
user irritation. RSS, RDF and XML namespaces are all
examples of the problems that the URI fallacy has
caused. 

=====

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sun, 25 Jul 2004 17:52:34 -0700

At 4:24 PM -0700 7/25/04, Tim Bray wrote:
>For the record, I strongly disagree.  If it turns out that I'm a 
>tiny minority, we'll recognize consensus the other way.  However, it 
>will be unacceptable to reference an unregistered URI scheme.

Further, it will never get approved by the IESG, for very good reason.

--Paul Hoffman, Director

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 25 Jul 2004 21:05:50 -0400

Bill de hÓra wrote:
> My /impression/ is that what's driving this is the implicit
> requirement, "all Atom entries must have unique (space and
> time) surrogate keys to support aggregation use-cases".
> Is that right?
	Yes. The NUMBER ONE complaint we get from PubSub users is that
there are duplicate entries in the feeds we generate. Other aggregators
have told me that their experience is the same. The problem is that we
simply can't do good enough duplicate detection based on textual
analysis of entries (i.e. computing MD5 hashes, etc.) if only because
entries that are hosted in multiple feeds often undergo slight changes
when copied from feed to feed (i.e. some whitespace may be dropped URL's
may change because of a "base" change.) Thus, the only hope we have of
doing a good job of duplicate detection is relying on statements by the
entry generator. i.e. if they give us unique, immutable ids and explicit
"Updated" dates.

> Also, does anyone think that specifying that atom:id not
> contain HTTP (or some broader subset of) URIs is baking
> bad practice into the spec?
	No. HTTP is only one of many protocols that are support URIs. In
the case of identifiers it turns out that its use introduces unfortunate
side-effects. One can support URI's and URN's without supporting HTTP. 

		bob wyman

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 26 Jul 2004 02:12:37 +0100

> adding my +1 to using NewsML URNs in Atom. 

NewsML isn't neccessarily inconsistent with that. But given you 
would be mandating a urn that has semantic import (update classs, 
rev numbers), tunneling/abuse wrt Atom notions of identity seems 
inevitable.

I suggest that a Tag URI is a better choice as it has less semantics 
that NewsML plus NewsML urns are explicitly specified as being for 
identifying NewsML content.

cheers
Bill

---

From: "Bill Kearney" <[email-masked]>
Date: Sun, 25 Jul 2004 21:33:56 -0400

> the wheel but only worse.

There are indeed problems with how ambiguity in the specs for RSS has caused
problems.

There has been an on-going interest on the part of the PEOPLE that consume feeds
in having a way to distinguish uniqueness of an item within a feed.  This has
been screwed up several times on the part of several toolmakers; both on the
producing AND on the consuming end of the equation.

So perhaps if we take a look, again, at the reasons why the identifying bits
that exist currently are problematic and/or misimplemented and why.

> RDF that using HTTP URLs as URIs causes problems. What

This blanket statement does little to clarify the situation.  There's nothing
wrong with using HTTP URI.  It's in the implementations seen thus far that
problems develop.  Overloading whether or not something is resolveable against
an HTTP identifier seems to confuse more than it helps.  This is one of the many
mistakes RSS made.  Let's not repeat it.

One big problem will be reaggregated or mutiply-published items.  That is, items
re-published from feed X into feed Y, where X and Y are considered distinctly
different sources (an entry from BBC's feed then picked up by Billy Bob's
Slanted News from Europe feed).  Or from sub-category or other composite feeds
from the same publisher (breaking news with an item from finance and then a
finance feed having the same item).

This gets worse when Billy Bob picks up the item and makes edits to it.  Perhaps
little more than a source quote.  As it stands now virtually NONE of the
aggregation tools retain anything resembling authoritative source information
when they re-aggregate an item.   Asking for source attribution or some sort of
provenance is going to be something these tools can't easily provide.
Sub-category feeds are perhaps less-worse in that the items themselves are often
spec'd by the same HTTP URL across the instances
(http://example.com/archives/00001.html regardless of it being in
http://example.com/rss/financial.rss or http://example.com/rss/breakingnews.xml)
But there are certainly going to be some that don't.  Nevermind the whole
consistency of ID arguments.

I'd favor an approach that strictly parts identifier from resolvable resource.
Let's just cut that cord and be done with it.  Whether or not these identifiers
are part of some 'registered' scheme is another matter.  If the items gain a
reliable identifying strategy I'm sure we and other aggregators will step up to
offer resolvability services regardless of whose scheme gets used.

-Bill Kearney
Syndic8.com

---

From: Dare Obasanjo <[email-masked]>
Date: Sun, 25 Jul 2004 19:07:54 -0700 (PDT)

--- Bill Kearney <[email-masked]> wrote:
> problems develop.  

There's lots wrong with HTTP URIs as opposed to HTTP
URLs, see
http://www.kuro5hin.org/story/2003/2/5/11349/85355 for
descriptions of the problems HTTP URIs have caused to
RDF and XML namespaces. 

Also a number of problems with aggregation today would
fade away if HTTP URLs weren't being used as
identifiers to entries. Duplicate entries in across
the same or multiple feeds is just one problem this
would solve. 

> Overloading whether or not
> something is resolveable against

The IETF/W3C were the ones that one day decided that
even though there were seperate constructs one limited
to identifying (URNs) the other for locations (URLs)
it would make sense to muddy the waters. 

> offer resolvability services regardless of whose

:) 

I see that we agree. 

=====

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 25 Jul 2004 22:12:33 -0400

>Further, it will never get approved by the IESG, for very good reason.
	That is precisely why PaceAtomIDIsNewsML proposes that we use
the already registered (since 2001) URN scheme for NewsML[1]. NewsML
provides what LDIS and tag do but has the advantage that it is already
registered. Also, it was the result of work done on a problem (news
syndication by formal news organizations) that is very similar to the
syndication problem being addressed by Atom.

		bob wyman

[1] http://ietf.org/rfc/rfc3085.txt

---

From: Tim Bray <[email-masked]>
Date: Sun, 25 Jul 2004 20:05:38 -0700

> entry generator. i.e. if they give us unique, immutable ids and 

Bob is *so* right.  I'm a heavy PubSub user and I get irritated at 
seeing the same thing 8 times and I know perfectly well that if we gave 
them deterministic, reliable date-stamps to work with the problem would 
just evaporate. -Tim

---

From: Dare Obasanjo <[email-masked]>
Date: Sun, 25 Jul 2004 20:11:51 -0700 (PDT)

> them deterministic, reliable date-stamps to work

That's only a small part of the problem. 

The major problem has little to do with date stamps
and more to do with providing globally unique IDs.
This is the problem I see in the Feedster and PubSub
feeds I've seen. 

=====

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 25 Jul 2004 23:44:23 -0400

Tim Bray wrote:
> Bob is *so* right.  I'm a heavy PubSub user and I get 
> irritated at seeing the same thing 8 times and I know
> perfectly well that if we gave them deterministic, 
> reliable date-stamps to work with the problem would 
> just evaporate. -Tim
	Aargh... We work pretty hard at finding duplicates... The idea
that you'd see as many as 8 dupes of a single entry is kind of
depressing. Of course, if we didn't run our detection code, you'd see
many more... Please accept that we're doing the best we can but there
really are limits to what you can accomplish using textual analysis and
the junk we get for guids, permalinks, atom:ids and dates today. Garbage
in, Garbage out...
	Also, please note that to do duplicate detection properly, we
need *both* unique atom:ids and reliable, meaningful date-stamps. (Note:
That "meaningful" bit is important. We find too many dates in feeds that
are dynamically generated with code like "Now()" and change every time
you access the feed.)

		bob wyman

---

From: "Bill Kearney" <[email-masked]>
Date: Mon, 26 Jul 2004 08:05:26 -0400

> in, Garbage out....

As we've discovered via Syndic8 it's often better to work with the data sources
to provide better content at the start.  We'd be more than happy to assist in
the process.

> are dynamically generated with code like "Now()" and change every time

Yes, when a tool generated the output has merit.  If only to detect when the
output code screwed up and stopped providing workable data.  One could also
argue that knowing that a feed was generated at 1pm and the most recent content
was generated at 3am the previous day is likewise important in some situations.

Recognizing however that polling brings it's own resource consumption issues,
it's worth omitting a generated feed timestamp if the actual content hasn't
changed.  There's little or no sense in changing the feed timestamp because it
invalidates caches and just wastes everyone's resources.

-Bill Kearney

---

From: "Bill Kearney" <[email-masked]>
Date: Mon, 26 Jul 2004 08:00:24 -0400

> syndication problem being addressed by Atom.

For some reason I'm left with the feeling of "inheriting or being restricted to
another effort's semantics".  While at the same time I'd prefer to avoid
reinventing the wheel.  NewsML is not without it's own set of headaches (if you
think RDF is verbose...) so I'm cautious about attempts to adopt it as a
solution here.  That said, it's structure for URN is useful and may well be
worth emulating.

-Bill Kearney
Syndic8.com

---

From: "Bill Kearney" <[email-masked]>
Date: Mon, 26 Jul 2004 08:23:53 -0400

> descriptions of the problems HTTP URIs have caused to

And guns don't kill people, people kill people.  Badly used identifiers are
independent of their structure.  There's no reason an http:// prefixed
identifier can't be used.  Eliminating the prefix won't do a damned thing to
change it besides 'making it look different'.

> identifiers to entries.

The separation of them as a resolvable resource versus a unique identifier would
work even if they were still using the http:// prefix.  Even if they (gasp)
proved to actually resolve!

> Duplicate entries in across

Properly used identifiers would solve it, what form they use is independent of
the argument.

> it would make sense to muddy the waters.

The historical reasons for the mashing together of URI/URL and near abandonment
of URN are muddy at best.  There's a lot more to the argument than what seems
like your desire to beat them up (IETF/W3C interchangeably it seems) about it.

> I see that we agree.

But probably not to the extent you think.

-Bill Kearney
Syndic8.com

---

From: Sam Ruby <[email-masked]>
Date: Mon, 26 Jul 2004 09:00:10 -0400

> change it besides 'making it look different'.

Bill, drawing an analogy to a topic where reasonable people disagree is 
not helping you make your case.

I believe that Dare's point (and perhaps Bob's) is that changing the 
prefix will make people stop and think.  And given experience with how 
rdf:about is used in RSS 1.0 today, and how guid is used in RSS 2.0 
today, he is not sure that would be a bad thing.

That goal (make people think) is worthy.  Whether that goal can be 
achieved by documentation, requiring NewsML scheme, or even simply 
inventing a scheme named "ptth" which is exactly identical to http 
except that the name of the scheme is spelled backwards is what we 
should be talking about.

- Sam Ruby

---

From: Sam Ruby <[email-masked]>
Date: Mon, 26 Jul 2004 10:16:16 -0400

Paul Hoffman / IMC wrote:
>> minority, we'll recognize consensus the other way.  However, it will 
>> be unacceptable to reference an unregistered URI scheme.
> 

At the moment, the Atom drafts reference an unregistered MIME type.  I 
presume that it is possible to correograph the registration with the 
final approval of the Atom specs.

Is it not possible to do likewise with the registration of URL schemes?

- Sam Ruby

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 26 Jul 2004 08:42:50 -0700

At 10:16 AM -0400 7/26/04, Sam Ruby wrote:
>At the moment, the Atom drafts reference an unregistered MIME type. 
>I presume that it is possible to correograph the registration with 
>the final approval of the Atom specs.

Yes, this is commonly done.

>Is it not possible to do likewise with the registration of URL schemes?

Yes, for URL schemes that are not controversial.

--Paul Hoffman, Director

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Mon, 26 Jul 2004 18:47:22 +0200

On Sun, 25 Jul 2004 23:44:23 -0400, Bob Wyman <[email-masked]> wrote:

> many more.

Off-topic, but anyway: How do you compute the MD5 hashes? Since you  
mentioned that whitespace make entries diff, even if they are the same,  
would it help to do the diff and/or MD5 hashing on the infoset instead of  
the XML string? Or do you compute everything based on the infoset already,  
or is loading every entry into a DOM too much computing? I'd just like to  
know.

> need *both* unique atom:ids and reliable, meaningful date-stamps.

Would this maybe underscore the need for Atom to explicitly recommend a  
URI scheme that ensures universally uniqueness, in the specification?

> We find too many dates in feeds that are dynamically generated with
> code like "Now()" and change every time you access the feed.

O-M-G. Some people are the most stupid people there is, sometimes.

---

From: Elias Torres <[email-masked]>
Date: Mon, 26 Jul 2004 12:52:06 -0400

BTW, LSID will be registered with IANA this year after the next OMG meeting:

http://www.omg.org/lsr/

Unless of course we come up with our own URN scheme for Atom or decide
for NewsML.

Elias

---

From: "Bill Kearney" <[email-masked]>
Date: Mon, 26 Jul 2004 13:17:15 -0400

> O-M-G. Some people are the most stupid people there is, sometimes.

While it is indeed pretty brain damaged, it's largely because of the
horrendously ambiguous specs.  That, combined with aggressive promotion of bad
practices and utter contempt for cooperation with others on the part of said
promoter, lead to the current state of affairs.

So I'll toss out the question, what, if any, need is there for an timestamp that
updates based on generation of the document, independent of the content itself?
It would be greatly helpful if the spec and/or examples discussed the downsides
of improper uses of timestamps.  Let's not just say when's the right time to use
a timestamp in a given element, but when it's not.  It's a shame to have to spec
/against/ stupidity but experience shows it might help.

-Bill Kearney
Syndic8.com

---

From: Mark Pilgrim <[email-masked]>
Date: Mon, 26 Jul 2004 13:03:23 -0400

> Yes, for URL schemes that are not controversial.

I guess that would rule out "http://" then.

-- 
Cheers,
-Mark

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Mon, 26 Jul 2004 19:27:56 +0200

On Sun, 25 Jul 2004 19:56:02 -0400, Elias Torres <[email-masked]> wrote:

> Leave the spec as it with just a URI? Is it a "recommendation" of
> several schemes that would serve good to both readers and publisher
> of atom feeds? Come up with an atom scheme for IDs?

Since there only seems to be one final and thorough specification for  
ID's, namely News ML ID, I think we should recommend that in the  
specification.

I've created a pace for this. Please read it and make suggestions on how  
to make it better:

<url: http://intertwingly.net/wiki/pie/PaceRecommendIdScheme>

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Mon, 26 Jul 2004 19:43:04 +0200

On Sun, 25 Jul 2004 22:12:33 -0400, Bob Wyman <[email-masked]> wrote:

> That is precisely why PaceAtomIDIsNewsML proposes that we use the
> already registered (since 2001) URN scheme for NewsML[1].

I've created a «competing» pace called PaceRecommendIdScheme[1], for the  
same purpose. The difference seems to be that your pace is more rigid to  
what atom:id may contain.

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

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Mon, 26 Jul 2004 19:52:02 +0200

> BTW, LSID will be registered with IANA this year after the next OMG  

Okay, cool.

> Unless of course we come up with our own URN scheme for Atom or decide

I think Atom should have its own URN scheme, since NewsML has the perfect  
ID syntax, but explicitly says that the NewsML URN should be used for  
NewsML resources. LSID could work, of course, but the syntax for NewsML  
URN's seems to be even stricter and better for ensuring universally  
uniqueness.

I would be happy with everything but HTTP URI's, though. All of 'tag',  
LSID and NewsML URN's would get us a lot further down Universal Unique  
Lane than HTTP URI's ever will.

---

From: Mark Baker <[email-masked]>
Date: Tue, 27 Jul 2004 11:20:50 -0400

> except that the name of the scheme is spelled backwards is what we 

+1 to using documentation.  -1 to the other options.

/me contemplates a "How to build persistent, dereferencable identifiers"
BCP.

Mark.