Subject: URIs vs Strings

From: Henry Story <[email-masked]>
Date: Wed, 25 Aug 2004 23:20:32 +0200

There is a debate going on on whether to use URI's or strings for ids.
As I understand IDs have to be globally unique. So my question is:

How can a blog writer find a globally unique string to identify his 
entry with?

I think he absolutely cannot. Any string you find could have been found 
by someone else. In order to be able to make sure that a string is 
globally unique it has to be constructed according to rules that will 
guarantee uniqueness. And this means that only URI's (or URNs) can be 
used. There has to be a well defined construction mechanism.

Is there anything I am missing in that argument?

Henry
http://bblfish.net

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 25 Aug 2004 15:27:02 -0700 (PDT)

> used. There has to be a well defined construction

Incorrect. Google for "DEC AND UUID" or "Microsoft AND
GUID". URIs provide a 'cheap' and 'easy' mechanism for
coming up with globally unique identifiers. They are
NOT the only way.  

=====
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: Henry Story <[email-masked]>
Date: Thu, 26 Aug 2004 00:36:39 +0200

> coming up with globally unique identifiers. They are

You are correct. I need to restate my position.

If one wants to be able to create a globally (universally?) unique ID 
in a distributed manner [1] one needs to have rules to allow the 
construction of such an ID.

A String is by definition just a sequence of bytes. Two strings are 
identical if the sequence is identical. It has no structure apart from 
that. It certainly has no structure that says anything about creating a 
globally unique string.

So whatever an ID is it *cannot* be a String.

Henry

[1] thanks to Julian Reschke for this phrasing.

---

From: Robert Sayre <[email-masked]>
Date: Wed, 25 Aug 2004 18:52:36 -0400

Julian Reschke wrote:
> Henry Story wrote:
> No, that's correct. 
...
> URIs are the most 
> popular, flexible and and widely accepted way to achieve that goal.

It's also the agreed upon consensus[0], So there's really no debate 
here. The only open question is spec text about these URIs, but note 
that the current issues list[1] hasn't scheduled this question. IMHO, 
this debate on this issue will be more productive after a new draft of 
the format spec is issued.

Currently scheduled:

   PaceDigitalSignatures
   PaceErrVerb
   PaceEquivalents
   PaceItemLicense
   PaceReduceMustMay
   PaceServiceError
   PaceSimplifiedFeedFormat

Robert Sayre

[0] http://www.imc.org/atom-syntax/mail-archive/msg08572.html
[1] http://www.imc.org/atom-syntax/mail-archive/msg08792.html

---

From: Henry Story <[email-masked]>
Date: Thu, 26 Aug 2004 01:04:38 +0200

On 26 Aug 2004, at 00:52, Robert Sayre wrote:

>> URIs are the most popular, flexible and and widely accepted way to 
>> achieve that goal.
>
> here. The only

Ok. I understand now.
Thanks.

Henry

[snip]

> at

---

From: Julian Reschke <[email-masked]>
Date: Thu, 26 Aug 2004 00:20:32 +0200

> Is there anything I am missing in that argument?

No, that's correct. You may be able to substitute "URI" by another 
globally controlled scheme to create new IDs in a distributed manner 
(like phone numbers + private extensions), but I guess URIs are the most 
popular, flexible and and widely accepted way to achieve that goal.

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: grayrest <[email-masked]>
Date: Wed, 25 Aug 2004 23:01:27 -0400

My understanding was simply that

1. IDs must be unique and invariant
2. IDs must be compared as if they were strings
3. The easiest way to get a unique ID is to add something to an
already unique value. The easiest unique string value to come across
is a URI.

A URI which, by definition, is unique if it is canoncial. It's too
much work to do canonization, so we specify a string comparison. This
has the added benefit of enabling IRIs and whatnot in the future.

Am I missing something?

Karl

---

From: Walter Underwood <[email-masked]>
Date: Wed, 25 Aug 2004 20:33:55 -0700

> has the added benefit of enabling IRIs and whatnot in the future.

I think so. The canonicalization is done when the URI is created,
not when it is compared. Normalized comparisons are optional.
Each implementation only needs to follow the rules for the URI
scheme(s) which it creates. It isn't "too much work".

Any other URI created should also be in canonical form, so it isn't
even extra code. Please, everyone, read the seven simple rules in the
2396bis draft.

 <http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#canonical-form>

The purpose of these rules is to "minimize false-negatives" and to
"minimize the amount of software processing" in comparisons. Those are
our goals, too.

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: Dave Pawson <[email-masked]>
Date: Thu, 26 Aug 2004 06:46:34 +0100

> coming up with globally unique identifiers. They are

+1. 
Makes more sense too. 
Loses this string comparator debate too.
Uses less electrons in most cases.
Meets more needs.
Is garbage, so no one is likely to try and dereference it.
Is more likely to be globally unique (practically).
Is meant for just this class of problem.

Downside, its so obvious.... NIH strikes?

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

---

From: Dave Pawson <[email-masked]>
Date: Thu, 26 Aug 2004 06:43:07 +0100

> popular, flexible and and widely accepted way to achieve that goal.

I still thinks its a valid question,
" How can a blog writer find a globally unique string to identify his 
entry with?"

Unless the writer owns a domain name, what do you think he or she will
use when 'required' to produce a unique uri|l?

---

From: Julian Reschke <[email-masked]>
Date: Thu, 26 Aug 2004 08:53:52 +0200

> use when 'required' to produce a unique uri|l?

We can give then a utility or a web page that generates one for them. 
For instance, a urn:uuid if it ever gets approved.

Best regards, Julian

---

From: Danny Ayers <[email-masked]>
Date: Thu, 26 Aug 2004 10:32:47 +0200

