[DDI-SRG] Proposal for DNS-based DDI URN resolution and new DDI URN Syntax

[I-Lin Kuo]

Hi Achim,

It's nice to see that DDI is still going strong.

It took me a while to understand that you actually mean to use DNS to store
NAPTR for individual DDI documents. See my last comment, marked with "***"


On Sun, May 24, 2009 at 11:31 PM, Joachim Wackerow <
joachim.wackerow at gesis.org> wrote:

> Hi I-Lin,
>
> It is good to hear from you. Thanks for your comments.
>
> Please note that the proposal uses DNS as a generic distributed database
> system not just to look up IP numbers for IP names or the other way around.
> This approach is also used by voice-over-ip techniques like ENUM and SIP.
>
> See my notes in the text below.
>
> Additional thoughts welcome.
>
> Achim
>
> I-Lin Kuo wrote:
>
>> 1) In both the examples
>>    DDI URN "urn:ddi:gesis.de:3_1:Instance.s1786.4_3"  is resolved to URL
>> "http://repos.gesis.org/URN?urn:ddi:gesis.de:3_1:Instance.s1786.4_3" by
>> the DNS record
>>
> The NAPTR record points the URN (written as a DNS domain) just to an URI
> which is here an URL. No wildcards are used in this example, further
> resolution or other techniques (see the "u" flag of NAPTR). You will find
> similar records at ENUM where a phone number points to an voice-over-ip
> address.
>

I'm not familiar with ENUM, so I'll quote from the Wikipedia entry for ENUM:

For an ENUM subscriber to be able to activate and use the ENUM service it
needs to obtain three elements from a Registrar:

   1. A personal Uniform Resource
Identifier<http://en.wikipedia.org/wiki/Uniform_Resource_Identifier>(URI)
to be used on the
   IP <http://en.wikipedia.org/wiki/Internet_Protocol> part of the network,
   as explained below
   2. One E.164 <http://en.wikipedia.org/wiki/E.164> regular personal
   telephone number associated with the personal URI, to be used on
the PSTN<http://en.wikipedia.org/wiki/PSTN>part of the network
   3. Authority to write his call forwarding/termination preferences in the
   NAPTR <http://en.wikipedia.org/wiki/NAPTR> record accessible via the
   personal URI

This works as follows: (1) the Registrar provides the Subscriber (or
Registrant) with a domain name, the
URI<http://en.wikipedia.org/wiki/Uniform_Resource_Identifier>,
that will be used to access a DNS server to fetch a
NAPTR<http://en.wikipedia.org/wiki/NAPTR>record, (2) a personal
E.164 <http://en.wikipedia.org/wiki/E.164> telephone number (the ENUM
number). The URI
<http://en.wikipedia.org/wiki/Uniform_Resource_Identifier>domain name
of (1) is biunivocally associated (one-to-one mapped) to the
subscriber E.164 <http://en.wikipedia.org/wiki/E.164> ENUM number of (2).
Finally (3) the NAPTR <http://en.wikipedia.org/wiki/NAPTR> record
corresponding to the subscriber
URI<http://en.wikipedia.org/wiki/Uniform_Resource_Identifier>contains
the subscriber call forwarding/termination preferences.

IK: ENUM uses a two step lookup process -- one to find the DNS server that
has the NAPTR record and two to retrieve the NAPTR from that server. The
part that's missing from the specification that I can see is the "how to
find the DNS server". I don't see how that, given a DDI xml document with
the URN "urn:ddi:gesis.de:3_1:Instance.s1786.4_3<http://repos.gesis.org/URN?urn:ddi:gesis.de:3_1:Instance.s1786.4_3>"
I'm supposed to be able to find the DNS server that holds the NAPTR entry.

>      and the rewrite rule
>>    <rewriteURI uriStartString="urn:ddi:gesis.de <http://gesis.de>"
>> rewritePrefix="http://repos.gesis.org/URN"urn:ddi:gesis.de <
>> http://gesis.de>"/>
>>
> "rewriteURI"  of XML catalog replaces just the defined prefix with another
> one. It is a simple string replacement, no resolution in a DNS sense. The
> resolver application which reads this XML catalog should accordingly map
> "urn:ddi:gesis.de:3_1:Instance.s1786.4_3" to "
> http://repos.gesis.org/URN?urn:ddi:gesis.de:3_1:Instance.s1786.4_3"
> The repository service at "http://repos.gesis.org/URN" should be able to
> give as response the object identified by the DDI URN.
> (See the XML Catalog specification at
> http://www.oasis-open.org/committees/entity/spec-2001-08-06.html#s.rewriteuri
> )
>

IK: It's the same issue here. How do I know that "gesis.de" is supposed to
be rewritten with "repos.gesis.org" unless I look it up somewhere? Where is
the DNS server that I can look this up ?


>
> When an application uses this service it has to do a regular DNS IP number
> lookup for repos.gesis.org. That shouldn't be a problem.


The problem is knowing to look up "repos.gesis.org" when the URN I'm
actually given is
"urn:ddi:gesis.de:3_1:Instance.s1786.4_3<http://repos.gesis.org/URN?urn:ddi:gesis.de:3_1:Instance.s1786.4_3>".
This rewrite rule does not exist in the client application.


