A Uniform Resource Name (URN) Namespace for Sources of Law (LEX)
draft-spinosa-urn-lex-13

Summary: Needs a YES. Has 3 DISCUSSes.

Alissa Cooper Discuss

Discuss (2020-02-19)
Given that this document is AD-sponsored, that it has changed significantly since it went through IETF LC, and that the IETF LC was several years ago, I think it needs to go through IETF LC again before proceeding.

The original Gen-ART review of this document <https://mailarchive.ietf.org/arch/msg/gen-art/A9NBHgeHucLGHlIDgZvAaq7-RyU> raised a major issue about how it is "partially specifying a complete system for federating the naming and access to legal documents." This issue does not appear to have been addressed. I believe Section 8 needs to be separated into a different document to accomplish this. I also don't see how Section 8 can be included and have this document remain informational.

The most recent Gen-ART review of this document <https://mailarchive.ietf.org/arch/msg/gen-art/xR44OWrdejWK77_8CywYhuYsvZo> raises a number of significant issues. I think the totality of that review indicates that this document is not ready for publication. At a minimum, issues 1, 5, 6, 11, and 12 need to be resolved prior to publication.

I support Adam's and Roman's DISCUSS positions.

Roman Danyliw Discuss

Discuss (2020-02-19)
This document does not contain a Security Considerations section.  There is only the following text in Section 2:

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

As this document suggests a notional architecture and workflow for the URNs in this namespace (not just registration of a namespace), one would have expected at least:

-- general caution about handling URI/URNs such as found in RFC3986, “A URI does not in itself pose a security threat.  However, as URIs are often used to provide a compact set of instructions for access to network resources [in this case of LEX, legal documents], care must be taken to properly interpret the data within a URI, to prevent that data from causing unintended access, and to avoid including data that should not be revealed in plain text.”

-- references to security considerations of generic URNs

-- caution on how the resolution of URNs over the network if done in the clear could leak sensitive information based on which specific laws were interesting; and point to privacy enhancing DNS technologies

-- given the delegated environment, caution on how URNs could be used as redirects users to malicious content

-- the vetting process that will be used to delegate portions of the namespace
Comment (2020-02-19)
The text, as written (particularly Section 8), does not appear to provide sufficient detail to create an interoperable system.  However, as this draft is Information, beyond addressing the DISCUSS, I won’t stand the way of the proponents building an ecosystem around this namespace.

Suggested areas of clarifications/polish:

** Section 1.2.  What’s the purpose of indicating these entities supported the publication?  It seems out of place.  Would we say “Vendor-1, University-2, Carrier-3 … supported this proposal?”  IMO, if specific individuals from that organization contributed to this document, please use the acknowledgement section.  

** Section 1.3.  Per “Outside Europe, similar initiatives have faced similar problems”, based on the prior text in this section, it isn’t clear what problems are being described.  The previous text only establishes that various countries are pursuing approaches to “introduce standards for the description of legal sources”.  Their respective design or implementation success isn’t explained.

** Section 1.3.  Consider adding a reference for these statements:
-- “The need for a unequivocal identifier of sources of law in different EU Member States … has been expressed in several conferences …”

-- “Similar concerns have been raised by international groups concerned with free access to legal information, …”

** Section 1.3.  Per “The Permanent Bureau of the Hague Conference on Private International Law is considering a resolution that would encourage member states …”, will references to draft legislation age well in an enduring RFC?

** Section 1.5.  What is a “LEX name”?  Is that the same as a “LEX identifier” previously used?  Recommend establishing the link between these two before use.   

** Section 4.4   Per “it is strongly RECOMMENDED that national characters and diacritic signs are turned into base ASCII characters”, the intent is clear, but what is the proposed deterministic algorithm?

** Section 6.2.  Consider adding a reference for IFLA’s FRBR.

** Section 8.1.  Per “Delegation of this responsibility will not be unreasonably withheld provided that the processes for their resolution and management are robust and are followed.”, can this withholding of delegation be clarified.

** Editorial Nits
-- Section 2.  Typo.  s/persitence/persistence/

-- Section 2.  Resolution.  What is “on the net”?  If that means the internet, consider using less colloquial language.

Benjamin Kaduk Discuss

Discuss (2020-02-19)
There is no Security Considerations section, required by RFC 7322, so I
support Roman's Discuss.  I'll also add a note that the presence of
aliases for a given resource also has potential security considerations,
as the aliased URNs are no longer unique identifiers.