[I mentioned this on another thread, but given the subject line of
this thread I'll drop it in here as well if I may be so bold...]

I fully support the use of URIs as the basis for Atom identifiers.
Atom's primary environment is the web, URIs are the identifiers of the
web. Encouraging canonicalization at source seems a good idea too.

However, if the comparisons between these identifiers is to be based
on string equivalence, then that is outside of the definition of URIs
(in RFC 2396). So to be avoid inaccuracies in the Atom documentation,
it may be useful to define a construct, URIstring, that shares all
characteristics of URIs except identity comparisons are carried out
char-by-char.

Cheers,
Danny.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 26 Aug 2004 10:50:36 +0200

> characteristics of URIs except identity comparisons are carried out

RFC2396 clearly states in section 6 
(<http://greenbytes.de/tech/webdav/rfc2396.html#rfc.section.6>) that 
there is no scheme-independant equivalence definition. Thus we define 
the method; and this is clearly what we need to do if we want to avoid 
false positives.

I *do* agree that it makes sense to have a construct that has the 
semantics of being a string that happens to have URI syntax.

Julian

---

From: Mark Pilgrim <[email-masked]>
Date: Thu, 26 Aug 2004 10:19:11 -0400

> use when 'required' to produce a unique uri|l?

tag: URIs use a combination of a domain name + a date on which you
controlled that domain as the starting point for constructing a
globally unique ID.  In the absence of a domain name, an email address
that you controlled on that date would also suffice.  (This is
mentioned explicitly in the spec.)

The usual suspects will now pounce on me and warn (correctly) that
tag: URIs are not a registered URI scheme.  But that doesn't negate
the fact that it is relatively simple to create globally unique IDs. 
All you need is something that is globally unique at a moment in time,
plus the moment in time.  Both of these are readily available.

-- 
Cheers,
-Mark

---

From: Henry Story <[email-masked]>
Date: Thu, 26 Aug 2004 16:47:17 +0200

> plus the moment in time.  Both of these are readily available.

Just for the sake of further clarification...

To be even more precise, should that not be:

All you need is:
	1- something that is globally unique at a moment in time
	2- a relation that relates you to that thing uniquely at that time
	3- a method of constructing an id with that relationship

For example the empire state building is unique. But for me to be able 
to be an ID creator there has to be a relation between me and the 
empire state building that can in some way be constructed, or else 
anyone could claim a similar relationship to that building, and so I 
would have no guarantee that the ID I created was indeed unique.

The tag scheme (which is not iana registered) works by taking a 
globally referenceable property of yours (a domain name, web page url 
perhaps) at a moment in time, specifying the moment, and adding some 
extra data of your choosing in order to give you a unique id.

If we each had ID numbers like our social security number we could also 
create our tags
that way, eg sstag:us:1203124143:/blog/1231

Henry

---

From: Danny Ayers <[email-masked]>
Date: Thu, 26 Aug 2004 17:00:16 +0200

> plus the moment in time.  Both of these are readily available.

[pounce]
But assuming that the current (misguided, IMHO) approach of advocating
non-HTTP resolvable IDs continues, then tag: URIs are technically
ideal.

The consensus is to base Atom ids on URIs, whether to use the
comparison ladder or to flatten it to a string.

Ok, so the spec shouldn't recommend the use of the tag: scheme until
it's registered. But that still fits with the proposed solutions. If
people choose to use it in practice, I'm not going to lose much sleep.
It might even be a good thing, to help get tag: registered.

Having said all that, allow me to turn the argument around a little.
Why should the the tag: scheme need to be registered? If Atom's id
uses string comparison rather than rfc2396's definition of equivalence
it's not a URI anyway.

Cheers,
Danny.

---

From: Robert Sayre <[email-masked]>
Date: Thu, 26 Aug 2004 11:10:57 -0400

> uses string comparison rather than rfc2396's definition of equivalence

http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#comparison-string

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 26 Aug 2004 08:37:23 -0700 (PDT)

> definition of equivalence

Why are people going around and around on this? There
is precedent for this behavior in
http://www.w3.org/TR/REC-xml-names/ and
http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#dfn-URI-reference

Basically the two major W3C specs that utilize URIs as
identifiers define character by character comparison
and don't require canonicalization

Can we just move past this issue, please? 

=====

__________________________________
Do you Yahoo!?
Y! Messenger - Communicate in real time. Download now. 
http://messenger.yahoo.com

---

From: Danny Ayers <[email-masked]>
Date: Thu, 26 Aug 2004 17:50:46 +0200

Heh - you beat me to it.

+1.

---

From: Danny Ayers <[email-masked]>
Date: Thu, 26 Aug 2004 17:48:34 +0200

I'd completely forgotten about this until trying to trace back what
RSS 1.0 says about ids. If RSS 1.0 was updated to follow the current
RDF specs, then its ids will actually be URIrefs, not URIs, and:

"Two RDF URI references are equal if and only if they compare as
equal, character by character, as Unicode strings." [1]

Which suggests two questions:

1. Should 
http://example.org/foo#bar 
be considered the same id as 
http://example.org/foo#wub ?

2. Should Atom use URIrefs for IDs?

[1] http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#dfn-URI-reference

---

From: Danny Ayers <[email-masked]>
Date: Thu, 26 Aug 2004 18:00:23 +0200

PS. We could have moved directly past a lot of issues had we adopted
some more of that second spec...

---

From: Henry Story <[email-masked]>
Date: Thu, 26 Aug 2004 17:59:16 +0200

> Can we just move past this issue, please?

Pretty cool. So why not just rewrite the spec to use urirefs? Then we 
have precedence
on our side, the problem is solved, and the debate is ended.

Henry

---

From: Ian Davis <[email-masked]>
Date: Thu, 26 Aug 2004 17:07:41 +0100

> plus the moment in time.  Both of these are readily available.

The 'tag' scheme is problematic since it requires the minter of the URI 
to have authority over a domain name or expose their email address in 
every ID. The majority of publishers will not have their own domain 
(e.g. LiveJournal or Blogger) and will be forced to use their email 
address.

The requirement to use a DNS name in the tag uri also places overhead on 
  large organisations with multiple points of feed production. These 
would have to coordinate tag production.

Not to mention the problems with the specification of email addresses. 
For example, it doesn't allow [email-masked]

Besides all these issues, I'm fond of the 'tag' schema and it certainly 
has uses for those interested enough to have their own domain. I don't 
think that includes the majority of potential Atom publishers though.

Ian

---

From: Mark Pilgrim <[email-masked]>
Date: Thu, 26 Aug 2004 12:26:33 -0400

> (e.g. LiveJournal or Blogger) and will be forced to use their email

I'm pretty sure Blogger has their own domain.

-- 
Cheers,
-Mark

---

From: Danny Ayers <[email-masked]>
Date: Thu, 26 Aug 2004 18:49:21 +0200

> http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#comparison-string

Sure, individual Atom ids may be a URIs according to the spec. But
unless the  Atom identification system follows all of the requirements
of the URI spec (including the other comparisons), then it would be
inaccurate and misleading to say that Atom's identifiers are the same
things as URIs.

Cheers,
Danny.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 26 Aug 2004 19:02:00 +0200

> of the URI spec (including the other comparisons), then it would be

These aren't "requirements". They are definitions of possible 
comparisons. Picking the simplest one is perfectly ok and doesn't make 
the IDs less URI-like.

Best regards, Julian

---

From: Robert Sayre <[email-masked]>
Date: Thu, 26 Aug 2004 13:04:14 -0400

> inaccurate and misleading to say that Atom's identifiers are the same

The specification plainly states that different types of comparison are 
appropriate for different applications. It does not state that a failing 
equality test in section 6.2.1 means that application MUST proceed to 
step 6.2.2.

BTW, Tim wrote this section of 2396bis.

Robert Sayre

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 26 Aug 2004 10:10:27 -0700

At 10:19 AM -0400 8/26/04, Mark Pilgrim wrote:
>tag: URIs are not a registered URI scheme.

<usual-supect hat-position='on' action='pounce'>
     We should not encourage use of unregistered URI schemes.
</usual-suspect-hat>

>   But that doesn't negate

Exactly. If the only thing you have control over on the Internet is a 
mail address, you can still make GUIDs based on valid URIs. 
<mailto:[email-masked]?subject=2004-08-26-10-06-27-363745356> is an 
easily-formed ID that is a valid (and even canonical) URI.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: David Powell <[email-masked]>
Date: Thu, 26 Aug 2004 18:09:36 +0100

> 2. Should Atom use URIrefs for IDs?

It depends on whether we reference 2396classic or 2396bis.

I wrote PaceUriReferences[1] a few weeks ago.  It basically proposes replacing
all use of the term "URI" with "URI reference", and then clarifies that atom:id
should be an "absolute URI reference".

RFC2396bis changes things though, because fragment is now part of
"URI", rather than being relegated to being part of "URI reference", so I guess
"absolute URI reference" and "URI" are the same thing under the newer draft?

> 1. Should http://example.org/foo#bar be considered the same id as 

No, because they are different absoulute-URIRefs / URIs.  

HTML also seems to use the term URI everywhere when it would be more accurate to
use URI reference. [2][3]

[1] http://www.intertwingly.net/wiki/pie/PaceUriReferences
[2] http://www.w3.org/TR/html4/struct/links.html#h-12.1
[3] http://www.w3.org/TR/html4/types.html#type-uri

-- 
Dave

---

From: Ian Davis <[email-masked]>
Date: Thu, 26 Aug 2004 19:05:49 +0100

> I'm pretty sure Blogger has their own domain.
I hope so. I'm pretty sure LiveJournal does too. I'm missing the subtle 
point you're making. I'm pretty sure you aren't conflating the 
publishers of content with the tool providers. Can you clarify what you 
meant.

Ian

---

From: Robert Sayre <[email-masked]>
Date: Thu, 26 Aug 2004 14:15:17 -0400

> publishers of content with the tool providers. Can you clarify what you 

These services take care of id generation for their users. Example feed:

http://www.livejournal.com/users/jwz/data/atom

Robert Sayre

---

From: Danny Ayers <[email-masked]>
Date: Thu, 26 Aug 2004 20:35:59 +0200

> should be an "absolute URI reference".

My apologies, I completely missed that one.

> use URI reference. [2][3]

Ok. I'm not sure of IETF processes, but given that RFC2396bis hasn't
yet been approved, presumably for now we'll have to reference
'classic' and call the IDs URIrefs - does that sound about right?

But for the future this does lead back to the question of string
comparisons... There does seem to be a conflict between URI refs in
RFC2396bis and those of URI refs in RDF/XML namespaces.

Cheers,
Danny.

---

From: Robert Sayre <[email-masked]>
Date: Thu, 26 Aug 2004 14:53:58 -0400

> 'classic' and call the IDs URIrefs - does that sound about right?

We've covered this issue in the past[0]. Paul stated that the chairs 
will examine this issue "later in the baking process".

I am not implying that everyone should read and remember every message 
to atom-syntax. I have every message printed out and I wear a tinfoil 
hat when I am looking for an old message.

Robert Sayre

[0] http://www.imc.org/atom-syntax/mail-archive/msg06447.html

---

From: Danny Ayers <[email-masked]>
Date: Thu, 26 Aug 2004 21:08:07 +0200

> equality test in section 6.2.1 means that application MUST proceed to

I think we're at cross-purposes here a little,  (possibly still with
disagreement ;-)  - I've not been very clear.  Let me try putting it
another way. Ok, assume Atom IDs use URIs but with string comparison
rather than the 'ladder'. Now Atom isn't an application in the sense
used above, it's a specification to which applications can be built.
As such I would suggest that it's inaccurate and misleading to say
that Atom specifies its identification as URIs because applications
built to support the Atom spec may behave differently to those built
to the URI spec. An application using URIs may say http://example.org
is the same as http://EXAMPLE.org. An application using Atom's
idenification system would say they're different.

Cheers,
Danny.

---

From: Robert Sayre <[email-masked]>
Date: Thu, 26 Aug 2004 15:32:34 -0400

> idenification system would say they're different.

Once again, section 6 specifically states that that false negatives will 
happen. It's not inaccurate or misleading in any sense.

If you disagree, propose alternate spec language and we can continue 
this oh-so-productive debate.

Robert Sayre

---

From: Ian Davis <[email-masked]>
Date: Thu, 26 Aug 2004 21:09:32 +0100

> http://www.livejournal.com/users/jwz/data/atom

Understood , but blogger publishes to a site via FTP so it's a tool 
provider with data storage like a web version of CityDesk or Radio 
Userland. Would those tools be expected to generate tags based on the 
citydesk or userland domains? What happens if the tool developer goes 
bust, gets acquired or changes its domain. Old versions of the tool 
would continue to produce tags based on domains that are not owned by 
the tool developer with potential conflicts.

Surely the tag domains would have to be based on the publisher's 
information, not the tool provider's. This means that the large number 
of people without their own domain will be required to expose their 
email addresses in every entry they publish.

Rather than continually pushing unsuitable URI schemes we ought to 
accept that the web seems to work just dandy with generic URIs. Let's 
just do as Dare suggests: character by character comparison
without require canonicalization.

I think it's pretty unlikely that clients are going to be directly 
comparing atom IDs anyway. It seems pretty inefficient to store 100+ 
bytes for *every* entry *ever* retrieved by the client. Does anyone 
believe that any client is going to directly compare new 100+ byte IDs 
against the list of 10,000+ already seen? Most clients will stick them 
into a database and index them, so the comparison is made against the 
hash of the ID instead of the original bytes.

Ian

Ian

---

From: Robert Sayre <[email-masked]>
Date: Thu, 26 Aug 2004 16:31:50 -0400

> without require canonicalization.

Aha! We're not actually arguing.

I don't know diddly about what makes a URI scheme suitable, but I do 
know what the current consensus is:

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

and, shock of shocks, it's character-by-character comparison without 
requiring canonicalization. Just like XML Namespaces.

I think we're on our twentieth lap here. The only disagreement is from 
Mark (anyone else?) on c14n. Maybe Mark can let us move forward with 
this draft. Then he can propose PaceRequireCanonicalization later on, 
against concrete spec text.

Robert Sayre

---

From: Julian Reschke <[email-masked]>
Date: Thu, 26 Aug 2004 22:42:54 +0200

> rather than the 'ladder'. Now Atom isn't an application in the sense

There is no way a spec could require comparison using the full "ladder", 
unless it restricts itself to a finite set of known schemes for which 
scheme-based and protocol-based normalization are actually *defined*. In 
general, they may not be defined at all.

> used above, it's a specification to which applications can be built.

How is that relevant? And what definition of "application" are you using 
here?

> idenification system would say they're different.

So?

Again:

- there are many ways to compare URIs,
- some of which are scheme-dependant

Different applications may pick different comparison methods (or none at 
all), but that doesn't change the fact that all of them are using URIs 
just the way they are defined in RFC2396(bis).

Julian

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 27 Aug 2004 08:42:33 +0200

On Thu, 26 Aug 2004 16:31:50 -0400, Robert Sayre <[email-masked]>  
wrote:

> Mark (anyone else?) on c14n.

I'm +1 with Mark on requiring or recommending c14n on publishers (not  
consumers).

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

