Re: [urn] Request for new URN namespace review: LEX

[Enrico Francesconi <[e-mail]>]

Dear All,
   as agreed please find below our replies to the remaining remarks, those of Sabrina and Juha. We will then proceed by including the proposed changes in the new draft.

Also these new replies have been grouped with respect to each reviewer and, for each remark, we provide:
a synthesis of the requests (Req:)
our answers (Ans:)
arguments for a further analysis (To Deepen:)
Best regards
   Pierluigi and Enrico



******************************
Sabrina’s comments
******************************
33. urn NID registry
Req: Expert review should be completed before your document can be approved for publication as an RFC
Ans: waiting for the conclusion of the revision

34. Sect. 11.1 - NAPTR records
Req: approval of the IAB to implement NAPTR records. Is the host lex.ittig.cnr.it guaranteed for a long term?
To Deepen: We can contact other institutions able to guarantee long-term maintenance of a hostname, ex. “registro.it”, the CNR (Italian National Research Council) service which provides registration of the domain names .it and .eu

Req: It might be better to document the approach in such a way that that exact form of the NAPTR record is not in the I-D
Ans: provide only a generic information, ex. dns-lex.foo

35. Jurisdiction codes registry

Req: Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing
category at http://www.iana.org/protocols?

To Deepen: see point 18, anyway at the beginning there are no records in it

36. Final operations
Req: only when the RFC will be approved
Ans: we’ll wait the final RFC approval

******************************
Juha’s comments
******************************
37. Mandate
Req: Based on the I-D, it is not clear what mandate ITTIG-CNR has. 
Would URN:LEX complement existing systems?
Establishing a urn namespace to sources of law can be useful in the long term.
Ans: No specific mandate: this is a proposal for a global namespace which every system can adhere to

38. Administration
Req: ITTIG-CNR will be responsible of maintaining the uniqueness of the <jurisdiction> 
element.
Req: In the level of country codes this will be easy. But there may be a large number of sub-
divisions within each country, and also organization-based sub-divisions. If urn:lex becomes popular, it may be a substantial task to maintain <jurisdiction> and to support organizations  in making their urn:lex identifiers actionable.
Has ITTIG-CNR estimated the amount of work required in the short term / long term?
Ans: The responsibility of maintaing jurisdiction codes will be distributed at the level of each 
jurisdiction, according to a federative de-centralized approach (see sect. 7.2)

39. Semantic and syntax
Req: The template does not provide sufficient information about the semantics and syntax of NSS, but luckily draft-spinosa-urn-lex-11 is very detailed in that respect. Most URN namespaces (and traditional identifiers) have relatively simple semantics. Identifiers may be totally "dumb" (it is impossible to see from the NSS what the URN identifies) and even if the identifier has some semantic like ISBN, things are kept simple (for those in the know, ISBN reveals the country and the publisher) URNs from proposed urn:lex namespace may contain a lot of information about the identified resource It may be difficult, both for humans and applications, to make sense of this.
Ans: The suggested metadata are necessary to guarantee, unequivocal identifiers, nevertheless not all of them are mandatory. In the references, only metadata at the level of Work are required (see email on 9/20 in response to Dale’s remarks)

Req: Having a lot of semantics in the NSS may overload the resolvers with tasks which should be  done by passing a request to an appropriate target system. It is also more challenging to develop assignment rules for a very semantic identifier system, and to be able to use such 
system correctly
Ans: the hierarchical structure paves the way to a structured resolution (see e-mail to Dale on 
9/20)

Req: As regards syntax, concerns about un-encoded use of @ to indicate an expression of a work
To Deepen: not clear the motivations

40. Resolution
Req: ITTIG-CNR intends to maintain a centralized resolution service for urn:lex. Better one for  each jurisdiction
Ans: Actually not. The idea is to de-centralize the system, starting from the jurisdiction, 
until the issuing authority. We will emphasize Sections 8.1 and 8.2

Req: It would of course be possible to harvest URN - URL mapping tables from national lex 
resolvers into the central resolver maintained by ITTIG-CNR.
Ans: Currently it is not foreseen



---------------------------------------------------------
Enrico Francesconi
ITTIG - CNR
Institute of Legal Information Theory and Techniques
Italian National Research Council

Via de' Barucci 20
50127 Florence
Italy

Tel: [phone]
Fax: [phone]
email: [e-mail]
---------------------------------------------------------

