<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" docName="draft-spinosa-urn-lex-24" number="9676" updates="" obsoletes="" category="info" submissionType="independent" tocInclude="true" xml:lang="en" symRefs="true" sortRefs="true" prepTime="2025-05-20T16:16:12" indexInclude="true" scripts="Common,Cyrillic,Hebrew,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-spinosa-urn-lex-24" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9676" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="LEX: URN Namespace for Sources of Law">LEX: A Uniform Resource Name (URN) Namespace for Sources of Law</title>
    <seriesInfo name="RFC" value="9676" stream="independent"/>
    <author initials="P." surname="Spinosa" fullname="PierLuigi Spinosa">
      <address>
        <postal>
          <street>Via Zanardelli, 15</street>
          <city>Firenze</city>
          <code>50136</code>
          <country>Italy</country>
        </postal>
        <phone>+39 339 5614056</phone>
        <email>pierluigi.spinosa@gmail.com</email>
      </address>
    </author>
    <author initials="E." surname="Francesconi" fullname="Enrico Franceseconi">
      <organization showOnFrontPage="true">National Research Council of Italy (CNR)</organization>
      <address>
        <postal>
          <street>Via de' Barucci, 20</street>
          <city>Firenze</city>
          <code>50127</code>
          <country>Italy</country>
        </postal>
        <phone>+39 055 43995</phone>
        <email>enrico.francesconi@cnr.it</email>
      </address>
    </author>
    <author initials="C." surname="Lupo" fullname="Caterina Lupo">
      <address>
        <postal>
          <street>Via San Fabiano, 25</street>
          <city>Roma</city>
          <code>117</code>
          <country>Italy</country>
        </postal>
        <phone>+39 3382632348</phone>
        <email>caterina.lupo@gmail.com</email>
      </address>
    </author>
    <date month="05" year="2025"/>
    <keyword>identifier for legal documents</keyword>
    <keyword>legislation</keyword>
    <keyword>case law</keyword>
    <keyword>administrative acts</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">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.</t>
      <t indent="0" pn="section-abstract-2">This specification is an Independent
Submission to the RFC Series. It is not a standard and does not have the
consensus of the IETF.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            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.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9676" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2025 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) 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.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-purpose-of-namespace-le">The Purpose of Namespace LEX</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.2">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.2.1"><xref derivedContent="1.2" format="counter" sectionFormat="of" target="section-1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-background">Background</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.3">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.3.1"><xref derivedContent="1.3" format="counter" sectionFormat="of" target="section-1.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-general-characteristics-of-">General Characteristics of the System</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.4">
                <t indent="0" pn="section-toc.1-1.1.2.4.1"><xref derivedContent="1.4" format="counter" sectionFormat="of" target="section-1.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-linking-a-lex-name-to-a-doc">Linking a LEX Name to a Document</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.5">
                <t indent="0" pn="section-toc.1-1.1.2.5.1"><xref derivedContent="1.5" format="counter" sectionFormat="of" target="section-1.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-use-of-lex-names-in-referen">Use of LEX Names in References</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.6">
                <t indent="0" pn="section-toc.1-1.1.2.6.1"><xref derivedContent="1.6" format="counter" sectionFormat="of" target="section-1.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-definitions">Definitions</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.7">
                <t indent="0" pn="section-toc.1-1.1.2.7.1"><xref derivedContent="1.7" format="counter" sectionFormat="of" target="section-1.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.8">
                <t indent="0" pn="section-toc.1-1.1.2.8.1"><xref derivedContent="1.8" format="counter" sectionFormat="of" target="section-1.8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-syntax-used-in-this-documen">Syntax Used in This Document</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.9">
                <t indent="0" pn="section-toc.1-1.1.2.9.1"><xref derivedContent="1.9" format="counter" sectionFormat="of" target="section-1.9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-namespace-registration">Namespace Registration</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-registration-of-lex">Registration of LEX</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2">
              <li pn="section-toc.1-1.2.2.1">
                <t indent="0" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-identifier-structure">Identifier Structure</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.2">
                <t indent="0" pn="section-toc.1-1.2.2.2.1"><xref derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-jurisdiction-code-registry">Jurisdiction-Code Registry</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.3">
                <t indent="0" pn="section-toc.1-1.2.2.3.1"><xref derivedContent="2.3" format="counter" sectionFormat="of" target="section-2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-conformance-with-urn-syntax">Conformance with URN Syntax</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.4">
                <t indent="0" pn="section-toc.1-1.2.2.4.1"><xref derivedContent="2.4" format="counter" sectionFormat="of" target="section-2.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-validation-mechanism">Validation Mechanism</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.5">
                <t indent="0" pn="section-toc.1-1.2.2.5.1"><xref derivedContent="2.5" format="counter" sectionFormat="of" target="section-2.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-scope">Scope</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-general-syntax-and-features">General Syntax and Features of the LEX Identifier</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-allowed-and-not-allowed-cha">Allowed and Not Allowed Characters</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-reserved-characters">Reserved Characters</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.3">
                <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-case-sensitivity">Case Sensitivity</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.4">
                <t indent="0" pn="section-toc.1-1.3.2.4.1"><xref derivedContent="3.4" format="counter" sectionFormat="of" target="section-3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-unicode-characters-outside-">Unicode Characters Outside the ASCII Range</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.5">
                <t indent="0" pn="section-toc.1-1.3.2.5.1"><xref derivedContent="3.5" format="counter" sectionFormat="of" target="section-3.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-abbreviations">Abbreviations</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.6">
                <t indent="0" pn="section-toc.1-1.3.2.6.1"><xref derivedContent="3.6" format="counter" sectionFormat="of" target="section-3.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-date-format">Date Format</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-specific-syntax-and-feature">Specific Syntax and Features of the LEX Identifier</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-spaces-connectives-and-punc">Spaces, Connectives, and Punctuation Marks</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-acronyms">Acronyms</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ordinal-numbers">Ordinal Numbers</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-creation-of-the-source-of-l">Creation of the Source of Law LEX Identifier: Baseline Structure</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-basic-principles">Basic Principles</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-model-of-sources-of-law-rep">Model of Sources of Law Representation</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.3">
                <t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-structure-of-the-local-name">Structure of the Local-Name</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.4">
                <t indent="0" pn="section-toc.1-1.5.2.4.1"><xref derivedContent="5.4" format="counter" sectionFormat="of" target="section-5.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-structure-of-the-document-i">Structure of the Document Identifier at "Work" Level</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.5">
                <t indent="0" pn="section-toc.1-1.5.2.5.1"><xref derivedContent="5.5" format="counter" sectionFormat="of" target="section-5.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-aliases">Aliases</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.6">
                <t indent="0" pn="section-toc.1-1.5.2.6.1"><xref derivedContent="5.6" format="counter" sectionFormat="of" target="section-5.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-structure-of-the-document-id">Structure of the Document Identifier at "Expression" Level</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.7">
                <t indent="0" pn="section-toc.1-1.5.2.7.1"><xref derivedContent="5.7" format="counter" sectionFormat="of" target="section-5.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-structure-of-the-document-ide">Structure of the Document Identifier at "Manifestation" Level</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.8">
                <t indent="0" pn="section-toc.1-1.5.2.8.1"><xref derivedContent="5.8" format="counter" sectionFormat="of" target="section-5.8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sources-of-law-references">Sources of Law References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-specific-syntax-of-the-iden">Specific Syntax of the Identifier at "Work" Level</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-authority-element">The Authority Element</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2.1.2">
                  <li pn="section-toc.1-1.6.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.6.2.1.2.1.1"><xref derivedContent="6.1.1" format="counter" sectionFormat="of" target="section-6.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-indication-of-the-authority">Indication of the Authority</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.1.2.2">
                    <t indent="0" pn="section-toc.1-1.6.2.1.2.2.1"><xref derivedContent="6.1.2" format="counter" sectionFormat="of" target="section-6.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-multiple-issuers">Multiple Issuers</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.1.2.3">
                    <t indent="0" pn="section-toc.1-1.6.2.1.2.3.1"><xref derivedContent="6.1.3" format="counter" sectionFormat="of" target="section-6.1.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-indication-of-the-issuer">Indication of the Issuer</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.1.2.4">
                    <t indent="0" pn="section-toc.1-1.6.2.1.2.4.1"><xref derivedContent="6.1.4" format="counter" sectionFormat="of" target="section-6.1.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-indication-of-the-body">Indication of the Body</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.1.2.5">
                    <t indent="0" pn="section-toc.1-1.6.2.1.2.5.1"><xref derivedContent="6.1.5" format="counter" sectionFormat="of" target="section-6.1.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-indication-of-the-function">Indication of the Function</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.1.2.6">
                    <t indent="0" pn="section-toc.1-1.6.2.1.2.6.1"><xref derivedContent="6.1.6" format="counter" sectionFormat="of" target="section-6.1.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-conventions-for-the-authori">Conventions for the Authority</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-measure-element">The Measure Element</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2.2.2">
                  <li pn="section-toc.1-1.6.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.6.2.2.2.1.1"><xref derivedContent="6.2.1" format="counter" sectionFormat="of" target="section-6.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-criteria-for-the-indication">Criteria for the Indication of the Type of Measure</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.6.2.2.2.2.1"><xref derivedContent="6.2.2" format="counter" sectionFormat="of" target="section-6.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-further-specification-to-th">Further Specification to the Type of Measure</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.2.2.3">
                    <t indent="0" pn="section-toc.1-1.6.2.2.2.3.1"><xref derivedContent="6.2.3" format="counter" sectionFormat="of" target="section-6.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-aliases-for-sources-of-law-">Aliases for Sources of Law with Different Normative References</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.2.2.4">
                    <t indent="0" pn="section-toc.1-1.6.2.2.2.4.1"><xref derivedContent="6.2.4" format="counter" sectionFormat="of" target="section-6.2.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-relations-between-measure-a">Relations Between Measure and Authority in the Aliases</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.6.2.3">
                <t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-details-element">The Details Element</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2.3.2">
                  <li pn="section-toc.1-1.6.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.6.2.3.2.1.1"><xref derivedContent="6.3.1" format="counter" sectionFormat="of" target="section-6.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-indication-of-the-details">Indication of the Details</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.3.2.2">
                    <t indent="0" pn="section-toc.1-1.6.2.3.2.2.1"><xref derivedContent="6.3.2" format="counter" sectionFormat="of" target="section-6.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-multiple-dates">Multiple Dates</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.3.2.3">
                    <t indent="0" pn="section-toc.1-1.6.2.3.2.3.1"><xref derivedContent="6.3.3" format="counter" sectionFormat="of" target="section-6.3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-unnumbered-measures">Unnumbered Measures</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.3.2.4">
                    <t indent="0" pn="section-toc.1-1.6.2.3.2.4.1"><xref derivedContent="6.3.4" format="counter" sectionFormat="of" target="section-6.3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-multiple-numbers">Multiple Numbers</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.6.2.4">
                <t indent="0" pn="section-toc.1-1.6.2.4.1"><xref derivedContent="6.4" format="counter" sectionFormat="of" target="section-6.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-annex-element">The Annex Element</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2.4.2">
                  <li pn="section-toc.1-1.6.2.4.2.1">
                    <t indent="0" pn="section-toc.1-1.6.2.4.2.1.1"><xref derivedContent="6.4.1" format="counter" sectionFormat="of" target="section-6.4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-formal-annexes">Formal Annexes</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.4.2.2">
                    <t indent="0" pn="section-toc.1-1.6.2.4.2.2.1"><xref derivedContent="6.4.2" format="counter" sectionFormat="of" target="section-6.4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-annexes-of-annexes">Annexes of Annexes</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-specific-syntax-of-the-vers">Specific Syntax of the Version Element of the "Expression"</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-version-element">The Version Element</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2.1.2">
                  <li pn="section-toc.1-1.7.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.7.2.1.2.1.1"><xref derivedContent="7.1.1" format="counter" sectionFormat="of" target="section-7.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-different-versions-of-a-leg">Different Versions of a Legislative Document</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.1.2.2">
                    <t indent="0" pn="section-toc.1-1.7.2.1.2.2.1"><xref derivedContent="7.1.2" format="counter" sectionFormat="of" target="section-7.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-identification-of-the-versi">Identification of the Version</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-summary-of-the-syntax-of-th">Summary of the Syntax of the Uniform Names of the LEX Namespace</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-procedure-of-uniform-names-">Procedure of Uniform Names Assignment</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2">
              <li pn="section-toc.1-1.9.2.1">
                <t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-specifying-the-jurisdiction">Specifying the Jurisdiction Element of the LEX Identifier</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.2">
                <t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent="9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-jurisdictional-registrar-fo">Jurisdictional Registrar for Names Assignment</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.3">
                <t indent="0" pn="section-toc.1-1.9.2.3.1"><xref derivedContent="9.3" format="counter" sectionFormat="of" target="section-9.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-identifier-uniqueness">Identifier Uniqueness</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.4">
                <t indent="0" pn="section-toc.1-1.9.2.4.1"><xref derivedContent="9.4" format="counter" sectionFormat="of" target="section-9.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-identifier-persistence-cons">Identifier Persistence Considerations</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-recommendations-for-the-res">Recommendations for the Resolution Process</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.10.2">
              <li pn="section-toc.1-1.10.2.1">
                <t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent="10.1" format="counter" sectionFormat="of" target="section-10.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-general-architecture-of-the">General Architecture of the System</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.2">
                <t indent="0" pn="section-toc.1-1.10.2.2.1"><xref derivedContent="10.2" format="counter" sectionFormat="of" target="section-10.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-catalogues-for-resolution">Catalogues for Resolution</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.3">
                <t indent="0" pn="section-toc.1-1.10.2.3.1"><xref derivedContent="10.3" format="counter" sectionFormat="of" target="section-10.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-suggested-resolver-behavior">Suggested Resolver Behavior</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12" format="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.13">
            <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="13" format="counter" sectionFormat="of" target="section-13"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.13.2">
              <li pn="section-toc.1-1.13.2.1">
                <t indent="0" pn="section-toc.1-1.13.2.1.1"><xref derivedContent="13.1" format="counter" sectionFormat="of" target="section-13.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.13.2.2">
                <t indent="0" pn="section-toc.1-1.13.2.2.1"><xref derivedContent="13.2" format="counter" sectionFormat="of" target="section-13.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.14">
            <t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.15">
            <t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <section anchor="the-purpose-of-namespace-lex" numbered="true" removeInRFC="false" toc="include" pn="section-1.1">
        <name slugifiedName="name-the-purpose-of-namespace-le">The Purpose of Namespace LEX</name>
        <t indent="0" pn="section-1.1-1">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.</t>
        <t indent="0" pn="section-1.1-2">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.</t>
        <t indent="0" pn="section-1.1-3">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