---

From: grayrest <[email-masked]>
Date: Fri, 27 Aug 2004 07:56:24 -0400

> I'm +1 with Mark on requiring or recommending c14n on publishers (not

I'm not sure if my vote counts, but I'm +1 on c14n for publishers and
not consumers. It's not that difficult to normalize your own url and
simplifies client implementation.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 27 Aug 2004 08:42:33 +0200

---

From: Jeremy Smith <[email-masked]>
Date: Fri, 27 Aug 2004 10:18:57 -0400

>simplifies client implementation.
    +1 for c14n on publishers.

---

From: Graham <[email-masked]>
Date: Fri, 27 Aug 2004 11:35:24 -0700

Jeremy, Asjborn, Grayrest, you can't +1 things without explaining what 
they achieve.

Graham

---

From: Jeremy Smith <[email-masked]>
Date: Fri, 27 Aug 2004 15:02:47 -0400

> Jeremy, Asjborn, Grayrest, you can't +1 things without explaining what 

    I believe that others have summed up the benefits of 
canonicalization at length.  I can add my own unique perspective, I suppose.

    Either producers are going to have to canonicalize URIs or consumers 
will have to before performing comparisons.  I think that the 
appropriate place in which to "sink that complexity" is in the producers 
of atom feeds.  If it is not done at the producer level, then such logic 
will become distributed across all of the different atom-parsing 
libraries that get released into the wild.  I believe it is much more 
appropriate to centralize the canonicalization logic within the 
producers of atom feeds.
    That, and, it just seems "right" to canonicalize URIs; but that 
