Why not "restart" IT as a lisp world using "adminsitrative" IDs numbers kind as symbol and "memory locations"
yves75
huge need of identifiers in order to be written and function properly.
People don't like huge flat list, but there are many of them, like
ISBNs for books for instance, without which not much would function.
There is also a tendancy to always mix naming and classification,
which is very understandable when using key words as IDs, but this
reason disappears when using numbers kind IDs, and after all a memory
adress space is also a huge flat list. Of course if these are
"adminsitrative", then comes up the question of their sources and
distribution principles. Tought about that for sometimes already, and
came up with an idea (filed and published as a patent) that I think
would provides the necessary flexibility while maintaining the
possibility to have these IDs on a fixed length. Besides, "name
spaces" that are usually described as "hierarchical" are in fact not
hierarchic at all. By that I mean that a file path for instance, is
very often more an s-expression on a flat list of symbol than a
"hierarchical path" : /mysoft/lib/doc is something like (doc (lib
(mysoft))), the documentation part of the library part of mysoft, so
that the symbol "lib" and "doc" are part of a global namespace
referring to the same one in /anothersoft/lib/doc.
More on this below :
http://iiscn.wordpress.com/about/
Unfortunately only in french for the time being, hope to find time to
make an english version.
Note : All of the above refers to publications, programs, works, list
or set of these things, other concepts or conventions such as unicode
code points, and not to individuals or persons, on this I am perfectly
in line with below IEEE position statement :
http://web.archive.org/web/20041106011802/http://www.ieeeusa.org/policy/positions/universalidentifiers.html
Which, that is a bit strange, has disappeared from the ieee web site.
In other words, much more than new syntaxes or models, what IT needs
is a common labels distributor, or a common huge stack of pins.
Would be interested to have your views on this.
yves75
>
> Which, that is a bit strange, has disappeared from the ieee web site.
>
> In other words, much more than new syntaxes or models, what IT needs
> is a common labels distributor, or a common huge stack of pins.
>
> Would be interested to have your views on this.
Sorry for typos and spelling mistakes
Raffael Cavallaro
> In other words, much more than new syntaxes or models, what IT needs
> is a common labels distributor, or a common huge stack of pins.
1. UUIDs: <http://en.wikipedia.org/wiki/Universally_unique_identifier>
give you *independent* unique "pins," but these are, quite
intentionaly, *not* a "common labels distributor." The practical
solution is to *not* coordinate, but make the liklihood of collision
very small because of the length of the ID. The whole point of UUIDs is
to avoid the computational, network, and administrative overhead of
global UUID coordination.
Here's a common lisp implementation of UUIDs:
<http://www.dardoria.net/software/uuid.html>
And there are platform specific calls for UUIDs as well.
What you're asking for is a globally coordinated, UUID database. I
think this will have to wait for a repressive world government or robot
overlords, whichever comes first ;^). IOW, it's only really useful if
every programmer on the planet can be compelled to use it for every
software entity that sees the light of day (i.e., interacts with other
software or users over any network). Enforcing that would require an
authoritarian world government. Remember, unless you can enforce
registration with this global database, you'll still run the risk of
collisions.
> Note : All of the above refers to publications, programs, works, list
> or set of these things, other concepts or conventions such as unicode
> code points, and not to individuals or persons, on this I am perfectly
> in line with below IEEE position statement :
> http://web.archive.org/web/20041106011802/http://www.ieeeusa.org/policy/positions/universalidentifiers.html
Which,
>
> that is a bit strange, has disappeared from the ieee web site.
2. Actually, the position statement and its background are still on the
ieee website:
background:
<http://www.ieee.org/organizations/pubs/newsletters/npss/0601/background_UID.htm>
position
statement:
<http://www.ieee.org/organizations/pubs/newsletters/npss/0601/against_UID.htm>
3. Beyond this clerical matter, I think it approaches doublespeak to
say that software entities should be uniquely identified, but that
people shouldn't, since people are frequently components of software
systems (customers, account holders, voters, taxpayers, deed holders,
prisioners, etc.).
IOW, either universal identifiers are a good idea or they aren't, and
the ieee position paper suggests that they are not. If the ieee
position is correct, then if you want security and privacy built into
your systems from the ground up, you want "a family of identifiers
[that] would allow different identifiers to be used, as appropriate to
the security needs, privacy desires, and other tradeoffs of different
transactions or situations," e.g., my social security number should not
be included as part of the "From:" field of this Usenet post (and of
course, it isn't).
Now, within any given domain, we certainly want to require uniqueness -
for example, no two people should have the same email address - but I'm
pretty sure that this need for uniqueness within a given domain has
been well known for a very long time.
warmest regards,
Ralph
--
Raffael Cavallaro
yves75
>
> Which,
>
>
>
> > that is a bit strange, has disappeared from the ieee web site.
>
> 2. Actually, the position statement and its background are still on the
> ieee website:
>
> background:
>
> position
>
> statement:
> <http://www.ieee.org/organizations/pubs/newsletters/npss/0601/against_...>
>
> 3. Beyond this clerical matter, I think it approaches doublespeak to
> say that software entities should be uniquely identified, but that
> people shouldn't, since people are frequently components of software
> systems (customers, account holders, voters, taxpayers, deed holders,
> prisioners, etc.).
>
> IOW, either universal identifiers are a good idea or they aren't, and
> the ieee position paper suggests that they are not. If the ieee
> position is correct, then if you want security and privacy built into
> your systems from the ground up, you want "a family of identifiers
> [that] would allow different identifiers to be used, as appropriate to
> the security needs, privacy desires, and other tradeoffs of different
> transactions or situations," e.g., my social security number should not
> be included as part of the "From:" field of this Usenet post (and of
> course, it isn't).
>
> Now, within any given domain, we certainly want to require uniqueness -
> for example, no two people should have the same email address - but I'm
> pretty sure that this need for uniqueness within a given domain has
> been well known for a very long time.
>
> warmest regards,
>
> Ralph
>
> --
> Raffael Cavallaro
Thanks for your answer Raffael, I know perfectly well about UUIDs, but
these do not provide the necessary "functionality". Typically UUIDs
are used for objects with short or medium term "life span", and/or for
objects for which the reference is absolutely never seen or need to be
typed. But nobody would think of using UUIDs as order IDs for
instance, or documents such as the ones with DOIs, or for all the
products having product IDs as GS1 bar codes, or for ISANs, or even
less for signs and characters such as UNICODE code points for
instance, why would "IT" think its problem is different ? Point is it
isn't at all, and a major part of the mess is due to not recognizing
that.
About authoritarian world government not at all, the ISBN org for
instance, is a non profit organisation located in Germany I think, far
from being a world government, and I doubt the ISBN.org organisation
ever had a single word at all to say about which book should be
published or not ! (apart from books about its own standard maybe)
And in fact the solution proposed removes fixed number of segments in
IDs (the case most of the time), as well as a defined size for each
segment (it is in fact based on a mathematical code decode algorithm),
so that it would provide I think the necessary flexibility, as well as
the ability to integrate most of the current already defined flat ID
spaces.
The idea is then to use these "ISCNs" in a very "native" way in the
programming environment, and that could be typically building a lisp
world where they are used exactly (or almost) as memory locations are
today used in a "classic" lisp environment.
And overall the message is also that there is no "solution" to be
found in a new syntax or model (as we hear time and time again), but
really in having these shared ID spaces. (people always tend to hear
"syntax, grammar, structure, rules" when they hear language, and
especially programming languages, but in the end the most important
thing is the dictionnary (more or less libraries and defined symbols
for programming languages))
As to "I think it approaches doublespeak to
say that software entities should be uniquely identified, but that
people shouldn't, since people are frequently components of software
systems (customers, account holders, voters, taxpayers, deed holders,
prisioners, etc.). "
Not sure why you say so, a publication is a publication, the fact it
is given a number is independent from its author.
But in fact the idea presented on my "blog" on this aspect is that
there should be a clear separation between entities responsible to
maintain a list of "personal contracts" on some people "accounts", and
entities providing associated services or contents, and that in fact
if you look at possible protocols, it is very easy to define them such
as no account ID at all has to be transmitted between "accounts
holders" and "service providers". Today we are heading in a direction
where, it is seen as a "fatality" that either service providers also
maintain the account, or that a common ID as to be used in all cases,
not the case at all !
Today it is a bit like if you should have an account within each
company emitting shares in order for you to buy some, clearly there
must be a clear separation between entities responsible to maintain
your "personal bookshelf and key data, that is references", and only
doing that, with being strictly forbidden to either look or publish
it, and entities responsible for providing services/contents, and
there should be several for each kind, which is perfectly feasible.
(and you should be able to transfer your complete account from one of
the "account holder entitie to another")
Cheers,
Yves
yves75
adresses which are also distributed in an "adminsitrative" fashion by
the way), it corresponds to 5 10^18 numbers/IDs per earth surface
square millimeters, or 1 10^16 numbers/IDs per second and per
inhabitant along a millenium for a population of 10 billions.
For 128 the proposal would loose some of these bits, but still there
is a lot ..
And the point is really to improve the ability to write and modify the
thing, not everyone obliged to use it.
Pascal J. Bourguignon
writes:
> 3. Beyond this clerical matter, I think it approaches doublespeak to
> say that software entities should be uniquely identified, but that
> people shouldn't, since people are frequently components of software
> systems (customers, account holders, voters, taxpayers, deed holders,
> prisioners, etc.).
French law prohibit the use of universal identifiers for people.
For example, enterprises should not use the S�curit� Social number as an
identifier in their databases.
> IOW, either universal identifiers are a good idea or they aren't, and
> the ieee position paper suggests that they are not. If the ieee
> position is correct, then if you want security and privacy built into
> your systems from the ground up, you want "a family of identifiers
> [that] would allow different identifiers to be used, as appropriate to
> the security needs, privacy desires, and other tradeoffs of different
> transactions or situations," e.g., my social security number should
> not be included as part of the "From:" field of this Usenet post (and
> of course, it isn't).
Well, in France, since you must not use the SSN as an identifier, it
doesn't matter if you publish a SSN. Actually, most of them are a
matter of public record:
S YY MM DD CCC NNN KK
S = sex (1 = male, 2 = female, other values are possible...)
YY = birth year modulo 100
MM = birth month
DD = departement
CCC = commune
NNN = number of your entry in the birth register of the commune
(for that year and month).
KK = check "sum".
So you can compute the SSN for normal people. There are other numbers
allocated for aliens, or other situations, that are less guessables, but
as mentionned above, it doesn't matter, since only the SSN use them as
identifier. Each administration and each enterprise has its own
identifier scheme.
Now, determining the degree this law is a law forbidding gravity is left
as an exercise to the reader.
> Now, within any given domain, we certainly want to require uniqueness
> - for example, no two people should have the same email address - but
> I'm pretty sure that this need for uniqueness within a given domain
> has been well known for a very long time.
That doesn't prevent a lot of couples to use the same email address (and
therefore to register only once to such domains, or use the + trick).
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
yves75
> > Now, within any given domain, we certainly want to require uniqueness
> > - for example, no two people should have the same email address - but
> > I'm pretty sure that this need for uniqueness within a given domain
> > has been well known for a very long time.
>
> That doesn't prevent a lot of couples to use the same email address (and
> therefore to register only once to such domains, or use the + trick).
Really, the proposal isn't about people identifiers at all, to tell
the truth I "hate" all this real names or non anonymous mindset, be
they on the "coolest" side à la facebook, or the most "technoid" ones
like an RFID chip under everybody skin (there are some people, even
academic ones that say they are in favor of such a thing ..)
pseudonyms have been used for a very long time! The proposal is really
about the "book of technology" (that can be considered as all machines
and programs stopped and considering only the evolution of them
through new versions, the connections of different instance somehow
also being part of the writing, and then you can also consider the
contents library). For people on the other hand, recognizing the need
for a "personal contracts, accounts, and licenses library" to be
handled by X or Y and transferable, but basically that doesn't change
anything you can do now (several emails, shared emails, etc), and that
wouldn't impose any common ID per person to be used in the systems by
different actors. It is also about having something which isn't
intrisically monopols based. And for contents for instance, I would
really appreciate being able to "buy a website", for life in a single
action (access to it), for instance the petit robert 2011, or many
other possible things (which is basically the same as buying an iphone
app for instance btw).
x
wrote in news:itt3h4$lvl$1...@dont-email.me:
> solution is to *not* coordinate, but make the liklihood of collision
> very small because of the length of the ID. The whole point of UUIDs
One way to make the probability of collision zero would be to derive the
UUID from the date and time and the latitude and longitude of the place
where it was generated. If the time gradient is fine enough, each new UUID
would be different because it would be generated at a different time. And
if the geographic gradient is fine enough, each place where UUID's are
generated would generate different ones. If you need them more frequently
than clock cycles, you can count up from zero at the start of each clock
cycle.
Pascal J. Bourguignon
> Raffael Cavallaro <raffaelc...@pas.despam.s.il.vous.plait.mac.com>
> wrote in news:itt3h4$lvl$1...@dont-email.me:
>
>> solution is to *not* coordinate, but make the liklihood of collision
>> very small because of the length of the ID. The whole point of UUIDs
>
> One way to make the probability of collision zero would be to derive the
> UUID from the date and time and the latitude and longitude of the place
> where it was generated.
We already have computer systems around or on different bodies in the
solar system. So you will have to add the body index relative to the
Sun.
We already have identified bodies around other stars, so you will have
to add the star index in the Milky Way.
And a galaxy index, and a cluster index, and a super cluster index.
I guess until we find a way to travel "faster than light", we can skip
the light cone identifier and the universe identifier.
Crap, I already said that to the OP in French!
--
__Pascal Bourguignon__ http://www.informatimago.com/
Raffael Cavallaro
> About authoritarian world government not at all, the ISBN org for
> instance, is a non profit organisation located in Germany I think, far
> from being a world government, and I doubt the ISBN.org organisation
> ever had a single word at all to say about which book should be
> published or not !
Malicious parties can spoof/counterfiet IDs and only law enforcement
can stop it.
To use your ISBN example, there are already fraudulent printers who
print unauthorized books, in violation of the Bern Convention, using
the ISBN code for the book they are counterfeiting. ISBN codes are
being hacked *already*. UPC codes have been hacked to allow lower price
purchase of merchandise.
A global identification database is only as useful as the degree of
compliance. Compliance is a law enforcement matter; the only reason
ISBN numbers work as well as they do is because national governments
take a dim view of book counterfeiting and periodically raid such
fraudulent printers; the only reason UPC codes work as well as they do
is because police arrest people counterfeiting them.
Enforcing *universal* compliance is an impossibility. That's why
programmers wisely chose a system (UUIDs) that doesn't require such
enforcement in order to function reliably.
yves75
Raffael, first of all the most usual way to generate UUIDs is to take
a MAC address (which are distributed administratively for every
ethernet or layer 2 device by the IEEE) and "lenghten" them up to 128
bits with random numbers, time stamps, or a mix of both. (that in
itself can create "tracability" questions), or sometime take a "domain
name" as the base (also distributed or "managed" administratively) and
also lenghten them up, so in a sense UUIDs are an extension of
administratively distributed IDs. But the key point is that, take the
"primary_keys" columns or "foreign_keys" columns of any or 99% of
todays RDBMS tables, and I don't think you will find any UUIDs in
there. Again UUIDs are mostly used for "transient" OS objects, but not
for any "real" persistent objects, be they business oriented such as
"order ids", "shipment ids", "product ids", "ticket numbers", "SIRET
numbers" or network oriented such as "node ids", "gateway ids", 'port
IDs", "all the IDs associated to phones or mobile devices" or
contents oriented such as "document ids", "ISANs", or "IMDB ids",
"youtube video IDs" and even less for all the attributes or functions
defined and used on these, and I don't think anybody is really
thinking of using them for these, as noted for instance in page 2 in
below document :
http://bibnum.bnf.fr/identifiants/identifiants-200605.pdf
Then about faking an existing ISBNs, ISCNs or other administratively
distributed IDs, don't see why UUIDs would make any difference there,
any existing ID can be "faked", that is copied and used in a context
where it shouldn't have been, and UUIDs are in no way different there.
In the end this is based on a "faith or trust chain", if ordering a
book with a given ISBN on Amazon or other shop, I trust Amazon for
providing me the right one, and in turn Amazon trust the publisher,
printer or distributor they are dealing with for providing the right
book. Same as if I buy an ethernet card, I trust the card maker to
have put in there a MAC adress that he got from the IEEE distribution
process. Or if receiving a packet from UPS or other package delivery
company having a given ID, I trust them for providing me the package
that was given this ID at shipment time.
Really don't see how UUIDs, administrative IDs or not, change anything
there.
However one thing for sure, people always complain that everything
works in "silos" in "IT", but this is primarily due to the fact that
if primary keys are defined as different IDs spaces at the beginning,
as is the case most of the time, then this is part of the systems TEXT
(or code) and data, and can only evolve this way. Using IDs in the
same space at the beginning on the other hand, doesn't oblige at all
to put everything in the same system, but allows further evolution or
refactoring made quasi impossible in the first case.
Cheers,
Yves
yves75
wrote:
> x <a...@b.c> writes:
> > Raffael Cavallaro <raffaelcavall...@pas.despam.s.il.vous.plait.mac.com>
> > wrote innews:itt3h4$lvl$1...@dont-email.me:
Pascal, as already pointed out in fr.comp.lang.lisp , I truly don't
understand your point regarding space travel and this IDs business,
computers sent to space are just a "projection" full of the same human
conventions and signs used on earth, "IT" doesn't "model" the world in
anyway (apart maybe from climate modeling and the like), it just
writes part of it, as does "la technique" in general.
Raffael Cavallaro
> don't see why UUIDs would make any difference there,
> any existing ID can be "faked
Version 4 UUIDs can't be easily faked because an attacker would have
only a 1 in 10^36 chance of guessing correctly. Under your system, the
actual IDs are entered in a *public* database making them trivial to
counterfeit. This is why it is so trivial (and common) to counterfeit
ISBN numbers for example; they're in a public database! This public
database only works because of *law enforcement*, not because everyone
on the planet magically agrees to be nicey-nice about book printing and
the associated copyrights.
The only remedy is to associate your public tags with *private* keys
known only to authorized parties, but then, of course, you no longer
have a *single* identifier, which is what the ieee (and I) have been
saying for this entire thread. If you want security, you must use
multiple IDs for different purposes/levels of privacy/levels of
authentication/levels of authorization.
OR just go the easy, probabilistic route, and use version 4 UUIDs,
which are effectively impossible to spoof because there are more than
10^36 of them.
yves75
Sorry Raffael, but I think you mix up two very different things.
1) Counterfeiting a publication that already has an IDs (for the
publication itself,not copy instances) : then this ID is public
whatever the system you use, as it is its --purpose-- to provide
access to this publication or information related to it. So whatever
ID used to identify this publication, it is public and you can just
paste it on your counterfeit copy and this is it. Again here you rely
on a trust chain to get a valid copy.
And by the way, ISBNs aren't in a "public database" at all, ISBNs are
a three segments identifier, first segment associated to a country (or
sometimes publication language, as for German), second segment the
editor, third segment the book or other published item within the
editor. Then you have databases of "ISBN identified published items"
related to libraries, online or not online bookshops, etc, but there
isn't a "central public database" of all "published"(used to identify
a publication) ISBNs.
You could say there could be problems of "stealing ISBNs" for an
editor that wouldn't want to bother getting an editor prefix for its
publications for instance (a bit like "unofficial port numbers"), but
this isn't the same issue at all as this guessing or counterfeiting
ISBNs. And by the way I don't think there are that much counterfeited
books these days, at least in Europe or the US, but this hasn't always
been the case by far, as described for instance by Diderot below :
http://classiques.uqac.ca/classiques/Diderot_denis/lettre_commerce_livre/lettre_com_livre.html
2) The problem of valid license numbers or instances identifiers :
there I understand your point, but this is completely different from
the publication identification aspect (the set of all copies), and
here I agree that it should be the responsibility of every publisher
to manage the corresponding IDs, and not use patterns that allow
"license key generators" if possible. But here somehow we go in the
"DRMs" issues, and somehow today I think if there were "private
bookshelves account holders" (or movies, records, etc, shelves),
recording that such account holder has bought this publication (the
access to it), at purchasing time in an interaction between the
account holder and the shop, this would be sufficient for further
access to the publication/service. Although yes, instance copies (or
license IDs) with "privately held databases of all assigned copy or
license IDs" could also be used in some cases, and picking them up
amongst a given ISCNs prefix could also be used there.
But again, in the "writing of the book", the issue is primarily
related to "concept" and publication IDs, much more than copies/
instance IDs, or for other things such as order ids, shipment ids, etc
where this "guessing" an id issue doesn't really come up.
Best regards,
Yves
Raffael Cavallaro
> Sorry Raffael, but I think you mix up two very different things.
It is you who are confused. You specifically want a *public* database
of *unique* tags. This is precisely what the IEEE recommends *against*.
Creating unique identifiers is *not* a technical problem; known
solutions are in widespread use. But making such a system work as
desired when the tags are *publicly* known is a political, social,
legal, compliance, and enforcement problem, not a technical one.
A *public* database is only as valuable as the level of compliance.
Compliance can only be enforced by governments/police. You seem to
assume that everyone on the planet will willingly cooperate just
because it would be convenient for you if they did. This is childishly
naive.
If compliance is not enforced you get:
a. Collisions. When people make up their own tags without registering
or requesting them from your global issuing authority, you *will* have
collisions. Since the only purpose of your tag database is uniqueness,
collisions render your whole system worthless.
b. Counterfeit. If governments/police do not enforce compliance, you
*will* have bad faith actors counterfeiting tags for profit and/or
malicious purposes. We already see this with ISBN codes (your own hand
picked example, btw), and UPC codes. And that's *with* law enforcement
trying to track down counterfeiters and stop them. What government or
police organization is going to enforce *global* compliance with your
proposed database?
So your only practical options are either:
1. Private, not public. Make your *unique* tags private to your
internal systems. This way you avoid collisions within all of your own
systems. You could use UUIDs for this as I suggested previously. The
chances of collisions is practically 0, and the opportunities for
malicious parties to guess an internally used UUID are likewise
essentially 0.
OR
2. Not unique. You publish one type of tag, but you map it to a
different *private* key for each purpose of identification,
authentication, and authorization, and for each desired degree of
privacy (this is what the ieee position paper is talking about).
You can't have a *public* and *unique* ID database without enforced
compliance. Compliance is a political, social, legal, and enforcement
problem, not a technical one. Moreover, compliance is a very difficult
problem to completely solve - that's why we have identity theft and
other forms of spoofing and counterfeiting. That's why the IEEE came
out *against* unique identifiers.
yves75
Sorry Raffael, you just don't understand what I'm talking about, and
the issue adressed, and putting little stars around each or a lot of
words doesn't change much about it.
Just consider that
- **all GS1** codes are public, and administratively distributed
- **all ISBNs** codes are public, and administratively distributed
- **all ISSNs** are public, and administratively distributed
- **all DOIs** are public, and administratively managed
- **all UNICODE code points** are public, and administratively managed
- no supermarket in the world would work without GS1 codes
- no library in the world or bookstore online or not would work
without ISBN codes (which are also GS1 codes)
- much of the reasearch papers references, would not work without DOIs
- No multilingual system would work without UNICODE code points
- The above represent ARTEFACT publication domains
- "IT" is also an artefact publication domain
- "IT", in all its glory, and awareness, pretends it could do without
IDs equivalent to the above (although it is *wiser* in some domains,
such as UNICODE for instance)
Ponders the above a bit,
That's about it
Cheers,
Yves
Fuschia, President-Elect of the Bright Purplish-Green Council
> Just consider that
> - **all GS1** codes are public, and administratively distributed
> - **all ISBNs** codes are public, and administratively distributed
> - **all ISSNs** are public, and administratively distributed
Aren't we forgetting something?
Internet domain names, and by extension all URLs. There's ICANN at the
top deciding what tlds exist and who administers them; then the .com,
.net, etc. registrars; then individual server operators who have foo.com
and can create bar.foo.com and other subdomains of foo.com; and then
individual site operators who have a website at bar.foo.com and can
create http://bar.foo.com/my/website/index.htm and the like.
Ultimately the one central point is ICANN deciding what tlds exist and
what registrars can create domains in each. Mostly you can get by
ignoring ICANN if you don't want a whole new tld. If you want a .com you
talk to a registrar. If you want yourname.blogspot.com you only need to
fill in a web form at Google and Google computers somewhere will make
sure it's not already taken.
yves75
Green Council" <fp-eotbp...@ibm.com> wrote:
> On 23/06/2011 4:18 PM, yves75 wrote:> Just consider that
> > - **all GS1** codes are public, and administratively distributed
> > - **all ISBNs** codes are public, and administratively distributed
> > - **all ISSNs** are public, and administratively distributed
>
> ...
>
> Aren't we forgetting something?
>
> Internet domain names, and by extension all URLs. There's ICANN at the
> top deciding what tlds exist and who administers them; then the .com,
> .net, etc. registrars; then individual server operators who have foo.com
> and can create bar.foo.com and other subdomains of foo.com; and then
> individual site operators who have a website at bar.foo.com and can
>
> Ultimately the one central point is ICANN deciding what tlds exist and
> what registrars can create domains in each. Mostly you can get by
> ignoring ICANN if you don't want a whole new tld. If you want a .com you
> talk to a registrar. If you want yourname.blogspot.com you only need to
> fill in a web form at Google and Google computers somewhere will make
> sure it's not already taken.
Yes fully agree with that, and the point is not to replace URLs (or
URIs, or URNs) at all, but the point is that :
- as said in the first message, "hierarchical" name spaces aren't in
fact --quite often-- hierarchic at all, but are more s-expression on a
flat symbol name space (or part of it)
- the perception that these "hierarchical" name spaces "scale up" is
an illusion, due to above item
- IT, and the web, as any other publication, artefacts, or
"conceptual" domain, needs a much more flattened, numerical style ID
space
- although I don't like the word "semantic" much, being more of a "tel
quelist", or Rimbaldist if you prefer (or maybe JY Girardist),
realizing something like the "semantic web", as defined by T.B. Lee,
means having something like that
- a symbol, a sign, an ideogramme, a letter, and associated UNICODE
code point isn't a "resource", it isn't an object either, but they are
key conventions in IT, and not only, a lot of things are similar
- if you buy the set (box) of Knuth first 3 volumes of "the art of
computer programming", this set (box) is a product having an ISBN --
next too--, or alongside if you prefer, the ISBNs of each of its
volumes
- any "primary key" in today's database systems is an identifier for
an IT "object" (and also often an ID for something in the "real"
world, if you want), "foreign key" is just a funny term to designate
another object.
- you can check the little wars about whether a DOI should be an URI/
URN or not
- today to insert a video in a forum or blog post, you don't use an
URL, you use something like [youtube]E&pgtrf[/youtube], where
"E&pgtrf" is a flat administratively managed public ID in the context
of youtube (and similar things for other video hosters)
- the vision isn't a top level with as many levels as needed down, but
more a source of IDs or a source of "convention atoms" or source of
"symbolic gas or pins" to facilitate the writing and ability to modify
the "technical book"
- the hierarchical aspect in these IDs is just there for distribution
aspects, and can be limited to 7 for instance (and doesn't need to be
fixed)
- a set or list of things can have one of these IDs alongside others
- software is as hard as hardware even if the "edit test edit" loop is
quite convenient in allowing to set up complex things
- the complexity in current systems is as much due to not "taking
care" of these IDs as the inherent complexity of the thing being
written, if not much more
- any ID can "traverse" any syntax or model, and this happens all the
time in IT
- talking or looking for an "enveloppe syntax" doesn't make sense, see
above point, and the fact that you can always define another syntax,
and use previous (already defined) IDs in it
- I am not sure whether this is related to Gödel theorem or not
- I am fully in line with ieee position statement referenced above
Something like that
Cheers,
Yves T
-----
http://iiscn.wordpress.com/about/
Pascal J. Bourguignon
> Yes fully agree with that, and the point is not to replace URLs (or
> URIs, or URNs) at all, but the point is that :
> - as said in the first message, "hierarchical" name spaces aren't in
> fact --quite often-- hierarchic at all, but are more s-expression on a
> flat symbol name space (or part of it)
This is wrong.
> - today to insert a video in a forum or blog post, you don't use an
> URL, you use something like [youtube]E&pgtrf[/youtube], where
> "E&pgtrf" is a flat administratively managed public ID in the context
> of youtube (and similar things for other video hosters)
Why can't you see that "youtube" is a node in the hierarchical name space,
with "E&pgtrf" being a child?
unicode://42
isbn://5060103590095
gs1://8420887000153
http://www.youtube.com/watch?v=FxXBUp-4800
looks quite hierarchical, and functional to me...
If you need to incorporate them in a lisp system, however, it would be
smarter to use another data structure than a package (with a single
hash-table of symbols) to store them, because you might have quite a lot
of leaves in those trees...
yves75
wrote:
What is wrong Pascal ? That key words "hierarchical" namespaces or
paths are often more s-expressions than real hierarchical spaces ?
No I think it is right : Don't you thing "README" for instance, is
used as the same symbol in all directory it appears ? The "README"
file being the image of a "README" function for the package or
directory it appears ?
And by the way this isn't a critic at all of this usage.
As to youtube, ISBN or other things, I'm just considering what appears
today in current TEXT (or databases).
And never said everything should be in a single system.
Pascal J. Bourguignon
> What is wrong Pascal ? That key words "hierarchical" namespaces or
> paths are often more s-expressions than real hierarchical spaces ?
> No I think it is right : Don't you thing "README" for instance, is
> used as the same symbol in all directory it appears ? The "README"
> file being the image of a "README" function for the package or
> directory it appears ?
> And by the way this isn't a critic at all of this usage.
Common Lisp has no hierarchical packages. That's enough of a problem in
this day and age...
yves75
wrote:
Not sure what common lisp has or hasn't has much influence to "this
day and age", Pascal
But anyway, this wasn't really the subject
Cheers,
Yves
yves75
> Not sure what common lisp has or hasn't has much influence to "this
> day and age", Pascal
Sorry, should be written :
Not sure whether what common lisp has or hasn't, has much influence
regarding "this
Raffael Cavallaro
> - **all ISBNs** codes are public, and administratively distributed
And they only work because governments and police enforce copyright laws.
What part of "compliance" do you not understand?
You propose a globabl, public, unique tag database. Who is going to
enforce compliance?
We can't even get a few lisp implementors to agree to update some
aspects of an already existing spec. You propose that every programmer
on the planet will agree to exclusively use tags assigned by a single
global authority in all software that runs on the internet. This
borders on delusional.
Raffael Cavallaro
Purplish-Green Council said:
> Aren't we forgetting something?
>
> Internet domain names, and by extension all URLs.
Which, again, only work because governments and the police enforce
them. Try spoofing the domain name of a major corporation and see how
long before the police kick in your door.
Wake up children - global schemes like these only function to the
extent that they do because of government and police enforcement, not
because everyone on the planet magically decides to be 100% compliant.
yves75
Ok Ralph, let's just stop there, really don't want to turn this into a
flame war, maybe you could realize that there are a lot of "primary
keys" in databases, that these different spaces create more complexity
than anything else, that no computer language Lisp Dylan or whatever
will help there, that a lot of "computer scientists" are still looking
for some solutions in syntax (as if the dictionnary never existed, or
as if something like XML would help in anyway without shared ID spaces
in any interface or exchange between two systems) or that when
publishing a video on youtube a public ID is allocated for ya on this
vid, that an ID is also allocated for you if creating a file in a
"cloud" file system, that this could also be used for code itself in
some ways, and that wasting isn't necessarily an issue there at all.
Don't forget that IP adresses are also some form of public IDs for
instance.
Regarding the law, police and actors relationships, you really don't
understand everything.
But many thanks for this exchange, truly eye opening really (or once
more).
With best regards,
Yves
Fuschia, President-Elect of the Bright Purplish-Green Council
> On 2011-06-23 20:34:16 +0000, Fuschia, President-Elect of the Bright
> Purplish-Green Council said:
>
>> Aren't we forgetting something?
>>
>> Internet domain names, and by extension all URLs.
>
> Which, again, only work because governments and the police enforce them.
Bullshit. Domain names and URLs worked for a long time with just
IETF/ICANN/Verisign administrating them. Now governments are looking to
potentially fuck them up with the so-called "PROTECT IP" act, which will
do anything but.
Raffael Cavallaro
Purplish-Green Council said:
> Domain names and URLs worked for a long time with just
> IETF/ICANN/Verisign administrating them.
We don't live in that past. We live in the present where the domain
name system works to the extent that it does because if you try to hack
it, the meatspace authorities will come after you.
Security is both a social/political/enforcement problem as well as a
technical problem. There is no technically brilliant aspect of the
domain name system that magically protects against fraudulent SSL
certificates:
<http://blog.mozilla.com/security/2011/03/22/firefox-blocking-fraudulent-certificates/>
<http://www.computerworld.com/s/article/9215360/Comodo_hacker_claims_another_certificate_authority>
etc.
Fuschia, President-Elect of the Bright Purplish-Green Council
> On 2011-06-25 19:17:38 +0000, Fuschia, President-Elect of the Bright
> Purplish-Green Council said:
>
>> Domain names and URLs worked for a long time with just
>> IETF/ICANN/Verisign administrating them.
>
> We don't live in that past. We live in the present where the domain name
> system works to the extent that it does because if you try to hack it,
> the meatspace authorities will come after you.
>
> Security is both a social/political/enforcement problem as well as a
> technical problem. There is no technically brilliant aspect of the
> domain name system that magically protects against fraudulent SSL
> certificates
Way to completely miss the point. Nobody said anything about SSL
certificates, which are a completely separate matter from URLs. SSL
provides for encrypted communications with a remote network host, and
possibly for validation that a particular person or business operates
that host. It's separate from DNS.
There's also a technical proposal in the works called DNSSEC for a much
less hackable DNS, which is less hackable for technical rather than
cops-busting-down-doors reasons.
Raffael Cavallaro
Purplish-Green Council said:
> Nobody said anything about SSL certificates, which are a completely
> separate matter from URLs.
SSL certificates are essential to authenticate the only widely
available secure means of accessing URLs that we have (HTTPS) so of
course SSL certificates are relevant to the verifiable functioning of
the URL system. Without SSL certificates man-in-the-middle attacks
would be rampant; no one could be sure that the URL they thought they
were connecting to was actually that URL or a site some hacker had
redirected them to. Do you do on line banking or credit card
transactions over ordinary http? I certainly hope not.
> There's also a technical proposal in the works called DNSSEC for a much
> less hackable DNS, which is less hackable for technical rather than
> cops-busting-down-doors reasons.
"less hackable" and unhackable are not the same, and DNSSEC isn't even
in use yet.
For the last time, technical people tend to wildly overestimate the
extent to which security is a technical issue, and grossly
underestimate how much it is a social, political, and enforcement
issue. Hackers generally attack the weakest link in a system, not the
most technically unassailable. The upshot is that what *really* keeps
such attacks to a minimum is law enforcement as deterrent, not the
technical brilliance of the system.
When people find ways to break into systems the police catch them, and
the courts put them away. Knowing this is a significant discouragement
to a much larger number of attacks. The locks on your doors are not the
only thing keeping others out; the knowledge that they could very well
go to prison for it is a major factor keeping your home safe whether
the locks are un-pickable or not.
Fuschia, President-Elect of the Bright Purplish-Green Council
> On 2011-06-25 21:16:42 +0000, Fuschia, President-Elect of the Bright
> Purplish-Green Council said:
>
>> Nobody said anything about SSL certificates, which are a completely
>> separate matter from URLs.
>
> SSL certificates are essential to authenticate the only widely available
> secure means of accessing URLs that we have (HTTPS) so of course SSL
> certificates are relevant to the verifiable functioning of the URL
> system.
What does your classic unsubstantiated and erroneous claim have to do
with Lisp, Cavallaro? SSL has nothing to do with URLs and everything to
do with *preventing eavesdropping* and *knowing who's at the other end
of the line*.
> Without SSL certificates man-in-the-middle attacks would be
> rampant; no one could be sure that the URL they thought they were
> connecting to was actually that URL or a site some hacker had redirected
> them to.
Classic illogic. You're conflating URLs with the identities of sites,
Cavallaro. First of all a single site normally has more than one URL,
Cavallaro. Second, a site can move to new addresses from time to time
and still be the same site.
> Do you do on line banking or credit card transactions over
> ordinary http? I certainly hope not.
Irrelevant.
>> There's also a technical proposal in the works called DNSSEC for a
>> much less hackable DNS, which is less hackable for technical rather
>> than cops-busting-down-doors reasons.
>
> "less hackable" and unhackable are not the same,
What does your classic pontification have to do with Lisp, Cavallaro?
> and DNSSEC isn't even in use yet.
Suffering from reading comprehension problems, Cavallaro? That's already
implicitly acknowledged by my use of the phrase "proposal in the works",
Cavallaro.
> For the last time, technical people tend to wildly overestimate the
> extent to which security is a technical issue,
What does your classic unsubstantiated and erroneous claim have to do
with Lisp, Cavallaro?
> and grossly underestimate how much it is a social, political, and
> enforcement issue. Hackers generally attack the weakest link in a
> system, not the most technically unassailable.
What does your classic pontification have to do with Lisp, Cavallaro?
So, with DNSSEC in place they'd probably attack something else besides
DNS. And then that would get shored up, and so on. Nobody's denying that
it's an ongoing arms race, Cavallaro.
> The upshot is that what *really* keeps such attacks to a
> minimum is law enforcement as deterrent, not the technical brilliance of
> the system.
Law enforcement is not particularly concerned with domain squatting and
similar disputes, Cavallaro. Wire fraud gets their attention, of course,
but it does so no matter how it is carried out technically.
> When people find ways to break into systems the police catch them, and
> the courts put them away.
What does your classic pontification have to do with Lisp, Cavallaro, or
even with the naming system for URLs?
> Knowing this is a significant discouragement to a much larger number
> of attacks.
Tell that to Sony and to everyone that's been hacked by Anonymous or
Lulzsec recently, Cavallaro. Meanwhile the biggest threat to DNS right
now is coming from the black hat hackers that are also known as the
Department of Homeland Security's Immigrations and Customs Enforcement
arm, Cavallaro, subsidized by us taxpayers. A Second American Revolution
would do more for Internet security than any amount of money spent
uselessly chasing Lulzsec and Anonymous, Cavallaro; indeed the latter
task can be likened quite strongly to chasing insurgents all around
Vietnam and, later, Iraq, Cavallaro.
> The locks on your doors are not the only thing keeping others out;
> the knowledge that they could very well go to prison for it is a
> major factor keeping your home safe whether the locks are
> un-pickable or not.
What does your classic pontification have to do with Lisp, Cavallaro?
> warmest regards,
>
> Ralph
What does your dubious claim have to do with Lisp, Cavallaro?
yves tremolet
Thanks for the "heads up" president !
I'm not an expert enough in security to add anything to the
discussion, but think I follow more or less your points.