I also support Alissa and Adam's Discusses.

Repeated advocacy for the use of http URLs seems misplaced in this
modern era (https is the appropriate replacement, providing for data
integrity and source authentication even when confidentiality is not
important).

The HTTP LEX identifier structure(s) proposed in Attachment D's
subsections are grossly inconsistent with BCP 190, and even the proposed
update in draft-nottingham-rfc7320bis.

There seems to be something of a mismatch between the goal of having "an
unequivocal identifier" and the weakness of only having a "recommended
construction" for the identifier.

The registration template in Section 2 seems internally inconsistent,
saying both that "use of r- and q-components [...] is not defined in
this document" but then going on to talk about things that can be done
using both the r-component and the q-component.

The ABNF in Attachment A uses only the 2*3alfa portion of the language
construction from BCP47, but BCP47 allows several other variants, and I
didn't see any descriptive text that indicates this limitation is
intentional.

The ABNF in Attachment A also does not admit the localization of the
"all" literal for the manifestation construction that is discussed in
the body text.

I agree with the conclusion of the genart reviewer: in aggregate, this
document is not ready for publication.  That said, I also agree with
Barry, that it's important to have a document published that properly
registers the "LEX" URN namespace ... there's just more work to be done
before this document can be that document.
Comment (2020-02-19)
Section 1.1

   document. Even a document that is not available online at all may
   still have a URN LEX that identifies it.

I'm not sure how to parse this; isn't "URN" the subject and "LEX" an
adjective modifying it (so that the order would be "LEX URN")?

Section 1.2

It's not clear that hardcoding this list into the immutable RFC provides
useful archival value.

   The following entities support this proposal at the time of
   publication:

Is this "support" in the sense of "utilize LEX URNs as identifiers" or
"believe that the proposal has merit and should proceed"?

Section 1.3

   In the last few years a number of initiatives have arisen in the
   field of legal document management.

I suggest rewording to a formulation that will not grow stale over time.

   Recently in the European Union, the community institutions have
   stressed the need for citizens, businesses, lawyers, prosecutors and
   judges to become more aware not only of (directly applicable) EU law,
   but also of the various national legal systems. The growing

"Recently" will still not age well.
Also, is this a recommendation to be aware of the existence of the
national legal systems, or particular aspects thereof?

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

It's rather unfortunate that this is http-based, not https-based, since
regular http does not provide integrity protection or source
authentication.

   However specifications and syntax rules of LEX identifier can be used
   also for http-based naming convention (Appendix D) to cope with

[http (not https) again]

Section 1.4

   Registrants wish now to promote interoperability among legal
   information systems by the definition of a namespace convention and
   structure that will create and manage identifiers for legal

Who are "registrants", here?  (Also, I think "now wish" is a more
conventional word order, not that talking about "now" is very helpful in
an archival document.)

   documents. The identifiers will be:
   - globally unique
   - transparent
   - bidirectional

What does "bidirectional" mean?  I note that it has a usage in terms of
"bidirectional text" (combining both left-to-right scripts and
right-to-left scripts), which one might perhaps imagine combining in LEX
URNs (and has its own technical challenges), but I'm not sure whether
that's what's intended.  For the "can go back and forth from one form to
the other", I think that "reversible" or "invertable" are more common
words.

   Transparency means that given an act and its relevant metadata
   (issuing authority, type of measure, etc.) it is possible to create
   the related urn identifier. Moreover this identifier is able to
   unequivocally identify the related act. These two properties makes
   the identification system bidirectional (from an act to its URN and
   from a URN to the related act).

These properties, again, seem inconsistent with merely having a
"recommended" scheme for constructing URNs; achieving them seems to
require rigid rules.

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

nit: singular/plural mismatch "sources of law"/"system".
nit: "information" does not need an article

   The identification system based on uniform names SHOULD include:

What is having requirements imposed on it by this list -- the remainder
of this specification?  If so, normative language does not seem
appropriate.

   - a schema for assigning names capable of representing unambiguously
     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);

nit: I suggest a parallel linguistic construction that places "namely
legislation, case law, and administrative acts" in parentheses to match
the other two top-level list elements.

   - a resolution mechanism - in a distributed environment - that ties a
     uniform name to the on-line location of the corresponding
     resources.

nit: I suggest "resource(s)"

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

"Only" doesn't seem appropriate given that we follow it up with "also,
part of the other one".

