Subject: A simpler proposal: PaceAtomIDAsString

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 3 Aug 2004 14:22:02 -0700

Greetings again. The earlier thread on atom:id made it clear that 
people really, really want to compare things consistently, and that 
using URIs might get in the way of that. Thus, I have made a 
simplifying proposal at 
<http://intertwingly.net/wiki/pie/PaceAtomIDAsString>.

It explicitly allows URIs for people who want URIs, and allows plain 
text for the rest of us.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Tue, 03 Aug 2004 23:45:37 +0200

> <http://intertwingly.net/wiki/pie/PaceAtomIDAsString>.

Hm. I actually thought you were joking when you proposed this the first  
time. :-) Anyway: +1!

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

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 3 Aug 2004 15:14:58 -0700 (PDT)

> It explicitly allows URIs for people who want URIs,

Where are the guidelines that make it so that people
can create globally unique identifiers using arbitrary
strings? 

=====
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!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 3 Aug 2004 15:52:20 -0700

>can create globally unique identifiers using arbitrary

Um, in the same place as the guidelines that make it so that people 
can create globally unique identifiers using URIs?

That is, they are the same.

--Paul Hoffman, Director

---

From: Graham Parks <[email-masked]>
Date: Wed, 04 Aug 2004 00:18:21 +0100

><http://intertwingly.net/wiki/pie/PaceAtomIDAsString>.

I agree 100% that the id should always be treated as a string. My problem is that with no rules on format, a publisher can only guessing that your identifier is unique, which isn't a problem with say, tag URIs. eg Gizmodo's GUIDs look like:

   <guid isPermaLink="false">18819@http://www.gizmodo.com/</guid>

Yes, it's unlikely anyone else will use a GUID like that, but it's very hard to be sure.

Graham

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 04 Aug 2004 01:30:43 +0200

><http://intertwingly.net/wiki/pie/PaceAtomIDAsString>.

Hmm, it would make more sense to me to specify that the content must
be for example the uc(md5_hex()) of some reasonably unique data and
that implementations must not change the id without the user's consent,
specifically not if [common cases]. That would avoid confusion about
normalizing, resolving, dereferencing, comparing, ... the id, which
scheme to choose, how to structure it, etc. while still providing the
necessary functionality. It would certainly yield in duplicate IDs and
there will still be authors and implementations that do not generate
proper IDs, but as far as I can see implementations will have to deal
with that anyway. Your proposal just obfuscates the issue as common
practise will likely be to use URIs anyway, which would likely yield
in all the problems we have when the spec says it is a more special
kind of string.

---

From: Bill de hÓra <[email-masked]>
Date: Wed, 04 Aug 2004 01:11:36 +0100

Paul Hoffman / IMC wrote:

> 
> Greetings again. The earlier thread on atom:id made it clear that people 
> really, really want to compare things consistently, and that using URIs 
> might get in the way of that. Thus, I have made a simplifying proposal 
> at <http://intertwingly.net/wiki/pie/PaceAtomIDAsString>.

> It explicitly allows URIs for people who want URIs, and allows plain 

