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.