could just be me.

Jeremy

---

From: Graham <[email-masked]>
Date: Fri, 27 Aug 2004 12:16:03 -0700

On 27 Aug 2004, at 12:11 pm, grayrest wrote:

> I can imagine someone misinterpreting/forgetting that this is the 
> case. C14ning the URI for
> publishers means that even if an implementor doesn't realize that IDs
> are not URIs, simple changes like changing ports doesn't cause ids to
> shift.

Erm, changing ports changes the canonical value too. Sorry - try again.

Graham

---

From: Graham <[email-masked]>
Date: Fri, 27 Aug 2004 12:17:36 -0700

On 27 Aug 2004, at 12:02 pm, Jeremy Smith wrote:

>    Either producers are going to have to canonicalize URIs or 
> consumers will have to before performing comparisons.

Sorry, no one has to and the system works just as well. Try again.

Graham

---

From: "Bob Wyman" <[email-masked]>
Date: Fri, 27 Aug 2004 15:29:14 -0400

Dare Obasanjo wrote:
> Google for "DEC AND UUID" or "Microsoft AND GUID".
	For those who didn't find the Digital source code for generating
UUIDs, (Not everyone remembers that DEC was Digital... see:

http://hegel.ittc.ukans.edu/topics/internet/internet-drafts/draft-l/draft-le
ach-uuids-guids-00.txt

	The code is copyright 1989 by HP and DEC... If my memory serves me
correctly, we actually started using the UUID code, or a predecessor, at DEC
at least five years earlier.

		bob wyman

---

From: Antone Roundy <[email-masked]>
Date: Fri, 27 Aug 2004 15:12:14 -0600

On Friday, August 27, 2004, at 01:17  PM, Graham wrote:
>> will have to before performing comparisons.
Because IDs are to be compared character-by-character, the only reason 
to canonicalize is to reduce the probability of accidentally generating 
the same ID differently at different times (right?).  In case Graham's 
response didn't get the point across, consumers don't need to 
canonicalize, because they compare IDs character-by-character--the 
burden of ensuring that an entry's ID is character-by-character the 
same as it ever was is entirely on the producer.

After all the discussion on this topic, I could do without 
canonicalization as long as we make the point extremely clear that 
clients are going to be doing character-by-character comparisons, so 
producers won't think they have wiggle room just because IDs look like 
URIs.  However, unless someone can show that canonicalization would be 
unduly difficult in some non-edge case, I'd still require it if it were 
up to me because it's a good way to get the message across 
unequivocally that there's no wiggle room.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 28 Aug 2004 00:36:50 +0200

> Jeremy, Asjborn, Grayrest, you can't +1 things without explaining what

Antone just explained it pretty clearly, so I don't see any need to  
copy+paste his reply in this thread.

---

From: Danny Ayers <[email-masked]>
Date: Sat, 28 Aug 2004 10:24:15 +0200

I was a little concerned about specifying string comparison-only for
URIs, and unclear on how RDF URIrefs related to URIrefs in RFC
2396bis. So I queried the [email-masked] list, and Roy Fielding was kind
enough to clarify for me [1].

Bottom line is there are unlikely to be any major problems with the
string-comparison approach, but in any case such problems can be
avoided entirely if the IDs are canonical.

I don't know of a precedent for requiring URI canonicalization, so
would hesitate to mandate it. But I think the next spec draft ought at
least say publishers SHOULD use canonical URIs, and based on
experiences with that the decision can be made on whether a MUST would
be better.

This is assuming clients SHOULD use string comparison, and MUST
preserve ids in a form that retains this ability (i.e. within whatever
encoding is used) if republishing.

Cheers,
Danny.

[1] http://lists.w3.org/Archives/Public/uri/2004Aug/0092.html

-- 

http://dannyayers.com

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 28 Aug 2004 11:24:38 +0200

> avoided entirely if the IDs are canonical.

Exactly.

> experiences with that the decision can be made on whether a MUST would

I think SHOULD is enough, but if we get consensus around MUST, that is  
great.

> encoding is used) if republishing.