<xref target="RFC3986" format="default" sectionFormat="of" derivedContent="RFC3986"/>.</t>
      </section>
      <section anchor="background" numbered="true" removeInRFC="false" toc="include" pn="section-1.2">
        <name slugifiedName="name-background">Background</name>
        <t indent="0" pn="section-1.2-1">This specification of a unique identifier for legal documents
follows a number of initiatives in the field of legal document
management.</t>
        <t indent="0" pn="section-1.2-2">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.</t>
        <t indent="0" pn="section-1.2-3">Other national initiatives in Europe introduced standards for the
description of legal sources <xref target="FRAN" format="default" sectionFormat="of" derivedContent="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
<xref target="FRAN" format="default" sectionFormat="of" derivedContent="FRAN"/>.  
	Several of these identifiers are based on a URN schema.</t>
        <t indent="0" pn="section-1.2-4">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.</t>
        <t indent="0" pn="section-1.2-5">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 <xref target="LVI" format="default" sectionFormat="of" derivedContent="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 <xref target="HCPIL" format="default" sectionFormat="of" derivedContent="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.</t>
        <t indent="0" pn="section-1.2-6">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.</t>
        <t indent="0" pn="section-1.2-7">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.</t>
        <t indent="0" pn="section-1.2-8">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.</t>
        <t indent="0" pn="section-1.2-9">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 <xref target="FRBR" format="default" sectionFormat="of" derivedContent="FRBR"/> sense (see <xref target="src-law" format="default" sectionFormat="of" derivedContent="Section 5.2"/>),
of a legal document (that is, there is more than one manifestation (see <xref target="src-law" format="default" sectionFormat="of" derivedContent="Section 5.2"/>) of 
the same legal document).</t>
        <t indent="0" pn="section-1.2-10">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.</t>
        <t indent="0" pn="section-1.2-11">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.</t>
      </section>
      <section anchor="general-characteristics-of-the-system" numbered="true" removeInRFC="false" toc="include" pn="section-1.3">
        <name slugifiedName="name-general-characteristics-of-">General Characteristics of the System</name>
        <t indent="0" pn="section-1.3-1">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:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1.3-2">
          <li pn="section-1.3-2.1">
            <t indent="0" pn="section-1.3-2.1.1">globally unique</t>
          </li>
          <li pn="section-1.3-2.2">
            <t indent="0" pn="section-1.3-2.2.1">transparent</t>
          </li>
          <li pn="section-1.3-2.3">
            <t indent="0" pn="section-1.3-2.3.1">reversible</t>
          </li>
          <li pn="section-1.3-2.4">
            <t indent="0" pn="section-1.3-2.4.1">persistent</t>
          </li>
          <li pn="section-1.3-2.5">
            <t indent="0" pn="section-1.3-2.5.1">location-independent</t>
          </li>
          <li pn="section-1.3-2.6">
            <t indent="0" pn="section-1.3-2.6.1">language-neutral</t>
          </li>
        </ul>
        <t indent="0" pn="section-1.3-3">These qualities facilitate management of legal documents and
a mechanism for stable cross-collection and cross-country
references.</t>
        <t indent="0" pn="section-1.3-4">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).</t>
        <t indent="0" pn="section-1.3-5">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.</t>
        <t indent="0" pn="section-1.3-6">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.</t>
        <t indent="0" pn="section-1.3-7">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.</t>
        <t indent="0" pn="section-1.3-8">The identification system based on uniform names includes:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1.3-9">
          <li pn="section-1.3-9.1">
            <t indent="0" pn="section-1.3-9.1.1">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).</t>
          </li>
          <li pn="section-1.3-9.2">
            <t indent="0" pn="section-1.3-9.2.1">A resolution mechanism -- in a distributed environment -- that ties a
uniform name to the online location of the corresponding
resource(s).</t>
          </li>
        </ul>
        <t indent="0" pn="section-1.3-10">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.</t>
      </section>
      <section anchor="linking-a-lex-name-to-a-document" numbered="true" removeInRFC="false" toc="include" pn="section-1.4">
        <name slugifiedName="name-linking-a-lex-name-to-a-doc">Linking a LEX Name to a Document</name>
        <t indent="0" pn="section-1.4-1">The LEX name is linked to the document through metadata, which
may be specified as follows:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1.4-2">
          <li pn="section-1.4-2.1">
            <t indent="0" pn="section-1.4-2.1.1">Within the document itself through a specific element within
an XML schema or by a meta tag <xref target="W3C.HTML" format="default" sectionFormat="of" derivedContent="W3C.HTML"/>.</t>
          </li>
          <li pn="section-1.4-2.2">
            <t indent="0" pn="section-1.4-2.2.1">Externally by means of a Resource Description Framework <xref target="W3C.RDF-SCHEMA" format="default" sectionFormat="of" derivedContent="W3C.RDF-SCHEMA"/>
triple, a specific attribute in a database, etc.</t>
          </li>
        </ul>
        <t indent="0" pn="section-1.4-3">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.</t>
      </section>
      <section anchor="use-of-lex-names-in-references" numbered="true" removeInRFC="false" toc="include" pn="section-1.5">
        <name slugifiedName="name-use-of-lex-names-in-referen">Use of LEX Names in References</name>
        <t indent="0" pn="section-1.5-1">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:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1.5-2">
          <li pn="section-1.5-2.1">
            <t indent="0" pn="section-1.5-2.1.1">Manually inserting the link with the                                                   
uniform name in the referring document. This is a burdensome procedure, especially for
documents that are already online.</t>
          </li>
          <li pn="section-1.5-2.2">
            <t indent="0" pn="section-1.5-2.2.1">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.</t>
          </li>
        </ul>
        <t indent="0" pn="section-1.5-3">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.</t>
      </section>
      <section anchor="definitions" numbered="true" removeInRFC="false" toc="include" pn="section-1.6">
        <name slugifiedName="name-definitions">Definitions</name>
        <t indent="0" pn="section-1.6-1">The following terms are used in this document:
        </t>
        <dl spacing="normal" indent="3" newline="false" pn="section-1.6-2">
          <dt pn="section-1.6-2.1">Source of Law:</dt>
          <dd pn="section-1.6-2.2">
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.</dd>
          <dt pn="section-1.6-2.3">Jurisdictional Registrar:</dt>
          <dd pn="section-1.6-2.4">
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.</dd>
        </dl>
      </section>
      <section anchor="terminology" numbered="true" removeInRFC="false" toc="include" pn="section-1.7">
        <name slugifiedName="name-terminology">Terminology</name>
        <t indent="0" pn="section-1.7-1">
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
        </t>
      </section>
      <section anchor="syntax-used-in-this-document" numbered="true" removeInRFC="false" toc="include" pn="section-1.8">
        <name slugifiedName="name-syntax-used-in-this-documen">Syntax Used in This Document</name>
        <t indent="0" pn="section-1.8-1">This document uses a syntax that is based on the Augmented
        Backus-Naur Form (ABNF) <xref target="RFC5234" format="default" sectionFormat="of" derivedContent="RFC5234"/> meta-language, which
        is used in many RFCs.</t>
      </section>
      <section anchor="namespace-registration" numbered="true" removeInRFC="false" toc="include" pn="section-1.9">
        <name slugifiedName="name-namespace-registration">Namespace Registration</name>
        <t indent="0" pn="section-1.9-1">The LEX namespace has been registered in the "Formal URN
Namespaces" registry. See <xref target="iana" format="default" sectionFormat="of" derivedContent="Section 12"/>.</t>
      </section>
    </section>
    <section anchor="registration-of-lex" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-registration-of-lex">Registration of LEX</name>
      <section anchor="identifier-structure" numbered="true" removeInRFC="false" toc="include" pn="section-2.1">
        <name slugifiedName="name-identifier-structure">Identifier Structure</name>
        <t indent="0" pn="section-2.1-1">The identifier has the following hierarchical structure:</t>
        <sourcecode type="abnf" markers="false" pn="section-2.1-2">
   "urn:lex:" NSS
</sourcecode>
        <t indent="0" pn="section-2.1-3">where NSS is the Namespace Specific String composed as follows:</t>
        <sourcecode type="abnf" markers="false" pn="section-2.1-4">
   NSS = jurisdiction ":" local-name
</sourcecode>
        <t indent="0" pn="section-2.1-5">where:</t>
        <dl newline="false" spacing="normal" indent="3" pn="section-2.1-6">
          <dt pn="section-2.1-6.1">jurisdiction:</dt>
          <dd pn="section-2.1-6.2">
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).</dd>
          <dt pn="section-2.1-6.3">local-name:</dt>
          <dd pn="section-2.1-6.4">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.).</dd>
        </dl>
        <t indent="0" pn="section-2.1-7">The jurisdiction element is composed of two specific fields:</t>
        <sourcecode type="abnf" markers="false" pn="section-2.1-8">
   jurisdiction = jurisdiction-code *(";" jurisdiction-unit)
</sourcecode>
        <t indent="0" pn="section-2.1-9">where:</t>
        <dl newline="false" spacing="normal" indent="3" pn="section-2.1-10">
          <dt pn="section-2.1-10.1">jurisdiction-code:</dt>
          <dd pn="section-2.1-10.2">
            <t indent="0" pn="section-2.1-10.2.1">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 <xref target="jur-cod-regist" format="default" sectionFormat="of" derivedContent="Section 2.2"/>).</t>
            <t indent="0" pn="section-2.1-10.2.2">Due to the differences in representation in the various
	    languages of a country, the use of the standard <xref target="ISO.3166-1" format="default" sectionFormat="of" derivedContent="ISO.3166-1"/> is
	    strongly <bcp14>RECOMMENDED</bcp14> 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 <xref target="non-ascii-char" format="default" sectionFormat="of" derivedContent="Section 3.4"/>).</t>
            <t indent="0" pn="section-2.1-10.2.3">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 <xref target="jur-cod-regist" format="default" sectionFormat="of" derivedContent="Section 2.2"/>).  Examples reported in this document are