Section 1.5

   - externally by means of an RDF triple, a specific attribute in a
     database, etc.

Please expand and/or provide a reference for "RDF"; it's not marked as
"well-known" at
https://www.rfc-editor.org/materials/abbrev.expansion.txt .

   One of these modalities is necessary for enabling automated

nit: exactly one, at least one, or a specific one?

Section 1.6

   LEX names will be used on a large scale in references as a HREF
   attribute value of the hypertext link to the referred document.

Forward-looking statements like this ("large scale") are risky; what if
reality proves to have different plans?

   In any case, whatever the method adopted is, new documents produced
   in XML format compliant with the relative DTD/XMLSchema, SHOULD
   express references through the uniform name of the document referred
   to.

I don't know what schema this is referring to.

Section 1.7

   - Jurisdictional Registrar:
     is an organization which shares and defines in any country or
     jurisdiction the assignment of the main components of the resource
     identifier through which its uniqueness is guaranteed. This task

What does "its" refer to?

     includes the definition of possible jurisdiction unit and the
     primary elements (issuing authority and type of legal measure) of
     uniform name, according to the characteristics of its own state or
     institution organization.

nits(?): I think maybe this is intended as "allowed jurisdiction units"
and "uniform names", though I'm not entirely sure.

Section 1.8

RFC 8174 has updated the BCP 14 boilerplate originally defined in RFC
2119.

Section 2

         In the last few years a number of institutional initiatives
         have arisen in the field of legal document management. They

[still not going to age well]

         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

This seems needlessly ambiguous to parse.  For example, I could group it
as "standards for (sources of law) (description and identification)",
"(standards for sources of law) (description and identification)", or
potentially even "standards for (sources of) (law description and
identification)".

         The LEX identifier is conceived to be: globally unique,
         transparent, bidirectional, persistent, location-independent,

[if "bidirectional" is changed above it should change here as well]

         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).

[same comment about forward-looking statements]
[same comment about "the relative DTD/XMLSchema"]

         <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

So we don't care about state, regional, municipal, or other laws more
locally scoped than country?

         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

Perhaps it's just me, but "<jurisdiction> element" makes it really hard
to think of anything that's not an XML-like markup language.

         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).

nit: comma splice.

         The resolution service associates a LEX identifier with a
         specific document address on the net. The related system will

The resolution service that Section 1.4 claims we're not considering in
this document?

         have a distributed architecture based on two fundamental
         components: a chain of information in DNS (Domain Name System)

What "related system"?

         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).

I shared the directorate reviewer's unease about recommending such
flexibility/fuzziness.

Section 3.1

   The <jurisdiction> element is composed of two specific fields:

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

I echo the directorate reviewer's concerns about using semicolon as a
delimeter.

   To facilitate the transparency of the name, the <jurisdiction-code>
   follows usually the rules of identification of other Internet

Usually?  How am I supposed to build unequivocable service based on
"usually"?

   urn:lex:us:federal.supreme.court:decision:1963-03-18;372.us.335 (US
   FSC decision)

I'm not sure I understand the "us:federal.supreme.court" bit (i.e., why
no semicolon is needed).

Section 3.2

   The "lex" NID syntax conforms to [RFC8141]. However, a series of
   characters are reserved to identify elements or sub-elements, or for
   future extensions of the identifier.

Which identifier?

Section 4.4

   If this conversion is not acceptable by a specific jurisdiction, UTF-
   8 %-encoding [STD63] may be used. In this case it should be noted
   that the generated URN (as some of its parts) can not be used
   directly for routing through DNS, and therefore the jurisdiction must
   adopt one of the following strategies:

I think technically the following list is not an exhaustive one (as the
current wording indicates), as (e.g.) a non-punycode DNS encoding might
be used under the control of a specific domain.

Section 5.2

   The use of acronyms might be confusing and encourage ambiguity in
   uniform names (the same acronym may indicate two different
   institutions or structures), therefore their expansion is highly
   RECOMMENDED.

Who is this recommendation directed at?
Who is responsible for ensuring uniqueness of identifiers and the
absence of ambiguity?

Section 6.1

   The uniform name must identify one and only one document (more
   precisely a "bibliographic entity") and is created in such a way that

Please define "bibliographic entity" whether directly or by reference.

Section 6.2

   In this document the FRBR model has been interpreted for the specific
   characteristics of the legal domain. In particular, a part from the

