Re: Draft minutes from TAG telcon of 2008-07-24, plain text

Whether the lookup overhead is acceptable or not I won't argue.  My point
was simply this: people in the discussion allude to naming rules imposed by
ARK; I claim that ARK imposes no such rules. (I'm not claiming that the ARK
approach is practical.) --Ray

----- Original Message ----- 
From: "Schleiff, Marty" <marty.schleiff@boeing.com>
To: "Ray Denenberg, Library of Congress" <rden@loc.gov>; <www-tag@w3.org>
Sent: Monday, July 28, 2008 3:27 PM
Subject: RE: Draft minutes from TAG telcon of 2008-07-24, plain text


Both proposed answers (name mapping authority discovery mechanism, and
"ark.loc.gov") add undesirable overhead to the ARK approach just to
determine if an identifier that looks like an ARK is in fact an ARK.
Perhaps ARK is far enough down the road that they can't rearchitect with
a booth-bradley TLD approach, or with a separate URI scheme, or some
other unambiguous indicator that would make the overhead unnecessary.

Other kinds of identifiers (at least XRIs) are designed without such
ambiguity, specifically to avoid unnecessary overhead just to figure out
whether an identifier is an XRI or not.

Even if it's necessary for ARK, I think the approach of using an
ambiguous indicator in the path of a URI should not be promoted for XRIs
or other non-ARK identifiers.


Marty.Schleiff@boeing.com; CISSP
Associate Technical Fellow - Cyber Identity Specialist
Information Security - Technical Controls
(206) 679-5933

-----Original Message-----
From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov]
Sent: Friday, July 25, 2008 2:31 PM
To: www-tag@w3.org
Subject: Re: Draft minutes from TAG telcon of 2008-07-24, plain text


>  it's not fine for any client to interpret the presence of ark: to
> mean "this URI is an ARK"

I think the ARK spec addresses this problem, at least theoretically (if
not practically).

Suppose the library of congress, who does not participate in ARK at
present, has a URI of the form:

http://www.loc.gov/ark:/12025/654xz321

where 12025/654xz321  is a document within our Architecture and
Recursive Knowledge database. The problem is that some client will see
that URI and assume that it will resolve to an instance of the resource
identified by the ARK  ark:/12025/654xz321

The answer to the problem (in theory) is that the client should first
know whether www.loc.gov services ARKs. More generally, there is (should
be) a "Name Mapping Authority" discovery mechanism. (e.g. if www.loc.gov
services ARKs then it is referred to as an "Name Mapping Authority").
The ARK spec discusses this discovery mechanism (if only theoretically).
Section 4, http://tools.ietf.org/html/draft-kunze-ark-15.

The second part of the problem, what if loc subsequently decides that it
wants to join the ARK party, though it already has unrelated URIs like
http://www.loc.gov/ark:/12025/654xz321  .

That's an easy problem (as Eric Hetzer pointed out) it can use
ark.loc.gov to service ARK requests, and as long as www.loc.gov isn't
listed in the ARK name mapping authority database, there's no conflict.

--Ray

Received on Monday, 28 July 2008 21:32:00 UTC