Yes to both; I think they should.

---

From: Julian Reschke <[email-masked]>
Date: Sat, 28 Aug 2004 11:51:39 +0200

>> avoided entirely if the IDs are canonical.

I'd like to understand what class of (unlikely) problems that would 
solve. Example, please?

> Yes to both; I think they should.

I thought they *MUST* do string comparison. Is there any reason to leave 
implementors the choice not to do it?

Regards, Julian

---

From: Henry Story <[email-masked]>
Date: Sat, 28 Aug 2004 12:03:38 +0200

On 28 Aug 2004, at 11:51, Julian Reschke wrote:

>
> Asbjørn Ulsberg wrote:
>
>> On Sat, 28 Aug 2004 10:24:15 +0200, Danny Ayers 
>> <[email-masked]>  wrote:

I think it just makes the spec simpler to understand.

>> I think SHOULD is enough, but if we get consensus around MUST, that 
>> is  great.
> I thought they *MUST* do string comparison. Is there any reason to 
> leave implementors the choice not to do it?

you can go with the weaker version, but it sometimes helps to have more 
than one protection. The question otherwise is: would it create any 
undue problems to have the spec be just a little tighter than 
necessary.

Another question I have is: why did the RDF group think it necessary to 
create a
URI reference object [1] when they could have just gone down the 
canonicalised URI route. Are we missing something?

Henry
http://bblfish.net/

[1]

---

From: Julian Reschke <[email-masked]>
Date: Sat, 28 Aug 2004 12:17:04 +0200

> I think it just makes the spec simpler to understand.

First of all, it makes the spec more complex, as it adds a new 
requirement that - as far as I understand - doesn't have any effect on 
interoperability as long as consumers indeed do string comparisons.

So again, if people talk about possible problems without 
canonicalization, they'd be able to provide an example, right?

> undue problems to have the spec be just a little tighter than necessary.

Well, if people do *not* perform string comparison, IDs that are 
supposed to be different may compare equal. This seems to be a major 
problem.

Best regards, Julian

---

From: Dare Obasanjo <[email-masked]>
Date: Sat, 28 Aug 2004 07:28:30 -0700 (PDT)

> canonicalised URI route. Are we missing something?

Because it is an unnecessary burden on producers?
Canonicalization is an attempt to protect against
consumers implemented by people who don't read the
spec. However I don't understand why people seem to
think that if consumers won't read the spec producers
will. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #23
I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks.

__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail

---

From: Antone Roundy <[email-masked]>
Date: Sat, 28 Aug 2004 08:32:49 -0600

> canonicalization, they'd be able to provide an example, right?
Example:

My company has a database full of whatever.  I write some code that 
generates and Atom feed from that data.  The company has some sort of 
rules for dynamically generating IDs based on some immutable data in 
the database, but we don't actually store the IDs.  An example ID is 
foo:www.geckotribe.com/bar/1/2/3.  So far so good.

Next, someone at the same company writes some code to output another 
Atom feed based on the same data (but filtered differently, so a 
different mix of entries ends up in their feed).  They are told the 
same rules for generating IDs based on data in the database, and their 
implementation generates IDs like foo:www.GeckoTribe.com/bar/1/2/3.  
Because of capitalization differences in the domain name portion, the 
IDs do not match.

Because the spec states that ID comparison is to be done 
character-by-character, my company's rules for generating IDs out of 
the database SHOULD HAVE specified whether to capitalize or not, but 
because the spec didn't call this particular point to the attention of 
the people who wrote the company rules, they didn't put anything about 
capitalization in those rules, and we ended up with a problem.  
Recommending canonicalization, and specifying clearly what we mean by 
canonical form, serves to bring the most likely sticking points to 
people's attention.  It reminds people that they can't simply trust 
some library that they're using to output URIs to do the right 
thing--different libraries may do things a little differently.

---

From: Dare Obasanjo <[email-masked]>
Date: Sat, 28 Aug 2004 08:04:37 -0700 (PDT)

> thing--different libraries may do things a little

If the morons at your company can't figure out that
the fact that IDs must be compared character by
character means they can't vary in capitalization from
reading the spec what makes you think that they'll pay
attention to any rules about canonicalization? 

Do you really think these people will be able to
implement the rules in
http://www.intertwingly.net/wiki/pie/PaceCanonicalIds
without screwing it up? That is if they bother reading
the spec to that degree of detail.

Adding this extra complexity to the spec only buys you
one thing; it makes the spec writers feel warm and
fuzzy. 

However since this is the only issue holding up IDs I
don't see why we can't just compromise on a SHOULD for
canonicalizing URIs and move on. 

=====

_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush

---

From: Walter Underwood <[email-masked]>
Date: Sat, 28 Aug 2004 08:45:48 -0700

--On Saturday, August 28, 2004 7:28 AM -0700 Dare Obasanjo <[email-masked]> wrote:
> spec.

No, it is allowance for normal humans who make understandable
mistakes. Treating URIs as URIs instead of as strings is a quite
understandable mistake.

So, we protect against that, and Atom implementation are
more likely to work.

This was said best by John Postel, be conservative in what
you generate and generous in what you accept. The most robust
approach would require canonical URIs and allow fancy comparisons.

The alternative is to spend forever tracking down minor problems
in other people's code, code which has already been deployed.
Fragile specs are a nightmare.

wunder

---

From: Julian Reschke <[email-masked]>
Date: Sat, 28 Aug 2004 18:15:36 +0200

> So, we protect against that, and Atom implementation are

Nope. Canonicalization doesn't guarantee that comparing as "URI" won't 
break anything, it just makes this scenario less probable.

That's why I dislike it -- implementors will possibly be encouraged not 
to implement comparison as specced, because IDs will be "canonical" 
anyway. Big mistake.

> approach would require canonical URIs and allow fancy comparisons.

That wouldn't work, unless you know beforehand what these "fancy" 
comparisons indeed are.

BTW: being generous in what you accept in this case would mean that 
you'd possibly get false positives. Is this really what you want?