hypothetical and assume that the corresponding domain name is used for the
jurisdiction-code.</t>
          </dd>
          <dt pn="section-2.1-10.3">jurisdiction-unit:</dt>
          <dd pn="section-2.1-10.4">
            <t indent="0" pn="section-2.1-10.4.1">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:</t>
            <ul empty="true" spacing="compact" bare="false" indent="3" pn="section-2.1-10.4.2">
              <li pn="section-2.1-10.4.2.1">"br:governo:decreto" (decree of federal government),</li>
              <li pn="section-2.1-10.4.2.2">"br;sao.paulo:governo:decreto" (decree of São (SU+00E3o) Paulo state)</li>
              <li pn="section-2.1-10.4.2.3">"br;sao.paulo;campinas:governo:decreto" (decree of Campinas municipality).</li>
            </ul>
          </dd>
        </dl>
        <t indent="0" pn="section-2.1-11">The following are fictitious examples of sources of law identifiers:</t>
        <artwork align="left" pn="section-2.1-12">
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)
</artwork>
      </section>
      <section anchor="jur-cod-regist" numbered="true" removeInRFC="false" toc="include" pn="section-2.2">
        <name slugifiedName="name-jurisdiction-code-registry">Jurisdiction-Code Registry</name>
        <t indent="0" pn="section-2.2-1">A new jurisdiction-code registry has been created. Note that this
        is a CNR registry and <strong>not</strong> an IANA registry.</t>
        <t indent="0" pn="section-2.2-2">Each
        entry contains the following elements:</t>
        <dl spacing="normal" indent="3" newline="false" pn="section-2.2-3">
          <dt pn="section-2.2-3.1">jurisdiction-code:</dt>
          <dd pn="section-2.2-3.2">The identifier assigned to the jurisdiction
(i.e., to the country or organization).</dd>
          <dt pn="section-2.2-3.3">jurisdiction:</dt>
          <dd pn="section-2.2-3.4">The official name of the jurisdiction (i.e., the country or organization).</dd>
          <dt pn="section-2.2-3.5">registrant:</dt>
          <dd pn="section-2.2-3.6">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 <bcp14>RECOMMENDED</bcp14> that each jurisdiction
create a registry of all delegated levels so that the organization
responsible for each sub-zone can easily be identified.</dd>
          <dt pn="section-2.2-3.7">reference:</dt>
          <dd pn="section-2.2-3.8">A reference to the defining document (if any).</dd>
        </dl>
        <t indent="0" pn="section-2.2-4">The table, available at the address lex-urn.nic.it, is initially empty. The registry is initially empty. The following are possible example entries:</t>
        <artwork align="left" pn="section-2.2-5">
"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\]
</artwork>
        <t indent="0" pn="section-2.2-6">CNR is responsible for the
jurisdiction-code and the root lex-nameserver.nic.it registries of the resolution
routing.</t>
        <t indent="0" pn="section-2.2-7">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.</t>
        <t indent="0" pn="section-2.2-8">The adopted registration policy is similar to that of the "Expert Review"
policy specified in <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>. The designated expert(s) will assign
jurisdiction-codes based on the following principles:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2.2-9">
          <li pn="section-2.2-9.1">
            <t indent="0" pn="section-2.2-9.1.1">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.</t>
          </li>
          <li pn="section-2.2-9.2">
            <t indent="0" pn="section-2.2-9.2.1">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.</t>
          </li>
          <li pn="section-2.2-9.3">
            <t indent="0" pn="section-2.2-9.3.1">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.</t>
          </li>
        </ul>
        <t indent="0" pn="section-2.2-10">Jurisdiction-codes <bcp14>MUST NOT</bcp14> be renamed, because that
would violate the rule that URN assignments be persistent.</t>
        <t indent="0" pn="section-2.2-11">Jurisdiction-codes <bcp14>MUST NOT</bcp14> 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).</t>
        <t indent="0" pn="section-2.2-12">Designated expert(s) can unilaterally initiate allocation or
obsolescence of a jurisdiction-code.</t>
        <t indent="0" pn="section-2.2-13">Requests for new jurisdiction-code assignments must include
the organization or country requesting it and contact information (email)
of who requested the assignment.</t>
      </section>
      <section anchor="conformance-with-urn-syntax" numbered="true" removeInRFC="false" toc="include" pn="section-2.3">
        <name slugifiedName="name-conformance-with-urn-syntax">Conformance with URN Syntax</name>
        <t indent="0" pn="section-2.3-1">The LEX namespace identifier (NID) syntax conforms to
<xref target="RFC8141" format="default" sectionFormat="of" derivedContent="RFC8141"/>. However, a series of characters are reserved for identifying
elements or sub-elements, or for future extensions of the LEX naming
convention (see <xref target="res-chars" format="default" sectionFormat="of" derivedContent="Section 3.2"/>).</t>
      </section>
      <section anchor="validation-mechanism" numbered="true" removeInRFC="false" toc="include" pn="section-2.4">
        <name slugifiedName="name-validation-mechanism">Validation Mechanism</name>
        <t indent="0" pn="section-2.4-1">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).</t>
      </section>
      <section anchor="scope" numbered="true" removeInRFC="false" toc="include" pn="section-2.5">
        <name slugifiedName="name-scope">Scope</name>
        <t indent="0" pn="section-2.5-1">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.</t>
      </section>
    </section>
    <section anchor="general-syntax-and-features-of-the-lex-identifier" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-general-syntax-and-features">General Syntax and Features of the LEX Identifier</name>
      <t indent="0" pn="section-3-1">This section lists the general features applicable to all
jurisdictions.</t>
      <section anchor="allowed-and-not-allowed-characters" numbered="true" removeInRFC="false" toc="include" pn="section-3.1">
        <name slugifiedName="name-allowed-and-not-allowed-cha">Allowed and Not Allowed Characters</name>
        <t indent="0" pn="section-3.1-1">The characters are defined in accordance with <xref target="RFC8141" format="default" sectionFormat="of" derivedContent="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.</t>
        <t indent="0" pn="section-3.1-2">For the full syntax of the uniform names in the LEX space, please
see <xref target="urn-lex-syn" format="default" sectionFormat="of" derivedContent="Section 8"/>.</t>
      </section>
      <section anchor="res-chars" numbered="true" removeInRFC="false" toc="include" pn="section-3.2">
        <name slugifiedName="name-reserved-characters">Reserved Characters</name>
        <t indent="0" pn="section-3.2-1">The following characters are reserved in the specific LEX
namespace:</t>
        <dl indent="6" newline="false" spacing="normal" pn="section-3.2-2">
          <dt pn="section-3.2-2.1">"@"</dt>
          <dd pn="section-3.2-2.2">Separator of the expression that contains information on 
    version and language.</dd>
          <dt pn="section-3.2-2.3">"$"</dt>
          <dd pn="section-3.2-2.4">Separator of the manifestation that contains information on
    format, editor, etc.</dd>
          <dt pn="section-3.2-2.5">":"</dt>
          <dd pn="section-3.2-2.6">Separator of the main elements of the name at any entity.</dd>
          <dt pn="section-3.2-2.7">";"</dt>
          <dd pn="section-3.2-2.8">Separator of the level. It identifies the introduction of an element
    at a hierarchically lower level or the introduction of a 
    specification.</dd>
          <dt pn="section-3.2-2.9">"+"</dt>
          <dd pn="section-3.2-2.10">Separator of the repetitions of an entire main element (e.g.,
    multiple authorities).</dd>
          <dt pn="section-3.2-2.11">"|"</dt>
          <dd pn="section-3.2-2.12">Separator between different formats of the same element (e.g.,
    date).</dd>
          <dt pn="section-3.2-2.13">","</dt>
          <dd pn="section-3.2-2.14">Separator of the repetitions of individual components in the main
    elements, each bearing the same level of specificity (e.g.,
    multiple numbers).</dd>
          <dt pn="section-3.2-2.15">"~"</dt>
          <dd pn="section-3.2-2.16">Separator of the partition identifier in references (e.g.,
    paragraph of an article).</dd>
          <dt pn="section-3.2-2.17">"*"</dt>
          <dd pn="section-3.2-2.18">Reserved for future expansions.</dd>
          <dt pn="section-3.2-2.19">"!"</dt>
          <dd pn="section-3.2-2.20">Reserved for future expansions.</dd>
        </dl>
        <t indent="0" pn="section-3.2-3">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 <xref target="annex-formal" format="default" sectionFormat="of" derivedContent="Section 6.4.1"/>).</t>
      </section>
      <section anchor="case-sensitivity" numbered="true" removeInRFC="false" toc="include" pn="section-3.3">
        <name slugifiedName="name-case-sensitivity">Case Sensitivity</name>
        <t indent="0" pn="section-3.3-1">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
        <bcp14>RECOMMENDED</bcp14> that names be created in
        lower case, but names that differ only in case or in the spelling of
        the same word <bcp14>MUST</bcp14> be considered equivalent
        (e.g., "Ministry" will be recorded as "ministry").</t>
      </section>
      <section anchor="non-ascii-char" numbered="true" removeInRFC="false" toc="include" pn="section-3.4">
        <name slugifiedName="name-unicode-characters-outside-">Unicode Characters Outside the ASCII Range</name>
        <t indent="0" pn="section-3.4-1">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 <bcp14>RECOMMENDED</bcp14> 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").</t>
        <t indent="0" pn="section-3.4-2">This mapping consists of:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.4-3">
          <li pn="section-3.4-3.1">
            <t indent="0" pn="section-3.4-3.1.1">Transcription from non-Latin alphabets</t>
          </li>
          <li pn="section-3.4-3.2">
            <t indent="0" pn="section-3.4-3.2.1">Transliteration of some signs (e.g., diaeresis and eszett)</t>
          </li>
          <li pn="section-3.4-3.3">
            <t indent="0" pn="section-3.4-3.3.1">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)</t>
          </li>
        </ul>
        <t indent="0" pn="section-3.4-4">The most suitable, well-known, and widespread mapping system for a given
language <bcp14>MUST</bcp14> 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.</t>
        <t indent="0" pn="section-3.4-5">If this conversion is not acceptable by a specific jurisdiction or
        it is not available in a given language, Unicode <bcp14>MUST</bcp14>
        be used, and for accessing network protocols, any Unicode code points
        outside the ASCII range <bcp14>MUST</bcp14> be converted to UTF-8
        percent-encoding according to <xref target="RFC3986" format="default" sectionFormat="of" derivedContent="RFC3986"/> and <xref target="RFC3629" format="default" sectionFormat="of" derivedContent="RFC3629"/> .</t>
        <t indent="0" pn="section-3.4-6">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:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.4-7">
          <li pn="section-3.4-7.1">
            <t indent="0" pn="section-3.4-7.1.1">Convert non-ASCII characters within the DNS into IDN
encoding using Punycode translation <xref target="RFC5894" format="default" sectionFormat="of" derivedContent="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.</t>
          </li>
          <li pn="section-3.4-7.2">
            <t indent="0" pn="section-3.4-7.2.1">Create a routing service relying on a software, outside of the DNS,
that addresses a proper resolution service.</t>
          </li>
        </ul>
        <t indent="0" pn="section-3.4-8">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 <xref target="RFC5893" format="default" sectionFormat="of" derivedContent="RFC5893"/>.</t>
        <t indent="0" pn="section-3.4-9">The preferred order is summarized as follows:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.4-10">
          <li pn="section-3.4-10.1">
            <t indent="0" pn="section-3.4-10.1.1">Conversion into basic ASCII is the <bcp14>RECOMMENDED</bcp14> solution (because
      conversions for network protocols and the DNS are not needed).</t>
          </li>
          <li pn="section-3.4-10.2">
            <t indent="0" pn="section-3.4-10.2.1">Using Unicode and converting to UTF-8 percent-encoding <xref target="RFC3629" format="default" sectionFormat="of" derivedContent="RFC3629"/> for accessing network protocols 
and to Punycode <xref target="RFC5894" format="default" sectionFormat="of" derivedContent="RFC5894"/> only for navigation in DNS via software interface.</t>
          </li>
          <li pn="section-3.4-10.3">
            <t indent="0" pn="section-3.4-10.3.1">Creation of a routing service relying on a software outside of DNS
and addressing a proper resolution service.</t>
          </li>
        </ul>
        <t indent="0" pn="section-3.4-11">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.</t>
        <t indent="0" pn="section-3.4-12">The following are two examples (Latin and Cyrillic alphabets) relating to the different
solutions adopted:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.4-13">
          <li pn="section-3.4-13.1">
            <t indent="0" pn="section-3.4-13.1.1">A circular adopted by the Municipality of Munich (Rundschreiben der
Stadt "München" (MU+00FCnchen)):</t>
            <artwork align="left" pn="section-3.4-13.1.2">