> On 06 ott 2017, at 21:00, Enrico Francesconi <[e-mail]> wrote:
> 
>  Dear All,
>    thanks a lot everyone for the global revision of the urn-lex draft and for your useful comments on the document. We have finalized the analysis of most of them, therefore we send you here below a sum-up of the interventions we would like to provide to the document.
> We will be back with feedback to the most recent comments from Sabrina’s and Juha’s in a following email.
> We grouped comments with respect to each reviewer and, for each remark, we provide:
> a synthesis of the requests (Req:)
> our answers (Ans:)
> arguments for a further analysis (To Deepen:)
> 
> In case approved we will prepare a draft v.12 accordingly, to be then validated.
> Please let us know how to proceeed or any additional remarks.
> Thanks again for your collaboration
> best regards
> 
> Pierluigi and Enrico
> 
> 
> ******************************
> Dale's comments
> ******************************
> A. Major items
> 
> 1. Annex A: Use of alfanum, etc.
> Req: Simplifying syntax with non-terminal elements
> Ans: We will simplify the syntax in the direction required
> 
> 2. Sez. 4.4: How are non-ASCII characters to be handled?
> Req: Different management of non-ASCII characters in different sections. UTF-8% encoded or punycode incompatible
> Ans: strongly recommend the use of ASCII base. In this case we can use a straightforward DNS query for routing. In case this solution is unacceptable for a jurisdiction: use UTF-8% encoded in URNs and use punycode conversion in DNS. In this case, the jurisdiction has to implement a software conversion as an interface for DDDS
> 
> 3. Sez. 3.2: Compatibility with RFC 2141 and use of "~"
> Req: character "~" not allowed in RFC 2141
> Ans: declare that the syntax conforms to RFC 8141
> 
> To Deepen: For backward compatibility, the "/", previously prohibited in URNs, is reserved for future use, then we can remove the "/" from prohibited characters and include it in "future expansions"
> 
> 4. Sez. 11.2: The pseudo-TLD ".lex"
> Req: it no longer works if .lex is assigned
> Ans: use pseudo-domain "lex.arpa"
> 
> 5. Sez. 6.7: Dealing with publishers
> Req: Possible issues if an event is assigned by an editor independently
> To Deepen: By joining the federated system, a publisher accepts the urn-lex rules. The Jurisdictional Registrar (Section 7.2) provides guidelines and monitors their application
> Req: Domain Name Editor: persistence of the manifestation depends on the publisher
> To Deepen: Common problem with all components where a domain name is indicated. Think of a solution through aliases
> 
> B. Minor points
> 
> 6. Abstract
> Req: World Wide Web Consortium reference for resource identification
> Ans: Replace W3C with IETF
> 
> 7. Sez. 1.1: The Purpose of Namespace "lex"
> Req: Useful when mapped on HTTP URLs and not URIs
> To Deepen: we often talk about http uri. Maybe we can emphasize its function as identifier rather than as locator.  The identifier is often not an absolute URL
> 
> 8. Sez. 1.4: General Characteristics of the System
> Req: SHOULD seems more appropriate than MUST
> Ans: replace "must" with "should"
> 
> 9. Sez. 2: Syntax label
> Req: The syntax and semantics of components r- and q- are not defined in the document
> Ans: after: "... introduced by [RFC8141]" insert: "The use of r- and q- components with LEX URNs is not defined in this document. But they provide new ... "
> 
> 10. Sect. 2: Documentation
> Req: better replace "none" with a reference to the same document
> Ans: replace "none" with: "The details of the syntax, semantics and use of LEX URNs are given in [this RFC]."
> 
> 11. Sect. 3.1: Identifier structure
> Req: Capitalization of Section Title: non-consistent document
> To Deepen: Check rules for writing section titles
> 
> Req: representation of non-ASCII characters in RFCs
> Ans: right: the guidelines suggest using the Unicode convention U + XXXX
> 
> 12. Examples
> Req: Are the examples shown real or hypothetical?
> Ans: Include the following: "All URN examples in the document are hypothetical"
> 
> 13. Sez. 5.3: Ordinal Numbers
> Req: To clarify whether it is Western or Eastern Arabic numbers
> Ans: add "Western" before "Arabic numbers"
> 
> 14. Sez. 6.1: Basic Principles
> Req: substitution suggestion of "by parser" with "from parser"
> Ans: replace "by parser" with "from parser"
> 
> 15. Sez. 6.7: Structure of the Document Identifier at Manifestation Level
> Req: syntax ambiguity: with only one element, it is not clear whether it is component or feature
> Ans: Correct syntax according to Dale's suggestions in the presence of features, component (if absent) is set to "all" (whole document)
> 
> 16. Sez. 6.8: Sources of Law References
> Req: Partition ID indicates an element and not a simple location
> To Deepen: It is true, but it depends on the level of granularity of the identification systems (documents or also partitions?).
> 
> 17. Sez. 8.1: The General Architecture of the System
> Req: Incomplete reference: RFC 3403 only defines NAPTR records
> Ans: Add reference to RFC 3405 explaining why the lex.urn.arpa domain is created
> 
> 18. Sez. 11.2: Jurisdiction-code Registration
> Req: missing the description of the registry structure
> Ans: Specify format and examples of the registry of jurisdiction codes
> 
> 19. Annex A: Summary of the syntax of the uniform names of the "lex" namespace
> Req: Reported several errors or ambiguities: lowercase; body/function/office, component/feature, ...
> Ans: review the syntax, according to Dale's suggestions. Test the syntax with a parser
> 
> 20. Annex A: Summary of the syntax of the uniform names of the "lex" namespace
> Req: syntax error for % encoded
> To Deepen: Correct the % encoded syntax (see RFC 3261 par.25.1)
> 
> 21. Annex A, Sec. B1.4 (Indication of the Body) and B1.5 (Indication of the Function)
> Req: ambiguity between body / function / office
> Ans: Correct syntax to eliminate ambiguities
> 
> 22. Annex D and D1: Http-based LEX identifier
> Req: HTTP and non-HTTP-based
> Ans: delete "based"
> 
> Req: Same names used for http and urn elements: same semantics but different syntax
> To Deepen: Use same names in http and urn elements, maybe change delimiters
> 
> 23. Sez. D1: Http-based URI
> Req: Wrong Link to Linked Data
> To Deepen: Correct reference to Linked Data
> 
> 
> ******************************
> Paul's comments
> ******************************
> 
> A. Major items
> 
> 24. Scope of the document
> Req: Doc. describes not only URN but a fully federated system. Better divide the two documents
> To Deepen: postpone the decision at the end of the discussion
> 
> 25. Name or query?
> Req: Doc. also describes how to use URNs as a query, incompatibility with URNs
> To Deepen: Document: URN Full and Unique; references: URN incomplete, but useful (see e-mail sent to Dale on 9/20)
> 
> B. Minor points
> 
> 26. Sez. 11.2: Jurisdiction-code Registration
> Req: Re-assigning ccTLD: using the solution of international institutions?
> Ans: The Registry of Jurisdiction Codes solves this problem. If the ccTLD was reassigned, the old assignment remains in the log. If it was already assigned, the applicant should choose a different one
> 
> Req: <name> .lex is no longer valid if .lex is assigned
> Ans: use pseudo-domain "lex.arpa" (see answer to Dale’s remark n.4)
> 
> 
> 27. Full utility of this URN form
> Req: it seems that a browser plugin in needed
> To Deepen: The DDDS for URNs is fully described in various RFCs (3401-05). However, to the best of our knowledge, the "urn:" schema is not recognized by browsers, the most widely used tool for accessing information. Therefore, to activate a resolution process from a native reference as "... href = ‘urn: ...’ ", there are 2 possibilities:
> 
> 1. Develop a browser plug-in, that can recognize the urn schema. Such a plug-in could route the urn to a service, active on one (or more) servers, which is able to walk through the DNS chain and return the address of the resolver (typically via http);
> 
> 2. Transform a native urn reference to an http one (like: ... href = "httReq: // <service>?urn: ..."), through a pre-processor or style sheet, where the urn is a parameter of the call to the service previously described.
> 
> 
> Req: Move the solution in a separate document
> 
> To Deepen: Postpone the decision to the end of this review
> 
> 
> 28. Sez. 4.4: Use of Punycode
> 
> Req: The syntax has to be revised for the non-ASCII. It includes %-encoding but not punycode
> 
> Ans: Use UTF-8 %encoded within a URN; convert punycode in the DNS (see Dale point 2.)
> 
> 
> 
> 29. Sez. 6.7: Ambiguity between components and features
> 
> Req:	syntax ambiguity: with one element it is not clear if it is a [component] or a [feature]
> 
> Ans: get rid of the syntax ambiguity in the manifestazione (see Dale's point 15.)
> 
> 
> 30. Annex D: Http-based LEX identifier
> 
> Req: it seems unuseful, there are no references: remove or incorporate in another doc
> 
> To Deepen: postpone the decision at the end of this revision phase
> 
> 
> 
> 31.	Name or query? (Answer to Alexey)
> Req: it is difficult to separate naming rules from the resolution aspects: split the document in two?
> Req: there are several elements which are difficult to identify by a user and drive you to the construction of different URNs
> To Deepen: a document has always a complete and unequivocal URN; a reference can have an incomplete URN, nevertheless useful for a retrieval service. (See also the mail sent to Dale on 9/20)
> 
> 32. Name or query? (Answer to Enrico’s email)
> Req: The user attempts to build a URN by some metadata he knows. The input URN is not actually a URN to the document under analysis - it is a query for some documents
> To Deepen: In the RFC we can better clarify the case of 1) a complete and unequivocal URN as document identifier; 2) an incomplete URN but still useful for retrieval and that can  be used in references (See also the e-mail sent to Dale on 9/20)
> 
> 
> 
> 
> ---------------------------------------------------------
> Enrico Francesconi
> ITTIG - CNR
> Institute of Legal Information Theory and Techniques
> Italian National Research Council
> 
> Via de' Barucci 20
> 50127 Florence
> Italy
> 
> Tel: [phone]
> Fax: [phone]
> email: [e-mail] <mailto:[e-mail]>
> ---------------------------------------------------------
> 
>> On 21 set 2017, at 09:57, Hakala, Juha E <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Hello, 
>> 
>> I have a few comments. 
>> 
>> Mandate
>> 
>> Based on the I-D, it is not clear to me what mandate ITTIG-CNR has. URN:LEX would complement existing systems; for instance in Finland laws are identified with cool URIs. For instance, English translation of Child welfare act can be found from http://finlex.fi/en/laki/kaannokset/2007/en20070417.pdf <http://finlex.fi/en/laki/kaannokset/2007/en20070417.pdf>. In the short term there might not be much interest to implement urn:lex in the Finlex system.
>> 
>> However, I do believe that establishing a urn namespace to sources of law can be useful in the long term. 
>> 
>> Administration 
>> 
>> ITTIG-CNR will be responsible of maintaining the uniqueness of the <jurisdiction> element. In the level of country codes this will be easy. But there may be a large number of sub-divisions within each country, and also organization-based sub-divisions. If urn:lex becomes popular, it may be a substantial task to maintain <jurisdiction> and to support organizations in making their urn:lex identifiers actionable. 
>> 
>> Has ITTIG-CNR estimated the amount of work required in the short term / long term?   
>> 
>> Semantics and syntax 
>> 
>> The template does not provide sufficient information about the semantics and syntax of NSS, but luckily draft-spinosa-urn-lex-11 is very detailed in that respect. 
>> 
>> Most URN namespaces (and traditional identifiers) have relatively simple semantics. Identifiers may be totally "dumb" (it is impossible to see from the NSS what the URN identifies) and even if the identifier has some semantic like ISBN, things are kept simple (for those in the know, ISBN reveals the country and the publisher). Other persistent identifier system are even more extreme when it comes to semantics: identifiers in ARK, Handle and DOI are usually dumb, and recommend strongly that all semantics should be avoided. 
>> 
>> URNs from proposed urn:lex namespace may contain a lot of information about the identified resource. For instance, I-D contains an example URN like this: 
>> 
>> urn:lex:eu:tibunal.justicia:sentencia:2009-06-11;33-08@original:es$text-html:juradmin.eu;jurifast:todo:anonimo 
>> 
>> It may be difficult, both for humans and applications, to make sense of this. 
>> 
>> ITTIG might consider making NSS simpler, and including at least some of the information which is now embedded in NSS (such as date and file format) into metadata records that would accompany URN:LEX identifiers. Having a lot of semantics in the NSS may overload the resolvers with tasks which should be done by passing a request to an appropriate target system. It is also more challenging to develop assignment rules for a very semantic identifier system, and to be able to use such system correctly.    
>> 
>> As regards syntax, I am concerned about un-encoded use of @ to indicate an expression of a work: 
>> 
>> local-name = work ["@" expression] ["$" manifestation]
>> 
>> Resolution
>> 
>> ITTIG-CNR intends to maintain a centralized resolution service for urn:lex. That is necessary for organization-based sub-domains. But for country-code based subdomains such as urn:lex:fi, resolvers may be established in the national level (just as in country code based sub-domains of urn:nbn). Generally, if it is not necessary to establish a global resolver service for a namespace, it is better to decentralize, since otherwise there will be a single point of failure. 
>> 
>> It would of course be possible to harvest URN - URL mapping tables from national lex resolvers into the central resolver maintained by ITTIG-CNR. 
>> 
>> All the best,   
>> 
>> Juha
>> 
>>> -----Original Message-----
>>> From: urn [mailto:[e-mail] <mailto:[e-mail]>] On Behalf Of Alexey Melnikov
>>> Sent: 20. syyskuuta 2017 15:13
>>> To: [e-mail] <mailto:[e-mail]>
>>> Cc: [e-mail] <mailto:[e-mail]>
>>> Subject: [urn] Request for new URN namespace review: LEX
>>> 
>>> Hi,
>>> as responsible AD for draft-spinosa-urn-lex, I would like to request Expert
>>> Review for a new URN Namespace.
>>> The registration template was extracted from draft-spinosa-urn-lex-11:
>>> 
>>>      Namespace Identifier:
>>> 
>>>         "lex" requested according to [RFC8141].
>>> 
>>>      Version:
>>> 
>>>         1.0
>>> 
>>>      Date:
>>> 
>>>         2017-05-25
>>> 
>>>      Registrant:
>>> 
>>>         Institute of Legal Information Theory and Techniques (ITTIG)
>>>         Italian National Research Council (CNR)
>>>         Via de' Barucci, 20
>>>         50127 Florence
>>>         Italy
>>>         e-mail: [e-mail] <mailto:[e-mail]>
>>>         phone: [phone]
>>> 
>>>         contact: Enrico Francesconi
>>>         e-mail: [e-mail] <mailto:[e-mail]>
>>> 
>>>      Purpose:
>>> 
>>>         The purpose of the "lex" namespace is to assign an unequivocal
>>>         identifier, in standard format, to documents that are sources
>>>         of law.
>>> 
>>>         In the last few years a number of institutional initiatives
>>>         have arisen in the field of legal document management. They
>>>         were aimed at introducing standards for sources of law
>>>         description and identification using XML and URI techniques,
>>>         respectively (for more details see Section 1.3) LEX identifier
>>>         is conceived to be general enough, so to provide guidance at
>>>         the core of the standard and sufficient flexibility to cover a
>>>         wide variety of needs for identifying all the legal documents
>>>         of different nature, namely legislative, case-law and
>>>         administrative acts. Moreover, it can be effectively used
>>>         within a federative environment where different publishers
>>>         (public and private) can provide their own items of an act
>>>         (that is there is more than one manifestation of the same act).
>>> 
>>>         The LEX identifier is conceived to be: globally unique,
>>>         transparent, bidirectional, persistent, location-independent,
>>>         and language-neutral. It is organized into parts. The first
>>>         part uses a predetermined standard to specify the country (or
>>>         more generally the jurisdiction) of origin for the legal
>>>         document being identified; the remainder is intended for local
>>>         use in identifying documents issued in that country or
>>>         jurisdiction. This second part depends only on sources of law
>>>         identification system operating in that nation. For more
>>>         details on the nature of the LEX characteristics and the
>>>         general internal organization, see Section 1.4.
>>> 
>>>         The LEX name is linked to the document through specific meta-
>>>         information, internally (with a tag) or externally (with a
>>>         attribute) (for details on this see Section 1.5)
>>> 
>>>         LEX names will be used on a large scale in references either in
>>>         (X)HTML document or, more generally, in XML documents format
>>>         compliant with the relative DTD/XMLSchema (see Section 1.6 for
>>>         more information).
>>> 
>>>      Syntax:
>>> 
>>>         The identifier has a hierarchical structure as follows:
>>> 
>>>                             "urn:lex:" NSS
>>> 
>>>         where <NSS> is the Namespace Specific String composed as
>>>         follows:
>>> 
>>>                   NSS = jurisdiction ":" local-name
>>> 
>>>         where:
>>> 
>>>         <jurisdiction> is the part providing the identification of the
>>>         jurisdiction, generally corresponding to the country, where the
>>>         source of law is issued. It is also possible to represent
>>>         international organizations (either states or public
>>>         administrations or private entities);
>>> 
>>>         <local-name> is the uniform name of the source of law in the
>>>         country or jurisdiction where it is issued; its internal
>>>         structure is common to the already adopted schemas. It is able
>>>         to represent all the aspects of an intellectual production, as
>>>         it is a legal document, from its initial idea, through its
>>>         evolution during the time, to its realisation by different
>>>         means (paper, digital, etc.).
>>> 
>>>         LEX specifications gives information on the internal structure
>>>         of both <jurisdiction> and <local-name>, including
>>>         specifications about case sensitivity, the use of national
>>>         characters and diacritics, as well as spaces, connectives,
>>>         punctuation marks, abbreviations, acronyms, date formats and
>>>         ordinal numbers. For more details on the internal structure and
>>>         syntax of the LEX identifier, see Section 3, 4 and 5.
>>> 
>>>         Recently the r- and q- components have been introduced by
>>>         [RFC8141]. They provide new and interesting perspectives when
>>>         using URNs in a complex sector as sources of law, characterized
>>>         by different versions, languages, publishers, and so on. In
>>>         particular, by using the r-component at the resolver level, and
>>>         therefore at the whole NSS level, you can select from the same
>>>         work only expressions written in a given language, or
>>>         manifestations published by a particular institutional site,
>>>         etc. Using the q-component at the act metadata level, you can
>>>         select versions that are valid at a particular date, or
>>>         modified by a specific act, etc.
>>> 
>>>      Assignment:
>>> 
>>>         The Jurisdictional Registrar (or those it delegates) of each
>>>         adhering country or organization is responsible of the
>>>         definition or acceptance of the uniform name's primary elements
>>>         (issuing authority and type of legal measure).
>>> 
>>>         Any country or jurisdiction, aiming to adopt this schema,
>>>         identifies a Jurisdictional Registrar, an organization which
>>>         shares and defines the structure of the optional part of the
>>>         name, according to the organization of the state or
>>>         institution. The process of assigning the <local-name> will be
>>>         managed by each specific country or jurisdiction under the
>>>         related <jurisdiction> element (details on this can be found in
>>>         Section 7.2).
>>> 
>>>         Identifiers in the "lex" namespace are defined through a
>>>         <jurisdiction> element assigned to the sources of law of a
>>>         specific country or organization, and a <local-name> assigned
>>>         by the issuing authority. The goal of the LEX schema is to
>>>         maintain uniqueness and persistence of all resources identified
>>>         by the assigned URNs. The elements values for the LEX
>>>         identifier within a jurisdiction are defined by the
>>>         Jurisdictional Registrar, this ensures that the constructed
>>>         URNs are unique (see Section 7.3 for details on uniqueness).
>>> 
>>>         The persistence of identifiers depends on the durability of the
>>>         institutions that assign and administer them (see Section 7.3
>>>         for details on persitence)
>>> 
>>>      Security and Privacy:
>>> 
>>>         This document introduces no additional security considerations
>>>         beyond those associated with the use and resolution of URNs in
>>>         general.
>>> 
>>>      Interoperability:
>>> 
>>>         As open standard naming convention to identify sources of law
>>>         at international level, LEX is meant to guarantee
>>>         interoperability among legal information systems across
>>>         national boundaries.
>>> 
>>>         The characteristics of the LEX naming convention facilitate
>>>         legal document management as well as provide a mechanism of
>>>         stable cross-collections and cross-country references, thus
>>>         allowing the distribution of the legal information towards a
>>>         federated architecture.
>>> 
>>>      Resolution:
>>> 
>>>         The resolution service associates a LEX identifier with a
>>>         specific document address on the net. The related system will
>>>         have a distributed architecture based on two fundamental
>>>         components: a chain of information in DNS (Domain Name System)
>>>         and a series of resolution services from URNs to URLs, each
>>>         competent within a specific domain of the namespace (see
>>>         Section 8.1 for more details).
>>> 
>>>         To cope with possible incomplete or inaccurate uniform names,
>>>         the implementation of a catalogue, based on a relational-
>>>         database, able to associate a URN to related URLs, is
>>>         suggested, as it will lead to a higher flexibility in the
>>>         resolution process. A resolver can provide names normalization,
>>>         completion of inaccurate or incomplete names, and finally their
>>>         resolution in network locations (see Section 8.2 and 8.3 for
>>>         characteristics and behaviour of a catalogue for resolution).
>>> 
>>>      Documentation:
>>> 
>>>         None
>>> 
>>>      Additional Information:
>>> 
>>>         See [FRAN] and [SPIN].
>>> 
>>>      Revision Information:
>>> 
>>>         None
>>> 
>>> _______________________________________________
>>> urn mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/urn
>