>       the agency ID "gesis.de <http://gesis.de>" is somehow resolved to "
>> repos.gesis.org <http://repos.gesis.org>". Where is this resolution
>> defined? This would seem to me to involve an additional lookup into a DDI
>> agency resolver? It's better to simply use the appropriate domain name or
>> subdomain name in order to avoid this extra step (as well as the creation of
>> a DDI agency resolver)
>>
>> 2) There's a conceptual confusion in what DNS is, as evidenced by the
>> statements:
>>
>> "The DDI URN (new format)
>>
>> urn:ddi:maintaining-agency-id:ddi-version-number:name-of-maintainable-object.id-of-maintainable-object.object-version-number
>> is related to the DNS name
>>
>> object-version-number.id-of-maintainable-object.name-of-maintainable-object.ddi-version-number.maintaining-agency-id.ddi.urn.arpa."
>>
> This is just a rewrite from one naming syntax (DDI URN) to another (DNS
> name). This should be done by the resolver application (client).
>

The resolver can do so if it is a pure syntactical manipulation. The
transformation from "gesis.de" to "respo.gesis.org" is not purely
syntactical. The transformation of a phone number such as +34 98 765 4321
into the ENUM domain "1.2.3.4.5.6.7.8.9.4.3.e164.arpa" via RFC 3761 is
purely syntactical (since all enum domains end with e164.arpa)

and
>>
>> "A DNS name has a maximum length of 255 characters (including all dots)"
>>
>> The DNS is a system for mapping readable hostnames to IP addresses. In the
>> narrowest sense of DNS, it simply maps domain names to ip addresses.
>>
>
> As mentioned above the proposal uses DNS as a distributed database by means
> of the NAPTR records.
>
>  As an example, with a URL such as "
>> http://repos.gesis.org/URN?urn:ddi:gesis.de:3_1:Instance.s1786.4_3", the
>> domain name of repos.gesis.org <http://repos.gesis.org> is resolved to
>> 216.24.138.156. Then the request is forwarded to the server at
>> 216.24.138.156, which decides what it wants to do with the rest of the URL.
>> The 255 octet limit only applies to the domain name "repos.gesis.org <
>> http://repos.gesis.org>", not to the entire URL. There are practical
>> limitations on the length of the entire URL, as browsers may place
>> limitations on the length of the URL, but those limits are unlikely to be
>> reached by DDI.
>>
> I would welcome when there is not a limitation on the names which are
> looked up in the DNS, but I'm not sure about that. The domain (at NAPTR the
> key, here the URN) seems to have the limitation of 255 octets (see
> http://tools.ietf.org/html/rfc3403#page-5). The URI (as replacement string
> in the NAPTR record) seems to have no limitation.
>

***Ah, OK, I didn't understand that you really mean to place each ddi
document as an actual entry in DNS. In that case, you really would be
limited to 255 octets. You could also get away with a single step lookup
process, and my previous points of argument would be moot.

However, I would advise against this architecture as it is not scalable.
There is a good reason why DNS entries are for domains and not individual
web documents.

>
>
>
>> So, I'd recommend that a review of the meanings of URI, URN, and URL be
>> done, and a lot of the references in the document to "DNS" be replaced by
>> URL.
>>
>> 3) Instead of resolving "urn:ddi:gesis.de:..." to "
>> http://repos.gesis.org/URN?...", I'd recommend that the resolution be to
>> "http://ddi.repos.gesis.org/...". While Apache can certainly rewrite any
>> URL, the first URL looks as if the main website server is doing the
>> resolution, while the second one looks as if there is a server dedicated to
>> DDI resolution.
>>
> I assumed that the web server of GESIS is www.gesis.org.
> ddi.repos.gesis.org is surely be clearer than repos.gesis.org. This is up
> to the institution which provides the service. Actually it could be also
> anything like xy.gesis.org or x.y.z.gesis.org
>
>
>> On Sun, May 24, 2009 at 2:32 AM, Joachim Wackerow <
>> joachim.wackerow at gesis.org <mailto:joachim.wackerow at gesis.org>> wrote:
>>
>>    Attached are two documents on DNS-based DDI URN resolution and on a
>>    new DDI URN syntax. Both documents are related.
>>
>>    This proposal raises the question, how we can deal with this with
>>    the background of the new version 3.1?
>>
>>    Achim
>>
>>    --    GESIS - Leibniz Institute for the Social Sciences
>>    Postal address: P.O. Box 122155, 68072 Mannheim, Germany
>>    Visiting address: B2 1, 68159 Mannheim, Germany
>>    Phone: +49 (0)621 1246 262
>>    Fax: +49 (0)621 1246 100
>>    E-mail: joachim.wackerow at gesis.org <mailto:joachim.wackerow at gesis.org>
>>    www.gesis.org/en/institute/ <http://www.gesis.org/en/institute/>
>>
>>    _______________________________________________
>>    DDI-SRG mailing list
>>    DDI-SRG at icpsr.umich.edu <mailto:DDI-SRG at icpsr.umich.edu>
>>    http://www.icpsr.umich.edu/mailman/listinfo/ddi-srg
>>
>>
>>
>>
>> --
>> I-Lin Kuo
>>
>
>
> --
> GESIS - Leibniz Institute for the Social Sciences
> Postal address: P.O. Box 122155, 68072 Mannheim, Germany
> Visiting address: B2 1, 68159 Mannheim, Germany
> Phone: +49 (0)621 1246 262
> Fax: +49 (0)621 1246 100
> E-mail: joachim.wackerow at gesis.org
> www.gesis.org/en/institute/
>



-- 
I-Lin Kuo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.icpsr.umich.edu/pipermail/ddi-srg/attachments/20090525/08fe1b69/attachment-0001.html