- 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:...
</artwork>
          </li>
          <li pn="section-3.4-13.2">
            <t indent="0" pn="section-3.4-13.2.1">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)):</t>
            <artwork align="left" pn="section-3.4-13.2.2">
- 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:...
</artwork>
          </li>
        </ul>
      </section>
      <section anchor="abbreviations" numbered="true" removeInRFC="false" toc="include" pn="section-3.5">
        <name slugifiedName="name-abbreviations">Abbreviations</name>
        <t indent="0" pn="section-3.5-1">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 <bcp14>RECOMMENDED</bcp14>
(e.g., "Min." is expanded as "ministry").</t>
      </section>
      <section anchor="dat-form" numbered="true" removeInRFC="false" toc="include" pn="section-3.6">
        <name slugifiedName="name-date-format">Date Format</name>
        <t indent="0" pn="section-3.6-1"><xref target="ISO.8601-1.2019" format="default" sectionFormat="of" derivedContent="ISO.8601-1.2019"/> and <xref target="ISO.8601-2.2019" format="default" sectionFormat="of" derivedContent="ISO.8601-2.2019"/> describe the international format for representing dates. Dates <bcp14>MUST</bcp14> always be represented in this format (4 digits for the year, 
2 digits for the month, and 2 digits for the day):</t>
        <sourcecode type="abnf" markers="false" pn="section-3.6-2">
    date-iso = year "-" month "-" day
</sourcecode>
        <t indent="0" pn="section-3.6-3">For example, "September 2, 99" will be written as "1999-09-02".</t>
        <t indent="0" pn="section-3.6-4">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:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.6-5">
          <li pn="section-3.6-5.1">
            <t indent="0" pn="section-3.6-5.1.1">in Hebrew characters (21 Elul 5759):</t>
            <artwork align="left" pn="section-3.6-5.1.2">כ״א-בֶּאֱלוּל-תשנ״ט
</artwork>
            <t indent="0" pn="section-3.6-5.1.3">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.</t>
          </li>
          <li pn="section-3.6-5.2">
            <t indent="0" pn="section-3.6-5.2.1">in U+ notation:</t>
            <artwork align="left" pn="section-3.6-5.2.2">
U+05D8U+05F4U+05E0U+05E9U+05EAU+002DU+05DCU+05D5U+05BCU+05DC
U+05D0U+05B1U+05D1U+05B6U+05BCU+002DU+05D0U+05F4U+05DB
</artwork>
          </li>
          <li pn="section-3.6-5.3">
            <t indent="0" pn="section-3.6-5.3.1">in UTF-8 code:</t>
            <artwork align="left" pn="section-3.6-5.3.2">
%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
</artwork>
          </li>
        </ul>
        <t indent="0" pn="section-3.6-6">Therefore, for all the dates in the LEX URN identifier 
(see Sections <xref target="det-elem" format="counter" sectionFormat="of" derivedContent="6.3"/> and <xref target="ide-vers" format="counter" sectionFormat="of" derivedContent="7.1.2"/>),
it is possible to indicate the date in the local format:</t>
        <sourcecode type="abnf" markers="false" pn="section-3.6-7">
    date = date-iso ["|" date-loc]
</sourcecode>
        <t indent="0" pn="section-3.6-8">For example, 1999-09-02 will be written in<br/> 
ISO plus Hebrew format as:
<tt>1999-09-02|כ״א-בֶּאֱלוּל-תשנ״ט</tt>
which is to be converted into UTF-8 for network protocols and for resolution (see <xref target="non-ascii-char" format="default" sectionFormat="of" derivedContent="Section 3.4"/>). The characters that are not allowed (e.g., "/") or reserved (e.g., ",") cannot exist 
inside the date-loc and therefore <bcp14>MUST</bcp14> be turned into ".". To be aligned with ISO format, any blank between day, month, and year <bcp14>MUST</bcp14> be converted into "-".</t>
        <t indent="0" pn="section-3.6-9">In the above Hebrew character examples, the sequence of characters<br/>
is <u format="lit-name-num" pn="u-1">כ</u>, <u format="lit-name-num" pn="u-2">״</u>, <u format="lit-name-num" pn="u-3">א</u>, <u format="lit-name-num" pn="u-4">-</u>, <u format="lit-name-num" pn="u-5">בֶּ</u>, <u format="lit-name-num" pn="u-6">אֱ</u>, <u format="lit-name-num" pn="u-7">ל</u>, <u format="lit-name-num" pn="u-8">וּ</u>, <u format="lit-name-num" pn="u-9">ל</u>, <u format="lit-name-num" pn="u-10">-</u>, <u format="lit-name-num" pn="u-11">ת</u>, <u format="lit-name-num" pn="u-12">ש</u>, <u format="lit-name-num" pn="u-13">נ</u>, <u format="lit-name-num" pn="u-14">״</u>, and <u format="lit-name-num" pn="u-15">ט</u>.</t>
      </section>
    </section>
    <section anchor="specific-syntax-and-features-of-the-lex-identifier" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-specific-syntax-and-feature">Specific Syntax and Features of the LEX Identifier</name>
      <t indent="0" pn="section-4-1"> This section discusses features related to specific
      jurisdictions. The implementation of these features is
      <bcp14>RECOMMENDED</bcp14>.</t>
      <section anchor="spaces-connectives-and-punctuation-marks" numbered="true" removeInRFC="false" toc="include" pn="section-4.1">
        <name slugifiedName="name-spaces-connectives-and-punc">Spaces, Connectives, and Punctuation Marks</name>
        <t indent="0" pn="section-4.1-1">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").</t>
      </section>
      <section anchor="acronyms" numbered="true" removeInRFC="false" toc="include" pn="section-4.2">
        <name slugifiedName="name-acronyms">Acronyms</name>
        <t indent="0" pn="section-4.2-1">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
<bcp14>RECOMMENDED</bcp14>
(e.g., "FAO" is expanded as "food.agriculture.organization").</t>
      </section>
      <section anchor="ordinal-numbers" numbered="true" removeInRFC="false" toc="include" pn="section-4.3">
        <name slugifiedName="name-ordinal-numbers">Ordinal Numbers</name>
        <t indent="0" pn="section-4.3-1">To standardise the representation, it is highly <bcp14>RECOMMENDED</bcp14> 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".</t>
      </section>
    </section>
    <section anchor="creation" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-creation-of-the-source-of-l">Creation of the Source of Law LEX Identifier: Baseline Structure</name>
      <section anchor="basic-principles" numbered="true" removeInRFC="false" toc="include" pn="section-5.1">
        <name slugifiedName="name-basic-principles">Basic Principles</name>
        <t indent="0" pn="section-5.1-1">The uniform name must identify one and only one document (more
precisely a "bibliographic resource" <xref target="ISBD" format="default" sectionFormat="of" derivedContent="ISBD"/>; see also <xref target="src-law" format="default" sectionFormat="of" derivedContent="Section 5.2"/>)
and is created in such a way that it is:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.1-2">
          <li pn="section-5.1-2.1">
            <t indent="0" pn="section-5.1-2.1.1">self-explanatory,</t>
          </li>
          <li pn="section-5.1-2.2">
            <t indent="0" pn="section-5.1-2.2.1">identifiable through simple and clear rules,</t>
          </li>
          <li pn="section-5.1-2.3">
            <t indent="0" pn="section-5.1-2.3.1">compatible with the practice commonly used for references,</t>
          </li>
          <li pn="section-5.1-2.4">
            <t indent="0" pn="section-5.1-2.4.1">able to be created from references in the text, automatically (by
parser) or manually, and</t>
          </li>
          <li pn="section-5.1-2.5">
            <t indent="0" pn="section-5.1-2.5.1">representative of both the formal and the substantive aspects of
the document.</t>
          </li>
        </ul>
      </section>
      <section anchor="src-law" numbered="true" removeInRFC="false" toc="include" pn="section-5.2">
        <name slugifiedName="name-model-of-sources-of-law-rep">Model of Sources of Law Representation</name>
        <t indent="0" pn="section-5.2-1">According to the Functional Requirements for Bibliographic Records
        (FRBR) <xref target="FRBR" format="default" sectionFormat="of" derivedContent="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.</t>
        <t indent="0" pn="section-5.2-2">The first two entities reflect its contents:</t>
        <dl spacing="normal" indent="3" newline="false" pn="section-5.2-3">
          <dt pn="section-5.2-3.1">work:</dt>
          <dd pn="section-5.2-3.2">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.</dd>
          <dt pn="section-5.2-3.3">expression:</dt>
          <dd pn="section-5.2-3.4">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.</dd>
        </dl>
        <t indent="0" pn="section-5.2-4">The other two entities relate to its form:</t>
        <dl spacing="normal" indent="3" newline="false" pn="section-5.2-5">
          <dt pn="section-5.2-5.1">manifestation:</dt>
          <dd pn="section-5.2-5.2">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.</dd>
          <dt pn="section-5.2-5.3">item:</dt>
          <dd pn="section-5.2-5.4">Identifies a specific copy of a manifestation; in this document, it
identifies individual physical copies as they are found in
particular physical locations.</dd>
        </dl>
        <t indent="0" pn="section-5.2-6">In this document, the <xref target="FRBR" format="default" sectionFormat="of" derivedContent="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.</t>
      </section>
      <section anchor="the-structure-of-the-local-name" numbered="true" removeInRFC="false" toc="include" pn="section-5.3">
        <name slugifiedName="name-structure-of-the-local-name">Structure of the Local-Name</name>
        <t indent="0" pn="section-5.3-1">The local-name within the LEX namespace <bcp14>MUST</bcp14> 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.</t>
        <t indent="0" pn="section-5.3-2">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:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.3-3">
          <li pn="section-5.3-3.1">
            <t indent="0" pn="section-5.3-3.1.1">the original version and all the amended versions of the same
document, and</t>
          </li>
          <li pn="section-5.3-3.2">
            <t indent="0" pn="section-5.3-3.2.1">the versions of the text expressed in the different official
languages of the state or organization.</t>
          </li>
        </ul>
        <t indent="0" pn="section-5.3-4">Finally, the uniform name allows a distinction among diverse
manifestations that may be produced by multiple publishers using
different means and formats.</t>
        <t indent="0" pn="section-5.3-5">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).</t>
        <t indent="0" pn="section-5.3-6">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).</t>
        <t indent="0" pn="section-5.3-7">Therefore, the more general structure of the local-name appears as
follows:</t>
        <sourcecode type="abnf" markers="false" pn="section-5.3-8">
       local-name = work ["@" expression] ["$" manifestation]
</sourcecode>
        <t indent="0" pn="section-5.3-9">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.</t>
      </section>
      <section anchor="structure-of-the-document-identifier-at-work-level" numbered="true" removeInRFC="false" toc="include" pn="section-5.4">
        <name slugifiedName="name-structure-of-the-document-i">Structure of the Document Identifier at "Work" Level</name>
        <t indent="0" pn="section-5.4-1">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:</t>
        <sourcecode type="abnf" markers="false" pn="section-5.4-2">
   work = authority ":" measure ":" details *(":" annex)
</sourcecode>
        <t indent="0" pn="section-5.4-3">where:</t>
        <dl newline="false" spacing="normal" indent="3" pn="section-5.4-4">
          <dt pn="section-5.4-4.1">authority:</dt>
          <dd pn="section-5.4-4.2">The issuing or proposing authority of the measure
(e.g., state, ministry, municipality, court, etc.).</dd>
          <dt pn="section-5.4-4.3">measure:</dt>
          <dd pn="section-5.4-4.4">The type of the measure, both public (e.g.,
constitution, act, treaty, regulation, decree, decision, etc.) and
private (e.g., license, agreement, etc.).</dd>
          <dt pn="section-5.4-4.5">details:</dt>
          <dd pn="section-5.4-4.6">The terms associated with the measure, typically the date
(usually the signature date) and the number included in the heading
of the act.</dd>
          <dt pn="section-5.4-4.7">annex:</dt>
          <dd pn="section-5.4-4.8">The identifier of the annex, if any (e.g., Annex 1).</dd>
        </dl>
        <t indent="0" pn="section-5.4-5">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.
</t>
        <t indent="0" pn="section-5.4-6">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 <xref target="syn-work" format="default" sectionFormat="of" derivedContent="Section 6"/>.
The following are hypothetical examples of work identifiers:</t>
        <artwork align="left" pn="section-5.4-7">
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
</artwork>
        <t indent="0" pn="section-5.4-8">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.</t>
        <t indent="0" pn="section-5.4-9">The following is an example where the type of measure or the full date
