Subject: PaceRecommendIdScheme

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

I haven't posted directly about this pace yet, so I'm doing it now:

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

== Proposal ==

Replace section 4.2.6 and 5.5 with:

=== 4.2.6  "atom:id" Element ===

The "atom:id" element's content conveys a permanent, universally unique  
identifier for the feed.  It MUST be universally unique, which means that  
it must be unique both at the time of creation and in the future. This  
means that it SHOULD contain the date and time of when the ID was  
created.  It MUST NOT change over time, even if the feed is relocated.  
atom:head elements MAY contain an atom:id element, but MUST NOT contain  
more than one.

The content of this element, when present, MUST be a URI. The URI scheme  
of atom:id MAY be a dereferencable URL scheme (like HTTP), but MUST NOT be  
expected to be one. That means that atom:id MUST NOT be expected to be  
dereferencable; it is just an identifier. The recommended URI scheme for  
atom:id is [http://www.ietf.org/rfc/rfc3085.txt "NewsML ID"].

atom:id MUST NOT under any circumstance be relative. It MUST always be a  
complete, opaque and absolute URI that does not require any  
post-processing to fulfil the above requirements for persistency and  
universally uniqueness.

=== 5.5  "atom:id" Element ===

The "atom:id" element's content conveys a permanent, universally unique  
identifier for the entry.  It MUST be universally unique, which means that  
it must be unique both at the time of creation and in the future. This  
means that it SHOULD contain the date of when it was created.  If the  
entry is served dynamically, the ID MUST be created only once and then  
stored along with the entry. The ID MUST NOT be created dynamically.

It MUST NOT change over time, even if other representations of the entry  
(such as a web representation pointed to by the entry's atom:link element)  
are relocated.

For a given entry, the atom:id element's content MUST be stable across all  
Atom Documents published by the same entity. This means that if the entry  
is represented in many different feeds simultaneously, the atom:id of  
these entries MUST be the same.

atom:entry MUST contain exactly one atom:id element.  The content of this  
element, MUST be a URI. The URI scheme of atom:id MAY be a dereferencable  
URL scheme (like HTTP), but MUST NOT be expected to be one. That means  
that atom:id MUST NOT be expected to be dereferencable; it is just an  
identifier. The recommended URI scheme for atom:id is  
[http://www.ietf.org/rfc/rfc3085.txt "NewsML ID"].

atom:id MUST NOT under any circumstance be relative. It MUST always be a  
complete, opaque and absolute URI that does not require any  
post-processing to fulfil the above requirements for persistency and  
universally uniqueness.

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

---

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

>[http://www.ietf.org/rfc/rfc3085.txt "NewsML ID"].

Sorry, but like others, I find it totally inappropriate to pick out
one particular scheme. There are other schemes that work in quite a
similar way, and there are still other schemes that cover other
needs that other people may feel is important in their applications.
There may also be new schemes in the future that cover still
different requirements.

Also, at least the current definition of the newsml scheme is
tied to NewsML documents, and Atom isn't nor shouldn't be
restricted to such. Also, Atom should not put requirements or
restrictions on the newsml scheme and the NewsML community.

Giving examples may be okay, but there should be more than one
example. With the language above, there is a risk some blogging
tools hard-code newsml into their code. That would be bad.

Regards,    Martin.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 29 Jul 2004 20:52:47 +0200

On Thu, 29 Jul 2004 17:29:14 +0900, Martin Duerst <[email-masked]> wrote:

> one particular scheme.

Okay.

> There are other schemes that work in quite a similar way, and there
> are still other schemes that cover other needs that other people may
> feel is important in their applications.

No one refuses anyone to use any other scheme. I just want to recommend  
one so Bob and his friends can find it easilly, and thus at a lesser cost  
and higher probability be able to generate universally unique and  
immutable ID's.

> There may also be new schemes in the future that cover still

Sure. That goes for absolutely all specifications referenced from ours.  
Specifications will be superseded and replaced with newer and better  
specifications in the future. We can't prevent that. We also don't forbid  
anyone to use such a future scheme either, as long as it generates a valid  
URI.

> restricted to such.

That's not a big problem. As Laurent Le Meur writes[1]:

   As the IPTC has already thought about a modification of the wording
   of the RFC3085 (there is an ambiguity in some wording), removing the
   express association between this URN and NewsML NewsItems could
   perhaps be studied by the IPTC, if NewsML URN are of interest for a
   broad range of users.

> Also, Atom should not put requirements or restrictions on the newsml
> scheme and the NewsML community.

Why would it? If the NewsML community agrees and maybe even encourages  
Atom's usage of NewsML URI's, why should we refrain from using it?

> example.

Sure. Dare has said that he will provide some examples soon.

> With the language above, there is a risk some blogging tools hard-code
> newsml into their code. That would be bad.

Although I don't necessarily think that it's a very good idea; why would  
that be bad, exactly?

____
[1] <url: http://www.imc.org/atom-syntax/mail-archive/msg07933.html>

---

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

>and higher probability be able to generate universally unique and

My guess is that if we just recomment a scheme, then we will
just get something hard-coded, with some assumptions that easily
may break the properties we need. We really have to get the
message out there that it's not the scheme that counts, it's
how the ids are created and maintained properly.

>   perhaps be studied by the IPTC, if NewsML URN are of interest for a

How long do you think it might take the IPTC to 'perhaps study if
NewsML URN are of interest for a broad range of users'? Do you
want to wait that long for the Atom spec to finish? I don't.

>Atom's usage of NewsML URI's, why should we refrain from using it?

Nobody is telling anybody that we should refrain from using it.
But if we make it the only scheme, or the 'recommended' scheme,
we are bound to put additional requirements and pressure on that
scheme, which may not work out well in the long range.

As a (theoretical) example, assume that currently newsml:
would be allowed to point to anything, but for certain
reasons, the IPTC wanted to change the definition so that
new ids created would only refer to NewsML items. As long
as Atom isn't depending on newsml:, they could do that
rather easily according to their needs. But if we start
to heavily rely on newsml:, we wouldn't like them to make
any kind of such change. So in essence, we infer on their
ability to move newsml: to where they want it to go for
their needs.

>Although I don't necessarily think that it's a very good idea; why would

Because some people may want to use different ids, or may
want to use different ids because their content comes from
somewhere else and already has an id.

Regards,    Martin.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 30 Jul 2004 23:08:50 +0200

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

> may break the properties we need.

I'm not saying recommending a scheme is enough. Please read  
PaceRecommendIdScheme if you haven't, because that pace does a lot more  
than just recommending a scheme. It still doesn't do enough to prevent bad  
ID's, though, so any language on how to improve it is appreciated.

> We really have to get the message out there that it's not the
> scheme that counts, it's how the ids are created and maintained
> properly.

Definately. Though, recommending a scheme other than HTTP will make people  
stop thinking that the URI is dereferencable, and thus make it a lot less  
transient. It has been said that the problem with HTTP URI's is not that  
they're HTTP URI's, but the way people think about HTTP URI's. It's this  
line of thought we need to fight and prevent, and the most effective way  
to do it, is to recommend another scheme.

> want to wait that long for the Atom spec to finish? I don't.

If we agree that it's a good idea to recommend a scheme, it's just to  
begin pushing on LSID and 'tag' to finish, and IPTC to widen NewsML URN's  
application space. If either of this is done by the time Atom goes 1.0, we  
will have to reconsider recommending a scheme, but if one or more of them  
are, there's no problem.

> scheme, which may not work out well in the long range.

Maybe, maybe not. I'm not all that worried about the impact Atom's  
recommended URI scheme will have on the picked scheme, though.

> new ids created would only refer to NewsML items.

Maybe, and just maybe, this is a good point and example. I'd like to note,  
though, that it's perfectly fine for Atom to specify its own URI scheme.  
It's also no problem changing the recommended scheme whenever this happens.

> Because some people may want to use different ids, or may want to use
> different ids because their content comes from somewhere else and
> already has an id.

I'd say that most existing ID's don't conform to atom:id's requirements  
anyway, so that's not something I'm concerned about. atom:id is probably  
the most important facet of Atom publishers needs to conform to, and I  
don't think any tool conforms to it today.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sat, 31 Jul 2004 23:41:14 +0200

>atom:head elements MAY contain an atom:id element, but MUST NOT contain  

If the element content identifies the feed it cannot change. Some entity
might change the element content, but it would then be a different feed.
While it might be undesirable to have different identifiers for feeds
commonly perceived as equal, I don't think it is reasonable to make that
a conformance criteria. It is not possible to write software that tests
whether it changed with perfect reliability, for example.

It is also not clear to me when two feeds are considered equivalent,
which would be necessary to determine whether the id changed. If the
author, title, tagline, and primary subject of the feed are changed, can
it still be the same feed? I also see valid reasons to "change" the id,
e.g. if the old id refers to a DNS name which is no longer controlled by
the feed author.

The same applies to uniqueness. While it might be undesirable if one
identifier identifies different feeds, I do not think this requirement
is reasonable. It would mean that I can  publish an Atom document with
<id>tag:diveintomark.org,2001-07-29:/</id> it would render Mark's feed
non-conforming. I do not think it should.

It would be better to include an informational note that publishers
should take all reasonable steps to maintain the identifier. We can also
specify that entry <id>s MUST be locally unique, and that intermediaries
MUST NOT change <id>s, etc., but we should stick to things that are at
least reliably human-testable.

>atom:id is [http://www.ietf.org/rfc/rfc3085.txt "NewsML ID"].

I do not understand what beeing expected to be a dereferencable URL
scheme means in this context. Maybe you want to state that Atom software
must not attempt to dereference the identifier? What is the use case for
empty <id> elements? Your text appears to allow that... I am opposed to
recommend a specific (list of) schemes.

>post-processing to fulfil the above requirements for persistency and  

I think it is okay to prohibe relative references, but I think fragment
identifiers should be allowed. I have no idea what the part about
post-processing could mean, could you elaborate?

>=== 5.5  "atom:id" Element ===

I don't think it is a good idea to duplicate all the content, it makes
it rather difficult to learn how atom:id differs for feeds and entries.