> Fragile specs are a nightmare.

That's correct. My point being is that the spec will have maximum 
robustness if it's crystal clear on it's requirements for comparison, 
and that's it.

Julian

---

From: Julian Reschke <[email-masked]>
Date: Sat, 28 Aug 2004 18:42:35 +0200

>> canonicalization, they'd be able to provide an example, right?

Ok,

thanks for providing an actual example. My reaction is: this may occur 
if the developers did not read or do not understand the spec. So 
whatever we can say about what the *impact* of string comparison is, we 
should say.

On the other hand: if this problem occurs, existing clients will not 
detect the duplicates; and it should become clear very very quickly that 
there is a problem that needs to be fixed.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sat, 28 Aug 2004 20:48:20 +0200

Danny Ayers wrote:

> The classic: aggregator receives posts with ids
> http://example.org/blog1 and HTTP://EXAMPLE.ORG/blog1, believes them
> to be different, displays both.

And that's what it should do.

It's the producer's job to ensure that the IDs make sense.

Regards, Julian

---

From: Danny Ayers <[email-masked]>
Date: Sat, 28 Aug 2004 20:45:10 +0200

> implementors the choice not to do it?

I left it down as SHOULD because it doesn't really impact anything
outside of the app (except perhaps for the end user). I personally
wouldn't have a problem with it being MUST in the spec.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Graham Parks <[email-masked]>
Date: Sat, 28 Aug 2004 14:53:04 -0400

On 28 Aug 2004, at 7:32 am, Antone Roundy wrote:

> They are told the same rules for generating IDs based on data in the database

I find it more likely that if this step happens at all, it'll happen correctly. Even more likely is that the step won't happen, and they'll pick different ids, which canonicalization won't save you from. In other words the chain of events that causes two people to pick different ids that happen to be the same canonically is so small I don't see the point in accounting for it.

Graham

---

From: Danny Ayers <[email-masked]>
Date: Sat, 28 Aug 2004 21:02:45 +0200

> to implement comparison as specced, because IDs will be "canonical"

I'm curious, how might the implementors do the comparisons that is
going to less strict that string comparison?

> That wouldn't work, unless you know beforehand what these "fancy"

Presumably the 'ladder' in RFC 2396. 

> you'd possibly get false positives. Is this really what you want?

There are no exceptions. Just situations in which it doesn't apply ;-)

> robustness if it's crystal clear on it's requirements for comparison,

Maybe not robustness, but almost certainly utility.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Bill de hÓra <[email-masked]>
Date: Sat, 28 Aug 2004 20:06:23 +0100

> attention to any rules about canonicalization? 

"If the morons at your company can't figure out that the fact that 
IDs are URIs which means they can vary in comparison from scheme to 
scheme, what makes you think that they'll pay attention to any rules 
about string comparison?"

This thread is pointless. URIs v Strings is the wrong technical 
deathmatch.

cheers
Bill

---

From: Bill de hÓra <[email-masked]>
Date: Sat, 28 Aug 2004 20:08:44 +0100

> It's the producer's job to ensure that the IDs make sense.

How do they not make sense?

cheers
Bill

---

From: Julian Reschke <[email-masked]>
Date: Sat, 28 Aug 2004 21:16:04 +0200

> going to less strict that string comparison?

Any comparison that involves URI-specific knowledge will be less strict.

> Presumably the 'ladder' in RFC 2396. 

s/2396/2396bis/

The "ladder" does not specify scheme-specific equivalences as they are 
outside the scope of RFC2396bis.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sat, 28 Aug 2004 21:30:27 +0200

> How do they not make sense?

They didn't make sense in that they were supposed to be equal, but 
weren't. If the spec states that recipients compare IDs as strings, 
producers will have to take care of this if they intend to produce two 
IDs that are supposed to compare equal.

Julian

---

From: "Bob Wyman" <[email-masked]>
Date: Sat, 28 Aug 2004 15:39:40 -0400

Danny Ayers wrote:
> I'm curious, how might the implementors do the comparisons
> that is going to less strict that string comparison?
	Here is an example:
	(No, the following is *not* anti-Microsoft...)
	Everyone is aware that Windows systems are typically much more
liberal in string matches than are Unix/Linux based systems when it
comes to case-sensitivity. Thus, Windows coders will often create string
keys in their databases which do case-insensitive matching by default
while folk in a number of other environments will often create
case-sensitive keys instead.
	The problem comes when someone who *has read* the spec tries to
implement it correctly. The reader will say: "Ok, I can't use the
special URI-type provided by my fancy database for this key. What I must
use is a simple string type (varchar?) since I need
character-by-character comparison." Then, newly discovered atom:id's are
tested for uniqueness by doing a lookup in the database -- using a
string key. All sorts of problems will arise if the string key is
case-insensitive.
	This sort of thing happens all the time -- even when "working"
code is moved from one system to another or a database is changed while
code is not changed. (i.e. if you access data via ODBC or JDBC, you
probably haven't written all sorts of code to verify the index
definitions when you attach to a new database...)
	So, this has been an example of someone trying to do the "Right
Thing" but getting bitten by non-canonicalized strings. Also, don't
forget that second part about the database being changed after working
code has been proven on an earlier database... Even if the original
author did the right thing, the system can be broken by a later
maintainer not being aware of the impact of changes in database behavior
defaults.
	If atom:id is a canonicalized URI, the problems above are much
less likely to occur.

		bob wyman

---

From: Julian Reschke <[email-masked]>
Date: Sat, 28 Aug 2004 21:50:21 +0200

> 	If atom:id is a canonicalized URI, the problems above are much

This is a good story; and I agree that it can happen. However, if the 
problem is case-sensitivity it escapes me how canonicalization will 
solve it.

Consider:

	http://example.com/FooBar
	http://Example.Com/foobar
	http://EXAMPLE.COM/FooBar

Under canonicalization, there'd still be two different IDs, although all 
of these would compare equal in a caseless comparison.

Best regards, Julian

---

From: Ian Davis <[email-masked]>
Date: Sat, 28 Aug 2004 21:12:40 +0100

> of these would compare equal in a caseless comparison.

Yes, case-sensitive character comparisons (i.e. octet comparisons) will 
result in no false positives when compared with full URI and scheme 
comparison. Case-insentive comparisons will conflate ids that are 
different under the URI rules.

So, +1 (again) to case-sensitive character id comparisons

Ian

---

From: "Bob Wyman" <[email-masked]>
Date: Sat, 28 Aug 2004 16:21:57 -0400

