



Independent Submission                                        P. Spinosa
Request for Comments: 9676                                              
Category: Informational                                   E. Francesconi
ISSN: 2070-1721                 National Research Council of Italy (CNR)
                                                                 C. Lupo
                                                                May 2025


    LEX: A Uniform Resource Name (URN) Namespace for Sources of Law

Abstract

   This document describes LEX, a Uniform Resource Name (URN) namespace
   identifier that identifies, names, assigns, and manages persistent
   resources in the legal domain.  This specification allows adoption of
   a common convention by multiple jurisdictions to facilitate ease of
   reference and access to resources in the legal domain.

   This specification is an Independent Submission to the RFC Series.
   It is not a standard and does not have the consensus of the IETF.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This is a contribution to the RFC Series, independently of any other
   RFC stream.  The RFC Editor has chosen to publish this document at
   its discretion and makes no statement about its value for
   implementation or deployment.  Documents approved for publication by
   the RFC Editor are not candidates for any level of Internet Standard;
   see Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc9676.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Table of Contents

   1.  Introduction
     1.1.  The Purpose of Namespace LEX
     1.2.  Background
     1.3.  General Characteristics of the System
     1.4.  Linking a LEX Name to a Document
     1.5.  Use of LEX Names in References
     1.6.  Definitions
     1.7.  Terminology
     1.8.  Syntax Used in This Document
     1.9.  Namespace Registration
   2.  Registration of LEX
     2.1.  Identifier Structure
     2.2.  Jurisdiction-Code Registry
     2.3.  Conformance with URN Syntax
     2.4.  Validation Mechanism
     2.5.  Scope
   3.  General Syntax and Features of the LEX Identifier
     3.1.  Allowed and Not Allowed Characters
     3.2.  Reserved Characters
     3.3.  Case Sensitivity
     3.4.  Unicode Characters Outside the ASCII Range
     3.5.  Abbreviations
     3.6.  Date Format
   4.  Specific Syntax and Features of the LEX Identifier
     4.1.  Spaces, Connectives, and Punctuation Marks
     4.2.  Acronyms
     4.3.  Ordinal Numbers
   5.  Creation of the Source of Law LEX Identifier: Baseline
           Structure
     5.1.  Basic Principles
     5.2.  Model of Sources of Law Representation
     5.3.  Structure of the Local-Name
     5.4.  Structure of the Document Identifier at "Work" Level
     5.5.  Aliases
     5.6.  Structure of the Document Identifier at "Expression" Level
     5.7.  Structure of the Document Identifier at "Manifestation"
           Level
     5.8.  Sources of Law References
   6.  Specific Syntax of the Identifier at "Work" Level
     6.1.  The Authority Element
       6.1.1.  Indication of the Authority
       6.1.2.  Multiple Issuers
       6.1.3.  Indication of the Issuer
       6.1.4.  Indication of the Body
       6.1.5.  Indication of the Function
       6.1.6.  Conventions for the Authority
     6.2.  The Measure Element
       6.2.1.  Criteria for the Indication of the Type of Measure
       6.2.2.  Further Specification to the Type of Measure
       6.2.3.  Aliases for Sources of Law with Different Normative
               References
       6.2.4.  Relations Between Measure and Authority in the Aliases
     6.3.  The Details Element
       6.3.1.  Indication of the Details
       6.3.2.  Multiple Dates
       6.3.3.  Unnumbered Measures
       6.3.4.  Multiple Numbers
     6.4.  The Annex Element
       6.4.1.  Formal Annexes
       6.4.2.  Annexes of Annexes
   7.  Specific Syntax of the Version Element of the "Expression"
     7.1.  The Version Element
       7.1.1.  Different Versions of a Legislative Document
       7.1.2.  Identification of the Version
   8.  Summary of the Syntax of the Uniform Names of the LEX Namespace
   9.  Procedure of Uniform Names Assignment
     9.1.  Specifying the Jurisdiction Element of the LEX Identifier
     9.2.  Jurisdictional Registrar for Names Assignment
     9.3.  Identifier Uniqueness
     9.4.  Identifier Persistence Considerations
   10. Recommendations for the Resolution Process
     10.1.  General Architecture of the System
     10.2.  Catalogues for Resolution
     10.3.  Suggested Resolver Behavior
   11. Security Considerations
   12. IANA Considerations
   13. References
     13.1.  Normative References
     13.2.  Informative References
   Acknowledgements
   Authors' Addresses

1.  Introduction

1.1.  The Purpose of Namespace LEX

   The purpose of the LEX namespace is to assign a unique identifier in
   a well-defined format to documents that are sources of law.  In this
   context, "sources of law" include any legal document within the
   domain of legislation, case law, administrative acts, or regulations.
   Potential sources of law (acts under the process of law formation,
   such as bills) are included as well.  "Legal doctrine", that is, the
   body of knowledge and theoretical speculation typical of legal
   scholars (e.g., commentary on judgment, jurisprudence review,
   commentary on legislation, encyclopedic entries, monographs, articles
   in magazines, manuals, etc.) is explicitly not covered.

   The identifier is conceived so that its construction depends only on
   the content of the document itself and not its online availability,
   physical location, and access mode.  The identifier itself is
   assigned by the jurisdiction of the identified document.  A document
   that is not available online may, nevertheless, have a LEX URN
   identifier.

   The LEX URN may be used as a way to represent references (and more
   generally, any type of relation) among various sources of law.  In an
   online environment with resources distributed among different web
   publishers, LEX URNs allow a simplified global interconnection of
   legal documents by means of automated resolution.  LEX URNs consist
   of persistent and location-independent identifiers and are
   particularly useful when they can be mapped into or associated with
   locators such as HTTP URLs.  Moreover, LEX URN details can be used as
   a reference to create persistent and location-independent identifiers
   that are HTTP-based [RFC3986].

1.2.  Background

   This specification of a unique identifier for legal documents follows
   a number of initiatives in the field of legal document management.

   Since 2001, the Italian Government promoted the NormeInRete project
   through the National Center for Information Technology in the Public
   Administration, the Ministry of Justice, and the National Research
   Council of Italy (CNR).  The NormeInRete project was aimed at
   introducing standards for describing and identifying sources of law
   using XML and URN techniques.

   Other national initiatives in Europe introduced standards for the
   description of legal sources [FRAN].  Collaborations between
   government, national research institutes, and universities have
   defined national XML standards for legal document management, as well
   as schemes for legal document identification.  Outside of Europe,
   similar initiatives have addressed similar problems [FRAN].  Several
   of these identifiers are based on a URN schema.

   In today's information society, the processes of political, social,
   and economic integration of European Union (EU) Member States, as
   well as the increasing integration of the worldwide legal and
   economic processes, are causing a growing interest in the exchange of
   legal information at national and transnational levels.  The growing
   desire for improved quality and accessibility of legal information
   amplifies the need for interoperability among legal information
   systems across national boundaries.  A common, well-defined schema
   used to identify sources of law at an international level is an
   essential prerequisite for interoperability.

   Interest groups within several countries have already expressed their
   intention to adopt a shared solution based on a URN technique.  In
   several conferences (such as [LVI]), representatives of the
   Publications Office of the European Union (OP) have expressed the
   need for a unique identifier for sources of law, based on open
   standards and able to provide advanced modalities of document
   hyperlinking, with the aim of promoting interoperability among
   national and European institution information systems.  Similar
   concerns have been raised by international groups concerned with free
   access to legal information, and the Permanent Bureau of the Hague
   Conference on Private International Law [HCPIL] encourages State
   Parties to "adopt neutral methods of citation of their legal
   materials, including methods that are medium-neutral, provider-
   neutral and internationally consistent".  In a similar direction, the
   CEN Metalex initiative is moving, at the European level, towards the
   definition of a standard interchange format for sources of law,
   including recommendations for defining naming conventions for them.

   Additionally, the need for unique identifiers for sources of law is
   of particular interest in the domain of case law.  This need is
   acutely felt within both common law systems (where cases are the main
   law sources) and civil law systems, because unique identifiers can
   provide integrated access to cases and legislation, as well as the
   ability to track the relationships between them.  This domain is
   characterized by a high degree of fragmentation in case law
   information systems, which usually lack interoperability.

   In the European Union, the community institutions have stressed the
   need for citizens, businesses, lawyers, prosecutors, and judges to
   become more aware of (directly applicable) EU laws and also the
   various national legal systems.  The growing importance of national
   judiciaries for the application of community law was stressed in the
   resolution of the European Parliament of 9 July 2008 on the role of
   the national judge in the European judicial system.  Similarly, the
   Council of the European Union has underlined the importance of cross-
   border access to national case law, as well as the need for its
   standardization, with a vision of a decentralized architecture with
   integrated access.  The Working Party on Legal Data Processing
   (e-Law) of the Council of the European Union formed a task group to
   study the possibilities for improving cross-border access to national
   case law.  Taking notice of the report of the Working Party's task
   group, in 2009, the Council of the European Union decided to
   elaborate on a uniform European system for the identification of case
   law (i.e., the European Case-Law Identifier (ECLI)) and a uniform set
   of metadata based on the Dublin Core.

   The Council of the European Union invited the Member States to
   introduce the European Legislation Identifier (ELI) in the legal
   information systems, which is an HTTP-based, Semantic Web-oriented
   identification system for legislation of the European Union and
   Member States.

   The LEX identifier (also referred to in this text as "LEX name") is
   conceived to be general enough to provide guidance at the core of the
   standard and offer sufficient flexibility to cover a wide variety of
   needs for identifying legal documents of different types, 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, in
   [FRBR] sense (see Section 5.2), of a legal document (that is, there
   is more than one manifestation (see Section 5.2) of the same legal
   document).

   Specifications and syntax rules for the LEX identifier can also be
   used for HTTP-based naming conventions to cope with different
   requirements in legal information management, for example, the need
   to have an identifier that is compliant with the Linked Open Data
   principles.

   This document supplements the required name syntax with a naming
   convention that interprets all these recommendations into an original
   solution for sources of law identification.

