From nobody Wed Sep 20 05:13:15 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B2C127005; Wed, 20 Sep 2017 05:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=CXZ7Bx/R; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mON9+Jgo Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRPEuHN-pH3z; Wed, 20 Sep 2017 05:13:12 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBB8713305E; Wed, 20 Sep 2017 05:13:11 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 2343D213C0; Wed, 20 Sep 2017 08:13:11 -0400 (EDT) Received: from web1 ([10.202.2.211]) by compute7.internal (MEProxy); Wed, 20 Sep 2017 08:13:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=Ugu+dgr3xnPgGFoujNu2NjKdiXQo6seJNo8kh3kRg5I=; b=CXZ7Bx/R 6agNSRqXMtdKUi8HTjfDtUIDnwzAju9mrw0JRk6Tluzk/vFa7wtm3INHiEMf45CP ZWx5Z12ZStoIuo2APi0Vfmrh3aHNdvrw0plqHs6ZQk45Xrt9PEFL3en17pfF1Cxd Fg1BQOjO44UyhLElj3AmgxGDUhnQieL+nv9ji3Qi2Bl59Tk+EWnbSUW577eiqNgk JktQM3IEK4dF6r3iHBFlEJVkiUXceqOAU/FZga1355AhyFZwgKRupvT6qfN23TMH nKVwRigdyRESTkd5INwhXBterBSZH9f2i9azz1ld0HMraAZ7ANwyFabnPJXzhL6G 9JezLx1iKm811A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=Ugu+dgr3xnPgGFoujNu2NjKdiXQo6 seJNo8kh3kRg5I=; b=mON9+JgoVxK7lN6wznI+03gUSLco5t59wBW99TZWhSvMu i6BbYK8drn+FmWqbd8sy84lpAnnZ5+CkjjEgJn9pl2Vdi527DfAp5vdnmO51zqZW hF8FvX8tO0AwgJqyutmgKErqazzOPBuFKwNyREWQptAPcaJFmdajo7RYpzSUsQ+1 V7234MHiJhs5UcrdpdG3/+iyB1URe0pCQi5Gi6xCRiWQrCaNX+e/WXTF6dwcNdqN hCi7F863f/3qwi/U5nzaCfLZDSCRHMlWMJxSQlrfGm6zLWsSEuMOXMSMraHBnkdp HYPO9R1ruZflDepUyatq58yV0ON/GEcnZLf98cj0g== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 05B9494721; Wed, 20 Sep 2017 08:13:11 -0400 (EDT) Message-Id: <1505909590.1544977.1112321704.5FEB92F9@webmail.messagingengine.com> From: Alexey Melnikov To: urn@ietf.org Cc: draft-spinosa-urn-lex.all@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-64b08692 Date: Wed, 20 Sep 2017 13:13:10 +0100 Archived-At: Subject: [urn] Request for new URN namespace review: LEX X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 12:13:14 -0000 Hi, as responsible AD for draft-spinosa-urn-lex, I would like to request Expert Review for a new URN Namespace. The registration template was extracted from draft-spinosa-urn-lex-11: Namespace Identifier: "lex" requested according to [RFC8141]. Version: 1.0 Date: 2017-05-25 Registrant: Institute of Legal Information Theory and Techniques (ITTIG) Italian National Research Council (CNR) Via de' Barucci, 20 50127 Florence Italy e-mail: lex@ittig.cnr.it phone: +39 055 43995 contact: Enrico Francesconi e-mail: enrico.francesconi@ittig.cnr.it Purpose: The purpose of the "lex" namespace is to assign an unequivocal identifier, in standard format, to documents that are sources of law. In the last few years a number of institutional initiatives have arisen in the field of legal document management. They were aimed at introducing standards for sources of law description and identification using XML and URI techniques, respectively (for more details see Section 1.3) LEX identifier is conceived to be general enough, so to provide guidance at the core of the standard and sufficient flexibility to cover a wide variety of needs for identifying all the legal documents of different nature, namely legislative, case-law and administrative acts. Moreover, it can be effectively used within a federative environment where different publishers (public and private) can provide their own items of an act (that is there is more than one manifestation of the same act). The LEX identifier is conceived to be: globally unique, transparent, bidirectional, persistent, location-independent, and language-neutral. It is organized into parts. The first part uses a predetermined standard to specify the country (or more generally the jurisdiction) of origin for the legal document being identified; the remainder is intended for local use in identifying documents issued in that country or jurisdiction. This second part depends only on sources of law identification system operating in that nation. For more details on the nature of the LEX characteristics and the general internal organization, see Section 1.4. The LEX name is linked to the document through specific meta- information, internally (with a tag) or externally (with a attribute) (for details on this see Section 1.5) LEX names will be used on a large scale in references either in (X)HTML document or, more generally, in XML documents format compliant with the relative DTD/XMLSchema (see Section 1.6 for more information). Syntax: The identifier has a hierarchical structure as follows: "urn:lex:" NSS where is the Namespace Specific String composed as follows: NSS = jurisdiction ":" local-name where: is the part providing the identification of the jurisdiction, generally corresponding to the country, where the source of law is issued. It is also possible to represent international organizations (either states or public administrations or private entities); is the uniform name of the source of law in the country or jurisdiction where it is issued; its internal structure is common to the already adopted schemas. It is able to represent all the aspects of an intellectual production, as it is a legal document, from its initial idea, through its evolution during the time, to its realisation by different means (paper, digital, etc.). LEX specifications gives information on the internal structure of both and , including specifications about case sensitivity, the use of national characters and diacritics, as well as spaces, connectives, punctuation marks, abbreviations, acronyms, date formats and ordinal numbers. For more details on the internal structure and syntax of the LEX identifier, see Section 3, 4 and 5. Recently the r- and q- components have been introduced by [RFC8141]. They provide new and interesting perspectives when using URNs in a complex sector as sources of law, characterized by different versions, languages, publishers, and so on. In particular, by using the r-component at the resolver level, and therefore at the whole NSS level, you can select from the same work only expressions written in a given language, or manifestations published by a particular institutional site, etc. Using the q-component at the act metadata level, you can select versions that are valid at a particular date, or modified by a specific act, etc. Assignment: The Jurisdictional Registrar (or those it delegates) of each adhering country or organization is responsible of the definition or acceptance of the uniform name's primary elements (issuing authority and type of legal measure). Any country or jurisdiction, aiming to adopt this schema, identifies a Jurisdictional Registrar, an organization which shares and defines the structure of the optional part of the name, according to the organization of the state or institution. The process of assigning the will be managed by each specific country or jurisdiction under the related element (details on this can be found in Section 7.2). Identifiers in the "lex" namespace are defined through a element assigned to the sources of law of a specific country or organization, and a assigned by the issuing authority. The goal of the LEX schema is to maintain uniqueness and persistence of all resources identified by the assigned URNs. The elements values for the LEX identifier within a jurisdiction are defined by the Jurisdictional Registrar, this ensures that the constructed URNs are unique (see Section 7.3 for details on uniqueness). The persistence of identifiers depends on the durability of the institutions that assign and administer them (see Section 7.3 for details on persitence) Security and Privacy: This document introduces no additional security considerations beyond those associated with the use and resolution of URNs in general. Interoperability: As open standard naming convention to identify sources of law at international level, LEX is meant to guarantee interoperability among legal information systems across national boundaries. The characteristics of the LEX naming convention facilitate legal document management as well as provide a mechanism of stable cross-collections and cross-country references, thus allowing the distribution of the legal information towards a federated architecture. Resolution: The resolution service associates a LEX identifier with a specific document address on the net. The related system will have a distributed architecture based on two fundamental components: a chain of information in DNS (Domain Name System) and a series of resolution services from URNs to URLs, each competent within a specific domain of the namespace (see Section 8.1 for more details). To cope with possible incomplete or inaccurate uniform names, the implementation of a catalogue, based on a relational- database, able to associate a URN to related URLs, is suggested, as it will lead to a higher flexibility in the resolution process. A resolver can provide names normalization, completion of inaccurate or incomplete names, and finally their resolution in network locations (see Section 8.2 and 8.3 for characteristics and behaviour of a catalogue for resolution). Documentation: None Additional Information: See [FRAN] and [SPIN]. Revision Information: None From nobody Thu Sep 21 00:57:51 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E54B133072; Thu, 21 Sep 2017 00:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.91 X-Spam-Level: X-Spam-Status: No, score=-2.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=helsinkifi.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJTVyLYHAy0C; Thu, 21 Sep 2017 00:57:40 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30105.outbound.protection.outlook.com [40.107.3.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC6E4132D14; Thu, 21 Sep 2017 00:57:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=HelsinkiFI.onmicrosoft.com; s=selector1-helsinki-fi; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gtVXTJF/xOJU41VqNa/QKIUuH2GUTSDAZ4uAU4lBsVQ=; b=dDidJKczdqyy2Rq+OaBFSadfWK3REb3EC7d97+1xC0CxNGcy7/vWnlPjbLlPvrg5rOnqA0cb18dM41WthlKQLT5Yd7LD0qKB8fLZcrd6ZQ4NRgmWfIDGiqv7FXT4Q0E3tWMovU/IyKDWgEDankI/FLYett42fpGgeHXlnTtHG64= Received: from HE1PR07MB3099.eurprd07.prod.outlook.com (10.170.244.161) by HE1PR07MB0857.eurprd07.prod.outlook.com (10.162.24.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Thu, 21 Sep 2017 07:57:35 +0000 Received: from HE1PR07MB3099.eurprd07.prod.outlook.com ([fe80::a8b2:67a0:9d31:bc52]) by HE1PR07MB3099.eurprd07.prod.outlook.com ([fe80::a8b2:67a0:9d31:bc52%13]) with mapi id 15.20.0077.011; Thu, 21 Sep 2017 07:57:35 +0000 From: "Hakala, Juha E" To: Alexey Melnikov , "urn@ietf.org" CC: "draft-spinosa-urn-lex.all@ietf.org" Thread-Topic: [urn] Request for new URN namespace review: LEX Thread-Index: AQHTMgnrxQwqCPfUVk+cwYnW0kkjraK+6hvw Date: Thu, 21 Sep 2017 07:57:35 +0000 Message-ID: References: <1505909590.1544977.1112321704.5FEB92F9@webmail.messagingengine.com> In-Reply-To: <1505909590.1544977.1112321704.5FEB92F9@webmail.messagingengine.com> Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.214.71.222] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB0857; 6:VP/H/nr8NkVsNw/+fBoBoOrsoEZtK8b3nIw5r+nUBrCwueouJhqKFZxC+knSfwrIIF+hZDlC5mJ3Ab8kGpwdqlqIaGivWCSf9JNOw7Ar7t7cH8vrWAiYDjS50MXAaFlpfC6z7mkQjvAhFMZzyO+nSP/r8RCgfHneWcGZcEtREIJwe27RXy/1alf4LfaEmozH90yynJt8dRRfn58LRfYCd+hGYDEC44fgsPSJuue9SmJl7v9NbuMlJa5jMEKMtSzKbWouZn1qNvyFlkdwOqxY7JvMDiJZnrGCekYvxBgcaoc1pN7C9ABbW9ist05mRof4lcshuWVp3V25s2loucZ+2w==; 5:zxYpvFaB2kNbse+vTYbZ6EBh0fchCKNoc2zb7BqNrPwDqO/t164mklcZLwEaUtAGXiOh5l3SVALhHLA0brfFU9M1AtGarEVTVZFR5bdz0bv7ZZEjWvHfX0BtJUiPokvDz4M6WWJrJkyMRSmvCpPj/w==; 24:myup8l1JB380oPL5tBzNA0TTXnj+tVN+DhkmCJcsWFxzJ34+2l7S8NLZBrhhLpnVRU8HxqR0tsmBEY9bZBvijV1+DRBprhu0kVlj7GV63TU=; 7:dx3x4dSQP6Lr+NL41bcs+PYIfZF500ndUw7aa2ZRa3N1K0Wj/iRAPCyVzqVZMS38js18LuxD5h4YwS9+9jKCNcoViU2pU3wwYPXE5NCoI6z9L8d2H6o8mmoUJ4lSuH3Zdm9HBb54Bep09Mhb6sgF6Vc+6P4/QKHOhZOftOsWU+tTIB1LihO1xNg24/6R18wO1//4OE+eRg5YzPjE7Unf364EEWnbvyjOpq1EmQjbE3k= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: fbaf4d40-1eb4-40f6-cb9c-08d500c66c03 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:HE1PR07MB0857; x-ms-traffictypediagnostic: HE1PR07MB0857: authentication-results: spf=none (sender IP is ) smtp.mailfrom=juha.hakala@helsinki.fi; x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705)(131327999870524); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6041248)(20161123562025)(20161123558100)(20161123560025)(20161123564025)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR07MB0857; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR07MB0857; x-forefront-prvs: 04371797A5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(13464003)(189002)(199003)(377424004)(252514010)(76176999)(8936002)(81156014)(54356999)(33656002)(66066001)(105586002)(81166006)(8676002)(5250100002)(7736002)(74482002)(305945005)(50986999)(2501003)(106356001)(74316002)(2906002)(6116002)(86362001)(2950100002)(102836003)(3846002)(2900100001)(7696004)(5660300001)(3280700002)(101416001)(3660700001)(110136005)(97736004)(68736007)(4326008)(14454004)(6436002)(53546010)(25786009)(6506006)(229853002)(6246003)(189998001)(99286003)(55016002)(8666007)(786003)(6306002)(316002)(9686003)(53936002)(478600001)(53376002)(966005); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB0857; H:HE1PR07MB3099.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: helsinki.fi does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: helsinki.fi X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Sep 2017 07:57:35.7412 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB0857 Archived-At: Subject: Re: [urn] Request for new URN namespace review: LEX X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 07:57:46 -0000 Hello,=20 I have a few comments.=20 Mandate Based on the I-D, it is not clear to me what mandate ITTIG-CNR has. URN:LEX= would complement existing systems; for instance in Finland laws are identi= fied with cool URIs. For instance, English translation of Child welfare act= can be found from http://finlex.fi/en/laki/kaannokset/2007/en20070417.pdf.= In the short term there might not be much interest to implement urn:lex in= the Finlex system. However, I do believe that establishing a urn namespace to sources of law c= an be useful in the long term.=20 Administration=20 ITTIG-CNR will be responsible of maintaining the uniqueness of the element. In the level of country codes this will be easy. But there = may be a large number of sub-divisions within each country, and also organi= zation-based sub-divisions. If urn:lex becomes popular, it may be a substan= tial task to maintain and to support organizations in making= their urn:lex identifiers actionable.=20 Has ITTIG-CNR estimated the amount of work required in the short term / lon= g term? =20 Semantics and syntax=20 The template does not provide sufficient information about the semantics an= d syntax of NSS, but luckily draft-spinosa-urn-lex-11 is very detailed in t= hat respect.=20 Most URN namespaces (and traditional identifiers) have relatively simple se= mantics. Identifiers may be totally "dumb" (it is impossible to see from th= e NSS what the URN identifies) and even if the identifier has some semantic= like ISBN, things are kept simple (for those in the know, ISBN reveals the= country and the publisher). Other persistent identifier system are even mo= re extreme when it comes to semantics: identifiers in ARK, Handle and DOI a= re usually dumb, and recommend strongly that all semantics should be avoide= d.=20 URNs from proposed urn:lex namespace may contain a lot of information about= the identified resource. For instance, I-D contains an example URN like th= is:=20 urn:lex:eu:tibunal.justicia:sentencia:2009-06-11;33-08@original:es$text-htm= l:juradmin.eu;jurifast:todo:anonimo=20 It may be difficult, both for humans and applications, to make sense of thi= s.=20 ITTIG might consider making NSS simpler, and including at least some of the= information which is now embedded in NSS (such as date and file format) in= to metadata records that would accompany URN:LEX identifiers. Having a lot = of semantics in the NSS may overload the resolvers with tasks which should = be done by passing a request to an appropriate target system. It is also mo= re challenging to develop assignment rules for a very semantic identifier s= ystem, and to be able to use such system correctly. =20 As regards syntax, I am concerned about un-encoded use of @ to indicate an = expression of a work:=20 local-name =3D work ["@" expression] ["$" manifestation] Resolution ITTIG-CNR intends to maintain a centralized resolution service for urn:lex.= That is necessary for organization-based sub-domains. But for country-code= based subdomains such as urn:lex:fi, resolvers may be established in the n= ational level (just as in country code based sub-domains of urn:nbn). Gener= ally, if it is not necessary to establish a global resolver service for a n= amespace, it is better to decentralize, since otherwise there will be a sin= gle point of failure.=20 It would of course be possible to harvest URN - URL mapping tables from nat= ional lex resolvers into the central resolver maintained by ITTIG-CNR.=20 All the best, =20 Juha > -----Original Message----- > From: urn [mailto:urn-bounces@ietf.org] On Behalf Of Alexey Melnikov > Sent: 20. syyskuuta 2017 15:13 > To: urn@ietf.org > Cc: draft-spinosa-urn-lex.all@ietf.org > Subject: [urn] Request for new URN namespace review: LEX >=20 > Hi, > as responsible AD for draft-spinosa-urn-lex, I would like to request Expe= rt > Review for a new URN Namespace. > The registration template was extracted from draft-spinosa-urn-lex-11: >=20 > Namespace Identifier: >=20 > "lex" requested according to [RFC8141]. >=20 > Version: >=20 > 1.0 >=20 > Date: >=20 > 2017-05-25 >=20 > Registrant: >=20 > Institute of Legal Information Theory and Techniques (ITTIG) > Italian National Research Council (CNR) > Via de' Barucci, 20 > 50127 Florence > Italy > e-mail: lex@ittig.cnr.it > phone: +39 055 43995 >=20 > contact: Enrico Francesconi > e-mail: enrico.francesconi@ittig.cnr.it >=20 > Purpose: >=20 > The purpose of the "lex" namespace is to assign an unequivocal > identifier, in standard format, to documents that are sources > of law. >=20 > In the last few years a number of institutional initiatives > have arisen in the field of legal document management. They > were aimed at introducing standards for sources of law > description and identification using XML and URI techniques, > respectively (for more details see Section 1.3) LEX identifier > is conceived to be general enough, so to provide guidance at > the core of the standard and sufficient flexibility to cover a > wide variety of needs for identifying all the legal documents > of different nature, namely legislative, case-law and > administrative acts. Moreover, it can be effectively used > within a federative environment where different publishers > (public and private) can provide their own items of an act > (that is there is more than one manifestation of the same act). >=20 > The LEX identifier is conceived to be: globally unique, > transparent, bidirectional, persistent, location-independent, > and language-neutral. It is organized into parts. The first > part uses a predetermined standard to specify the country (or > more generally the jurisdiction) of origin for the legal > document being identified; the remainder is intended for local > use in identifying documents issued in that country or > jurisdiction. This second part depends only on sources of law > identification system operating in that nation. For more > details on the nature of the LEX characteristics and the > general internal organization, see Section 1.4. >=20 > The LEX name is linked to the document through specific meta- > information, internally (with a tag) or externally (with a > attribute) (for details on this see Section 1.5) >=20 > LEX names will be used on a large scale in references either in > (X)HTML document or, more generally, in XML documents format > compliant with the relative DTD/XMLSchema (see Section 1.6 for > more information). >=20 > Syntax: >=20 > The identifier has a hierarchical structure as follows: >=20 > "urn:lex:" NSS >=20 > where is the Namespace Specific String composed as > follows: >=20 > NSS =3D jurisdiction ":" local-name >=20 > where: >=20 > is the part providing the identification of the > jurisdiction, generally corresponding to the country, where the > source of law is issued. It is also possible to represent > international organizations (either states or public > administrations or private entities); >=20 > is the uniform name of the source of law in the > country or jurisdiction where it is issued; its internal > structure is common to the already adopted schemas. It is able > to represent all the aspects of an intellectual production, as > it is a legal document, from its initial idea, through its > evolution during the time, to its realisation by different > means (paper, digital, etc.). >=20 > LEX specifications gives information on the internal structure > of both and , including > specifications about case sensitivity, the use of national > characters and diacritics, as well as spaces, connectives, > punctuation marks, abbreviations, acronyms, date formats and > ordinal numbers. For more details on the internal structure and > syntax of the LEX identifier, see Section 3, 4 and 5. >=20 > Recently the r- and q- components have been introduced by > [RFC8141]. They provide new and interesting perspectives when > using URNs in a complex sector as sources of law, characterized > by different versions, languages, publishers, and so on. In > particular, by using the r-component at the resolver level, and > therefore at the whole NSS level, you can select from the same > work only expressions written in a given language, or > manifestations published by a particular institutional site, > etc. Using the q-component at the act metadata level, you can > select versions that are valid at a particular date, or > modified by a specific act, etc. >=20 > Assignment: >=20 > The Jurisdictional Registrar (or those it delegates) of each > adhering country or organization is responsible of the > definition or acceptance of the uniform name's primary elements > (issuing authority and type of legal measure). >=20 > Any country or jurisdiction, aiming to adopt this schema, > identifies a Jurisdictional Registrar, an organization which > shares and defines the structure of the optional part of the > name, according to the organization of the state or > institution. The process of assigning the will be > managed by each specific country or jurisdiction under the > related element (details on this can be found in > Section 7.2). >=20 > Identifiers in the "lex" namespace are defined through a > element assigned to the sources of law of a > specific country or organization, and a assigned > by the issuing authority. The goal of the LEX schema is to > maintain uniqueness and persistence of all resources identified > by the assigned URNs. The elements values for the LEX > identifier within a jurisdiction are defined by the > Jurisdictional Registrar, this ensures that the constructed > URNs are unique (see Section 7.3 for details on uniqueness). >=20 > The persistence of identifiers depends on the durability of the > institutions that assign and administer them (see Section 7.3 > for details on persitence) >=20 > Security and Privacy: >=20 > This document introduces no additional security considerations > beyond those associated with the use and resolution of URNs in > general. >=20 > Interoperability: >=20 > As open standard naming convention to identify sources of law > at international level, LEX is meant to guarantee > interoperability among legal information systems across > national boundaries. >=20 > The characteristics of the LEX naming convention facilitate > legal document management as well as provide a mechanism of > stable cross-collections and cross-country references, thus > allowing the distribution of the legal information towards a > federated architecture. >=20 > Resolution: >=20 > The resolution service associates a LEX identifier with a > specific document address on the net. The related system will > have a distributed architecture based on two fundamental > components: a chain of information in DNS (Domain Name System) > and a series of resolution services from URNs to URLs, each > competent within a specific domain of the namespace (see > Section 8.1 for more details). >=20 > To cope with possible incomplete or inaccurate uniform names, > the implementation of a catalogue, based on a relational- > database, able to associate a URN to related URLs, is > suggested, as it will lead to a higher flexibility in the > resolution process. A resolver can provide names normalization, > completion of inaccurate or incomplete names, and finally their > resolution in network locations (see Section 8.2 and 8.3 for > characteristics and behaviour of a catalogue for resolution). >=20 > Documentation: >=20 > None >=20 > Additional Information: >=20 > See [FRAN] and [SPIN]. >=20 > Revision Information: >=20 > None >=20 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn