[urn] Request for new URN namespace review: LEX

Alexey Melnikov <aamelnikov@fastmail.fm> Wed, 20 September 2017 12:13 UTC

Return-Path: <aamelnikov@fastmail.fm>
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: <xms:V1vCWSMq1JrO8JaP0xIo-q3NImzjRWG2KcfkaHbL7XuoCC0kq20yIw>
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 <aamelnikov@fastmail.fm>
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: <https://mailarchive.ietf.org/arch/msg/urn/Nt0SQ3D88MUmbp0W_sgIGxpd-QU>
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 <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/urn/>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=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 <NSS> is the Namespace Specific String composed as
         follows:

                   NSS = jurisdiction ":" local-name

         where:

         <jurisdiction> is the part providing the identification of the
         jurisdiction, generally corresponding to the country, where the
         source of law is issued. It is also possible to represent
         international organizations (either states or public
         administrations or private entities);

         <local-name> is the uniform name of the source of law in the
         country or jurisdiction where it is issued; its internal
         structure is common to the already adopted schemas. It is able
         to represent all the aspects of an intellectual production, as
         it is a legal document, from its initial idea, through its
         evolution during the time, to its realisation by different
         means (paper, digital, etc.).

         LEX specifications gives information on the internal structure
         of both <jurisdiction> and <local-name>, including
         specifications about case sensitivity, the use of national
         characters and diacritics, as well as spaces, connectives,
         punctuation marks, abbreviations, acronyms, date formats and
         ordinal numbers. For more details on the internal structure and
         syntax of the LEX identifier, see Section 3, 4 and 5.

         Recently the r- and q- components have been introduced by
         [RFC8141]. They provide new and interesting perspectives when
         using URNs in a complex sector as sources of law, characterized
         by different versions, languages, publishers, and so on. In
         particular, by using the r-component at the resolver level, and
         therefore at the whole NSS level, you can select from the same
         work only expressions written in a given language, or
         manifestations published by a particular institutional site,
         etc. Using the q-component at the act metadata level, you can
         select versions that are valid at a particular date, or
         modified by a specific act, etc.

      Assignment:

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

         Any country or jurisdiction, aiming to adopt this schema,
         identifies a Jurisdictional Registrar, an organization which
         shares and defines the structure of the optional part of the
         name, according to the organization of the state or
         institution. The process of assigning the <local-name> will be
         managed by each specific country or jurisdiction under the
         related <jurisdiction> element (details on this can be found in
         Section 7.2).

         Identifiers in the "lex" namespace are defined through a
         <jurisdiction> element assigned to the sources of law of a
         specific country or organization, and a <local-name> assigned
         by the issuing authority. The goal of the LEX schema is to
         maintain uniqueness and persistence of all resources identified
         by the assigned URNs. The elements values for the LEX
         identifier within a jurisdiction are defined by the
         Jurisdictional Registrar, this ensures that the constructed
         URNs are unique (see Section 7.3 for details on uniqueness).

         The persistence of identifiers depends on the durability of the
         institutions that assign and administer them (see Section 7.3
         for details on persitence)

      Security and Privacy:

         This document introduces no additional security considerations
         beyond those associated with the use and resolution of URNs in
         general.

      Interoperability:

         As open standard naming convention to identify sources of law
         at international level, LEX is meant to guarantee
         interoperability among legal information systems across
         national boundaries.

         The characteristics of the LEX naming convention facilitate
         legal document management as well as provide a mechanism of
         stable cross-collections and cross-country references, thus
         allowing the distribution of the legal information towards a
         federated architecture.

      Resolution:

         The resolution service associates a LEX identifier with a
         specific document address on the net. The related system will
         have a distributed architecture based on two fundamental
         components: a chain of information in DNS (Domain Name System)
         and a series of resolution services from URNs to URLs, each
         competent within a specific domain of the namespace (see
         Section 8.1 for more details).

         To cope with possible incomplete or inaccurate uniform names,
         the implementation of a catalogue, based on a relational-
         database, able to associate a URN to related URLs, is
         suggested, as it will lead to a higher flexibility in the
         resolution process. A resolver can provide names normalization,
         completion of inaccurate or incomplete names, and finally their
         resolution in network locations (see Section 8.2 and 8.3 for
         characteristics and behaviour of a catalogue for resolution).

      Documentation:

         None

      Additional Information:

         See [FRAN] and [SPIN].

      Revision Information:

         None