1.3.  General Characteristics of the System

   The specifications in this document promote interoperability among
   legal information systems by defining a namespace convention and
   structure that will create and manage identifiers for legal
   documents.  The identifiers are intended to have the following
   qualities:

   *  globally unique

   *  transparent

   *  reversible

   *  persistent

   *  location-independent

   *  language-neutral

   These qualities facilitate management of legal documents and a
   mechanism for stable cross-collection and cross-country references.

   Transparency means that, for a given act and its relevant metadata
   (issuing authority, type of measure, etc.), it is possible to create
   a related URN that is able to uniquely identify the act in a way that
   is reversible (from an act to its URN and from a URN to the act).

   Language neutrality, in particular, is an important feature that
   promotes adoption of the standard by organizations that must adhere
   to official language requirements.  This specification provides
   guidance to both public and private groups that create, promulgate,
   and publish legal documents.  Registrants wish to minimize the
   potential for creating conflicting proprietary schemes, while
   preserving sufficient flexibility to allow for diverse document types
   and to respect the need for local control of collections by an
   equally diverse assortment of administrative entities.

   The challenge is to provide the right amount guidance at the core of
   the specification while providing sufficient flexibility to cover a
   wide variety of needs.  LEX does this by splitting the identifier
   into parts.  The first part uses a preexisting standard specification
   ("country/jurisdiction name standard") to indicate the country (or
   more generally, the jurisdiction) of origin for the legal document
   being identified; the remainder ("local-name") is intended for local
   use in identifying documents issued in that country or jurisdiction.

   The second part depends only on the identification system for sources
   of law operating in that nation, and it is mainly composed by
   formalized information related to the enacting authority, the type of
   measure, the details, and possibly the annex.

   The identification system based on uniform names includes:

   *  A schema for assigning names capable of unambiguously representing
      any addressed source of law (namely legislation, case law, and
      administrative acts) issued by any authority (intergovernmental,
      supranational, national, regional, and local) at any time (past,
      present, and future).

   *  A resolution mechanism -- in a distributed environment -- that
      ties a uniform name to the online location of the corresponding
      resource(s).

   This document considers the first of these requirements.  It also
   contains a few references to the architecture of the resolution
   service and to the corresponding software.

1.4.  Linking a LEX Name to a Document

   The LEX name is linked to the document through metadata, which may be
   specified as follows:

   *  Within the document itself through a specific element within an
      XML schema or by a meta tag [W3C.HTML].

   *  Externally by means of a Resource Description Framework
      [W3C.RDF-SCHEMA] triple, a specific attribute in a database, etc.

   At least one of these references is necessary to enable automated
   construction, an update of catalogues (distributed and centralized),
   and the implementation of resolvers that associate the uniform name
   of a document with its physical location.  LEX assumes no particular
   relationship between the originator of the document, its publisher,
   the implementer of catalogues, or resolution services.

1.5.  Use of LEX Names in References

   LEX names can be used in references as an HREF attribute value of the
   hypertext link to the referred document.  This link can be created in
   two ways:

   *  Manually inserting the link with the uniform name in the referring
      document.  This is a burdensome procedure, especially for
      documents that are already online.

   *  Automatically constructing (either permanently or temporarily) the
      link with the uniform name from references in the text using a
      parser.  This procedure offers more time savings, even if it is
      subject to a certain percentage of errors, since references are
      not always accurate or complete.  This solution could nevertheless
      be acceptable for documents that are already published.

   No matter which method is adopted, new documents produced in a
   certain format (for example, XML, XHTML, etc.) should express
   references through the uniform name of the document referred to.

1.6.  Definitions

   The following terms are used in this document:

   Source of Law:  A general concept that refers to legislation, case
      law, regulations, and administrative acts.  In its broadest sense,
      the source of law is anything that can be conceived as the
      originator of 'erga omnes' legal rules.  In this document, "source
      of law" also refers to acts during their creation, such as bills,
      that might or might not become laws.

   Jurisdictional Registrar:  An organization in any jurisdiction that
      shares and defines the assignment of the main components of the
      resource identifier through which the identifier uniqueness is
      guaranteed.

1.7.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

1.8.  Syntax Used in This Document

   This document uses a syntax that is based on the Augmented Backus-
   Naur Form (ABNF) [RFC5234] meta-language, which is used in many RFCs.

1.9.  Namespace Registration

   The LEX namespace has been registered in the "Formal URN Namespaces"
   registry.  See Section 12.

2.  Registration of LEX

2.1.  Identifier Structure

   The identifier has the following hierarchical structure:

      "urn:lex:" NSS

   where NSS is the Namespace Specific String composed as follows:

      NSS = jurisdiction ":" local-name

   where:

   jurisdiction:  Identifies the scope (state, regional, municipal,
      supranational, or organizational) where a set of sources of law
      have validity.  It is also possible to represent international
      organizations (either states, public administrations, or private
      entities).

   local-name:  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 represents all aspects of an
      intellectual production, from its initial idea, through its
      evolution during the time, to its realization by different means
      (paper, digital, etc.).

   The jurisdiction element is composed of two specific fields:

      jurisdiction = jurisdiction-code *(";" jurisdiction-unit)

   where:

   jurisdiction-code:  Usually the identification code of the country
      where the source of law is issued.  To facilitate the transparency
      of the name, the jurisdiction-code usually follows the rules of
      identification of other Internet applications, based on domain
      name (for details and special cases, see Section 2.2).

      Due to the differences in representation in the various languages
      of a country, the use of the standard [ISO.3166-1] is strongly
      RECOMMENDED for easier identification of the country.  Therefore,
      a LEX URN ID always begins with a sequence of ASCII characters:
      "urn:lex:ccTLD".  For all the other components that follow the
      jurisdiction-code, the Jurisdictional Registrar decides the mode
      of representation (ASCII or UTF-8 percent-encoding; see
      Section 3.4).

      Where applicable, the domain name of the country or multinational
      or international organization is used.  If such information is not
      available for a particular institution, a specific code will be
      defined (see Section 2.2).  Examples reported in this document are
      hypothetical and assume that the corresponding domain name is used
      for the jurisdiction-code.

   jurisdiction-unit:  The possible administrative hierarchical sub-
      structures defined by each country or organization within their
      specific legal system.  This additional information can be used
      when two or more levels of legislative or judicial production
      exist (e.g., federal, state, and municipality level) and the same
      bodies may be present in each jurisdiction.  Therefore, the
      jurisdiction-unit differs for acts of the same type issued by
      similar authorities but pertain to different jurisdictions related
      to different geographical areas.  An example can be the following:

         "br:governo:decreto" (decree of federal government),
         "br;sao.paulo:governo:decreto" (decree of São (SU+00E3o) Paulo
         state)
         "br;sao.paulo;campinas:governo:decreto" (decree of Campinas
         municipality).

   The following are fictitious examples of sources of law identifiers:

   urn:lex:it:stato:legge:2003-09-21;456
       (Italian act)
   urn:lex:fr:etat:loi:2004-12-06;321
       (French act)
   urn:lex:es:estado:ley:2002-07-12;123
       (Spanish act)
   urn:lex:ch;glarus:regiere:erlass:2007-10-15;963
       (Glarus Swiss Canton decree)
   urn:lex:eu:commission:directive:2010-03-09;2010-19-EU
       (EU Commission Directive)
   urn:lex:us:supreme.court:decision:1978-04-28;77-5953
       (US SC decision: Riley vs Illinois)
   urn:lex:be:conseil.etat:decision:2008-07-09;185.273
       (Decision of the Belgian Council of State)

2.2.  Jurisdiction-Code Registry

   A new jurisdiction-code registry has been created.  Note that this is
   a CNR registry and *not* an IANA registry.

   Each entry contains the following elements:

   jurisdiction-code:  The identifier assigned to the jurisdiction
      (i.e., to the country or organization).

   jurisdiction:  The official name of the jurisdiction (i.e., the
      country or organization).

   registrant:  Essential information that identifies the organization
      that requested the registration of the code.  The registrant will
      be responsible for its DNS zone, the attribution of sub-zone
      delegations, and so on.  It is RECOMMENDED that each jurisdiction
      create a registry of all delegated levels so that the organization
      responsible for each sub-zone can easily be identified.

   reference:  A reference to the defining document (if any).

   The table, available at the address lex-urn.nic.it, is initially
   empty.  The registry is initially empty.  The following are possible
   example entries:

   "br"; "Brazil"; "Prodasen, Federal Senate, address, contact";
         \[reference\]
   "eu"; "European Union"; "DG Digit, European Commission, address,
         contact"; \[reference\]
   "un.org"; "United Nations"; "DPI, United Nations, address,
             contact"; \[reference\]

   CNR is responsible for the jurisdiction-code and the root lex-
   nameserver.nic.it registries of the resolution routing.

   A new Jurisdictional Registrar will contact CNR or the designated
   expert(s) according to the established rules of governance (published
   on the CNR website dedicated to LEX governance).  The application
   will be evaluated according to the Jurisdictional Registrar
   authoritativeness and the offered guarantees.  The designated
   expert(s) will evaluate such applications with a similar approach as
   evaluations of the DNS.  Typically, such applications should come
   from public administrations, as authorities enacting sources of law.

   The adopted registration policy is similar to that of the "Expert
   Review" policy specified in [RFC8126].  The designated expert(s) will
   assign jurisdiction-codes based on the following principles:

   *  If a request comes from a jurisdiction that corresponds to a
      country and the jurisdiction-code is the same as a top-level
      Country Code Top-Level Domain (ccTLD), then the top-level ccTLD
      should be used as the jurisdiction-code.

   *  If a request comes from a jurisdiction that corresponds to a
      multi-national organization (e.g., European Union) or
      international organization (e.g., United Nations and World Trade
      Organization), the Top-Level Domain Name (e.g., "eu") or the
      Domain Name (e.g., "un.org" and "wto.org") of the organization
      should be used as the jurisdiction-code.

   *  If a multi-national or international organization does not have a
      registered domain, the designated expert(s) should assign
      something like "name.lex.arpa", where the name will be the acronym
      of the organization name in the language chosen by the
      organization itself.  For example, the jurisdiction-code of the
      European Economic Community could be "eec.lex.arpa".  The alias
      mechanism allows for acronyms in different languages.

   Jurisdiction-codes MUST NOT be renamed, because that would violate
   the rule that URN assignments be persistent.

   Jurisdiction-codes MUST NOT ever be deleted.  They can only be marked
   as "obsolete", i.e., closed for new assignments within the
   jurisdiction.  Requests to obsolete a jurisdiction-code are also
   processed by the designated expert(s).

   Designated expert(s) can unilaterally initiate allocation or
   obsolescence of a jurisdiction-code.

   Requests for new jurisdiction-code assignments must include the
   organization or country requesting it and contact information (email)
   of who requested the assignment.

