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

["Hakala, Juha E" <[e-mail]>]

Dear Enrico,

thank you for the answers; I have some further comments below.

From: Enrico Francesconi [mailto:[e-mail]] On Behalf Of Enrico Francesconi
Sent: 13. lokakuuta 2017 0:27
To: [e-mail]
Cc: Alexey Melnikov <[e-mail]>; [e-mail]; Pierluigi Spinosa <[e-mail]>; Hakala, Juha E <[e-mail]>
Subject: Re: [urn] Request for new URN namespace review: LEX

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<http://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<http://registro.it>”, the CNR (Italian National Research Council) service which provides registration of the domain names .it and .eu
Juha: a name like lex.registro.it would be better than lex.ittig.cnr.it, which has a lot of semantics in it. Here in Finland, the national library runs a URN resolver at the URI http://urn.fi, which is as neutral as possible.
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
Juha: OK. Since ITTI-CNR has no specific mandate, it is easy to see a situation where the coordinator responsibility is passed to another organization in Italy or even elsewhere. Therefore it is important to have a neutral domain like lex.registro.it or something similar.
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)’
Juha: efficient de-centralization often requires at least some level of central co-ordination. In this case, I think it would be useful to maintain a central registry of Jurisdictional Registrars. This would make it easy for any organization which wishes to use urn:lex to find out if there already is a registrar for their country or jurisdiction. The registry would also minimize the risk of having multiple organizations in one country accidentally adopting the registrar role.
I wonder if it would be useful to mention in chapter 10 (Community considerations) of draft-spinoza-urn-lex something about how potential registrars may find information about this system. A completely new identifier system usually needs some promotion in order to become popular. Similarly, chapter 7.2 might mention promotion of URNs and URN:LEX as one of the registrar tasks.

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)
Juha: yes, I do understand that some semantics is required for resolution. URN:NBN, which I have registered, uses (mandatory) country code and additional information to locate the right resolver.
But in lex, semantics goes much beyond what is required for finding a resolver. And some of the assumptions about semantics may not be valid in all jurisdictions. For instance, you say

Each version is characterized by the period of time during which that
   text is to be considered as the valid text (in force or effective).
Finland, for instance, cannot provide this kind of date/time information about validity of legal documents.
All Finnish laws are available online for free from a system called Finlex. The URI of the current Finnish copyright act in Finnish is
http://finlex.fi/fi/laki/ajantasa/1961/19610404
and in Swedish
http://finlex.fi/sv/laki/ajantasa/1961/19610404
Note that 19610404 is not a date, but act number 404 in 1961.
Lex work level urn could then be something like:
urn:lex:fi:oik:laki:1961;0404
where OIK refers to the Ministry of justice and LAKI to an act.
Since 1961, Copyright act has been amended many times, but URI has remained the same ever since the online system was established. A user who retrieves the text, can see the changes and when there were made. But the original version is no longer there.
Chapter 6 has a lot of examples, but they are all similar with respect to e.g. date. It would be good to have more diversity among examples, so that potential users do not misunderstand the requirements.
Syntax might be made simpler by using URN f-component to identify partitions. Then for instance the URN in this example:


to refer to the paragraph 3 of the article 15 of the French

   Act of 15 may 2004, n. 106, the reference is written

   "urn:lex:fr:etat:loi:2004-05-15;106~art15;par3").
might become
 urn:lex:fr:etat:loi:2004-05-15;106#art15par3
if the text encoding of the identified document allows that. This would also simplify things from retrieval point of view; it is likely that even with the original URN the entire text of the legal document will be retrieved, and then it is up to the browser to take the user to the correct place. With URI fragment that is technically simple; with syntax like ~art15;par3 it may be necessary to build the required functionality to the user interface.

Req: As regards syntax, concerns about un-encoded use of @ to indicate an expression of a work
To Deepen: not clear the motivations
Juha: the motivation was just to say that it is necessary to percent encode special characters which cannot be expressed in HTTP URIs in unencoded form, such as @.
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

Juha: it should be possible to make resolvers in urn:lex aware of each other, if there is a central registry of resolvers. This would make it possible, at some point in the future, to harvest the mapping tables from all urn:lex resolvers. But I do understand that there is currently no plan to do such a thing. However, within jurisdictions such co-operation may be necessary even in short term.

All the best,

Juha

---------------------------------------------------------
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 06 ott 2017, at 21:00, Enrico Francesconi <[e-mail]<mailto:[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. 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]] 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