are essential for identify specific materials of a case:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.4-10">
          <li pn="section-5.4-10.1">
            <t indent="0" pn="section-5.4-10.1.1">4/59 Judgment of the EEC Court of Justice 04/04/1960, Mannesmann AG and others / ECSC High Authority</t>
            <artwork align="left" pn="section-5.4-10.1.2">
  urn:lex:eec.lex.arpa:court.justice:judgement:1960-04-04;4-59
</artwork>
          </li>
          <li pn="section-5.4-10.2">
            <t indent="0" pn="section-5.4-10.2.1">4/59 Order of the EEC Court of Justice 18/05/1960, Mannesmann AG and others / ECSC High Authority</t>
            <artwork align="left" pn="section-5.4-10.2.2">
  urn:lex:eec.lex.arpa:court.justice:order:1960-05-18;4-59
</artwork>
          </li>
        </ul>
      </section>
      <section anchor="aliases" numbered="true" removeInRFC="false" toc="include" pn="section-5.5">
        <name slugifiedName="name-aliases">Aliases</name>
        <t indent="0" pn="section-5.5-1">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).</t>
        <t indent="0" pn="section-5.5-2">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").</t>
        <t indent="0" pn="section-5.5-3">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).</t>
      </section>
      <section anchor="structure-of-the-document-identifier-at-expression-level" numbered="true" removeInRFC="false" toc="include" pn="section-5.6">
        <name slugifiedName="name-structure-of-the-document-id">Structure of the Document Identifier at "Expression" Level</name>
        <t indent="0" pn="section-5.6-1">There may be several expressions of a legal text connected to
specific versions or languages.</t>
        <t indent="0" pn="section-5.6-2">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:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.6-3">
          <li pn="section-5.6-3.1">
            <t indent="0" pn="section-5.6-3.1.1">amendments due to the issuing of other legal
acts and to the subsequent production of updated or consolidated
texts,</t>
          </li>
          <li pn="section-5.6-3.2">
            <t indent="0" pn="section-5.6-3.2.1">correction of publication errors (rectification or errata corrige), and</t>
          </li>
          <li pn="section-5.6-3.3">
            <t indent="0" pn="section-5.6-3.3.1">entry into or departure from a particular time span, depending on
the specific date in which different partitions of a text come into
force.</t>
          </li>
        </ul>
        <t indent="0" pn="section-5.6-4">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:</t>
        <sourcecode type="abnf" markers="false" pn="section-5.6-5">
    expression = version [":" language]
</sourcecode>
        <t indent="0" pn="section-5.6-6">where:</t>
        <dl newline="false" spacing="normal" indent="3" pn="section-5.6-7">
          <dt pn="section-5.6-7.1">version:</dt>
          <dd pn="section-5.6-7.2">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 <xref target="syn-ver" format="default" sectionFormat="of" derivedContent="Section 7"/>).</dd>
          <dt pn="section-5.6-7.3">language:</dt>
          <dd pn="section-5.6-7.4">The identification code of the language in which the
document is expressed, according to <xref target="RFC5646" format="default" sectionFormat="of" derivedContent="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.</dd>
        </dl>
        <t indent="0" pn="section-5.6-8">The following are hypothetical examples of document identifiers for expressions:</t>
        <artwork align="left" pn="section-5.6-9">
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)
</artwork>
      </section>
      <section anchor="struct-manif" numbered="true" removeInRFC="false" toc="include" pn="section-5.7">
        <name slugifiedName="name-structure-of-the-document-ide">Structure of the Document Identifier at "Manifestation" Level</name>
        <t indent="0" pn="section-5.7-1">To identify a specific manifestation, the uniform name of the
expression is followed by a suitable suffix containing the following
main elements:</t>
        <dl spacing="normal" indent="3" newline="false" pn="section-5.7-2">
          <dt pn="section-5.7-2.1">editor:</dt>
          <dd pn="section-5.7-2.2">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.</dd>
          <dt pn="section-5.7-2.3">format:</dt>
          <dd pn="section-5.7-2.4">The digital format (e.g., XML, HTML, PDF, etc.) expressed
according to the MIME Content-Type standard <xref target="RFC2045" format="default" sectionFormat="of" derivedContent="RFC2045"/>, where the
"/" character is to be substituted with the "-" sign.</dd>
          <dt pn="section-5.7-2.5">component:</dt>
          <dd pn="section-5.7-2.6">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.).</dd>
          <dt pn="section-5.7-2.7">feature:</dt>
          <dd pn="section-5.7-2.8">Other features of the document (e.g., anonymized
decision text).</dd>
        </dl>
        <t indent="0" pn="section-5.7-3">Thus, the manifestation suffix reads:</t>
        <sourcecode type="abnf" markers="false" pn="section-5.7-4">
    manifestation = editor ":" format
                    [":" component [":" feature]]
</sourcecode>
        <t indent="0" pn="section-5.7-5">To indicate possible features or peculiarities, each main element of
the manifestation <bcp14>MAY</bcp14> 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:</t>
        <sourcecode type="abnf" markers="false" pn="section-5.7-6">
    editor = publisher *(";" specification)

    format = mime *(";" specification)

    component = part *(";" specification)

    feature = attribute *(";" specification)
</sourcecode>
        <t indent="0" pn="section-5.7-7">The syntax details of the manifestation element are shown in
<xref target="urn-lex-syn" format="default" sectionFormat="of" derivedContent="Section 8"/> in the related part.</t>
        <t indent="0" pn="section-5.7-8">The following are hypothetical examples:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.7-9">
          <li pn="section-5.7-9.1">
            <t indent="0" pn="section-5.7-9.1.1">The original version of the Italian act 3 April 2000, n. 56 might have
the following manifestations with their relative uniform names:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.7-9.1.2">
              <li pn="section-5.7-9.1.2.1">
                <t indent="0" pn="section-5.7-9.1.2.1.1">PDF format (vers. 1.7) of the whole act edited by the Italian Parliament:</t>
                <artwork align="left" pn="section-5.7-9.1.2.1.2">
urn:lex:it:stato:legge:2000-04-03;56$parlamento.it:
application-pdf;1.7
</artwork>
              </li>
              <li pn="section-5.7-9.1.2.2">
                <t indent="0" pn="section-5.7-9.1.2.2.1">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:</t>
                <artwork align="left" pn="section-5.7-9.1.2.2.2">
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
</artwork>
              </li>
            </ul>
          </li>
          <li pn="section-5.7-9.2">
            <t indent="0" pn="section-5.7-9.2.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:</t>
            <artwork align="left" pn="section-5.7-9.2.2">
urn:lex:eu:tribunal.justicia:sentencia:2009-06-11;33-08
@original:es$juradmin.eu;jurifast:text-html:todo:anonimo
</artwork>
          </li>
        </ul>
        <t indent="0" pn="section-5.7-10">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).</t>
      </section>
      <section anchor="sources-of-law-references" numbered="true" removeInRFC="false" toc="include" pn="section-5.8">
        <name slugifiedName="name-sources-of-law-references">Sources of Law References</name>
        <t indent="0" pn="section-5.8-1">References to sources of law often refer to specific partitions of
the act (article, paragraph, etc.) and not to the entire document.</t>
        <t indent="0" pn="section-5.8-2">From a legal point of view, a partition is always a text block that
represents a logical subdivision of an act.</t>
        <t indent="0" pn="section-5.8-3">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.</t>
        <t indent="0" pn="section-5.8-4">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., &lt;a
id=partitionID&gt;&lt;/a&gt; tag in the HTML markup language <xref target="W3C.HTML" format="default" sectionFormat="of" derivedContent="W3C.HTML"/>). In this case, it is only possible to point to a partition but not extract it.</t>
        <t indent="0" pn="section-5.8-5">Partitions should be assigned unique labels or
IDs within the including document, and their value should be the same
regardless of document format.</t>
        <t indent="0" pn="section-5.8-6">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.</t>
        <t indent="0" pn="section-5.8-7">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.</t>
        <t indent="0" pn="section-5.8-8">According to these requirements, the syntax of a reference is:</t>
        <sourcecode type="abnf" markers="false" pn="section-5.8-9">
     URN-reference = URN-document ["~" partition-id]
</sourcecode>
        <t indent="0" pn="section-5.8-10">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".</t>
        <t indent="0" pn="section-5.8-11">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. 
        </t>
        <t indent="0" pn="section-5.8-12">When resolving to HTTP,
the resolver <bcp14>SHALL</bcp14> 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 &lt;URL-document&gt;#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 &lt;URL-document&gt;#art15
only.</t>
        <t indent="0" pn="section-5.8-13">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.</t>
      </section>
    </section>
    <section anchor="syn-work" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-specific-syntax-of-the-iden">Specific Syntax of the Identifier at "Work" Level</name>
      <section anchor="the-authority-element" numbered="true" removeInRFC="false" toc="include" pn="section-6.1">
        <name slugifiedName="name-the-authority-element">The Authority Element</name>
        <section anchor="indication-of-the-authority" numbered="true" removeInRFC="false" toc="include" pn="section-6.1.1">
          <name slugifiedName="name-indication-of-the-authority">Indication of the Authority</name>
          <t indent="0" pn="section-6.1.1-1">The authority element of a uniform name may indicate the following in the
various cases:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.1.1-2">
            <li pn="section-6.1.1-2.1">
              <t indent="0" pn="section-6.1.1-2.1.1">The actual authority issuing the legal provision. More
specifically, the authority adopting the provision or enacting it.</t>
            </li>
            <li pn="section-6.1.1-2.2">
              <t indent="0" pn="section-6.1.1-2.2.1">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).</t>
            </li>
            <li pn="section-6.1.1-2.3">
              <t indent="0" pn="section-6.1.1-2.3.1">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).</t>
            </li>
            <li pn="section-6.1.1-2.4">
              <t indent="0" pn="section-6.1.1-2.4.1">The entity that proposed the legal material not yet included in the
institutional process (e.g., a proposed bill written by a
political party).</t>
            </li>
          </ul>
        </section>
        <section anchor="multiple-issuers" numbered="true" removeInRFC="false" toc="include" pn="section-6.1.2">
          <name slugifiedName="name-multiple-issuers">Multiple Issuers</name>
          <t indent="0" pn="section-6.1.2-1">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:</t>
          <sourcecode type="abnf" markers="false" pn="section-6.1.2-2">
   authority = issuer *("+" issuer)
</sourcecode>
          <t indent="0" pn="section-6.1.2-3">This is an example: "ministry.justice+ministry.finances".</t>
        </section>
        <section anchor="indication-of-the-issuer" numbered="true" removeInRFC="false" toc="include" pn="section-6.1.3">
          <name slugifiedName="name-indication-of-the-issuer">Indication of the Issuer</name>
          <t indent="0" pn="section-6.1.3-1">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:</t>
          <sourcecode type="abnf" markers="false" pn="section-6.1.3-2">
   issuer = (institution *(";" body-function)) / office
</sourcecode>
          <t indent="0" pn="section-6.1.3-3">This is an example: "ministry.finances;department.revenues;manager".</t>
        </section>
        <section anchor="indication-of-the-body" numbered="true" removeInRFC="false" toc="include" pn="section-6.1.4">
          <name slugifiedName="name-indication-of-the-body">Indication of the Body</name>
          <t indent="0" pn="section-6.1.4-1">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").</t>
        </section>
        <section anchor="indication-of-the-function" numbered="true" removeInRFC="false" toc="include" pn="section-6.1.5">
          <name slugifiedName="name-indication-of-the-function">Indication of the Function</name>
          <t indent="0" pn="section-6.1.5-1">Generally, the function is indicated, sometimes instead of the Body
itself:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.1.5-2">
            <li pn="section-6.1.5-2.1">
              <t indent="0" pn="section-6.1.5-2.1.1">In the case of political, representative, or elective offices
(e.g., "university.oxford;rector:decree" instead of
"university.oxford;rectorship:decree").</t>
            </li>
            <li pn="section-6.1.5-2.2">
              <t indent="0" pn="section-6.1.5-2.2.1">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").</t>
            </li>
          </ul>
          <t indent="0" pn="section-6.1.5-3">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").</t>
          <t indent="0" pn="section-6.1.5-4">The function <bcp14>MUST</bcp14> be indicated when:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.1.5-5">
            <li pn="section-6.1.5-5.1">
              <t indent="0" pn="section-6.1.5-5.1.1">It is not the same as the director or the person in charge of the
