Hi All,
Let me first introduce
myself to the community. I have been working on the LSID standard
at IBM since January 2003. I have had the pleasure working with people
in various communities on implementing LSID services and framing the specification
into its current OMG-approved form. I implemented and am maintaining
the Java version of the protocol. I work with several other LSID
experts at IBM in Cambridge, MA so between us, we may be able to answer
any of your LSID questions. I look forward to working wth all of
you.
In a previous posting, some concerns
about the use of DNS in LSID resolution were raised. I will address
them below.
- Ben Szekely
* DNS would not scale to support a large number of
digital objects as
required in a GUID framework (did they mean to use one domain name as an
identifier for every object?!?!?)
This argument is an easy one to toss. With LSID,
DNS is only used to resolve the authority portion of the LSID. The number
of LSID authorities is likely to be much smaller than the number of internet
domains so such scalability is not a problem.
* Names included in identifiers might be implicated in trademark disputes.
You have the same problem with regular domain names.
An organization must use their own trademarks in the authority name.
* DNS administration model is not suitable for a general purpose name
system, i.e., only network administrators can manage DNS records.
Each authority need only setup their SRV record once.
* Change in ownership of domain names can prevent authorities from
resolving identifiers.
If an organization changes their authority name after
issuing LSIDs, they should support resolution of the old LSIDs for a sufficient
duration.
* That reduces semantic opacity of identifiers
The authority name says nothing about where any of
the services reside. The location of the authority service, as well
as the data and metadata services may not reside on a host with a domain
that looks anything like the authority name. In this way, the LSID
is opaque as possible. We must have *some* service to resolve the
name thus, the authority name must be non-opaque to some machine somewhere.
Our opacity requirement is that it is opaque to the users.