According to the pace, it's not plain text for the rest of us, it's 
Unicode for the rest of us. If the comparison rules are to be 
character based over Unicode, that would suggest the Unicode 
encoding must also be specified so we know how many bytes are being 
used per character and so on. A 'string of Unicode characters' isn't 
sufficient by itself. Perhaps the Pace is using "character" in a 
non-Unicode sense (if so, that's confusing). If the intention is 
really to compare on Unicode characters/codepoints independent of 
the encoding scheme (ie along the lines of some kind of Unicode 
'Infoset'), that needs to be said - it's certainly not plain text 
anymore.

But:

"Even if a particular atom:id instance looks like a URI, it SHOULD 
NOT be treated as one."

doesn't seem consistent with the idea that we can have URIs if we 
want. The pace is saying (to me) something along these lines "if it 
looks like a HTTP URL you shouldn't run GET on it; if it looks like 
a NewsML URI you shouldn't infer from the versioning bits". We have 
experience that suggests people will not be able to oblige 
themselves to this kind of constraint. IMO it should be struck.

Generally I'm concerned that we will use URI scheme structures to 
generate unique keys (they're handy for that) and thus end up with 
Unicode strings that look like URIs but are not supposed to be 
treated as URIs, ever where those URIs have comparison and 
normalization rules. I believe this is maximally surprising.

May I suggest this wording for the time being:

"       The "atom:id" element's content conveys a permanent, 
globally unique identifier for the feed. It MUST NOT change over 
time, even if the feed is relocated. An atom:head element MAY 
contain an atom:id element, but MUST NOT contain more than one. The 
content of this element, when present, MUST be a string of Unicode 
characters encoded as UTF-8. When atom:id elements are compared, 
they MUST be compared on a character-by-character basis.

       It is not a goal that atom:id be usable for retrieval of 
information.

       Historically, in syndication feeds, the detection of 
duplicates has been error-prone because of failure to assign 
identifiers which are globally unique and stable. Identifiers have 
been observed to change when a feed moved hosts or when an entry was 
reassigned to a different category or its title was edited. The 
management of globally unique and immutable identifiers requires 
prior planning and extra effort, but this is more than justified by 
the benefits of robust duplicate detection. "

Of course this begs the question - what if the Atom is encoded as 
UTF-16?

In all seriousness, perhaps I just don't understand the pace.

cheers
Bill

---

From: Tim Bray <[email-masked]>
Date: Tue, 03 Aug 2004 17:40:04 -0700

On Aug 3, 2004, at 5:11 PM, Bill de hÓra wrote:

> character based over Unicode, that would suggest the Unicode encoding 
> must also be specified so we know how many bytes are being used per 
> character and so on. A 'string of Unicode characters' isn't sufficient 
> by itself.

All your other points aside, yes it is sufficient.  This is appearing 
in an Atom feed which is an XML document, right?  In an XML document, 
element content or attribute value can contain any legal XML character 
(a generous subset of Unicode)... what encoding the XML document is in 
is an orthogonal issue.

[Not commenting on the proposal itself, just saying that this 
particular criticism is off-base] --Tim

---

From: Ken MacLeod <[email-masked]>
Date: 03 Aug 2004 20:12:19 -0500

> It explicitly allows URIs for people who want URIs, and allows plain

We'll probably need to make sure we can create links to these "Atom
string IDs" that are different than URI links:

    <link rel="in-reply-to" atom-id="1234"/>
    <link rel="related"
       href="http://home.introweb.nl/~dodger/itunesserver.html"/>

  -- Ken

---

From: Bill de hÓra <[email-masked]>
Date: Wed, 04 Aug 2004 02:09:59 +0100

Tim Bray wrote:

> All your other points aside, yes it is sufficient.  This is appearing in 
> an Atom feed which is an XML document, right?  In an XML document, 

I don't see that.

The pace seems to want to bring up Unicode character compares sans 
encodings, but it's being discussed in the context of plain text, it 
says URIs aren't to be treated URIs, but it's being discussed in the 
context that you can have your URIs if you want. And now we're 
talking about the legal range of XML characters in element content!

If it's the case that you're right (encoding has nothing to do with 
atom:id comparison), why don't we say something around XML 
characters directly instead of Unicode directly - then we can talk 
about 'XML plain text'.

cheers
Bill

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 3 Aug 2004 18:44:13 -0700

At 12:18 AM +0100 8/4/04, Graham Parks wrote:
>I agree 100% that the id should always be treated as a string. My 
>problem is that with no rules on format, a publisher can only 
>guessing that your identifier is unique, which isn't a problem with 
>say, tag URIs.

As has been said on this list before, publishers are "only guessing" 
that for any ID, including one that is a tag: URI.

At 1:30 AM +0200 8/4/04, Bjoern Hoehrmann wrote:
>be for example the uc(md5_hex()) of some reasonably unique data

That's good if you want opaque identifiers, but I haven't heard any 
need (or even desire!) for those so far.

>  and
>specifically not if [common cases].

That wording would be true for any atom:id proposal. But it's kind of 
obvious, isn't it? Do we really need to state it?

>Your proposal just obfuscates the issue as common

I'm not sure why you think it will be common practice. It's easy to 
do the right thing here and munge together a DNS name, a time, and a 
random string.

At 1:11 AM +0100 8/4/04, Bill de hÓra wrote:
>Unicode for the rest of us.

Those are *identical*.

>  If the comparison rules are to be character based over Unicode, 
>that would suggest the Unicode encoding must also be specified so we 
>know how many bytes are being used per character and so on.

Nope, exactly wrong. It is character-by-character, not byte-by-byte.

>a NewsML URI you shouldn't infer from the versioning bits".

Correct.

>  We have experience that suggests people will not be able to oblige 

How do others feel about this? I thought the discussion trend was 
going towards "do not deference atom:ids".

>they MUST be compared on a character-by-character basis.

I don't think that would not work in a document whose encoding is 
anything other than UTF-8.

>       It is not a goal that atom:id be usable for retrieval of information.

I'm OK with that wording.

--Paul Hoffman, Director

---

From: Robert Sayre <[email-masked]>
Date: Tue, 03 Aug 2004 22:11:39 -0400

> Nope, exactly wrong. It is character-by-character, not byte-by-byte.

How about putting it in an attribute, and directing implementors to compare
normalized attribute values? [0]

"When atom:id elements are compared, they MUST NOT be considered identical
unless their @foo attributes have identical normalized values."

Robert Sayre

[0] http://www.w3.org/TR/REC-xml/#AVNormalize

---

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

> normalized attribute values? [0]

Good idea in principle, but in practice I believe attribute 
normalization is kind of icky and tricky.  James Clark complained about 
it to me at least once, and if James thinks it's hard, it's hard. -Tim

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 04 Aug 2004 04:43:44 +0200

>need (or even desire!) for those so far.

Well, as far as I can see, none of the arguments against specific URI
schemes, specific kinds of URIs, specific forms of URIs, etc. applies
to such identifiers... and I do not understand how that would be more
opaque than what you propose.

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 3 Aug 2004 21:33:26 -0700 (PDT)

> That is, they are the same.

I still don't get it. For URI schemes the consensus
seemed to be to pick some combination of (scheme +
domain + date + extra gunk) for individual schemes to
maintain uniqueness. Are you claiming that using some
similar syntax will be adopted for saying that any
arbitrary string can be an atom:id, if so where in the
Pace is this highlighted? 

=====

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

---

From: David Powell <[email-masked]>
Date: Wed, 4 Aug 2004 12:51:21 +0100

> It explicitly allows URIs for people who want URIs, and allows plain 

-1

The main advantage in using URIs is that it provides a hierarchy of namespaces
which can be delegated out from authorities to publishers to ensure uniqueness
of ids.

ISBN numbers, XML Namespaces, RFC822 Message-Ids, even UUIDs use namespaces in
this way to help ensure global uniqueness of ids.

I don't see how allowing people to create ids in any format that they feel
like,
without requiring any namespacing, can improve on the situation of
having namespacing, albeit namespacing that might fail in edge cases.

My prefered aproach would be for atom:ids to be created as URIs to aid
uniqueness, but to then to be stored, and compared as opaque strings by all
parties after that point.  I don't see why any normalization or canonicalization
should be required within Atom because Atom does not require dereferencing of
ids.

I don't see how Tim's argument that spiders normalize URLs applies to atom:ids.

Atom ids provide no guarantee of dereferenceability, and they will not be
written on busses.  Spiders normalize URLs because URLs get copied around by
humans, and if two different locators work for the same site, then they are
equivalent.

This is not the case for Atom ids.  Atom ids are not used as locators within
Atom, they get created once by the publisher, and then stored in a database or
wherever, if they are different then they are different.

I would agree that Atom agents should be allowed to normalize FeedURIs in Atom
then I would agree because the FeedURI is used as a locator, variants will
work, so it makes sense that these variants should be treated as equivalent. 
This does not apply to atom:ids.

If publishers wan't to make their id's dereferenceable then they can do, and
agents such as spiders that dereference those ids can consider canonicalizing
them, but that is nothing to do with Atom.

-- 
Dave

---

From: Sam Ruby <[email-masked]>
Date: Wed, 04 Aug 2004 08:31:23 -0400

> should be required within Atom because Atom does not require dereferencing of

If we state that atom:id is a URI, then this likely will be captured in 
a schema as xsd:anyURI.  On platforms like .Net, this will generate code 
that uses the native System.Uri class.  This will convey some advantages 
in producing feeds and protocol requests in that there are built-in 
checks to ensure that the URIs produces are all well-formed.

On the consumption side, however, this will imply that all URIs are 
effectively canonicalized.

IMHO, we should recognize that fact and either require canonicalization 
(my preference), or drop the requirement that ids be URIs and live with 
the consequences of having to deal with feeds like the following (look 
for guid):

http://www.keepmedia.com/rss/featurednews/
http://www.microsite.reuters.com/rss/topNews

- Sam Ruby

---

From: Ken MacLeod <[email-masked]>
Date: 04 Aug 2004 10:54:22 -0500

> It explicitly allows URIs for people who want URIs, and allows plain

-1 to an "internal (to Atom systems) only" identifier.

As defined, this identifier can only be considered an "internal"
identifier, not a public identifier.  The suggestion that a "public
identifier can be used in this field to create a unique internal
identifier" does not make atom:id a public identifier and means that
systems that interface with Atom have no defined way of using it as
public identifier.

There is a significant difference between saying that "atom:id is not
intended as a primary access mechanism" and "atom:id is not intended
to be dereferencable".  Currently, most of the proposals say the
latter, when I believe what is meant is the former.

"Dereferencing" is a broader term than whether a resource can be
fetched using HTTP or FTP.  It also means the ability to use the URI
in finding other locations of the resource and in making references to
the resource[1].  An "internal only" identifier restricts that to Atom
enabled processing systems only, which seems short sighted.

Previous proposals have used the term "URI" with the implication that
they are "public identifiers", mostly because URIs are the only
significant public identification system in use on the Internet today.

If the intent is to not use public identifiers for Atom resources,
that should be stated more clearly so implementors can be more
informed about what they are seeking concensus on.

  -- Ken

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 4 Aug 2004 09:20:31 -0700

>which can be delegated out from authorities to publishers to ensure uniqueness

Fully disagree. Those namespaces can be expressed as strings as 
easily (or more easily) than as URIs.

>this way to help ensure global uniqueness of ids.

For example, ISBN numbers and RFC2822 Message-Ids are created as 
strings, not as URIs.

--Paul Hoffman, Director

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 4 Aug 2004 09:12:51 -0700

>opaque than what you propose.

Sorry, I'm confused. I am not proposing making IDs opaque; I thought you were.

--Paul Hoffman, Director

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 4 Aug 2004 09:17:36 -0700

At 9:33 PM -0700 8/3/04, Dare Obasanjo wrote:
>maintain uniqueness.

Agree.

>  Are you claiming that using some

No, I copied the text from the current pace. Whether or not people 
like the "strings instead of URIs" idea, we can add the proposed 
suggestion of "domain + date + extra gunk". Suggesting that the 
"extra gunk" have randomness in it might be useful as well.

--Paul Hoffman, Director

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 4 Aug 2004 09:10:16 -0700

>normalized attribute values? [0]

That's OK with me, if we believe that everyone's normalization code works.

At 7:34 PM -0700 8/3/04, Tim Bray wrote:
>normalization is kind of icky and tricky.  James Clark complained 
>about it to me at least once, and if James thinks it's hard, it's 
>hard.

Sounds like a reasonable reason not to do it, but others have gotten 
normalization down reasonably well in the real world so far.

--Paul Hoffman, Director

---

From: Tim Bray <[email-masked]>
Date: Wed, 04 Aug 2004 09:30:35 -0700

On the whole atom:id thing, may I suggest that this is mostly about 
marketing, not technology.

First of all, I acknowledge that I was originally against the idea of 
atom:id but have become convinced that it's sound, in part because of 
the immense numbers of duplicate entries in my RSS feeds (particularly 
the synthetic ones) every morning.

I think the most important thing about atom:id is that we market the 
hell out of it, make it clear that it's required to be there and 
required to be unique and required not to change.  So it's an 
evangelism/marketing problem, not a technical problem.

Second, personally I can live with pretty well any of the proposals out 
there, the one I advanced saying they're URIs but dereferencing is a 
non-goal and with a lot of drum-banging about persistance and 
uniqueness, or Sam's proposal adding the requirement that have to be 
canonicalized (same drum-banging) or Paul's suggestion that they just 
be strings (same drum-banging).  So for me, the tactics are: grab 
whatever will build consensus and make sure we get the evangelism 
right.  The only thing I'm clearly against is specifying a URI scheme.

So the meaningful arguments on URI vs string seem pretty simple: On the 
upside, IF we say it's a URI, then there exist helpful and 
widely-implemented ways around to mint URIs that have an excellent 
chance of being globally unique and persistent, and it will cut down on 
the required creativity and maybe increase the net chances of getting 
useful atom:id's.

On the downside, if we say it's a URI, some people are moronically 
going to assume it has to be the current URI in use, and change it when 
they move the entry, thus defeating the purpose.

Of those two, the upside of URIs looks maybe a little better than the 
downside, but if a majority disagrees, hey, I'm there.

But either way, let's get lots of shouting and yelling in the spec 
about the importance of uniqueness and persistence.

If others agree that the technical arguments aren't that big a deal, 
maybe I should run another survey and we all agree to get behind 
whatever gets the plurality?

BTW, I totally don't think the arguments from URI comparison are 
relevant, the most insanely overaggressive URI comparator in the world 
isn't going to be producing false positives unless someone actively 
sets out to be malicious, so I don't think this is a factor in choosing 
whether to not to make atom:id a URI. -Tim

---

From: Elias Torres <[email-masked]>
Date: Wed, 4 Aug 2004 13:04:41 -0400

BTW, all that would be doing is re-creating what URNs are supposed to
be doing in the first place and what other URN specs have already
defined beyond what we are responsible for doing in this spec. This
discussion is getting nowhere. This issue it's just a matter of
compromise, we do not need to invent something new.

Again in summary we have:

1. Use URIs
2. Use one or more existing URN schemes
3. Use xsd:strings

From monitoring the list for a few weeks now, I think there are plenty
of people that have problems with URIs (except for Tim, Martin and a
couple of others) for the overall reason that they are too broad and
general to make them "identifiers", plus other issues like
normalization, encoding and parsing. IDAsString is trying to solve
some of the issues from URIs (byte-per-byte, char-per-char,
codepoint-per-codepoint, whatever), but starts all over on the fact
that it does not help the users/applications to generate a proper
identification. Lastly, the problem with picking an existing URN
scheme is that it's too specific and it might not satisfy everyone.

For the last argument, I disagree. The spec is responsible to limit
elements if we feel that it will help those using them. Why use XML?
Why require only one title? Why have author? Why is author string? Why
is author binary? For the answer to the questions, I feel it's ok to
pick something and stick with it. What is the purpose of atom:id? To
identify. They need to be what we say they will and so people will be
able to write code that makes use of them. atom:id is extremely
important for this type of technology and so we have a chance of
really making a difference. Punting by using URIs will not be of great
use, even though it will sound flexible, extensible and/or general.

Tim/Paul as chairs need to help us solve this discussion because it's
taking too long. I have tried to compromise by not making anymore
waves, but the issue keeps coming back over and over. I know where Tim
stands, but I think that enough people have issues with URIs so we
need to start narrowing the choices down, vote/whatever and move on. I
know URIs will never be such a bad end-result because we usually
prefer to make decisions that result in less value rather than cause
more harm. URIs will cause less harm than if we pick the wrong scheme
or strings, but since many are raising concerns, we need someone to
arbitrate not take a side.

From the RFC:

 A URN differs from a URL in that it's primary purpose is persistent
  labeling of a resource with an identifier.  That identifier is drawn
  from one of a set of defined namespaces, each of which has its own
  set name structure and assignment procedures.  

Elias Torres

---

From: Sam Ruby <[email-masked]>
Date: Wed, 04 Aug 2004 14:16:00 -0400

> whatever gets the plurality?

It probably is time for a poll, but my fear is that the way the question 
is phrased will determine the outcome.

I care more about "clearly and thoroughly specified" than I do about uri 
vs string.  Let me enumerate the scenario that concerns me:

1) a SOURCE generates a feed containing entries with ids which are not 
in canonical form.  Just to make the scenario definate, let's say that 
the atom:ids feeds contain a "%7E" in the path portion of the URI.

2) a REPUBLISHER (like PlanetSun, but written in .Net) consumes the 
feeds based on the published schema and serializes an aggregated site 
based on the same.  The ids are morphed from a "%7E" to a "~" in the 
process.