structure (for example, an undersecretary, a deputy
director, etc.). </t>
            </li>
            <li pn="section-6.1.5-5.2">
              <t indent="0" pn="section-6.1.5-5.2.1">The type of measure may be both monocratic or collegial; the
indication of the office eliminates the ambiguity.</t>
            </li>
          </ul>
        </section>
        <section anchor="conventions-for-the-authority" numbered="true" removeInRFC="false" toc="include" pn="section-6.1.6">
          <name slugifiedName="name-conventions-for-the-authori">Conventions for the Authority</name>
          <t indent="0" pn="section-6.1.6-1">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.</t>
        </section>
      </section>
      <section anchor="the-measure-element" numbered="true" removeInRFC="false" toc="include" pn="section-6.2">
        <name slugifiedName="name-the-measure-element">The Measure Element</name>
        <section anchor="criteria-for-the-indication-of-the-type-of-measure" numbered="true" removeInRFC="false" toc="include" pn="section-6.2.1">
          <name slugifiedName="name-criteria-for-the-indication">Criteria for the Indication of the Type of Measure</name>
          <t indent="0" pn="section-6.2.1-1">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").</t>
        </section>
        <section anchor="further-specification-to-the-type-of-measure" numbered="true" removeInRFC="false" toc="include" pn="section-6.2.2">
          <name slugifiedName="name-further-specification-to-th">Further Specification to the Type of Measure</name>
          <t indent="0" pn="section-6.2.2-1">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
          <bcp14>MAY</bcp14> be followed by further specifications that are
          useful in referencing, even if the details are lacking:</t>
          <sourcecode type="abnf" markers="false" pn="section-6.2.2-2">
      measure = measure-type *(";" specification)
</sourcecode>
          <t indent="0" pn="section-6.2.2-3">These are examples: "regulations;accounting" or "act;bankruptcy".</t>
        </section>
        <section anchor="aliases-for-sources-of-law-with-different-normative-references" numbered="true" removeInRFC="false" toc="include" pn="section-6.2.3">
          <name slugifiedName="name-aliases-for-sources-of-law-">Aliases for Sources of Law with Different Normative References</name>
          <t indent="0" pn="section-6.2.3-1">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").</t>
        </section>
        <section anchor="relations-between-measure-and-authority-in-the-aliases" numbered="true" removeInRFC="false" toc="include" pn="section-6.2.4">
          <name slugifiedName="name-relations-between-measure-a">Relations Between Measure and Authority in the Aliases</name>
          <t indent="0" pn="section-6.2.4-1">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:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.2.4-2">
            <li pn="section-6.2.4-2.1">
              <t indent="0" pn="section-6.2.4-2.1.1">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").</t>
            </li>
            <li pn="section-6.2.4-2.2">
              <t indent="0" pn="section-6.2.4-2.2.1">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").</t>
            </li>
            <li pn="section-6.2.4-2.3">
              <t indent="0" pn="section-6.2.4-2.3.1">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").</t>
            </li>
          </ul>
        </section>
      </section>
      <section anchor="det-elem" numbered="true" removeInRFC="false" toc="include" pn="section-6.3">
        <name slugifiedName="name-the-details-element">The Details Element</name>
        <section anchor="indication-of-the-details" numbered="true" removeInRFC="false" toc="include" pn="section-6.3.1">
          <name slugifiedName="name-indication-of-the-details">Indication of the Details</name>
          <t indent="0" pn="section-6.3.1-1">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.).</t>
          <t indent="0" pn="section-6.3.1-2">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.</t>
          <t indent="0" pn="section-6.3.1-3">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.</t>
          <t indent="0" pn="section-6.3.1-4">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:</t>
          <sourcecode type="abnf" markers="false" pn="section-6.3.1-5">
   details = (dates / period) ";" numbers
</sourcecode>
          <t indent="0" pn="section-6.3.1-6">The following are examples: "2000-12-06;126" and "14.legislature;s.2544".</t>
        </section>
        <section anchor="multiple-dates" numbered="true" removeInRFC="false" toc="include" pn="section-6.3.2">
          <name slugifiedName="name-multiple-dates">Multiple Dates</name>
          <t indent="0" pn="section-6.3.2-1">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:</t>
          <sourcecode type="abnf" markers="false" pn="section-6.3.2-2">
   dates = date *("," date)
</sourcecode>
          <t indent="0" pn="section-6.3.2-3">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:</t>
          <artwork align="left" pn="section-6.3.2-4">
  personal.data.protection.authority:measure:1999-12-30,2000-01-
  13;1-p-2000
</artwork>
          <t indent="0" pn="section-6.3.2-5">As specified in <xref target="dat-form" format="default" sectionFormat="of" derivedContent="Section 3.6"/>, all the dates can have
          the date typical of the jurisdiction in addition to the ISO
          format.</t>
        </section>
        <section anchor="unnumbered-measures" numbered="true" removeInRFC="false" toc="include" pn="section-6.3.3">
          <name slugifiedName="name-unnumbered-measures">Unnumbered Measures</name>
          <t indent="0" pn="section-6.3.3-1">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
<bcp14>MUST</bcp14>, in any case, contain a discriminating element, which can be any
identifier used internally and not published by the authority
(e.g., protocol).</t>
          <t indent="0" pn="section-6.3.3-2">If the authority does not have its own identifier, one identifier
<bcp14>MUST</bcp14> be created for the name system. In order to easily differentiate
it, such number is preceded by the string "lex-":</t>
          <sourcecode type="abnf" markers="false" pn="section-6.3.3-3">
   number-lex = "lex-" 1*DIGIT
</sourcecode>
          <t indent="0" pn="section-6.3.3-4">The following is an example: "ministry.finances:decree:1999-12-20;lex-3".</t>
          <t indent="0" pn="section-6.3.3-5">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).</t>
          <t indent="0" pn="section-6.3.3-6">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.</t>
        </section>
        <section anchor="mult-num" numbered="true" removeInRFC="false" toc="include" pn="section-6.3.4">
          <name slugifiedName="name-multiple-numbers">Multiple Numbers</name>
          <t indent="0" pn="section-6.3.4-1">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:</t>
          <sourcecode type="abnf" markers="false" pn="section-6.3.4-2">
  number = document-id *("," document-id)
</sourcecode>
          <t indent="0" pn="section-6.3.4-3">The following is an example: "2000-06-12;c-10-97,c-11-97,c-12-97".</t>
          <t indent="0" pn="section-6.3.4-4">The characters that are not allowed (e.g., "/") or reserved (e.g.,
":"), including the comma, cannot exist inside the document-id and
therefore <bcp14>MUST</bcp14> be turned into "-".</t>
          <t indent="0" pn="section-6.3.4-5">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).</t>
        </section>
      </section>
      <section anchor="the-annex-element" numbered="true" removeInRFC="false" toc="include" pn="section-6.4">
        <name slugifiedName="name-the-annex-element">The Annex Element</name>
        <section anchor="annex-formal" numbered="true" removeInRFC="false" toc="include" pn="section-6.4.1">
          <name slugifiedName="name-formal-annexes">Formal Annexes</name>
          <t indent="0" pn="section-6.4.1-1">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.</t>
          <t indent="0" pn="section-6.4.1-2">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 <bcp14>MUST</bcp14> 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.</t>
          <t indent="0" pn="section-6.4.1-3">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:</t>
          <sourcecode type="abnf" markers="false" pn="section-6.4.1-4">
    annex = annex-id *(";" specification)
</sourcecode>
          <t indent="0" pn="section-6.4.1-5">The following is an example:</t>
          <artwork align="left" pn="section-6.4.1-6">
  region.sicily;council:deliberation:1998-02-12;14:annex.a;
  borders.park
</artwork>
          <t indent="0" pn="section-6.4.1-7">The characters that are not allowed (e.g., "/") or that are
          reserved (e.g., ":") must not be featured in the annex-id and
          therefore <bcp14>MUST</bcp14> be turned into ".".</t>
        </section>
        <section anchor="annex-annex" numbered="true" removeInRFC="false" toc="include" pn="section-6.4.2">
          <name slugifiedName="name-annexes-of-annexes">Annexes of Annexes</name>
          <t indent="0" pn="section-6.4.2-1">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:</t>
          <artwork align="left" pn="section-6.4.2-2">
  region.sicily;council:deliberation:1998-02-12;14:annex.a;
  borders.park:table.1;municipality.territories
</artwork>
        </section>
      </section>
    </section>
    <section anchor="syn-ver" numbered="true" removeInRFC="false" toc="include" pn="section-7">
      <name slugifiedName="name-specific-syntax-of-the-vers">Specific Syntax of the Version Element of the "Expression"</name>
      <section anchor="the-version-element" numbered="true" removeInRFC="false" toc="include" pn="section-7.1">
        <name slugifiedName="name-the-version-element">The Version Element</name>
        <section anchor="different-versions-of-a-legislative-document" numbered="true" removeInRFC="false" toc="include" pn="section-7.1.1">
          <name slugifiedName="name-different-versions-of-a-leg">Different Versions of a Legislative Document</name>
          <t indent="0" pn="section-7.1.1-1">The creation of an updated text of a document may have one of the
following forms:</t>
          <dl spacing="normal" indent="3" newline="false" pn="section-7.1.1-2">
            <dt pn="section-7.1.1-2.1">"multi-version":</dt>
            <dd pn="section-7.1.1-2.2">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.</dd>
            <dt pn="section-7.1.1-2.3">"single-version":</dt>
            <dd pn="section-7.1.1-2.4">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 <bcp14>SHOULD</bcp14> be linked to one another and
immediately navigable.</dd>
          </dl>
          <t indent="0" pn="section-7.1.1-3">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.</t>
          <t indent="0" pn="section-7.1.1-4"><xref target="RFC8288" format="default" sectionFormat="of" derivedContent="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 <xref target="RFC8288" format="default" sectionFormat="of" derivedContent="RFC8288"/>, the following
relations are useful:</t>
          <dl spacing="normal" indent="3" newline="false" pn="section-7.1.1-5">
            <dt pn="section-7.1.1-5.1">current (or last or last-version):</dt>
            <dd pn="section-7.1.1-5.2">in-force version</dd>
            <dt pn="section-7.1.1-5.3">self:</dt>
            <dd pn="section-7.1.1-5.4">this version</dd>
            <dt pn="section-7.1.1-5.5">next:</dt>
            <dd pn="section-7.1.1-5.6">next version</dd>
            <dt pn="section-7.1.1-5.7">previous:</dt>
            <dd pn="section-7.1.1-5.8">previous version</dd>
            <dt pn="section-7.1.1-5.9">first:</dt>
            <dd pn="section-7.1.1-5.10">original version</dd>
          </dl>
          <t indent="0" pn="section-7.1.1-6">It is <bcp14>RECOMMENDED</bcp14> 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").</t>
        </section>
        <section anchor="ide-vers" numbered="true" removeInRFC="false" toc="include" pn="section-7.1.2">
          <name slugifiedName="name-identification-of-the-versi">Identification of the Version</name>
          <t indent="0" pn="section-7.1.2-1">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.</t>
          <t indent="0" pn="section-7.1.2-2">Such a suffix identifies each version of a legal provision and
includes, first and foremost, one of the following elements:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7.1.2-3">
            <li pn="section-7.1.2-3.1">
              <t indent="0" pn="section-7.1.2-3.1.1">The issuing date of the last amending measure taken into account.</t>
            </li>
            <li pn="section-7.1.2-3.2">
              <t indent="0" pn="section-7.1.2-3.2.1">The date that the communication of the rectification or
errata corrige was published.</t>
            </li>
            <li pn="section-7.1.2-3.3">
              <t indent="0" pn="section-7.1.2-3.3.1">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).</t>
            </li>
          </ul>
          <t indent="0" pn="section-7.1.2-4">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.</t>
          <sourcecode type="abnf" markers="false" pn="section-7.1.2-5">
   version = (amendment-date / specification)
             *(";" (event-date / event))
</sourcecode>
          <t indent="0" pn="section-7.1.2-6">where:</t>
          <dl newline="false" spacing="normal" indent="3" pn="section-7.1.2-7">
            <dt pn="section-7.1.2-7.1">amendment-date:</dt>
            <dd pn="section-7.1.2-7.2">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.</dd>
            <dt pn="section-7.1.2-7.3">specification:</dt>
            <dd pn="section-7.1.2-7.4">Contains any information that is useful to identify the version unambiguously
and univocally.</dd>
            <dt pn="section-7.1.2-7.5">event-date:</dt>
            <dd pn="section-7.1.2-7.6">Contains the date in which a version is put into