2.3.  Conformance with URN Syntax

   The LEX namespace identifier (NID) syntax conforms to [RFC8141].
   However, a series of characters are reserved for identifying elements
   or sub-elements, or for future extensions of the LEX naming
   convention (see Section 3.2).

2.4.  Validation Mechanism

   The Jurisdictional Registrar (or those it delegates) of each adhering
   country or organization is responsible for the definition or
   acceptance of the uniform name's primary elements (issuing authority
   and type of legal measure).

2.5.  Scope

   The scope is global.  In fact, each Body that enacts sources of law
   can identify them by this scheme.  Furthermore, other bodies (even
   non-enacting sources of law, such as newspapers, magazine publishers,
   etc.) that aim to reference legal documents can unequivocally
   identify them by this scheme.

3.  General Syntax and Features of the LEX Identifier

   This section lists the general features applicable to all
   jurisdictions.

3.1.  Allowed and Not Allowed Characters

   The characters are defined in accordance with [RFC8141].  For various
   reasons that are explained later, only a subset of characters is
   allowed in the LEX NSS.  All other characters are either eliminated
   or converted.

   For the full syntax of the uniform names in the LEX space, please see
   Section 8.

3.2.  Reserved Characters

   The following characters are reserved in the specific LEX namespace:

   "@"   Separator of the expression that contains information on
         version and language.

   "$"   Separator of the manifestation that contains information on
         format, editor, etc.

   ":"   Separator of the main elements of the name at any entity.

   ";"   Separator of the level.  It identifies the introduction of an
         element at a hierarchically lower level or the introduction of
         a specification.

   "+"   Separator of the repetitions of an entire main element (e.g.,
         multiple authorities).

   "|"   Separator between different formats of the same element (e.g.,
         date).

   ","   Separator of the repetitions of individual components in the
         main elements, each bearing the same level of specificity
         (e.g., multiple numbers).

   "~"   Separator of the partition identifier in references (e.g.,
         paragraph of an article).

   "*"   Reserved for future expansions.

   "!"   Reserved for future expansions.

   To keep backward compatibility with existing applications in some
   jurisdictions, the LEX NID syntax does not include the use of the
   character "/" in this version.  This character is always converted
   into "-", except in the formal annexes (see Section 6.4.1).

3.3.  Case Sensitivity

   For all the languages where different cases (uppercase or lowercase)
   or different spellings of the same word are possible, names belonging
   to LEX namespace are case-insensitive.  For the Latin alphabet, it is
   RECOMMENDED that names be created in lower case, but names that
   differ only in case or in the spelling of the same word MUST be
   considered equivalent (e.g., "Ministry" will be recorded as
   "ministry").