3) a CONSUMER written in Java will see these URIs as being different. 
(Note: a CONSUMER written in .Net won't see any problems).

So: if we go with URIs, I want to make sure that we need to select one 
of three "culprits" in the above scenario:

1) The SOURCE generated a feed that is invalid
2) The REPUBLISHER made an invalid transformation
3) The CONSUMER didn't implement equivalence properly

If we decide that the SOURCE is wrong, then this is something that can 
easily be checked for in the feedvalidator and will generally not 
involve much of a burden to producers.

If we decide that the REPUBLISHER is wrong in the scenario above, then 
the schema should be xsd:string and we shouldn't be messing with URIs at 
all (IMHO).  We lose some benefits of URIs, but interoperability doesn't 
suffer.

If we decide that the CONSUMER is wrong, then the overhead is a bit 
more; while SOURCES have the luxury of knowing their own URI scheme, 
CONSUMERS have to deal with every eventuality.

My concern is that if we don't pick one, the inevitable result will be 
that the burden is passed down to the CONSUMER and that it will become 
common knowledge that consumers will need to aggresively normalize URIs. 
  Such knowledge won't be backed up by any spec text.

So... if there are choices, I want to make sure that they all are 
cleanly and thoroughly specified.  I personally will vote against any 
choices which involve hand waving in the form of "the problems aren't 
likely to occur all that often anyway".