force, is effective, or is published.</dd>
            <dt pn="section-7.1.2-7.7">event:</dt>
            <dd pn="section-7.1.2-7.8">A name assigned to the event producing a further version
(e.g., amendment, decision, etc.).</dd>
          </dl>
          <t indent="0" pn="section-7.1.2-8">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).</t>
          <t indent="0" pn="section-7.1.2-9">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").</t>
          <t indent="0" pn="section-7.1.2-10">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).</t>
          <t indent="0" pn="section-7.1.2-11">As specified in <xref target="dat-form" format="default" sectionFormat="of" derivedContent="Section 3.6"/>, all the dates can have the date typical of the jurisdiction in addition to the date in ISO format.</t>
        </section>
      </section>
    </section>
    <section anchor="urn-lex-syn" numbered="true" removeInRFC="false" toc="include" pn="section-8">
      <name slugifiedName="name-summary-of-the-syntax-of-th">Summary of the Syntax of the Uniform Names of the LEX Namespace</name>
      <sourcecode type="abnf" markers="false" pn="section-8-1">
; 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    = "-" / "_" / "'" / "=" / "(" / ")"
</sourcecode>
    </section>
    <section anchor="the-procedure-of-uniform-names-assignment" numbered="true" removeInRFC="false" toc="include" pn="section-9">
      <name slugifiedName="name-procedure-of-uniform-names-">Procedure of Uniform Names Assignment</name>
      <section anchor="specifying-the-jurisdiction-element-of-the-lex-identifier" numbered="true" removeInRFC="false" toc="include" pn="section-9.1">
        <name slugifiedName="name-specifying-the-jurisdiction">Specifying the Jurisdiction Element of the LEX Identifier</name>
        <t indent="0" pn="section-9.1-1">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.</t>
      </section>
      <section anchor="jurisdictional-registrar-for-names-assignment" numbered="true" removeInRFC="false" toc="include" pn="section-9.2">
        <name slugifiedName="name-jurisdictional-registrar-fo">Jurisdictional Registrar for Names Assignment</name>
        <t indent="0" pn="section-9.2-1">Any country or jurisdiction that intends to adopt this schema <bcp14>MUST</bcp14>
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 <xref target="jur-cod-regist" format="default" sectionFormat="of" derivedContent="Section 2.2"/>).  It must appoint a Jurisdictional 
Registrar and must apply the Designated Experts to register the new jurisdiction-code.</t>
        <t indent="0" pn="section-9.2-2">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.</t>
        <t indent="0" pn="section-9.2-3">The process of assigning the local-name is managed by each
specific country or jurisdiction under the related jurisdiction
element.</t>
        <t indent="0" pn="section-9.2-4">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.</t>
        <t indent="0" pn="section-9.2-5">The Jurisdictional Registrar <bcp14>MUST</bcp14> 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.</t>
        <t indent="0" pn="section-9.2-6">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.</t>
        <t indent="0" pn="section-9.2-7">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.</t>
        <t indent="0" pn="section-9.2-8">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.</t>
      </section>
      <section anchor="identifier-uniqueness" numbered="true" removeInRFC="false" toc="include" pn="section-9.3">
        <name slugifiedName="name-identifier-uniqueness">Identifier Uniqueness</name>
        <t indent="0" pn="section-9.3-1">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 <xref target="creation" format="default" sectionFormat="of" derivedContent="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 <bcp14>MUST</bcp14>
provide clear documentation of rules by which names are to be
constructed and <bcp14>MUST</bcp14> update its registries and make them accessible.</t>
        <t indent="0" pn="section-9.3-2">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.</t>
      </section>
      <section anchor="identifier-persistence-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-9.4">
        <name slugifiedName="name-identifier-persistence-cons">Identifier Persistence Considerations</name>
        <t indent="0" pn="section-9.4-1">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.</t>
        <t indent="0" pn="section-9.4-2">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.</t>
        <t indent="0" pn="section-9.4-3">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.</t>
        <t indent="0" pn="section-9.4-4">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.</t>
        <t indent="0" pn="section-9.4-5">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.</t>
        <t indent="0" pn="section-9.4-6">Issuing authorities that operate in more localized scopes, ranging
from national scope down to very local scope, <bcp14>MUST</bcp14> equally take
responsibility for the persistence of identifiers within their scope.</t>
      </section>
    </section>
    <section anchor="recommendations-for-the-resolution-process" numbered="true" removeInRFC="false" toc="include" pn="section-10">
      <name slugifiedName="name-recommendations-for-the-res">Recommendations for the Resolution Process</name>
      <section anchor="the-general-architecture-of-the-system" numbered="true" removeInRFC="false" toc="include" pn="section-10.1">
        <name slugifiedName="name-general-architecture-of-the">General Architecture of the System</name>
        <t indent="0" pn="section-10.1-1">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.</t>
        <t indent="0" pn="section-10.1-2">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.</t>
        <t indent="0" pn="section-10.1-3">The client retrieves the document associated with this URN using the
procedure described in <xref target="RFC3404" format="default" sectionFormat="of" derivedContent="RFC3404"/>, which starts with a DNS NAPTR
query.</t>
        <t indent="0" pn="section-10.1-4">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.</t>
        <t indent="0" pn="section-10.1-5">For the LEX namespace, CNR will 1) maintain the root zone of the
chain resolution, equivalent to "lex.urn.arpa" (see <xref target="RFC3405" format="default" sectionFormat="of" derivedContent="RFC3405"/>), in
the lex-nameserver.nic.it (see <xref target="iana" format="default" sectionFormat="of" derivedContent="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 <xref target="jur-cod-regist" format="default" sectionFormat="of" derivedContent="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").</t>
        <t indent="0" pn="section-10.1-6">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").</t>
        <t indent="0" pn="section-10.1-7">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 <bcp14>MUST</bcp14> perform any necessary punycode
conversion <xref target="RFC5891" format="default" sectionFormat="of" derivedContent="RFC5891"/> before sending the query.</t>
        <t indent="0" pn="section-10.1-8">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.</t>
      </section>
      <section anchor="catalogues-for-resolution" numbered="true" removeInRFC="false" toc="include" pn="section-10.2">
        <name slugifiedName="name-catalogues-for-resolution">Catalogues for Resolution</name>
        <t indent="0" pn="section-10.2-1">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.</t>
        <t indent="0" pn="section-10.2-2">In addition, the catalogue must manage the aliases, the various
versions and languages of the same source of law, and the
related manifestations.</t>
        <t indent="0" pn="section-10.2-3">It is suggested that each enacting authority implement its own
catalogue, assigning a corresponding unambiguous uniform name to each
resource.</t>
      </section>
      <section anchor="suggested-resolver-behaviour" numbered="true" removeInRFC="false" toc="include" pn="section-10.3">
        <name slugifiedName="name-suggested-resolver-behavior">Suggested Resolver Behavior</name>
        <t indent="0" pn="section-10.3-1">First, the resolver <bcp14>SHOULD</bcp14> separate the part corresponding to
the partition ID from the document name, with the "~" separator.</t>
        <t indent="0" pn="section-10.3-2">The resolution process <bcp14>SHOULD</bcp14> 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.</t>
        <t indent="0" pn="section-10.3-3">The resolver <bcp14>SHOULD</bcp14> 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.</t>
        <t indent="0" pn="section-10.3-4">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.</t>
        <t indent="0" pn="section-10.3-5">Lacking more specific indications, the resolver <bcp14>SHOULD</bcp14> 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.).</t>
        <t indent="0" pn="section-10.3-6">Finally, the resolver <bcp14>SHOULD</bcp14> append the "#" character
followed by the partition ID to URLs, to create URI fragments for
browser pointing.</t>
      </section>
    </section>
    <section anchor="security-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-11">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-11-1">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.</t>
    </section>
    <section anchor="iana" numbered="true" removeInRFC="false" toc="include" pn="section-12">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-12-1">IANA has registered LEX namespace in the
"Formal URN Namespaces" registry <xref target="RFC8141" format="default" sectionFormat="of" derivedContent="RFC8141"/>.</t>
      <t indent="0" pn="section-12-2">In addition, to activate a distributed resolution system, IANA has registered the following NAPTR record in the URN.ARPA domain:</t>
      <sourcecode type="dns-rr" markers="false" pn="section-12-3">
lex.urn.arpa.
    IN NAPTR  100  10  ""  ""  ""  lex-nameserver.nic.it.
</sourcecode>
      <t indent="0" pn="section-12-4">Note that lex-nameserver.nic.it indicates the CNR server (see <xref target="jur-cod-regist" format="default" sectionFormat="of" derivedContent="Section 2.2"/>)                  