Julian Reschke wrote:
> This is a good story; and I agree that it can happen.
	Thanks.

> Under canonicalization, there'd still be two different IDs, although
> all of these would compare equal in a caseless comparison.
	Your example is incomplete. There are 2^4
semantically-equivalent ways to capitalize "http". There are 2^10
semantically-equivalent ways to capitalize "example.com" and 2^14
semantically-equivalent ways to capitalize "http://example.com/". 
	Canonicalization reduces all these possibilities to only *one
way*. I see the elimination of (2^14 -1) possible ways to confuse a
character-by-character comparison as a significant reduction in the
opportunity to make mistakes. It is not a "solution"; however, it is a
major step in the right direction.

	Additionally, there are at least 2^6 different ways to encode
"FooBar" when in a path if one treats path as a URI component rather
than as a string. Canonicalization only gives us one correct way to
encode "FooBar" as a string. This reduction in variety is a good thing
and should result in some improvement in the overall consistency of Atom
processing.

		bob wyman

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 28 Aug 2004 22:34:23 +0200

> It's the producer's job to ensure that the IDs make sense.

And you don't think c14n is a step in the right direction there?

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 28 Aug 2004 22:37:42 +0200

> Because it is an unnecessary burden on producers?

Bah! How difficult is it, really?

> Canonicalization is an attempt to protect against consumers
> implemented by people who don't read the spec.

Partly, yes. Why shouldn't we have that protection, when it's very likely  
it will help?

> However I don't understand why people seem to think that if
> consumers won't read the spec producers will.

Good question. Nonetheless, requiring or recommending c14n for producers  
help.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 28 Aug 2004 22:43:48 +0200

> Any comparison that involves URI-specific knowledge will be less strict.

Who has said anything about URI scheme-specific comparison? Producers know  
which URI scheme they provide in atom:id's. They should then know what it  
takes to canonicalize them. Consumers should compare them char-by-char no  
matter what. Where does the URI scheme-specific comparison come into play?

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 28 Aug 2004 22:48:03 +0200

On Sat, 28 Aug 2004 08:04:37 -0700 (PDT), Dare Obasanjo <[email-masked]>  
wrote:

> However since this is the only issue holding up IDs I don't see why we
> can't just compromise on a SHOULD for canonicalizing URIs and move on.

I would be okay with that.

---

From: Dare Obasanjo <[email-masked]>
Date: Sat, 28 Aug 2004 14:40:24 -0700 (PDT)

> and should result in some improvement in the overall

It seems you don't understand how canonicalization
works. To spell it out, Julian's point is that the
canonicalization of capitalizations does not apply to
the path component of HTTP URLs. So 

 http://www.example.com/FOO.txt

and 

 http://www.example.com/foo.txt 

are both in canonical form. Your case of applications
generating IDs from database fields where the same ID
has different cases will not be helped by
canonicalization. 

=====

---

From: "Bob Wyman" <[email-masked]>
Date: Sat, 28 Aug 2004 18:36:43 -0400

Dare Obasanjo wrote:
> It seems you don't understand how canonicalization works.
> To spell it out, Julian's point is that the canonicalization
> of capitalizations does not apply to the path component
> of HTTP URLs.
	It seems that you are too quick to jump on potential error... If
you read my note you'll see I made *no* reference to capitalization when
I mentioned "different ways to encode" the *path* component. My comments
on case were restricted to the protocol and domain fields. There are
many alternative encodings of the path element that are eliminated by
canonicalization.

> Your case of applications generating IDs from database fields
> where the same ID has different cases will not be helped by
canonicalization. 
	Read the example again. Canonicalization will require lowercase
for protocol and domain components. Given that these are part of the ID,
the probability of case-related errors is reduced -- even though, as I
said in my note, it is not eliminated.

		bob wyman

---

From: Graham Parks <[email-masked]>
Date: Sat, 28 Aug 2004 19:21:09 -0400

> said in my note, it is not eliminated.

So, am I right in thinking that the benefits of c14n amount to:
i) Protection from millions of times each day that someone rewrites id generation code but chooses different capitalization for the scheme or domain name, but somehow remembers not to make any other changes.
ii) Gateways that either don't exist, don't currently pass ids through at all, or don't mangle ids, but it's assumed will inevitably all start canonicalizing for the sake of it, because "search engines canonicalize all the time", in a completely different context.
iii) Implementors that don't read the spec and use C# or Java URI comparison classes, and who come across feeds where one entry has id "http://www.example.com/", and another has "HTTP://www.example.com/", and won't conflate the entries.

Are you shitting me?

Graham

---

From: Danny Ayers <[email-masked]>
Date: Sun, 29 Aug 2004 01:28:32 +0200

> I would be okay with that.

Me too.

Nor can I think of any other publication-oriented system which demands
URI canonicalization, so no matter how desirable it seems, it's pretty
well untested, and SHOULD may be the cautious choice.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Dare Obasanjo <[email-masked]>
Date: Sat, 28 Aug 2004 18:53:58 -0700 (PDT)

--- Bob Wyman <[email-masked]> wrote:

> works.

Then what is the point of your example in your mail at
http://www.imc.org/atom-syntax/mail-archive/msg09113.html

First of all it contains bogus statements like
"Windows systems are typically much more
liberal in string matches than are Unix/Linux based
systems when it
comes to case-sensitivity" which I have no idea how to
parse. Does it mean that String.Equals in the .NET
Framework or strcmp in Visual C++ work differently
than in Java or C on Unix systems? 

Anyway specifically in your mail you wrote 

"Then, newly discovered atom:id's are
tested for uniqueness by doing a lookup in the
database -- using a
string key. All sorts of problems will arise if the
string key is
case-insensitive."

Are you now claiming that you did not write this or I
somehow misunderstood that what this implies about
your belief in case insensitivity and
canonicalization? Seriously, what does that statement
mean if it doesn't imply that somehow URI
canonicalization will make it possible to do case
insensitive searches on URIs without problems? 

It's one thing to make an honest mistake about an
arcane technology like URI canonicalization and
another to pretend you didn't say something to mask
ignorance about a particular topic. 

> said in my note, it is not eliminated.

WTF? So part of the ID will have normalized case. How
exactly will that prevent case related errors in
anything but HIGHLY CONTRIVED scenarios? Your argument
makes sense if canonicalization converted all text to
a single case but it doesn't which tremendously
weakens your argument.  

=====

---

From: Julian Reschke <[email-masked]>
Date: Sun, 29 Aug 2004 10:43:32 +0200

