LSID DNS concerns

Wed Dec 21 11:47:21 CET 2005

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.

--=_alternative 005C375E852570DE_=
Content-Type: text/html; charset="US-ASCII"

Hi All,
 &nbsp; &nbsp; Let me first introduce
myself to the community. &nbsp;I have been working on the LSID standard
at IBM since January 2003. &nbsp;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. &nbsp;I implemented and am maintaining
the Java version of the protocol. &nbsp;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. &nbsp;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. &nbsp;I will address
them below.
 
 - Ben Szekely
 
 <tt>* 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?!?!?)</tt>
 
 <tt>This argument is an easy one to toss. &nbsp;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.</tt>
 
 <tt>You have the same problem with regular domain names.
&nbsp;An organization must use their own trademarks in the authority name.</tt>
 <tt> 
* DNS administration model is not suitable for a general purpose name 
system, i.e., only network administrators can manage DNS records.</tt>
 
 <tt>Each authority need only setup their SRV record once.
</tt>
 <tt> 
* Change in ownership of domain names can prevent authorities from 
resolving identifiers.</tt>
 
 <tt>If an organization changes their authority name after
issuing LSIDs, they should support resolution of the old LSIDs for a sufficient
duration.</tt>
 <tt> 
* That reduces semantic opacity of identifiers</tt>
 
 <tt>The authority name says nothing about where any of
the services reside. &nbsp;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. &nbsp;In this way, the LSID
is opaque as possible. &nbsp;We must have *some* service to resolve the
name thus, the authority name must be non-opaque to some machine somewhere.
&nbsp;Our opacity requirement is that it is opaque to the users. &nbsp;</tt>