- Sam Ruby

---

From: Dave Pawson <[email-masked]>
Date: Wed, 04 Aug 2004 19:19:40 +0100

> evangelism/marketing problem, not a technical problem.

A good perspective Tim. Without the marketing hype I simply can't see it
happening, there is no carrot, and no stick.
   It'll confuse readers is of very little concern to the
non-egotistical author.

On the evil side, if I choose a really well read blog, and duplicate
their url's as id's, can I 'hack' my way into being well read? If these
id values may not be de-referenced, perhaps yes? Will this be the
equivalent of moving up the google ratings?
Is this a possibility?
Can we protect against that somehow?

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

---

From: Graham <[email-masked]>
Date: Wed, 4 Aug 2004 14:44:29 -0400

> based on the same.  The ids are morphed from a "%7E" to a "~" in the 

The republisher is wrong for mangling the id.

<id>http://www.example.com/~user/</id>

and

<id>http://www.example.com/%7Euser/</id>

are clearly not the same. But there's no need for PaceAtomIDAsString 
(which is an unworkable idea) - just state in the verbiage about it 
being good to use the same id when republishing that it has to be the 
same characters. I know this isn't schema-friendly, but we've said 
before that schemas are a secondary concern.

Graham

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 4 Aug 2004 12:09:33 -0700 (PDT)

> Can we protect against that somehow?

I dunno. What happens if you create an RSS feed and
use the links to a popular weblog as values as your
rdf:about/guid values? Whatever happens there is
exactly what would happen in the Atom case. 

=====

---

From: "Bob Wyman" <[email-masked]>
Date: Wed, 4 Aug 2004 15:47:24 -0400

Tim Bray wrote:
> The only thing I'm clearly against is 
> specifying a URI scheme. ...
> let's get lots of shouting and yelling in the spec 
	It seems to me that one way to increase the level of understanding
of how to do things properly would be to provide one of the following:
	1. An example URI scheme (i.e. show a tag or newsml id and discuss
why it meets the requirements of atom.
	2. A recommended URI scheme or schemes (i.e. recommend one or more
of tag, newsml, publicid, etc.)
	Would the level of objection to mentioning a specific scheme be
reduced if we only presented the specific scheme or schemes as examples or
recommendations?
	Personally, I think it is vital that readers of the spec be exposed
to at least one "satisfactory" scheme before they go off to invent their own
schemes.

		bob wyman

---

From: Tim Bray <[email-masked]>
Date: Wed, 04 Aug 2004 13:00:55 -0700

> why it meets the requirements of atom.

Well, tag: isn't registered and urn:newsml: is specifically limited to 
NewsML information, not Atom information.  So one problem is that there 
actually isn't right now a terrifically attractive properly-registered 
scheme.  Except of course for well-constructed and managed HTTP URIs, 
which is exactly what everyone is trying to avoid. -Tim

---

From: Robert Sayre <[email-masked]>
Date: Wed, 04 Aug 2004 13:08:19 -0400

> That's OK with me, if we believe that everyone's normalization code 

I tried the following in Mozilla and IE, both of which use 
non-validating parsers when you just view an xml file, I believe. I've 
grouped the elements where their normalized attribute values are 
expected to be identical. IE/MSXML appeared to trim the trailing 
whitespace in the third set of elements, which I don't believe it should 
do for CDATA attributes, but it was consistent. I don't see how we can 
compare based on anything else.

Robert Sayre

<?xml version="1.0" standalone="no" ?>
<!DOCTYPE dtd_test[
<!ENTITY foo "http://example.com">
<!ENTITY bar "http://example.net">
<!ENTITY baz "http://example.net">
<!ENTITY quux "#2003,04,23452345">
]>
<test>
  <id uri="&foo;" />
  <id uri="http://example.com" />
 
  <id uri="&bar;" />
  <id uri="&baz;" />
 
  <id uri="http://example.net " />
  <id uri="&bar;&#x9;" />
  <id uri="&baz; " />
  <id uri="&baz;&#xA;" />
  <id uri="&baz;
" />

  <id uri="http://example.com#2003,04,23452345"  />
  <id uri="http://example.com&quux;" />
</test>

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 04 Aug 2004 22:15:11 +0200

>Sorry, I'm confused. I am not proposing making IDs opaque; I thought you were.

As far as I can see, the above is a subset of what you propose.
Why is "any string" less opaque than "specific strings"?

---

From: "Bob Wyman" <[email-masked]>
Date: Wed, 4 Aug 2004 18:40:32 -0400

Tim Bray wrote:
> So one problem is that there actually isn't right 
> now a terrifically attractive properly-registered 
> scheme.
	Would it be acceptable to insert some non-normative text that
described how to use a "properly registered" URN scheme, such as
urn:publicid, in a way that met Atom's requirements. The non-normative text
would:
	1. Recommend use of a properly registered scheme such as
urn:publicid
	2. Note that the combination of domain+date+unique-stuff works well
in most cases.
	3. Show some examples of "satisfactory" urn:publicid-based
identifiers as well as some that are not satisfactory.
	i.e. urn:publicid:pubsub.com:20040804:example1 is good,
urn:publicid:5443234 is bad...

		bob wyman

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 4 Aug 2004 15:53:03 -0700

>As far as I can see, the above is a subset of what you propose.

Nope, not at all. I didn't say or suggest md5 of anything.

>Why is "any string" less opaque than "specific strings"?

Again, I'm not understanding what you said. I didn't discuss making 
the strings opaque in the pace.

--Paul Hoffman, Director

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 4 Aug 2004 15:48:57 -0700

>The republisher is wrong for mangling the id.

+1

--Paul Hoffman, Director

---

From: "Bob Wyman" <[email-masked]>
Date: Wed, 4 Aug 2004 19:23:03 -0400

Dave Pawson wrote:
> On the evil side, if I choose a really well read blog, and 
> duplicate their url's as id's, can I 'hack' my way into being
> well read?
	I think "spoofing" is a much more likely "evil thing".
	Someone could copy the ids of feeds or entries that they didn't like
and publish a feed with "alternative" content. They would be hoping that
news aggregators would rely on atom:id alone to detect cross-feed
duplication of entries or renaming of feeds. If the spoofer uses the id of
an "offending" entry but publishes it with a modified-date which is later
than that of the version under attack, some aggregators could be tricked
into discarding the original messages and replacing it with the spoof entry.
	Other attacks might rely on guessing the id assignment practices of
a feed and then populating another feed with entries that anticipated those
to be created in the new feed. In some cases, this could cause aggregators
to decide that entries were duplicates or old versions of the spoof entries.
There are a variety of flavors to this type of attack. Most should be
obvious.

> Can we protect against that somehow?
	Not without some difficulty. Methods include:
	1. Relying on digital signatures and various PKI solutions. (i.e.
signed ids).
	2. Only comparing atom:id's within the scope of a single "source"
feed. (i.e. don't support cross feed duplicate detection based on atom:id
values alone.)
	3. Relying on id assignment schemes that at least ensure that you
violate some rule (and potentially law) when you spoof someone. This would
mean we'd have to have a registered scheme and we'd have to invest in its
use the same kind of "property rights" that are associated with domain
names. (This won't eliminate the problem but at least provides some legal
sanctions that might discourage casual spoofing.)

		bob wyman

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 05 Aug 2004 04:39:59 +0200

>the strings opaque in the pace.

Sorry but a string without any defined semantics is rather opaque to me.
As far as I understand, an element like

  <id>9DD4E461268C8034F5C8564E155C67A6</id>

would be legal under both your and my definition, you are saying it is
opaque under my definition and not opaque under your definition, that,
I am afraid, makes no sense to me at all. So you seem to be saying that
this would be non-conforming under your definition, I am however unable
to find anything in your Pace that says so. Hence I am lost here.

---

From: Dave Pawson <[email-masked]>
Date: Thu, 05 Aug 2004 09:01:42 +0100

> to at least one "satisfactory" scheme before they go off to invent their own

+1  A clear call for an informative section. Addressing both why, and
how (through examples).

---

From: Walter Underwood <[email-masked]>
Date: Sun, 08 Aug 2004 17:22:14 -0700

> -1 to an "internal (to Atom systems) only" identifier.

-1 from me, too.

Spiders will see the same content in Atom and non-Atom contexts.
An Atom-only ID is of limited use.

If the term "metadata crosswalk" is familiar, that is the sort
of thing search engines must do, all the time. This applies to
IDs, titles, even dates.

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Tue, 10 Aug 2004 22:51:06 +0200

On Wed, 4 Aug 2004 09:17:36 -0700, Paul Hoffman / IMC <[email-masked]>  
wrote:

> No, I copied the text from the current pace. Whether or not people like  
> the "strings instead of URIs" idea, we can add the proposed suggestion  
> of "domain + date + extra gunk". Suggesting that the "extra gunk" have  
> randomness in it might be useful as well.

This would be rather nice. Just see how unique RFC 822 MessageID's are,  
for example. 'MyAggregator:AsbjornUlsberg:2004-08-05:[email-masked]'  
should be fairly unique, imho.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 10 Aug 2004 15:32:57 -0700

We're still not talking about dates until tomorrow. That's US time, 
not European time. :-)

--Paul Hoffman, Director