Asbjørn Ulsberg wrote:
> 
> On Sat, 28 Aug 2004 20:48:20 +0200, Julian Reschke 

No, not at all.

Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 29 Aug 2004 10:56:35 +0200

Asbjørn Ulsberg wrote:

> 
> On Sat, 28 Aug 2004 21:16:04 +0200, Julian Reschke 
> Who has said anything about URI scheme-specific comparison? Producers 
> know  which URI scheme they provide in atom:id's. They should then know 
> what it  takes to canonicalize them. Consumers should compare them 
> char-by-char no  matter what. Where does the URI scheme-specific 
> comparison come into play?

Again.

As long as consumers do what the spec says, canonicalization doesn't buy 
you anything at all, as recipients compare as strings.

The trouble starts when they don't, in which case there is a large 
number of ways to get it wrong. Canonicalization will eliminate *some* 
cases, but not all.

So if we have broken consumers, will canonicalization make them less 
broken? Possibly.

However

- if the spec mentions canonicalization for producers, there's a real 
risk that developers of consumers will get their comparisons wrong 
because they think that what they get will always be canonicalized, and

- making the spec strict (just specify string comparison) and prodiving 
test cases (test atom feeds) can ensure that consumers indeed *do* get 
this right.

Best regards, Julian

---

From: Danny Ayers <[email-masked]>
Date: Sun, 29 Aug 2004 11:30:58 +0200

On Sun, 29 Aug 2004 10:56:35 +0200, Julian Reschke <[email-masked]> wrote
> you anything at all, as recipients compare as strings.

Errm, yes it does, because there are loads of equivalent URIs
comparisons that will produce false negatives if the consumer does
string comparison, but that would match correctly if they were
canonicalized before publication (and the consumer does string
comparison).

> number of ways to get it wrong. Canonicalization will eliminate *some*

If consumers approximate the comparisons in rfc2396bis, then
canonicalization will help in a large proportion of cases. If they
don't, they are seriously broken.

> test cases (test atom feeds) can ensure that consumers indeed *do* get

Or it may lead to consumers thinking that producers all use string
comparison, and get it wrong for those that don't. There's only a
limited distance you can get in predicting non-compliant developer
behaviour. I think we should guess on the side that favours doing the
Right Thing.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Dare Obasanjo <[email-masked]>
Date: Sun, 29 Aug 2004 03:51:43 -0700 (PDT)

> canonicalized before publication (and the consumer

Instead of talking in hypotheticals can you actually
name some real life instances when this has actually
been a problem? You do realize that for the past five
years or more people have been exchanging XML
documents with URIs as identifiers [any RDF or XML
document with namespaces which includes 50% - 75% of
the RSS feeds in existence] over the Web and these
string comparison problems you claim will be an issue
have not been. 
 
> behaviour. I think we should guess on the side that

Basically you're trying to spec behavior for people
who won't read the spec? So now producers have to do
extra, unnecessary work just in case some consumers
don't read the spec. 

(a) That's the most ass backwards thing I've heard in
a while 

(b) if the consumers are implemented incorrectly they
deserve the broken behavior that ensues

=====

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 29 Aug 2004 12:04:41 -0400

> ignorance about a particular topic. 
	You seem so intent on proving me wrong that you continue to
mischaracterize what I have written. It's sort of like listening to
republicans on a Sunday morning TV talk show...
	I have never suggested that canonicalization would impact the
case of characters in the path component of URI's. I have only mentioned
case when speaking of the protocol and domain fields. As to the path
component, there are still many alternate ways to encode a single
string. For instance, everyone is familiar, I think with such the
problems with "%20" etc... If not, please review C14N. You should not
have any difficulty coming up with at least 2^6 different ways to encode
"foobar" when it appears in a path. However, only one of those
semantically equivelant methods would be permitted by C14N rules.

>First of all it contains bogus statements like "Windows systems
> are typically much more liberal in string matches than are
> Unix/Linux based systems when it comes to case-sensitivity"
	File names in Windows systems have always been case-insensitive.
This goes back to Windows' roots in DOS and probably reaches back to
DOS's roots in the non-Unix operating systems (many from Digital) that
influenced its early definition. On the other hand, Unix has always had
case-sensitive file names. I believe that the case-insensitivity of DOS
and Windows file names has influenced DOS/Windows developers to
implement case-insensitivity as the default string match in other areas
matches over the years.

> Does it mean that String.Equals in the .NET
	I was speaking of Windows itself -- not code that has been
layered on top of it in recent years.

	It remains the case that canonicalization drastically reduces
the number of ways in which any particular URI can be written. In some
cases, this is done by restricting case, in others, it is done by
restricting or requiring the use of a particluar method of encoding a
character. The result in variety *will* result in fewer opportunities
for error. That is the whole point of C14N.

		bob wyman

-----Original Message-----
From: Dare Obasanjo [mailto:[email-masked]] 
Sent: Saturday, August 28, 2004 9:54 PM
To: [email-masked]; 'Julian Reschke'
Cc: 'Atom Syntax'
Subject: RE: URIs vs Strings

--- Bob Wyman <[email-masked]> wrote:

> you read my note you'll see I made *no* reference to capitalization 
> when I mentioned "different ways to encode" the *path*
> component. My comments

 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #23
I will keep a special cache of low-tech weapons and train my troops in
their use. That way -- even if the heroes manage to neutralize my power
generator and/or render the standard-issue energy weapons useless -- my
troops will not be overrun by a handful of savages armed with spears and
rocks.

---

From: Danny Ayers <[email-masked]>
Date: Sun, 29 Aug 2004 19:15:39 +0200

> string comparison problems you claim will be an issue

Namespace identification is qualitively different from per-instance
identification on the web. The requirements are different (a huge
difference in the number of things identified), and there is
considerably less experience to draw on. General good practice with
identifiers suggests that ambiguity is best avoided, and URI
canonicalization at source is a relatively low-cost way of minimizing
ambiguity.

> who won't read the spec? 

No. Because, like I said in the sentence before last, "There's only a
limited distance you can get in predicting non-compliant developer
behaviour.".

So now producers have to do
> extra, unnecessary work just in case some consumers

No. Earlier in this thread you said: "However since this is the only
issue holding up IDs I
don't see why we can't just compromise on a SHOULD for canonicalizing
URIs and move on.". I agree.

> (a) That's the most ass backwards thing I've heard in

No. It's the most ass backwards thing you imagined you heard in a while.

> deserve the broken behavior that ensues

I agree. But we should also make correct implementation as
straightforward as possible.

Cheers,
Danny.

-- 

http://dannyayers.com