3.4.  Unicode Characters Outside the ASCII Range

   In order to exploit the DNS as a routing tool towards the proper
   resolution system, keep editing and communication more simple, and
   avoid character percent-encoding, it is RECOMMENDED that characters
   outside the ASCII range (e.g., national characters, diacritic signs,
   etc.) are turned into base ASCII characters (e.g., the Italian term
   "sanità" (sanitU+00E0)" replaced into "sanita", the French term
   "ministère" (ministU+00E8re) replaced into "ministere", in case by
   transliteration (e.g., "München" (MU+00FCnchen) replaced into
   "muenchen").

   This mapping consists of:

   *  Transcription from non-Latin alphabets

   *  Transliteration of some signs (e.g., diaeresis and eszett)

   *  Preservation of only the basic characters, eliminating the signs
      placed above (e.g., accents and tilde), below (e.g., cedilla and
      little tail), or on (e.g., oblique cut)

   The most suitable, well-known, and widespread mapping system for a
   given language MUST be chosen by the jurisdiction or by the
   jurisdiction-unit (in agreement with the jurisdiction) in the case of
   different languages in various regions, also taking into account the
   choices made for the same language by other jurisdictions.  This
   mapping is simpler and more feasible for languages that use the Latin
   alphabet and gradually becomes more complex for other alphabets and
   for writing systems that use opposite orientation (from right to
   left) or are based on ideographic symbols.

   If this conversion is not acceptable by a specific jurisdiction or it
   is not available in a given language, Unicode MUST be used, and for
   accessing network protocols, any Unicode code points outside the
   ASCII range MUST be converted to UTF-8 percent-encoding according to
   [RFC3986] and [RFC3629] .

   In this case, it should be noted that the generated URN (as well as
   some of its parts) cannot be used directly for routing through the
   DNS.  Therefore, the jurisdiction must adopt one of the following
   strategies:

   *  Convert non-ASCII characters within the DNS into IDN encoding
      using Punycode translation [RFC5894] (e.g., "münchen"
      (mU+00FCnchen) in xn--mnchen-3ya) and develop a software interface
      that converts the URN before the navigation in the DNS.

   *  Create a routing service relying on a software, outside of the
      DNS, that addresses a proper resolution service.

   Note that the LEX URN ID could contain groups of characters (UTF-8
   percent-encoded) of some languages with different orientations.  In
   this case, the BiDi rules apply [RFC5893].

   The preferred order is summarized as follows:

   *  Conversion into basic ASCII is the RECOMMENDED solution (because
      conversions for network protocols and the DNS are not needed).

   *  Using Unicode and converting to UTF-8 percent-encoding [RFC3629]
      for accessing network protocols and to Punycode [RFC5894] only for
      navigation in DNS via software interface.

   *  Creation of a routing service relying on a software outside of DNS
      and addressing a proper resolution service.

   The first solution allows native DNS routing while the other two
   solutions require software development for the interface or the
   routing.  However, it is up to the specific jurisdiction to choose
   the preferred solution.

   The following are two examples (Latin and Cyrillic alphabets)
   relating to the different solutions adopted:

   *  A circular adopted by the Municipality of Munich (Rundschreiben
      der Stadt "München" (MU+00FCnchen)):

      - ASCII: urn:lex:de:stadt.munchen:rundschreiben:...;
      - Unicode: urn:lex:de:stadt.mU+00FCnchen:rundschreiben:...;
      - UTF-8: urn:lex:de:stadt.m%C3%BCnchen:rundschreiben:...;
      - PUNYCODE: urn:lex:de:stadt.xn--mnchen-3ya:rundschreiben:...

   *  A state law of the Russian Federation (Latin: gosudarstvo zakon;
      Cyrillic: "состояние закон"
      (U+0441U+043EU+0441U+0442U+043EU+044FU+043DU+0438U+0435
      U+0437U+0430U+043AU+043EU+043D)), assuming that the Russia
      jurisdiction-code is expressed in ASCII ("ru") (while the Cyrillic
      version would be "рф" (U+0440U+0444)):

      - ASCII: urn:lex:ru:gosudarstvo:zakon:...
      - Unicode: urn:lex:ru:U+0441U+043EU+0441U+0442U+043EU+044FU+043D
                 U+0438U+0435:U+0437U+0430U+043AU+043EU+043D:...
      - UTF-8: urn:lex:ru:%D1%81%D0%BE%D1%81%D1%82%D0%BE%D1
               %8F%D0%BD%D0%B8%D0%B5:%D0%B7%D0%B0%D0%BA
               %D0%BE%D0%BD:...
      - PUNYCODE: urn:lex:ru:xn--80aebe3cdmfdkg:xn--80ankme:...

3.5.  Abbreviations

   Abbreviations are often used in law for indicating institutions
   (e.g., Min.), structures (e.g., Dept.), or legal measures (e.g.,
   Reg.), but they are not used in a uniform way.  Therefore, their
   expansion is highly RECOMMENDED (e.g., "Min." is expanded as
   "ministry").

3.6.  Date Format

   [ISO.8601-1.2019] and [ISO.8601-2.2019] describe the international
   format for representing dates.  Dates MUST always be represented in
   this format (4 digits for the year, 2 digits for the month, and 2
   digits for the day):

       date-iso = year "-" month "-" day

   For example, "September 2, 99" will be written as "1999-09-02".

   This format ensures interoperability between different representation
   systems and there are several programs for mapping other formats to
   this one.  However, to make reading and understanding such other
   formats (e.g., Jewish calendar), the LEX URN scheme provides that the
   date can be added in the jurisdiction's own format.  The date in the
   previous example (1999-09-02) would be as follows:

   *  in Hebrew characters (21 Elul 5759):

      כ״א-בֶּאֱלוּל-תשנ״ט

      Note that the example above uses right-to-left (RTL) script, which
      in the context of this specification may be displayed differently
      by different document presentation environments.  The descriptive
      text may be more reliable to follow than the necessarily device-
      and application-specific rendering.

   *  in U+ notation:

      U+05D8U+05F4U+05E0U+05E9U+05EAU+002DU+05DCU+05D5U+05BCU+05DC
      U+05D0U+05B1U+05D1U+05B6U+05BCU+002DU+05D0U+05F4U+05DB

   *  in UTF-8 code:

      %d7%98%d7%b4%d7%a0%d7%a9%d7%aa-%d7%9c%d7%95%d6%bc%d7%9c%d7%
      90%d6%b1%d7%91%d6%b6%d6%bc-%d7%90%d7%b4%d7%9b

   Therefore, for all the dates in the LEX URN identifier (see Sections
   6.3 and 7.1.2), it is possible to indicate the date in the local
   format:

       date = date-iso ["|" date-loc]

   For example, 1999-09-02 will be written in
   ISO plus Hebrew format as: 1999-09-02|כ״א-בֶּאֱלוּל-תשנ״ט which is to
   be converted into UTF-8 for network protocols and for resolution (see
   Section 3.4).  The characters that are not allowed (e.g., "/") or
   reserved (e.g., ",") cannot exist inside the date-loc and therefore
   MUST be turned into ".".  To be aligned with ISO format, any blank
   between day, month, and year MUST be converted into "-".

   In the above Hebrew character examples, the sequence of characters
   is "כ" (HEBREW LETTER KAF, U+05DB), "״" (HEBREW PUNCTUATION
   GERSHAYIM, U+05F4), "א" (HEBREW LETTER ALEF, U+05D0), "-" (HYPHEN-
   MINUS, U+002D), "בֶּ" (HEBREW LETTER BET, HEBREW POINT SEGOL, HEBREW
   POINT DAGESH OR MAPIQ, U+05D1 U+05B6 U+05BC), "אֱ" (HEBREW LETTER
   ALEF, HEBREW POINT HATAF SEGOL, U+05D0 U+05B1), "ל" (HEBREW LETTER
   LAMED, U+05DC), "וּ" (HEBREW LETTER VAV, HEBREW POINT DAGESH OR
   MAPIQ, U+05D5 U+05BC), "ל" (HEBREW LETTER LAMED, U+05DC), "-"
   (HYPHEN-MINUS, U+002D), "ת" (HEBREW LETTER TAV, U+05EA), "ש" (HEBREW
   LETTER SHIN, U+05E9), "נ" (HEBREW LETTER NUN, U+05E0), "״" (HEBREW
   PUNCTUATION GERSHAYIM, U+05F4), and "ט" (HEBREW LETTER TET, U+05D8).

4.  Specific Syntax and Features of the LEX Identifier

   This section discusses features related to specific jurisdictions.
   The implementation of these features is RECOMMENDED.

4.1.  Spaces, Connectives, and Punctuation Marks

   When explicitly present, all language connectives (e.g., articles,
   prepositions, etc.), punctuation marks, and special characters (e.g.,
   apostrophes, dashes, etc.) are eliminated (no transformation occurs
   in cases of languages with declensions or agglutinating languages).
   The words that are left are connected to each other by a dot ("."),
   which substitutes for the space (e.g., "Ministry of Finances, Budget,
   and Economic Planning" becomes
   "ministry.finances.budget.economic.planning" and "Ministerstvo
   Finansov" becomes "ministerstvo.finansov").

4.2.  Acronyms

   The use of acronyms might be confusing and encourage ambiguity in
   uniform names (the same acronym may indicate two different
   institutions or structures); therefore, their expansion is highly
   RECOMMENDED (e.g., "FAO" is expanded as
   "food.agriculture.organization").

4.3.  Ordinal Numbers

   To standardise the representation, it is highly RECOMMENDED that any
   ordinal number included in a component of a document name (e.g., in
   the description of an institution Body) is indicated in Western
   Arabic numerals, regardless to the original expression, whether Roman
   numerals, an adjective, Arabic numerals with an apex, etc. (such as
   IV, third, 1° (1U+00B0), and 2^).  For example, "Department IV"
   becomes "department.4".

5.  Creation of the Source of Law LEX Identifier: Baseline Structure

5.1.  Basic Principles

   The uniform name must identify one and only one document (more
   precisely a "bibliographic resource" [ISBD]; see also Section 5.2)
   and is created in such a way that it is:

   *  self-explanatory,

   *  identifiable through simple and clear rules,

   *  compatible with the practice commonly used for references,

   *  able to be created from references in the text, automatically (by
      parser) or manually, and

   *  representative of both the formal and the substantive aspects of
      the document.

5.2.  Model of Sources of Law Representation

   According to the Functional Requirements for Bibliographic Records
   (FRBR) [FRBR] model developed by IFLA (International Federation of
   Library Associations and Institutions), four fundamental entities (or
   aspects) can be specified in a source of law, as in any intellectual
   production.

   The first two entities reflect its contents:

   work:  Identifies a distinct intellectual creation; in this document,
      it identifies a source of law in both its original form and its
      amended form over time.

   expression:  Identifies a specific intellectual realization of a
      work; in this document, it identifies every different (original or
      up-to-date) version of the source of law over time and/or language
      in which the text is expressed.

   The other two entities relate to its form:

   manifestation:  Identifies a physical embodiment of an expression of
      a work; in this document, it identifies embodiments in different
      media (printing, digital, etc.), encoding formats (XML, PDF,
      etc.), or other publishing characteristics.

   item:  Identifies a specific copy of a manifestation; in this
      document, it identifies individual physical copies as they are
      found in particular physical locations.

   In this document, the [FRBR] model has been interpreted for the
   specific characteristics of the legal domain.  In particular, apart
   from the language that does produce a specific expression, the
   discriminative criterion between expression and manifestation is
   based on the difference of the juridical effects that a variation can
   provide with respect to the involved actors (citizens, parties, and
   institutions).  In this scenario, the main characteristic of the
   expression of an act is represented by its validity over the time
   during which it provides the same juridical effects.  These effects
   may change as a result of amendments or annulments of other
   legislative or jurisprudential acts.  Therefore, notes, summaries,
   comments, anonymizations, and other editorial activities over the
   same text do not produce different expressions.  Instead, they
   produce different manifestations.

5.3.  Structure of the Local-Name

   The local-name within the LEX namespace MUST contain all the
   necessary pieces of information enabling the unequivocal
   identification of a legal document.  If the local-name violates this
   requirement, the related URN is not a valid one within the LEX
   namespace.

   In the legal domain, three components are always present at the
   "work" level: the enacting authority, the measure type, and the
   details.  A fourth component, the annex, is added if any.  It is
   often necessary to differentiate various expressions, that is:

   *  the original version and all the amended versions of the same
      document, and

   *  the versions of the text expressed in the different official
      languages of the state or organization.

   Finally, the uniform name allows a distinction among diverse
   manifestations that may be produced by multiple publishers using
   different means and formats.

   In every case, the basic identifier of the source of law (work)
   remains the same, but information is added regarding the specific
   version under consideration (expression).  Similarly, a suffix is
   added to the expression for representing the characteristics of the
   publication (manifestation).

   Information that forms a uniform name for a source of law at each
   level (work, expression, and manifestation) is expressed in the
   official language of the relevant jurisdiction.  More language-
   dependent names (aliases) are created in cases where there are
   multiple official languages (as in Switzerland) or more involved
   jurisdictions (as in international treaties).

   Therefore, the more general structure of the local-name appears as
   follows:

          local-name = work ["@" expression] ["$" manifestation]

   However, consistent with legislative practice, the uniform name of
   the main original provision (work) becomes the identifier of an
   entire class of documents that includes the following: the original
   main document, the annexes, and all the versions, languages, and
   formats that are subsequently generated.

5.4.  Structure of the Document Identifier at "Work" Level

   The structure of the document identifier is comprised of the four
   fundamental elements mentioned above, distinguished one from the
   other and ordered by increasingly narrow domains and competencies:

      work = authority ":" measure ":" details *(":" annex)

   where:

   authority:  The issuing or proposing authority of the measure (e.g.,
      state, ministry, municipality, court, etc.).

   measure:  The type of the measure, both public (e.g., constitution,
      act, treaty, regulation, decree, decision, etc.) and private
      (e.g., license, agreement, etc.).

   details:  The terms associated with the measure, typically the date
      (usually the signature date) and the number included in the
      heading of the act.

   annex:  The identifier of the annex, if any (e.g., Annex 1).

   Both the main document and its annexes have their own uniform names
   so that they can be referenced individually; the identifier of the
   annex adds a suffix to that of the main document.  In a similar way,
   the identifier of an annex of an annex adds an ending to that of the
   annex that it is attached to.

   The main elements of the work name are generally divided into several
   elementary components, and for each component, specific rules of
   representation are established (criteria, modalities, syntax, and
   order).  For the details regarding each element, see Section 6.  The
   following are hypothetical examples of work identifiers:

   urn:lex:it:stato:legge:2006-05-14;22
   urn:lex:uk:ministry.justice:decree:1999-10-07;45
   urn:lex:ch;glarus:regiere:erlass:2007-10-15;963
   urn:lex:es:tribunal.supremo:decision:2001-09-28;68
   urn:lex:fr:assemblee.nationale:proposition.loi:13.legislature;1762
   urn:lex:br:estado:constituicao:1988-10-05;lex-1
   urn:lex:un.org:united.nations;general.assembly:resolution:
       1961-11-28;a-res-1661
   urn:lex:nl:hoge.raad:besluit:2008-04-01;bc8581

   The type of measure is important to identify case law and
   legislation, especially within legal systems where cases are
   traditionally identified only through the year of release and a
   number.  Since the aim of the LEX schema is to identify specific
   materials, the type of measure or the full date are able to
   differentiate between materials belonging to a specific case.

   The following is an example where the type of measure or the full
   date are essential for identify specific materials of a case:

   *  4/59 Judgment of the EEC Court of Justice 04/04/1960, Mannesmann
      AG and others / ECSC High Authority

        urn:lex:eec.lex.arpa:court.justice:judgement:1960-04-04;4-59

   *  4/59 Order of the EEC Court of Justice 18/05/1960, Mannesmann AG
      and others / ECSC High Authority

        urn:lex:eec.lex.arpa:court.justice:order:1960-05-18;4-59

5.5.  Aliases

   International treaties involve multiple signatory jurisdictions and
   are therefore represented through multiple identifiers, each of them
   related to a signatory.  For example, a bilateral France and Germany
   treaty is identified through two URNs (aliases) belonging to either
   the "fr" or "de" jurisdiction (e.g., "urn:lex:fr:etat:traite:..." and
   "urn:lex:de:staat:vertrag:..." since it pertains to both the French
   and German jurisdictions).

   In the states or organizations that have multiple official languages,
   a document has multiple identifiers.  Each identifier is expressed in
   a different official language and is basically a set of equivalent
   aliases.  This system permits manual or automated construction of the
   uniform name of the referred source of law in the same language used
   in the document itself (e.g.,
   "urn:lex:eu:council:directive:2004-12-07;31" and
   "urn:lex:eu:consiglio:direttiva:2004-12-07;31").

   Moreover, a document can be assigned more than one uniform name in
   order to facilitate its linking from other documents.  This option
   can be used for documents that, although unique, are commonly
   referenced from different perspectives, for example, the form of a
   document's promulgation and its specific content (e.g., a Regulation
   promulgated through a Decree of the President of the Republic).

5.6.  Structure of the Document Identifier at "Expression" Level

   There may be several expressions of a legal text connected to
   specific versions or languages.

   Each version is characterized by the period of time during which that
   text is to be considered to be in force or effective.  The lifetime
   of a version ends with the issuing of the subsequent version.  New
   versions of a text may be brought into existence by:

   *  amendments due to the issuing of other legal acts and to the
      subsequent production of updated or consolidated texts,

   *  correction of publication errors (rectification or errata
      corrige), and

   *  entry into or departure from a particular time span, depending on
      the specific date in which different partitions of a text come
      into force.

   Each version may be expressed in more than one language, with each
   language version having its own specific identifier.  The identifier
   of a source of law expression adds such information to the work
   identifier using the following main structure:

       expression = version [":" language]

   where:

   version:  The identifier of the version of the original or amended
      source of law.  In general, it is expressed by the promulgation
      date of the amending act; other specific information can be used
      for particular documents.  If necessary, the original version is
      specified by the string "original" and is expressed in the
      language of the act or version (for the details regarding this
      element, please see Section 7).

   language:  The identification code of the language in which the
      document is expressed, according to [RFC5646] (it=Italian,
      fr=French, de=German, etc.).  The granularity level of the
      language (for example, the specification of the German language as
      used in Switzerland rather than standard German) is left to each
      specific jurisdiction.  The information is not necessary when the
      text is expressed in the sole official language of the country or
      jurisdiction.

   The following are hypothetical examples of document identifiers for
   expressions:

   urn:lex:ch:etat:loi:2006-05-14;22@originel:fr
       (original version in French)
   urn:lex:ch:staat:gesetz:2006-05-14;22@original:de
       (original version in German)
   urn:lex:ch:etat:loi:2006-05-14;22@2008-03-12:fr
       (amended version in French)
   urn:lex:ch:staat:gesetz:2006-05-14;22@2008-03-12:de
       (amended version in German)
   urn:lex:be:conseil.etat:decision:2008-07-09;185.273@originel:fr
       (original version in French of a Belgian decision)

5.7.  Structure of the Document Identifier at "Manifestation" Level

   To identify a specific manifestation, the uniform name of the
   expression is followed by a suitable suffix containing the following
   main elements:

   editor:  Editorial staff who produced it, expressed according to the
      publisher's Internet domain name.  Since publishers' domain names
      may vary over time, manifestations already assigned by a publisher
      remain unchanged, even if the identified object is no longer
      accessible.  In this case, in order to make its materials
      accessible, the publisher will have to create a new manifestation
      with a new domain name for each object.

   format:  The digital format (e.g., XML, HTML, PDF, etc.) expressed
      according to the MIME Content-Type standard [RFC2045], where the
      "/" character is to be substituted with the "-" sign.

   component:  Possible components of the expressions contained in the
      manifestation.  Such components are expressed by language-
      dependent labels representing the whole document (in English
      "all"), the main part of the document (in English "body"), or the
      caption label of the component itself (e.g., Table 1, Figure 2,
      etc.).

   feature:  Other features of the document (e.g., anonymized decision
      text).

   Thus, the manifestation suffix reads:

       manifestation = editor ":" format
                       [":" component [":" feature]]

   To indicate possible features or peculiarities, each main element of
   the manifestation MAY be followed by further specifications
   (separated by ";"), for example, the archive name and electronic
   publisher for the editor and the version for format.  Therefore, the
   main elements of the manifestation will assume the following forms:

       editor = publisher *(";" specification)

       format = mime *(";" specification)

       component = part *(";" specification)

       feature = attribute *(";" specification)

   The syntax details of the manifestation element are shown in
   Section 8 in the related part.

   The following are hypothetical examples:

   *  The original version of the Italian act 3 April 2000, n. 56 might
      have the following manifestations with their relative uniform
      names:

      -  PDF format (vers. 1.7) of the whole act edited by the Italian
         Parliament:

         urn:lex:it:stato:legge:2000-04-03;56$parlamento.it:
         application-pdf;1.7

      -  XML format (version 2.2 DTD NIR) of the text of the act and PDF
         format (version 1.7) of the "Figura 1" (figure 1) contained in
         the body, edited by the Italian Senate:

         urn:lex:it:stato:legge:2000-04-03;56$senato.it:text-xml;
           dtd-nir-2.2:testo
         urn:lex:it:stato:legge:2000-04-03;56$senato.it:
           application-pdf;1.7:figura.1

   *  The Spanish URN of the HTML format of the whole Judgment of the
      European Court of Justice n. 33/08 of 11/06/2009, in Spanish
      version, published in the Jurifast database in anonymized form:

      urn:lex:eu:tribunal.justicia:sentencia:2009-06-11;33-08
      @original:es$juradmin.eu;jurifast:text-html:todo:anonimo

   It is useful to be able to assign a uniform name to a manifestation
   (or to a part of it) in case non-textual objects are involved.  These
   may be multimedia objects that are non-textual in their own right
   (e.g., geographic maps, photographs, etc.) or texts recorded in non-
   textual formats (e.g., image scans of documents).

5.8.  Sources of Law References

   References to sources of law often refer to specific partitions of
   the act (article, paragraph, etc.) and not to the entire document.

   From a legal point of view, a partition is always a text block that
   represents a logical subdivision of an act.

   In the digital representation, a partition is represented by an
   element (a block of text) with its own ID; this ID aims to identify
   the related element and locate it.  Therefore, it is possible to
   either extract or point to a partition.

   For markup that does not fit the logical structure of the text (like
   HTML), generally only the starting point of the partition, rather
   than the whole block of text or element, is identified through a
   label (e.g., <a id=partitionID></a> tag in the HTML markup language
   [W3C.HTML]).  In this case, it is only possible to point to a
   partition but not extract it.

   Partitions should be assigned unique labels or IDs within the
   including document, and their value should be the same regardless of
   document format.

   To enable the construction of the partition identifier between
   different collections of documents, specific construction rules for
   IDs or labels will be defined and shared within each country or
   jurisdiction for any document type.  For example, in legislation,
   paragraph 2 of article 3 might have the value "art3;par2" as the
   label or ID; similarly, for case law, paragraph 22 of the judgment in
   Case 46/76 Bauhuis v Netherlands might have the value "par22" as the
   label or ID.

   Furthermore, it is useful to foresee the compatibility with
   applications that are able to manage this information (e.g.,
   returning the proper element); these procedures are particularly
   useful in the case of rather long acts, such as codes, constitutions,
   regulations, etc.  For this purpose, it is necessary that the
   partition identifier be transmitted to the servers (resolution and
   application).  Therefore, it cannot be separated by the typical "#"
   character of URI fragment, which is not transmitted to the server.

   According to these requirements, the syntax of a reference is:

        URN-reference = URN-document ["~" partition-id]

   For example, referring to paragraph 3 of article 15 of the French Act
   of 15 May 2004, n. 106, the reference can be
   "urn:lex:fr:etat:loi:2004-05-15;106~art15;par3".

   If a different separator ("~") is used after the document name, the
   partition ID is not withheld by the browser but is transmitted to the
   resolution process.  If the partition syntax is compatible with the
   media type used, this enables the resolver to retrieve (for example,
   out of a database) only the referred partition; otherwise, the whole
   act is returned.

   When resolving to HTTP, the resolver SHALL transform the partition ID
   to an appropriate internal reference (#) on the page or at the
   beginning if that point cannot be found.  The transformation in the
   URI fragment is obtained by appending the "#" character followed by
   the partition ID to the URL (in the example above, the returned URL
   will be <URL-document>#art15;par3).  Doing this, knowing the
   granularity of the act markup, the resolver could exploit the
   hierarchical structure of the ID by eliminating sub-partitions that
   are not addressed.  In the previous example, if only the article was
   identified in the act, it could return <URL-document>#art15 only.

   It is possible to use the general syntax (with "#"); in this case,
   only the URN document component of the reference is transmitted to
   the resolver; therefore, the whole document will always be retrieved.

6.  Specific Syntax of the Identifier at "Work" Level

6.1.  The Authority Element

6.1.1.  Indication of the Authority

   The authority element of a uniform name may indicate the following in
   the various cases:

   *  The actual authority issuing the legal provision.  More
      specifically, the authority adopting the provision or enacting it.

   *  The institution where the provision is registered, known, and
      referenced to, even if produced by others (e.g., the bills
      identified through the reference to the Chamber where they are
      presented).

   *  The institution regulated (and referred to in citations) by the
      legal provision even when this is issued by another authority
      (e.g., the statute of a Body).

   *  The entity that proposed the legal material not yet included in
      the institutional process (e.g., a proposed bill written by a
      political party).

6.1.2.  Multiple Issuers

   Some sources of law are enacted by a number of issuing parties (e.g.,
   inter-ministerial decrees, agreements, etc.).  In this case, the
   authority element contains all the issuing parties (properly
   separated) as follows:

      authority = issuer *("+" issuer)

   This is an example: "ministry.justice+ministry.finances".

6.1.3.  Indication of the Issuer

   Each issuing authority is essentially represented by either an
   institutional office (e.g., Prime Minister) or an institution (e.g.,
   Ministry); in the last case, the authority is indicated in accordance
   with the institution's hierarchical structure, from more general to
   more specific (Council, Department, etc.), ending with the relative
   office (President, Director, etc.).  Therefore, the structure of the
   issuer is as follows:

      issuer = (institution *(";" body-function)) / office

   This is an example: "ministry.finances;department.revenues;manager".

6.1.4.  Indication of the Body

   Depending on the kind of measure, the body within the issuing
   authority is unambiguously determined (e.g., the Council for Regional
   Acts), and it is not normally indicated in the references.  Just like
   in practice, the indication of the enacting authority is limited to
   the minimum in relation to the type of measure (e.g.,
   "region.tuscany:act" and not "region.tuscany;council:act").

6.1.5.  Indication of the Function

   Generally, the function is indicated, sometimes instead of the Body
   itself:

   *  In the case of political, representative, or elective offices
      (e.g., "university.oxford;rector:decree" instead of
      "university.oxford;rectorship:decree").

   *  When referring to a top officer in the institution (e.g., general
      manager, general secretary, etc.), which is not always possible to
      associate a specific internal institutional structure to (e.g.,
      "national.council.research;general.manager").

   It is not indicated when it clearly corresponds to the person in
   charge of an institution (typically, a general director); in this
   case, only the structure and not the person in charge is indicated
   (e.g., "ministry.justice;department.penitentiary.administration").

   The function MUST be indicated when:

   *  It is not the same as the director or the person in charge of the
      structure (for example, an undersecretary, a deputy director,
      etc.).

   *  The type of measure may be both monocratic or collegial; the
      indication of the office eliminates the ambiguity.

6.1.6.  Conventions for the Authority

   Acts and measures bearing the same relevance as an act, issued or
   enacted since the foundation of the State, have conventionally
   indicated "state" (expressed in each country's official language) as
   the authority.  The same convention is used for constitutions, codes
   (civil, criminal, civil procedure, criminal procedure, etc.), and
   international treaties.

6.2.  The Measure Element

6.2.1.  Criteria for the Indication of the Type of Measure

   In uniform names, the issuing authority of a document is mandatory.
   This makes it unnecessary to indicate any further qualification of
   the measure (e.g., ministerial decree, directorial ordinance, etc.),
   even if it is widely used.  When the authority-measure combination
   clearly identifies a specific document, the type of measure is not
   defined through attributes referring to the enacting authority (e.g.,
   "region.tuscany:act" and not "region.tuscany:regional.act").

6.2.2.  Further Specification to the Type of Measure

   In the measure element, it is usually sufficient to indicate the type
   of a measure.  As usual, rather than through the formal details (date
   and number), references to sources of law may be made through some of
   their characteristics, such as the subject matter covered (e.g.,
   accounting regulations), nicknames referring to the promoter (e.g.,
   Bolkestein directive), or the topic of the act (e.g., Bankruptcy
   Law), etc.  In these cases, the type of measure MAY be followed by
   further specifications that are useful in referencing, even if the
   details are lacking:

         measure = measure-type *(";" specification)

   These are examples: "regulations;accounting" or "act;bankruptcy".

6.2.3.  Aliases for Sources of Law with Different Normative References

   There are legislative measures that, although unique, are usually
   cited in different ways, for example, introducing them into the legal
   order through a legislative act (President's decree, legislative
   decree, etc.) or through their legislative category (regulations,
   consolidation, etc.).  In order to ensure the validity of the
   references in all cases, an alias (an additional URN LEX identifier)
   that takes into account the measure category is added to what
   represents the legislative form of the same act (e.g.,
   "state:decree.legislative:1992-07-24;358" and
   "state:consolidation;public.contracts:1992-07-24;358").

6.2.4.  Relations Between Measure and Authority in the Aliases

   The sources of law including different normative references are
   usually introduced in legislation through the adoption or the issuing
   of an act, which they are either included or attached to.  Therefore,
   it is necessary to create an alias linking the two aspects of the
   same document.  Specifically, the different measures can be:

   *  Adopted/issued by an authority different from the one regulated by
      the provision (e.g., the statute of a Body).  In this case, the
      correlation is established between two uniform names, each
      featuring a completely different authority element (e.g.,
      "italian.society.authors.publishers:statute" and
      "ministry.cultural.activities+ministry.finances.budget.economic.
      planning:decree").

   *  Issued by the institution itself either because it has issuing
      authority or by virtue of a proxy (e.g., a provision that refers
      to the functioning of the Body itself).  In this case, the two
      aliases share the first part of the authority (e.g.,
      "municipality.firenze:statute" and
      "municipality.firenze;council:deliberation").

   *  Issued by the same Body to regulate a particular sector of its own
      competence.  In this case, the authority element is the same
      (e.g., "ministry.justice:regulation;use.information.tools.
      telematic.process" and "ministry.justice:decree").

6.3.  The Details Element

6.3.1.  Indication of the Details

   The details of a source of law usually include the date of the
   enactment and the identification number (inclusion in the body of
   laws, registry, protocol, etc.).

   Some measures can have multiple dates.  There are also cases in which
   the number of the measure does not exist (unnumbered measures) or a
   measure has multiple numbers (e.g., unified cases).  For these
   reasons, the setup of both elements (date and number) includes
   multiple values.

   Some institutions (e.g., the Parliaments) usually identify documents
   through their period of reference (e.g., the legislature number)
   rather than through a date, which would be much less meaningful and
   never used in references (e.g., Senate bill S.2544 of the XIV
   legislature).  In these cases, the component period is substituted
   for the component dates.

   Usually, details of a measure are not reported according to a
   specific sequence.  In accordance with the global structure of the
   uniform name, which goes from general to specific, the sequence date-
   number has the following form:

      details = (dates / period) ";" numbers

   The following are examples: "2000-12-06;126" and
   "14.legislature;s.2544".

6.3.2.  Multiple Dates

   Some sources of law, even if unique, are identified by more than one
   date.  In this case, all the given dates are to be reported and
   indicated as follows:

      dates = date *("," date)

   For example, the measure of the Data Protection Authority of December
   30, 1999-January 13, 2000, No. 1/P/2000 has the following uniform
   name:

     personal.data.protection.authority:measure:1999-12-30,2000-01-
     13;1-p-2000

   As specified in Section 3.6, all the dates can have the date typical
   of the jurisdiction in addition to the ISO format.

6.3.3.  Unnumbered Measures

   Measures not officially numbered in the publications may have a non-
   unequivocal identifier, because several measures of the same type can
   exist and can be issued on the same day by the same authority.  To
   ensure that the uniform name is unambiguous, the numbers field MUST,
   in any case, contain a discriminating element, which can be any
   identifier used internally and not published by the authority (e.g.,
   protocol).

   If the authority does not have its own identifier, one identifier
   MUST be created for the name system.  In order to easily
   differentiate it, such number is preceded by the string "lex-":

      number-lex = "lex-" 1*DIGIT

   The following is an example: "ministry.finances:decree:1999-12-
   20;lex-3".

   It is the responsibility of the authority issuing a document to
   assign a discriminating specification to it.  When there are multiple
   authorities, only one of them is responsible for the assignment of
   the number to the document (e.g., the proponent).

   The unnumbered measures published on an official publication (e.g.,
   the Official Gazette), are recognized by the univocal identifying
   label printed on the paper instead of by a progressive number.  Such
   an identifier, even if it is unofficial but assigned to a document in
   an official publication, is preferred because it has the clear
   advantage of being public and is therefore easier to find.

6.3.4.  Multiple Numbers

   Some legal documents (e.g., bills), even if unique, are identified by
   a set of numbers (e.g., the unification of cases or bills).  In this
   case, in the numbers field, all the identifiers are reported,
   according to the following structure:

     number = document-id *("," document-id)

   The following is an example: "2000-06-12;c-10-97,c-11-97,c-12-97".

   The characters that are not allowed (e.g., "/") or reserved (e.g.,
   ":"), including the comma, cannot exist inside the document-id and
   therefore MUST be turned into "-".

   When special characters contained in the number of the act are
   distinctive of the act itself (e.g., bill n. 123-bis (removal of 123)
   and n. 123/bis (return of 123)) and would disappear with the
   conversion to "-", a further ending must be added to distinguish the
   acts (e.g., bill n.123-bis-removal and 123-bis-return).

6.4.  The Annex Element

6.4.1.  Formal Annexes

   Although annexes are an integral part of a legal document, they may
   be referred to and undergo amendments separately from the act to
   which they are annexed.  Therefore, it is necessary that both the
   main document as well as each formal individual annex is
   unequivocally identified.

   Formal annexes may be registered as separate parts or together with a
   legal provision; they may or may not be autonomous in nature.  In any
   case, they MUST be given a uniform name that includes the uniform
   name of the source of law to which they are attached and a suffix
   that identifies the annex itself.

   The suffix of formal annexes includes the official heading of the
   annex and, possibly, further specifications (e.g., the title) that
   will facilitate the retrieval of the annex in case the identifier is
   missing:

       annex = annex-id *(";" specification)

   The following is an example:

     region.sicily;council:deliberation:1998-02-12;14:annex.a;
     borders.park

   The characters that are not allowed (e.g., "/") or that are reserved
   (e.g., ":") must not be featured in the annex-id and therefore MUST
   be turned into ".".

6.4.2.  Annexes of Annexes

   When there are annexes to an annex, their corresponding identifiers
   are created by adding to the identifier of the original annex those
   of the annexes that are connected with it (that is, attached to it).
   For example, Table 1 attached to the Annex A of the preceding legal
   act has the following uniform name:

     region.sicily;council:deliberation:1998-02-12;14:annex.a;
     borders.park:table.1;municipality.territories

7.  Specific Syntax of the Version Element of the "Expression"

7.1.  The Version Element

7.1.1.  Different Versions of a Legislative Document

   The creation of an updated text of a document may have one of the
   following forms:

   "multi-version":  Specific markups that identify the modified parts
      of a document (added, substituted, or deleted parts) and their
      related periods of effectiveness are indicated inside a single
      object (e.g., an XML file).  Such a document will be able, in a
      dynamic way, to appear in different forms according to the
      requested date of effectiveness.  In this document type, a set of
      metadata usually contains the life cycle of the document (from the
      original to the last modification), including the validity time
      interval of each version and of each related text portion.

   "single-version":  A new and distinct object is created for each
      amendment to the text at a given time.  Each object is, therefore,
      characterized by its own period of validity.  In any case, all the
      versions SHOULD be linked to one another and immediately
      navigable.

   In a "multi-version" document, each time interval should have a link
   to the related in-force document version that can be displayed.  In a
   "single-version" document, the metadata should contain links to all
   the previous modifications and a link only to the following version,
   if any.

   [RFC8288] can be used as a reference to establish links between
   different document versions, either in the "multi-version" or in the
   "single-version" document.  According to [RFC8288], the following
   relations are useful:

   current (or last or last-version):  in-force version

   self:  this version

   next:  next version

   previous:  previous version

   first:  original version

   It is RECOMMENDED that these relations be inserted in the header of
   each version (if "single-version") or associated to each entry
   containing a single URN (if "multi-version").

7.1.2.  Identification of the Version

   In order to identify the different time versions of the same act, a
   specific suffix has to be added to the uniform name of the original
   document.

   Such a suffix identifies each version of a legal provision and
   includes, first and foremost, one of the following elements:

   *  The issuing date of the last amending measure taken into account.

   *  The date that the communication of the rectification or errata
      corrige was published.

   *  A specification that must identify the reason concerning the
      amendment (e.g., the specific phase of the legislative process),
      for the cases in which the date is not usually used (e.g., bills).

   It is possible to add further specifications that will distinguish
   each of the different versions of the text to guarantee identifier
   unequivocalness.  Examples include changes of the in-force or
   effectiveness of a formal partition or portion of the text itself
   (e.g., when the amendments introduced by an act are applied at
   different times) or different events occurring on the same date.

      version = (amendment-date / specification)
                *(";" (event-date / event))

   where:

   amendment-date:  Contains the issuing date of the last considered
      amendment or of the last communication of amendment.  If the
      original text introduces differentiated periods in which an act is
      effective and the information system produces one version for each
      of them, such element contains the string "original" expressed in
      the language of the act or version.

   specification:  Contains any information that is useful to identify
      the version unambiguously and univocally.

   event-date:  Contains the date in which a version is put into force,
      is effective, or is published.

   event:  A name assigned to the event producing a further version
      (e.g., amendment, decision, etc.).

   The issuing date of an amending act was chosen as the identifier of a
   version because it can be obtained from the heading (formal data).
   For example, the name "state:royal.decree:1941-01-30;12@1998-02-19"
   identifies the updated text of the "Royal Decree of 30/1/1941, No.
   12" with the amendments introduced by the "Law Decree of 19/2/1998,
   No. 51" without any indication of its actual entry into force.  The
   same uniform name with the additional ending ";1999-01-01" indicates
   the in-force or effective version starting on a different date
   (1/1/99).

   For full compatibility, every update of text, or of the
   effectiveness, of a "multi-version" document implies the creation of
   a new uniform name, even if the object remains single, containing the
   identifier of the virtually generated version, as in the case of a
   "single-version" document.  Specific metadata will associate every
   uniform name with the period of time during which such a name,
   together with its corresponding text, is to be considered valid
   (e.g., the "multi-version" document containing "R.D. of 01/30/1941,
   no. 12", updated by the amendments introduced by the "D.Lgs. of
   02/19/1998, no. 51", contains the name of the original version
   "state:royal.decree:1941-01-30;12" as well as the name of the updated
   version "state:royal.decree:1941-01-30;12@1998-02-19").

   Note that if there are attachments or annexes, the creation of a new
   version (even in the case of only one component) would imply the
   creation of a new uniform name for all the connected objects in order
   to guarantee their alignment (i.e., the main document, attachments,
   and annexes).

   As specified in Section 3.6, all the dates can have the date typical
   of the jurisdiction in addition to the date in ISO format.

8.  Summary of the Syntax of the Uniform Names of the LEX Namespace

   ; Structure of a Uniform Resource Name (URN) of the LEX namespace
   ; - NID = LEX namespace identifier
   ; - NSS = LEX Namespace Specific String
   URN = "urn:" NID ":" NSS
   NID = "lex"

   ; Structure of a LEX specific name
   NSS = jurisdiction ":" local-name

   ; Structure of the jurisdiction element
   jurisdiction = jurisdiction-code *(";" jurisdiction-unit)
   jurisdiction-code = 2*alf-dot
   jurisdiction-unit = alf-dot

   ; Structure of the local-name element
   local-name = work ["@" expression] ["$" manifestation]

   ; Structure of the work element
   work = authority ":" measure ":" details *(":" annex)

   ; Structure of the authority element
   authority = issuer *("+" issuer)
   issuer = (institution *(";" body-function)) / office
   institution = alf-dot
   body-function = alf-dot
   office = alf-dot

   ; Structure of the measure element
   measure = measure-type *(";" specification)
   measure-type = alf-dot
   specification = alf-dot

   ; Structure of the details element
   details = (dates / period) ";" numbers
   dates = date *("," date)
   period = alf-dot
   numbers = number / number-lex
   number = (document-id *("," document-id))
   document-id = alf-dot-oth
   number-lex = "lex-" 1*DIGIT

   ; Structure of the annex element
   annex = annex-id *(";" specification)
   annex-id = alf-dot

   ; Structure of the expression element
   expression = version [":" language]

   ; Structure of the version element
   version = (amendment-date / specification)
             *(";" (event-date / event))
   amendment-date = date
   event-date = date
   event = alf-dot

   ; Structure of the language element
   language = 2*3alfa *["-" extlang] / 4*8alfa
   extlang  = 3alfa *2("-" 3alfa)

   ; Structure of the manifestation element
   manifestation = editor ":" format
                   [":" component [":" feature]]
   editor = publisher *(";" specification)
   publisher = alf-dot-hyp
   format = mime *(";" specification)
   mime = alf-dot-hyp
   component = part *(";" specification)
   part = alf-dot-hyp
   feature = attribute *(";" specification)
   attribute = alf-dot-hyp

   ; Structure of the date
   date = date-iso ["|" date-loc]
   date-iso = year "-" month "-" day
   year = 4DIGIT
   month = 2DIGIT
   day = 2DIGIT
   date-loc = *(alfadot / other)

   ; Allowed, reserved and future characters
   ; - allowed = alfadot / other / reserved
   ; - reserved = ":" / "@" / "$" / "+" / "|" / ";" / "," / "~"
   ; - future   = "*" /  "!"
   alf-dot = alfanum *alfadot
   alf-dot-hyp = alfanum *(alfadot / "-")
   alf-dot-oth = alfanum *(alfadot / other)
   alfadot = alfanum / "."
   alfa = lowercase / uppercase
   alfanum = alfa / DIGIT / encoded
   lowercase = %x61-7A        ; lower-case ASCII letters (a-z)
   uppercase = %x41-5A        ; upper-case ASCII letters (A-Z)
   DIGIT     = %x30-39        ; decimal digits (0-9)
   encoded   = "%" 2HEXDIG
   HEXDIG = DIGIT / %x41-46 / %x61-66 ; hex digits (0-9,A-F,a-f)
   other    = "-" / "_" / "'" / "=" / "(" / ")"

9.  Procedure of Uniform Names Assignment

9.1.  Specifying the Jurisdiction Element of the LEX Identifier

   Under the LEX namespace, each country or international organization
   is assigned a jurisdiction-code, which characterizes the URNs of the
   source of law of that country or jurisdiction.  This code is assigned
   according to ccTLD (as well as TLDN (Top-Level Domain Name) or DN
   (Domain Name) for organizations) representation, and it is the value
   of the jurisdiction-code element, which preserves cross-country
   uniqueness of the identifiers.

9.2.  Jurisdictional Registrar for Names Assignment

   Any country or jurisdiction that intends to adopt this schema MUST
   identify a Jurisdictional Registrar, an organization that shares and
   defines the structure of the optional part (jurisdiction-unit) of the
   name, according to the organization of the state or institution (for
   details, see Section 2.2).  It must appoint a Jurisdictional
   Registrar and must apply the Designated Experts to register the new
   jurisdiction-code.

   For example, in a federal state, a jurisdiction-unit corresponding to
   the name of each Member State (e.g., "br;sao.paulo",
   "br;minas.gerais", etc.) may be defined.

   The process of assigning the local-name is managed by each specific
   country or jurisdiction under the related jurisdiction element.

   In any country, the Jurisdictional Registrar shares and defines the
   assignment of the primary elements (issuing authority and type of
   legal measure) of the local-names considering the characteristics of
   its own state or institution organization.

   The Jurisdictional Registrar MUST establish, according to the
   guidelines indicated in this document, a uniform procedure within the
   country or organization to define local-name elements, make decisions
   about normalizations, solve and avoid possible name collisions, and
   maintain authoritative registries of various kinds (e.g., for
   authorities, types of measures, etc.).  In particular, accurate
   point-in-time representations of the structure and naming of
   government entities are important to semantically aware applications
   in this domain.

   Moreover, the Jurisdictional Registrar shares and defines the rules
   to construct partition IDs for each document type, possibly in
   accordance with those already defined in other jurisdictions.

   Finally, the Jurisdictional Registrar will develop and publish the
   rules and guidelines for the local-name construction as well as the
   predefined values and codes.  The Jurisdictional Registrar should
   also promote the LEX URN identifier for the sources of law of its
   jurisdiction.

   Such a set of rules will have to be followed by all institutional
   bodies adopting the LEX URN identification system in a country or
   jurisdiction, as well as by private publishers.  Each of them will be
   responsible for assigning names to their domains.

9.3.  Identifier Uniqueness

   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 is assigned by the issuing authority
   in conformance with the syntax defined in Section 5.  The main
   elements (authority and type of measure) of the local-name are
   defined by the Jurisdictional Registrar, so that it is ensured that
   the constructed URNs are unique.  The Jurisdictional Registrar MUST
   provide clear documentation of rules by which names are to be
   constructed and MUST update its registries and make them accessible.

   Any enacting authority is responsible for defining formal parameters
   to guarantee local-name uniqueness by attributing, if necessary, a
   conventional internal number, which when combined with the other
   local-name components (authority, measure, and date), builds a unique
   identifier.  Uniqueness is achieved by checking against the catalogue
   of previously assigned names.

9.4.  Identifier Persistence Considerations

   The persistence of identifiers depends on the durability of the
   institutions that assign and administer them.  The goal of the LEX
   schema is to maintain uniqueness and persistence of all resources
   identified by the assigned URNs.

   In particular, CNR is responsible for maintaining the uniqueness of
   the jurisdiction element.  Given that the jurisdiction is assigned on
   the basis of the long-held ccTLD representation of the country (or
   the TLDN or DN of the organization) and that the associated code for
   country or organization is expected to continue indefinitely, the URN
   also persists indefinitely.

   The rules for the construction of the name are conceived to delegate
   the responsibility of their uniqueness to a set of authorities that
   is identified within each country or organization.

   Therefore, each authority is responsible for assigning URNs that have
   a very long life expectancy and can be expected to remain unique for
   the foreseeable future.  Practical and political considerations, as
   well as diverse local forms of government organization, will result
   in different methods of assigning responsibility for different levels
   of the name.

   Where this cannot be accomplished by the implementation of an
   authoritative hierarchy, it is highly desirable that it be done by
   creating consensus around a series of published rules for the
   creation and administration of names by institutions and bodies that
   operate by means of collaboration rather than compulsion.

   Issuing authorities that operate in more localized scopes, ranging
   from national scope down to very local scope, MUST equally take
   responsibility for the persistence of identifiers within their scope.

10.  Recommendations for the Resolution Process

10.1.  General Architecture of the System

   The task of the resolution service is to associate a LEX identifier
   with a specific document address on the Internet.  In contrast with
   systems that can be constructed around rigorous and enforceable
   engineering premises, such as DNS, the LEX namespace resolver will be
   expected to cope with a wide variety of inputs that are incomplete or
   partially incorrect, particularly those created by the automated
   extraction of references from texts.  In this document, the result is
   a particular emphasis on a flexible and robust resolver design.

   The system has a distributed architecture based on two fundamental
   components: a chain of information in the DNS and a series of
   resolution services from URNs to URLs, each competent within a
   specific domain of the namespace.

   The client retrieves the document associated with this URN using the
   procedure described in [RFC3404], which starts with a DNS NAPTR
   query.

   A resolution service can delegate the resolution and management of
   hierarchically dependent portions of the name.  Delegation of this
   responsibility will not be unreasonably withheld provided that the
   processes for their resolution and management are robust and
   followed.

   For the LEX namespace, CNR will 1) maintain the root zone of the
   chain resolution, equivalent to "lex.urn.arpa" (see [RFC3405]), in
   the lex-nameserver.nic.it (see Section 12) and 2) update the DNS
   information with a new record to delegate the relative resolution
   when a new country (e.g., "br") or organization is added (see
   Section 2.2).  This delegation may be obtained by a regular
   expression that matches the initial part of the URN (e.g.,
   "urn:lex:br") and redirects towards the proper zone (e.g.,
   "lex.senado.gov.br").

   Likewise, the institution responsible for the jurisdiction uniform
   names (e.g., "urn:lex:br") has the task of managing the relative root
   in the DNS system (e.g., "lex.senado.gov.br" zone) and routing the
   resolution towards its resolvers on the basis of parts of the uniform
   names.  In a similar way, it can delegate the resolution of country/
   organization sub-levels (e.g., "urn:lex:br;sao.paolo") towards the
   relative zone (e.g., "lex.sao-paolo.gov.br").

   Such a DNS routing chain does not work for all the URN components
   containing percent-encoded characters.  Therefore, when converting a
   LEX URN in UTF-8 code to a DNS query, clients MUST perform any
   necessary punycode conversion [RFC5891] before sending the query.

   The resolution service is made up of two elements: a knowledge base
   (consisting in a catalogue or a set of transformation rules) and
   software to query the knowledge base.

10.2.  Catalogues for Resolution

   Incompleteness and inaccuracy are rather frequent in legal citations;
   thus, incomplete or inaccurate uniform names of the referred document
   are likely to be built from textual references (this is even more
   frequent if they are created automatically through a specific
   parser).  For this reason, the implementation of a catalogue, based
   on a relational database, is suggested, as it will lead to higher
   flexibility in the resolution process.

   In addition, the catalogue must manage the aliases, the various
   versions and languages of the same source of law, and the related
   manifestations.

   It is suggested that each enacting authority implement its own
   catalogue, assigning a corresponding unambiguous uniform name to each
   resource.

10.3.  Suggested Resolver Behavior

   First, the resolver SHOULD separate the part corresponding to the
   partition ID from the document name, with the "~" separator.

   The resolution process SHOULD implement a normalization of the
   uniform name to be resolved.  This may involve transforming some
   components to the canonical form (e.g., filling out the acronyms,
   expanding the abbreviations, unifying the institution names,
   standardizing the type of measures, etc.).  For this function,
   authorities and types of measure registries are useful.

   The resolver SHOULD then query the catalogue searching for the URN
   that corresponds exactly to the given one (normalized if necessary).
   Since the names coming from the references may be inaccurate or
   incomplete, an iterative and heuristic approach (based on partial
   matches) is indicated.  Incomplete references (not including all the
   elements to create the canonical uniform name) are normal and
   natural; for a human reader, the reference would be "completed" by
   contextual understanding of the reference in the document in which it
   occurs.

   In this phase, the resolver should use the partition ID information
   to retrieve, if it is possible, only the referred partition;
   otherwise, the entire document is returned.

   Lacking more specific indications, the resolver SHOULD select the
   best (most recent) version of the requested source of law and provide
   all the manifestations with their related items.  A more specific
   indication in the uniform name to be resolved will, of course, result
   in a more selective retrieval, based on any suggested expression and/
   or manifestations components (e.g., date, language, format, etc.).

   Finally, the resolver SHOULD append the "#" character followed by the
   partition ID to URLs, to create URI fragments for browser pointing.

11.  Security Considerations

   Security considerations are those normally associated with the use
   and resolution URNs in general.  Additional security considerations
   concerning the authenticity of a document do not pertain to the LEX
   specifications, but they pertain to security and trust issues that
   can be addressed with other means, like digital signatures, data
   encryption, etc.

12.  IANA Considerations

   IANA has registered LEX namespace in the "Formal URN Namespaces"
   registry [RFC8141].

   In addition, to activate a distributed resolution system, IANA has
   registered the following NAPTR record in the URN.ARPA domain:

   lex.urn.arpa.
       IN NAPTR  100  10  ""  ""  ""  lex-nameserver.nic.it.

   Note that lex-nameserver.nic.it indicates the CNR server (see
   Section 2.2) that is responsible for the resolution of the LEX
   namespace at the time of this writing.

13.  References

13.1.  Normative References

   [ISO.8601-1.2019]
              ISO, "Date and time - Representations for information
              interchange", ISO 8601-1:2019, February 2019,
              <https://www.iso.org/standard/70907.html>.

   [ISO.8601-2.2019]
              ISO, "Data elements and interchange formats - Information
              interchange - Representation of dates and times",
              ISO 8601-2:2019, February 2019,
              <https://www.iso.org/standard/70908.html>.

   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
              <https://www.rfc-editor.org/info/rfc2045>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3404]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
              Part Four: The Uniform Resource Identifiers (URI)",
              RFC 3404, DOI 10.17487/RFC3404, October 2002,
              <https://www.rfc-editor.org/info/rfc3404>.

   [RFC3405]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
              Part Five: URI.ARPA Assignment Procedures", BCP 65,
              RFC 3405, DOI 10.17487/RFC3405, October 2002,
              <https://www.rfc-editor.org/info/rfc3405>.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
              2003, <https://www.rfc-editor.org/info/rfc3629>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/info/rfc3986>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/info/rfc5234>.

   [RFC5646]  Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
              Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
              September 2009, <https://www.rfc-editor.org/info/rfc5646>.

   [RFC5891]  Klensin, J., "Internationalized Domain Names in
              Applications (IDNA): Protocol", RFC 5891,
              DOI 10.17487/RFC5891, August 2010,
              <https://www.rfc-editor.org/info/rfc5891>.

   [RFC5893]  Alvestrand, H., Ed. and C. Karp, "Right-to-Left Scripts
              for Internationalized Domain Names for Applications
              (IDNA)", RFC 5893, DOI 10.17487/RFC5893, August 2010,
              <https://www.rfc-editor.org/info/rfc5893>.

   [RFC5894]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Background, Explanation, and
              Rationale", RFC 5894, DOI 10.17487/RFC5894, August 2010,
              <https://www.rfc-editor.org/info/rfc5894>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [RFC8141]  Saint-Andre, P. and J. Klensin, "Uniform Resource Names
              (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,
              <https://www.rfc-editor.org/info/rfc8141>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8288]  Nottingham, M., "Web Linking", RFC 8288,
              DOI 10.17487/RFC8288, October 2017,
              <https://www.rfc-editor.org/info/rfc8288>.

   [W3C.HTML] "HTML", W3C REC HTML, W3C HTML,
              <https://www.w3.org/TR/html/>.

13.2.  Informative References

   [FRAN]     Francesconi, E., "Technologies for European Integration.
              Standards-based Interoperability of Legal Information
              Systems", ISBN 978-88-8398-050-3, 2007.

   [FRBR]     International Federation of Library Associations and
              Institutions, "Functional Requirements for Bibliographic
              Records", February 2009,
              <https://www.ifla.org/files/assets/cataloguing/frbr/
              frbr_2008.pdf>.

   [HCPIL]    The European Commission, "Access to Foreign Law in Civil
              and Commercial Matters", The Hague Conference on Private
              International Law, February 2012,
              <https://assets.hcch.net/docs/b093f152-a4b3-4530-949e-
              65c1bfc9cda1.pdf>.

   [ISBD]     The Standing Committee of the IFLA Cataloguing Section 
              Berlin/Munich: De Gruyter Saur, "ISBD: International
              Standard Bibliographic Description – Consolidated
              Edition", ISBN 978-3-11-026379-4, 2011.

   [ISO.3166-1]
              ISO, "Codes for the representation of names of countries
              and their subdivisions - Part 1: Country codes, ISO
              3166-1:2020, 2020.", 2020.

   [LVI]      Peruginelli, G., Ed. and M. Ragona, Ed., "Law via the
              Internet. Free Access, Quality of Information,
              Effectiveness of Rights", ISBN 9788883980589, April 2009.

   [SART]     Sartor, G., Palmirani, M., Francesconi, E., and M.
              Biasiotti, "Legislative XML for the Semantic Web:
              Principles, Models, Standards for Document Management",
              ISBN 978-94-007-1887-6, 2011.

   [SPIN]     Spinosa, P., "Identification of Legal Documents through
              URNs (Uniform Resource Names)", Proceedings of the EuroWeb
              2001, The Web in Public Administration , 2001.

   [W3C.RDF-SCHEMA]
              Brickley, D., Ed. and R. Guha, Ed., "RDF Schema 1.1", W3C
              REC rdf-schema, W3C rdf-schema, February 2014,
              <https://www.w3.org/TR/rdf-schema/>.

Acknowledgements

   The authors wish to thank all those who provided suggestions and
   comments.

   The authors are grateful to the Legislative XML community [SART] for
   the interesting discussions on this topic and to the Working Group
   "Identification of the legal resources through URNs" of the Italian
   NormeInRete project for the guidance provided [SPIN].

   The authors owe a debt of gratitude to Tom Bruce, former director of
   the Legal Information Institute of the Cornell University Law School,
   for his contribution in revising this document and sharing fruitful
   discussions that greatly improved the document.  The authors wish to
   specially thank Marc van Opijnen (Dutch Ministry of Security and
   Justice) for his valuable comments on LEX specifications, which
   contributed to improving this document, as well as for the common
   work aimed to harmonize the ECLI and LEX specifications.  Thanks also
   to Joao Alberto de Oliveira Lima, Legislative System Analyst of the
   Brazilian Federal Senate, and to Attila Torcsvari, Information
   Management Consultant, for their detailed comments on the first draft
   versions of this document, which provided significant improvements to
   the final document.  Thanks also to Robert Richards of the Legal
   Information Institute (Cornell University Law School), promoter and
   maintainer of the Legal Informatics Research social network, as well
   as to the members of this network, for their valuable comments on
   this document.

   Finally, many thanks go to Loriana Serrotti, who significantly
   contributed to the first draft versions of this document.

Authors' Addresses

   PierLuigi Spinosa
   Via Zanardelli, 15
   50136 Firenze
   Italy
   Phone: +39 339 5614056
   Email: pierluigi.spinosa@gmail.com


   Enrico Franceseconi
   National Research Council of Italy (CNR)
   Via de' Barucci, 20
   50127 Firenze
   Italy
   Phone: +39 055 43995
   Email: enrico.francesconi@cnr.it


   Caterina Lupo
   Via San Fabiano, 25
   117 Roma
   Italy
   Phone: +39 3382632348
   Email: caterina.lupo@gmail.com
