A Uniform Resource Name (URN) Namespace for Sources of Law (LEX)
Summary: Needs a YES. Has 3 DISCUSSes.
Alissa Cooper Discuss
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
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
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
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.
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
[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.
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 <email@example.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 <firstname.lastname@example.org>: 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
This document refers to itself as a "standard" in approximately 30 different places. This seems problematically misleading for a document being published as Informational.
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
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
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...