nit: s/a part/apart/ (right?)

Section 6.4

   <measure> is the type of the measure, both public nature (e.g.,
   constitution, act, treaty, regulation, decree, decision, etc.) as
   well as private one (e.g., license, agreement, etc);

A license or agreement can be a source of *law* erga omnes?!

   Examples (hypothetical) of <work> identifiers are:

   urn:lex:it:stato:legge:2006-05-14;22
   urn:lex:uk:ministry.justice:decree:1999-10-07;45

What happens if there's more than one decree from the ministry of
justice on a given day?

Section 6.6

   <version> is 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; anyway other specific
   information can be used for particular documents. If necessary, the

This is not looking so good from the perspective of "going backwards"
from a given document to the authoritative LEX URN based solely on the
document...

   urn:lex:ch:etat:loi:2006-05-14;22@originel:fr (original version in
   French)
   [...]
   urn:lex:be:conseil.etat:decision:2008-07-09;185.273@originel:fr
   (original version in French of a Belgian decision)

These are inconsistent with the text three paragraphs prior about '''the
string "original"'''.

Section 6.7

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

This substitution seems like it could introduce ambiguity (there are
*many* instances of "-" in
https://www.iana.org/assignments/media-types/media-types.xhtml).

   - editorial staff who produced it, expressed according to its
     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 for each of them a new manifestation with the
     new domain name;

I'm confused.  This sounds like "to make such a manifestation available,
some other manifestation will have to be used instead of the original
manifestation", which sounds an awful lot like "such a manifestation
cannot be made available".

   The <manifestation> suffix will thus read:

             manifestation = format ":" editor
                             [(":" component [":" feature]) /
                              (":" "all" ":" feature)]

I thought the string "all" was supposed to be a language-dependent
label; this ABNF does not allow for such behavior.  The following
paragraph notwithstanding, I would suggest using a dedicated ABNF
construction for <language-specific-"all">.

   equivalents. To indicate possible features or peculiarities, each
   main element of the manifestation MAY be followed by further
   specifications, for example as regards <format> the version, for

"Followed" using what separator?

Section 6.8

   represented by an element (a block of text) with its own ID; this ID
   aims to identify the related element and to locate it. In this case,
   therefore, it is possible either extracting or pointing to a
   partition.

nit: s/extracting or pointing/to extract or to point/

   In both cases, having a partition identifier is useful; therefore,
   for allowing browsers to point to a specific partition, it is
   necessary that such partition is endowed with an unequivocal label or
   ID within the including document and its value is the same
   independently from the document format.

What/who is going to require (and enforce) the consistency of ID value
across formats?

   For enabling the construction of the partition identifier between
   different collections of documents, specific construction rules for
   IDs or labels SHOULD be defined and shared, within each country or
   jurisdiction, for any document type (e.g., for legislation, the

When might this "SHOULD" be violated?

   (e.g., to refer to the paragraph 3 of the article 15 of the French
   Act of 15 may 2004, n. 106, the reference is written
   "urn:lex:fr:etat:loi:2004-05-15;106~art15;par3").

nit: unless the French jurisdictional registrar has already promulgated
this encoding, I suggest to avoid definitive language such as "is
written".

   Anyway, to make it effective in a browser pointing to the indicated
   partition, the resolver SHOULD transform the partition ID of each
   returned URL in a URI fragment; this is obtained appending to the URL
   the "#" character followed by the partition ID (in the example above,
   the returned URL will be <URL-document>#art15;par3). Doing this,

Has this recommendation seen specific review from ART-area expertise?
It seems surprising to me, though I am not an expert in this area.

Section 7.1

   the source of law of that country or jurisdiction. This code is
   assigned according to ccTLD (as well as TLDN or DN for the

Please expand TLDN and DN.

Section 7.2

   Such a set of rules will have to be followed by all institutional
   bodies adherent to the project as well as by private publishers and
   each of them will be responsible for assigning names to their
   domains.

What is "the project"?

Section 8.1

   Such DNS routing chain does not work for all the URN components
   containing %-encoded characters. Therefore in these cases a proper
   software implementing punycode conversion or routing service has to
   be developed.

Given that a goal of this proposal is to make national law accessible to
all audiences (including international ones), it seems an unreasonable
requirement to expect a given user outside of the jurisdiction requiring
such a routing service to know how to properly use that routing service
to access the law information.  I note that clients may not be
performing (e.g.) QNAME minimization and would thus face errors when
attempting to construct a request for the full resource, even though a
reduced query would allow it to proceed towards a more local resolver
that may be aware of the necessary procedures for handling
percent-encoded characters.

Section 8.2, 8.3

[same comment as above in Section 2 regarding "fuzziness"]

Section 10

   quality and currency. A shared identification mechanism resources
   guarantees that a distributed system will be as efficient and
   effective as a comparable centralized system.

nit: singular/plural mismatch ("mechanism resources")

   Creators of Internet content that references legal materials -
   including publishers operating well outside the traditional arenas of
   legal publishing - benefit by the registration of the namespace
   because facilitates the linking of legal documents, whether by manual
   or automated means, and reduces the cost of maintaining documents
   that contain such references.

nit: s/because facilitates/because it facilitates/ (?)

   Any citizen or organisation with Internet web browser capability will
   be entitled to access the namespace and its associated application,
   registers, and resolution services, to facilitate document access.

Who is going to enforce this?  It is a laudable goal and consistent with
IETF ideals on openness and transparency, but regrettably the law is not
open-access at present in all jurisdictions.

   It is envisaged to promote the urn:lex identification system for
   sources of law through all the various dissemination channels such as
   conferences, a project dedicated website, references from other
   projects, etc.

This doesn't really seem to add value in an archival document.

Section 11.1

   where <urn-lex.zone.org> indicates the server of the organization
   that is responsible for the "lex" area under urn.arpa and
   urn.uri.arpa, and will be specified at implementation time.

What is "implementation time"?  When IANA processes the registration?

Section 11.2

   - <registrant>: all information about the organization that requested
     the registration of the code. Such organization will be responsible

"All information" subject to what scope?  "All information" about an
organization seems potentially unbounded...

   In the current experimental LEX registration phase, ITTIG-CNR will
   take care to create and maintain the registry for <jurisdiction-
   code>. As the criteria of the LEX names assignment will be
   consolidated, after the experimental phase such registry will be
   maintained by IANA.

What are the criteria to determine the exit from the "experimental
phase"?

   - in case when such multi-national or international organization does
     not have a registered domain, Designated Expert(s) should assign
     something like <name>.lex.arpa, where <name> is the English acronym
     of the organization name. For example, the jurisdiction code of the
     European Economic Community is "eec.lex.arpa".

*is*?!  This assignment has already been made?

Attachment A

There doesn't seem to be anything to distinguish between the
"institution" and "office" constructions.

It's slightly surprising to see a production named "alfanum" admit
percent-encoded values as well.

Attachment B1.2

How is a list of multiple issuers sorted to obtain a definitive
identifier?

Attachment B2.3

   In order to ensure, in all the cases, the validity of the references,
   an alias that takes into account the measure category is associated
   to the uniform name, representing the legislative form.

I don't understand what is meant by "is associated to".

Attachment B3.3

   To ensure that the uniform name is unambiguous, the <numbers> field
   MUST, in any case, contain a discriminating element, which can be any
   identifier used internally, and not published, by the authority
   (e.g., protocol).

How can an identifier be not published and used only internally but
remain part of the URN that unequivocally identifies a measure?

Attachment B3.4

   This conversion may imply that the uniform name of the document is no
   more unique (e.g., removal 123-BIS and return 123/BIS of the bill 123
   both are identified as "123-bis"); in this case, it is necessary to
   add a specific distinctive ending (e.g., "123-bis-removal" and "123-
   bis-return").

This seems awkward to implement and introduces state to the allocation
process such that there is an ordering dependency on how identifiers are
allocated.  In particular, it cannot be known in advance if some other
document will be created that this procedure would cause to produce a
conflict in need of a distinctive ending, so in some sense a distinctive
ending should always be used.

Attachment B4.1

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

["unequivocally" seems to be used much more than "univocally" in the
rest of this document]

Attachment C1.1

   In a "multi-version" document each time interval should have a link
   to the related in-force document version obtained by displaying in a
   different way the very same document.

I don't understand what this sentence means.  What is "obtained by
displaying in a different way the very same document"?  How is a given
document supposed to be "displayed in a different way"?

   - <amendment-date> contains the issuing date of the last considered
     amendment or of the last communication of amendment. In case 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";

Is this string localized to the relevant language?

Attachment D1

   Http URIs have been recently promoted as stable and location-
   independent identifiers [RFC3986].  According to this syntax, at all

As noted by the directorate reviewer, "recently" seems very out of place
here.

I reiterate my unease at using "http" vs. "https".

   Such kind of identifiers have been recently suggested also within the

["recently" again; RFC 5988 is hardly "recent" (ten years old) and the
w3.org reference older still]

   identifier and manifestation of an act). The independence from the
   resource location is managed by a "303 Redirect" status code (see
   http://linkeddatabook.com/editions/1.0/#htoc11) which may require a

I suggest that RFC 7231 is a much more appropriate reference for the
"303 See Other" status code.

(Alexey Melnikov) (was Yes) Discuss

Discuss (2020-02-21)
[Updated. See some extra comments at the end.]
I have some small issue which need fixing before I would recommend approval of this document:

1) ABNF for "manifestation" in Attachment A doesn't match the same from Section 6.7:

In 6.7:

             manifestation = format ":" editor 
                             [(":" component [":" feature]) /
                              (":" "all" ":" feature)]

In Attachment A:

manifestation = format *(";" specification)
                ":" editor *(";" specification)
                [(":" component [":" feature]) /
                 (":" "all" ":" feature)] 


It looks like you updated the definition in Section 6.7, but forgot to update the Attachment A to match. Please advise how you intend to fix this.
Comment (2020-02-21)
1) In 6.7:

   Note that the value "all" can be expressed by language-dependent	
   equivalents.

The ABNF seems to suggest that "all" is always supported. Is the word "also" missing after "can"?

2) In 6.8:

   Using a different separator ("~") from the document name, the
   partition ID is not withheld by the browser but it is transmitted to
   the resolution process. This enables the resolver to retrieve (for
   example, out of a database), if it is possible, only the referred
   partition, otherwise to return the whole act.
   Anyway, to make it effective in a browser pointing to the indicated
   partition, the resolver SHOULD transform the partition ID of each
   returned URL in a URI fragment; this is obtained appending to the URL
   the "#" character followed by the partition ID (in the example above,
   the returned URL will be <URL-document>#art15;par3)

Note that the fragment syntax is defined by the media type retrieved, so the above comment is only going to be valid if the partition syntax is compatible with the URI fragment for the media type used!


**********************************************************************
* Note, that I am conducting an experiment when people aspiring to be*
* Area Directors get exposed to AD work ("AD shadowing experiment"). *
* As a part of this experiment they get to review documents on IESG  *
* telechats according to IESG Discuss criteria document and their    *
* comments get relayed pretty much verbatim to relevant editors/WGs. *
* As an AD I retain responsibility in defending their position when  *
* I agree with it.                                                   *
* Recipients of these reviews are encouraged to reply to me directly * 
* about perceived successes or failures of this experiment.          *
**********************************************************************

I also have some comments on Benjamin's comments below marked with "[[Alexey]]:"


The following comments were provided by Benjamin Schwartz <bemasc@google.com>:

Benjamin would have balloted *DISCUSS* on this document. He wrote:

**********************************************************************
* Note, that I am conducting an experiment when people aspiring to be*
* Area Directors get exposed to AD work ("AD shadowing experiment"). *
* As a part of this experiment they get to review documents on IESG  *
* telechats according to IESG Discuss criteria document and their    *
* comments get relayed pretty much verbatim to relevant editors/WGs. *
* As an AD I retain responsibility in defending their position when  *
* I agree with it.                                                   *
* Recipients of these reviews are encouraged to reply to me directly * 
* about perceived successes or failures of this experiment.          *
**********************************************************************

The following comments were provided by Benjamin Schwartz <bemasc@google.com>:

Benjamin would have balloted *No Objections* on this document. He wrote:

I support the URN proposal here, but assigning control of this namespace is unnecessary and should be avoided.  We need more clarity around which requirements bind whom, because of the jurisdiction-specified format, and around the lookup procedure.  I also think the intended status should be Proposed Standard or Experimental, given the detailed, novel proposal.


## Section 1.3


The two sentences:
> “Outside Europe, similar initiatives have faced similar problems.”  “Numerous less-visible efforts in the United States and elsewhere have struggled with similar issues.”
What problems?  The text doesn’t identify any problems or struggles.  Please explain or rephrase.


## Section 3.1


Please specify the allowed characters in jurisdiction-code and jurisdiction-unit.


Please provide an example of how this URN is expected to work for legal systems that do not principally rely on a roman-type alphabet.


The text claims that jurisdictions are free to choose their own format, but the listed examples all conform to a single structure.  This is confusing.


## Section 5


The thing being described in this section needs a name.  I would suggest calling it the “baseline structure”, “simple schema”, or similar.  That would allow improved clarity about when these requirements are binding, e.g. they are binding only if the jurisdiction chooses to adopt the baseline structure.


# Section 6.4


I can no longer tell who is bound by this.  Is this part of the recommended simple schema in Section 5, or is it a binding requirement on all schemas that might be used by jurisdictions?


The example of “fsf.org” as a “jurisdiction” suggests that the word “jurisdiction” is not appropriate for this element.  “Source of law” would be better.  If the name “jurisdiction” is kept, a substantial caveat text up front would be appropriate, and all text indicating that this is “normally a country” should be removed, as non-state entities produce vastly more indexable legal documents than the states themselves.


# Section 6.8


What is an “<a name> tag”?  This should have a reference.


# Section 7.1


Why “country or international organization”?  Surely national and local non-governmental organizations, corporations, or natural persons might also produce legal documents of interest?


“is assigned” by whom?  At a minimum, needs a forward reference to Section 7.4


# Section 7.4


   In particular, ITTIG-CNR, as proposer, is responsible of maintaining
   the uniqueness of the <jurisdiction> element


Why do we need ITTIG-CNR to take on this role?  We already have the DNS itself.  Why not simply declare that the jurisdiction element is a domain name?


# Section 8.1


This technical architecture unnecessarily replicates the existing DNS TLD system, restricts participation in the LEX scheme, and centralizes control (and vulnerability) of the LEX namespace.  Instead of constructing a domain using the suffix “lex.urn.arpa”, this draft should use an attrleaf label (https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-16) (e.g. “_lex”) as a prefix.


   Such DNS routing chain does not work for all the URN components
   containing %-encoded characters. Therefore in these cases a proper
   software implementing punycode conversion or routing service has to
   be developed.


This paragraph should be rephrased as a normative requirement to implement IDN-punycode conversion with an RFC reference.


RFC 2169 is ancient, experimental, and hasn’t been cited in 15 years.  If it’s mentioned here, it needs more of a disclaimer, especially since it predates HTTPS.  However, I also think it’s the wrong architecture in this case.  Instead of identifying “the characteristics (protocol, port, site) of the service ... capable of associating the relative URLs with the URN in question”, it would be more flexible to simply declare that client shall do a NAPTR query that resolves to an HTTPS URL, which conveys the document itself.  If redirection is needed, HTTP 301 will suffice.


# Section 11.2


As noted above, there is no need for a lex.urn.arpa domain, or a new registry.  In the case of institutions that no longer exist (e.g. EEC), they can be represented by their successor institutions, or explicitly as subdomains of historic archives.  Representations without active control would place the registry in the position of arbiter of history.  We should not ask ITTIG-CNR or IANA to resolve disputes on who shall control the records of the law of the Soviet Union, Ancient Rome, or any other defunct institution.  We can simply let the user decide, by their choice of “jurisdiction” domain.

(Adam Roach) Discuss

Discuss (2020-02-19)
This document refers to itself as a "standard" in approximately 30 different places. This seems problematically misleading for a document being published as Informational.
Comment (2020-02-19)
Section 1.8: Please update this section to use the boilerplate from RFC 8174.

I share Barry's concerns, but reach the same conclusion as he has.

Deborah Brungard No Objection

Barry Leiba Abstain

Comment (2020-02-07)
As I've explained in extensive reviews of this document over its long, overly delayed history, I think there are serious issues with this document and how the "lex" URN namespace will be managed... but I also think it's more important to get it defined and registered, and to let the proponents manage it and prove me wrong.

Éric Vyncke Abstain

Comment (2020-02-20)
Thank you for the authors for this long effort for a useful and valid goal.

As I am running out of time to review seriously and in depth this document, I am balloting 'ABSTAIN" but please note that while I am not always supporting all DISCUSS points by default (or even I do not agree with them); but, on this one Alissa's, Roman's, and Adam's DISCUSS appear like pretty valid and MUST be addressed...

Martin Duke No Record

Erik Kline No Record

Murray Kucherawy No Record

Warren Kumari No Record

Alvaro Retana No Record

Martin Vigoureux No Record

Magnus Westerlund No Record

Robert Wilton No Record