that is responsible for the resolution of the LEX namespace at the time of this writing.</t>
    </section>
  </middle>
  <back>
    <references pn="section-13">
      <name slugifiedName="name-references">References</name>
      <references anchor="sec-normative-references" pn="section-13.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="ISO.8601-1.2019" target="https://www.iso.org/standard/70907.html" quoteTitle="true" derivedAnchor="ISO.8601-1.2019">
          <front>
            <title>Date and time - Representations for information interchange</title>
            <author>
              <organization showOnFrontPage="true">ISO</organization>
            </author>
            <date month="February" year="2019"/>
          </front>
          <seriesInfo name="ISO" value="8601-1:2019"/>
        </reference>
        <reference anchor="ISO.8601-2.2019" target="https://www.iso.org/standard/70908.html" quoteTitle="true" derivedAnchor="ISO.8601-2.2019">
          <front>
            <title>Data elements and interchange formats - Information interchange - Representation of dates and times</title>
            <author>
              <organization showOnFrontPage="true">ISO</organization>
            </author>
            <date month="February" year="2019"/>
          </front>
          <seriesInfo name="ISO" value="8601-2:2019"/>
        </reference>
        <reference anchor="RFC2045" target="https://www.rfc-editor.org/info/rfc2045" quoteTitle="true" derivedAnchor="RFC2045">
          <front>
            <title>Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</title>
            <author fullname="N. Freed" initials="N." surname="Freed"/>
            <author fullname="N. Borenstein" initials="N." surname="Borenstein"/>
            <date month="November" year="1996"/>
            <abstract>
              <t indent="0">This initial document specifies the various headers used to describe the structure of MIME messages. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2045"/>
          <seriesInfo name="DOI" value="10.17487/RFC2045"/>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC3404" target="https://www.rfc-editor.org/info/rfc3404" quoteTitle="true" derivedAnchor="RFC3404">
          <front>
            <title>Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)</title>
            <author fullname="M. Mealling" initials="M." surname="Mealling"/>
            <date month="October" year="2002"/>
            <abstract>
              <t indent="0">This document describes a specification for taking Uniform Resource Identifiers (URI) and locating an authoritative server for information about that URI. The method used to locate that authoritative server is the Dynamic Delegation Discovery System. This document is part of a series that is specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3404"/>
          <seriesInfo name="DOI" value="10.17487/RFC3404"/>
        </reference>
        <reference anchor="RFC3405" target="https://www.rfc-editor.org/info/rfc3405" quoteTitle="true" derivedAnchor="RFC3405">
          <front>
            <title>Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures</title>
            <author fullname="M. Mealling" initials="M." surname="Mealling"/>
            <date month="October" year="2002"/>
            <abstract>
              <t indent="0">This document is fifth in a series that is completely specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="65"/>
          <seriesInfo name="RFC" value="3405"/>
          <seriesInfo name="DOI" value="10.17487/RFC3405"/>
        </reference>
        <reference anchor="RFC3629" target="https://www.rfc-editor.org/info/rfc3629" quoteTitle="true" derivedAnchor="RFC3629">
          <front>
            <title>UTF-8, a transformation format of ISO 10646</title>
            <author fullname="F. Yergeau" initials="F." surname="Yergeau"/>
            <date month="November" year="2003"/>
            <abstract>
              <t indent="0">ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="63"/>
          <seriesInfo name="RFC" value="3629"/>
          <seriesInfo name="DOI" value="10.17487/RFC3629"/>
        </reference>
        <reference anchor="RFC3986" target="https://www.rfc-editor.org/info/rfc3986" quoteTitle="true" derivedAnchor="RFC3986">
          <front>
            <title>Uniform Resource Identifier (URI): Generic Syntax</title>
            <author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee"/>
            <author fullname="R. Fielding" initials="R." surname="Fielding"/>
            <author fullname="L. Masinter" initials="L." surname="Masinter"/>
            <date month="January" year="2005"/>
            <abstract>
              <t indent="0">A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="66"/>
          <seriesInfo name="RFC" value="3986"/>
          <seriesInfo name="DOI" value="10.17487/RFC3986"/>
        </reference>
        <reference anchor="RFC5234" target="https://www.rfc-editor.org/info/rfc5234" quoteTitle="true" derivedAnchor="RFC5234">
          <front>
            <title>Augmented BNF for Syntax Specifications: ABNF</title>
            <author fullname="D. Crocker" initials="D." role="editor" surname="Crocker"/>
            <author fullname="P. Overell" initials="P." surname="Overell"/>
            <date month="January" year="2008"/>
            <abstract>
              <t indent="0">Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="68"/>
          <seriesInfo name="RFC" value="5234"/>
          <seriesInfo name="DOI" value="10.17487/RFC5234"/>
        </reference>
        <reference anchor="RFC5646" target="https://www.rfc-editor.org/info/rfc5646" quoteTitle="true" derivedAnchor="RFC5646">
          <front>
            <title>Tags for Identifying Languages</title>
            <author fullname="A. Phillips" initials="A." role="editor" surname="Phillips"/>
            <author fullname="M. Davis" initials="M." role="editor" surname="Davis"/>
            <date month="September" year="2009"/>
            <abstract>
              <t indent="0">This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="47"/>
          <seriesInfo name="RFC" value="5646"/>
          <seriesInfo name="DOI" value="10.17487/RFC5646"/>
        </reference>
        <reference anchor="RFC5891" target="https://www.rfc-editor.org/info/rfc5891" quoteTitle="true" derivedAnchor="RFC5891">
          <front>
            <title>Internationalized Domain Names in Applications (IDNA): Protocol</title>
            <author fullname="J. Klensin" initials="J." surname="Klensin"/>
            <date month="August" year="2010"/>
            <abstract>
              <t indent="0">This document is the revised protocol definition for Internationalized Domain Names (IDNs). The rationale for changes, the relationship to the older specification, and important terminology are provided in other documents. This document specifies the protocol mechanism, called Internationalized Domain Names in Applications (IDNA), for registering and looking up IDNs in a way that does not require changes to the DNS itself. IDNA is only meant for processing domain names, not free text. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5891"/>
          <seriesInfo name="DOI" value="10.17487/RFC5891"/>
        </reference>
        <reference anchor="RFC5893" target="https://www.rfc-editor.org/info/rfc5893" quoteTitle="true" derivedAnchor="RFC5893">
          <front>
            <title>Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)</title>
            <author fullname="H. Alvestrand" initials="H." role="editor" surname="Alvestrand"/>
            <author fullname="C. Karp" initials="C." surname="Karp"/>
            <date month="August" year="2010"/>
            <abstract>
              <t indent="0">The use of right-to-left scripts in Internationalized Domain Names (IDNs) has presented several challenges. This memo provides a new Bidi rule for Internationalized Domain Names for Applications (IDNA) labels, based on the encountered problems with some scripts and some shortcomings in the 2003 IDNA Bidi criterion. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5893"/>
          <seriesInfo name="DOI" value="10.17487/RFC5893"/>
        </reference>
        <reference anchor="RFC5894" target="https://www.rfc-editor.org/info/rfc5894" quoteTitle="true" derivedAnchor="RFC5894">
          <front>
            <title>Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale</title>
            <author fullname="J. Klensin" initials="J." surname="Klensin"/>
            <date month="August" year="2010"/>
            <abstract>
              <t indent="0">Several years have passed since the original protocol for Internationalized Domain Names (IDNs) was completed and deployed. During that time, a number of issues have arisen, including the need to update the system to deal with newer versions of Unicode. Some of these issues require tuning of the existing protocols and the tables on which they depend. This document provides an overview of a revised system and provides explanatory material for its components. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5894"/>
          <seriesInfo name="DOI" value="10.17487/RFC5894"/>
        </reference>
        <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126" quoteTitle="true" derivedAnchor="RFC8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <author fullname="M. Cotton" initials="M." surname="Cotton"/>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <date month="June" year="2017"/>
            <abstract>
              <t indent="0">Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
              <t indent="0">To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
              <t indent="0">This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/>
        </reference>
        <reference anchor="RFC8141" target="https://www.rfc-editor.org/info/rfc8141" quoteTitle="true" derivedAnchor="RFC8141">
          <front>
            <title>Uniform Resource Names (URNs)</title>
            <author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre"/>
            <author fullname="J. Klensin" initials="J." surname="Klensin"/>
            <date month="April" year="2017"/>
            <abstract>
              <t indent="0">A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" URI scheme and a particular URN namespace, with the intent that the URN will be a persistent, location-independent resource identifier. With regard to URN syntax, this document defines the canonical syntax for URNs (in a way that is consistent with URI syntax), specifies methods for determining URN-equivalence, and discusses URI conformance. With regard to URN namespaces, this document specifies a method for defining a URN namespace and associating it with a namespace identifier, and it describes procedures for registering namespace identifiers with the Internet Assigned Numbers Authority (IANA). This document obsoletes both RFCs 2141 and 3406.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8141"/>
          <seriesInfo name="DOI" value="10.17487/RFC8141"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8288" target="https://www.rfc-editor.org/info/rfc8288" quoteTitle="true" derivedAnchor="RFC8288">
          <front>
            <title>Web Linking</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
            <date month="October" year="2017"/>
            <abstract>
              <t indent="0">This specification defines a model for the relationships between resources on the Web ("links") and the type of those relationships ("link relation types").</t>
              <t indent="0">It also defines the serialisation of such links in HTTP headers with the Link header field.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8288"/>
          <seriesInfo name="DOI" value="10.17487/RFC8288"/>
        </reference>
        <reference anchor="W3C.HTML" target="https://www.w3.org/TR/html/" quoteTitle="true" derivedAnchor="W3C.HTML">
          <front>
            <title>HTML</title>
            <author/>
          </front>
          <seriesInfo name="W3C REC" value="HTML"/>
          <seriesInfo name="W3C" value="HTML"/>
        </reference>
      </references>
      <references anchor="sec-informative-references" pn="section-13.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="FRAN" quoteTitle="true" derivedAnchor="FRAN">
          <front>
            <title>Technologies for European Integration.  Standards-based Interoperability of Legal Information Systems</title>
            <author initials="E." surname="Francesconi" fullname="Enrico Francesconi">
              <organization showOnFrontPage="true">European Press Academic Publishing</organization>
            </author>
            <date year="2007"/>
          </front>
          <seriesInfo name="ISBN" value="978-88-8398-050-3"/>
        </reference>
        <reference anchor="FRBR" target="https://www.ifla.org/files/assets/cataloguing/frbr/frbr_2008.pdf" quoteTitle="true" derivedAnchor="FRBR">
          <front>
            <title>Functional Requirements for Bibliographic Records</title>
            <author>
              <organization showOnFrontPage="true">International Federation of Library Associations and Institutions</organization>
            </author>
            <date month="February" year="2009"/>
          </front>
        </reference>
        <reference anchor="HCPIL" target="https://assets.hcch.net/docs/b093f152-a4b3-4530-949e-65c1bfc9cda1.pdf" quoteTitle="true" derivedAnchor="HCPIL">
          <front>
            <title>Access to Foreign Law in Civil and Commercial Matters</title>
            <author>
              <organization showOnFrontPage="true">The European Commission</organization>
            </author>
            <date month="February" year="2012"/>
          </front>
          <refcontent>The Hague Conference on Private International Law</refcontent>
        </reference>
        <reference anchor="ISBD" quoteTitle="true" derivedAnchor="ISBD">
          <front>
            <title>ISBD: International Standard Bibliographic Description – Consolidated Edition</title>
            <author>
              <organization showOnFrontPage="true">The Standing Committee of the IFLA Cataloguing Section Berlin/Munich: De Gruyter Saur</organization>
            </author>
            <date year="2011"/>
          </front>
          <seriesInfo name="ISBN" value="978-3-11-026379-4"/>
        </reference>
        <reference anchor="ISO.3166-1" quoteTitle="true" derivedAnchor="ISO.3166-1">
          <front>
            <title>Codes for the representation of names of countries and their subdivisions - Part 1: Country codes, ISO 3166-1:2020, 2020.</title>
            <author>
              <organization showOnFrontPage="true">ISO</organization>
            </author>
            <date year="2020"/>
          </front>
        </reference>
        <reference anchor="LVI" quoteTitle="true" derivedAnchor="LVI">
          <front>
            <title>Law via the Internet. Free Access, Quality of Information, Effectiveness of Rights</title>
            <author initials="G." surname="Peruginelli" fullname="Ginevra Peruginelli" role="editor">
              <organization showOnFrontPage="true">European Press Academic Publishing</organization>
            </author>
            <author initials="M." surname="Ragona" fullname="Mario Ragona" role="editor">
              <organization showOnFrontPage="true">European Press Academic Publishing</organization>
            </author>
            <date month="April" year="2009"/>
          </front>
          <seriesInfo name="ISBN" value="9788883980589"/>
        </reference>
        <reference anchor="SART" quoteTitle="true" derivedAnchor="SART">
          <front>
            <title>Legislative XML for the Semantic Web: Principles, Models, Standards for Document Management</title>
            <author initials="G." surname="Sartor" fullname="Giovanni Sartor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Palmirani" fullname="Monica Palmirani">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Francesconi" fullname="Enrico Francesconi">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Biasiotti" fullname="Maria Angela Biasotti">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011"/>
          </front>
          <seriesInfo name="ISBN" value="978-94-007-1887-6"/>
        </reference>
        <reference anchor="SPIN" quoteTitle="true" derivedAnchor="SPIN">
          <front>
            <title>Identification of Legal Documents through URNs (Uniform Resource Names)</title>
            <author initials="P." surname="Spinosa" fullname="PierLuigi Spinosa">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2001"/>
          </front>
          <seriesInfo name="Proceedings of the EuroWeb 2001, The Web in Public Administration" value=""/>
        </reference>
        <reference anchor="W3C.RDF-SCHEMA" target="https://www.w3.org/TR/rdf-schema/" quoteTitle="true" derivedAnchor="W3C.RDF-SCHEMA">
          <front>
            <title>RDF Schema 1.1</title>
            <author fullname="Dan Brickley" role="editor"/>
            <author fullname="R.V. Guha" role="editor"/>
            <date year="2014" month="February"/>
          </front>
          <seriesInfo name="W3C REC" value="rdf-schema"/>
          <seriesInfo name="W3C" value="rdf-schema"/>
        </reference>
      </references>
    </references>
    <section numbered="false" anchor="acknowledgements" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">The authors wish to thank all those who provided
      suggestions and comments.</t>
      <t indent="0" pn="section-appendix.a-2">The authors are grateful to the Legislative XML community <xref target="SART" format="default" sectionFormat="of" derivedContent="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 <xref target="SPIN" format="default" sectionFormat="of" derivedContent="SPIN"/>.</t>
      <t indent="0" pn="section-appendix.a-3">The authors owe a debt of gratitude to <contact fullname="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 <contact fullname="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 <contact fullname="Joao Alberto de Oliveira Lima"/>, Legislative System Analyst
      of the Brazilian Federal Senate, and to <contact fullname="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 <contact fullname="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.</t>
      <t indent="0" pn="section-appendix.a-4">Finally, many thanks go to <contact fullname="Loriana Serrotti"/>, who
      significantly contributed to the first draft versions of this document.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="P." surname="Spinosa" fullname="PierLuigi Spinosa">
        <address>
          <postal>
            <street>Via Zanardelli, 15</street>
            <city>Firenze</city>
            <code>50136</code>
            <country>Italy</country>
          </postal>
          <phone>+39 339 5614056</phone>
          <email>pierluigi.spinosa@gmail.com</email>
        </address>
      </author>
      <author initials="E." surname="Francesconi" fullname="Enrico Franceseconi">
        <organization showOnFrontPage="true">National Research Council of Italy (CNR)</organization>
        <address>
          <postal>
            <street>Via de' Barucci, 20</street>
            <city>Firenze</city>
            <code>50127</code>
            <country>Italy</country>
          </postal>
          <phone>+39 055 43995</phone>
          <email>enrico.francesconi@cnr.it</email>
        </address>
      </author>
      <author initials="C." surname="Lupo" fullname="Caterina Lupo">
        <address>
          <postal>
            <street>Via San Fabiano, 25</street>
            <city>Roma</city>
            <code>117</code>
            <country>Italy</country>
          </postal>
          <phone>+39 3382632348</phone>
          <email>caterina.lupo@gmail.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
