A Uniform Resource Name (URN) Namespace for Sources of Law (LEX)
draft-spinosa-urn-lex-24
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2024-11-14
|
24 | (System) | RFC Editor state changed to AUTH48 |
2024-10-07
|
24 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2024-10-04
|
24 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2024-10-04
|
24 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2024-10-04
|
24 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2024-09-05
|
24 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2024-09-04
|
24 | (System) | IANA Action state changed to In Progress from On Hold |
2024-08-17
|
24 | PierLuigi Spinosa | New version available: draft-spinosa-urn-lex-24.txt |
2024-08-17
|
24 | (System) | New version approved |
2024-08-17
|
24 | (System) | Request for posting confirmation emailed to previous authors: Caterina Lupo , Enrico Francesconi , PierLuigi Spinosa |
2024-08-17
|
24 | PierLuigi Spinosa | Uploaded new revision |
2024-08-14
|
23 | PierLuigi Spinosa | New version available: draft-spinosa-urn-lex-23.txt |
2024-08-14
|
23 | (System) | New version approved |
2024-08-14
|
23 | (System) | Request for posting confirmation emailed to previous authors: Caterina Lupo , Enrico Francesconi , PierLuigi Spinosa |
2024-08-14
|
23 | PierLuigi Spinosa | Uploaded new revision |
2024-07-02
|
22 | (System) | IANA Action state changed to On Hold from In Progress |
2024-07-02
|
22 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2024-07-01
|
22 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2024-07-01
|
22 | (System) | IANA Action state changed to In Progress from On Hold |
2024-06-21
|
22 | (System) | IANA Action state changed to On Hold from In Progress |
2024-06-21
|
22 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2024-06-18
|
22 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2024-06-18
|
22 | (System) | IANA Action state changed to In Progress from On Hold |
2024-06-12
|
22 | (System) | IANA Action state changed to On Hold from In Progress |
2024-06-12
|
22 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2024-05-24
|
22 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2024-05-24
|
22 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2024-05-23
|
22 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2024-05-15
|
22 | (System) | RFC Editor state changed to EDIT |
2024-05-15
|
22 | (System) | IANA Action state changed to In Progress |
2024-05-15
|
22 | Eliot Lear | ISE state changed to Sent to the RFC Editor from In ISE Review |
2024-05-15
|
22 | Eliot Lear | Sent request for publication to the RFC Editor |
2024-05-15
|
22 | (System) | Revised I-D Needed tag cleared |
2024-05-15
|
22 | Enrico Francesconi | New version available: draft-spinosa-urn-lex-22.txt |
2024-05-15
|
22 | (System) | New version approved |
2024-05-15
|
22 | (System) | Request for posting confirmation emailed to previous authors: Caterina Lupo , Enrico Francesconi , PierLuigi Spinosa |
2024-05-15
|
22 | Enrico Francesconi | Uploaded new revision |
2024-03-18
|
21 | Eliot Lear | Tag Revised I-D Needed set. |
2024-02-16
|
21 | Cindy Morgan | ISE state changed to In ISE Review::IESG Review Completed from In IESG Review |
2024-02-12
|
21 | Amanda Baber | IANA Experts State changed to Expert Reviews OK from Reviews assigned |
2024-02-12
|
21 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2024-01-31
|
21 | Murray Kucherawy | Shepherding AD changed to Murray Kucherawy |
2024-01-02
|
21 | Amanda Baber | (Via drafts-eval@iana.org): IESG/Authors/ISE: IANA will need the authors to take action before we can complete the registrations for draft-spinosa-urn-lex-21. It should also be noted … (Via drafts-eval@iana.org): IESG/Authors/ISE: IANA will need the authors to take action before we can complete the registrations for draft-spinosa-urn-lex-21. It should also be noted that the public mailing lists meant to review those registrations may not have many active members. We understand that this document will require three IANA actions: 1) updating the reference for the existing "lex" registration at https://www.iana.org/assignments/urn-namespaces, 2) adding a NAPTR record to the urn.arpa domain, and 3) adding a NAPTR record to the urn.uri.arpa domain. However, according to RFC 3405, in order to add records to urn.arpa and uri.arpa, the authors must submit their requests to these mailing lists for a two-week public review: https://mm.icann.org/mailman/listinfo/register-urn https://mm.icann.org/mailman/listinfo/register-uri Because those lists (which haven't seen much activity post-2011) currently have ~20 members each, we've sent informal review requests to Leslie Daigle and Ted Hardie. We haven't heard from Leslie yet, but Ted had these notes: > My quick scan of this sees a few potential issues with things listed > as SHOULD which I believe would be better as MUST; I was also a little > confused by this: > > "Such DNS routing chain does not work for all the URN components > containing %-encoded characters. Therefore, when converting a lex:URN > in UTF-8 code to a DNS query, clients MUST perform any necessary > punycode conversion [RFC5891] before sending the query." There are no designated experts for urn.arpa or uri.arpa, so unless the IESG instructs us otherwise, we'll mark this document "IANA OK" two weeks after the authors submit their review requests, provided that the lists don't raise any of the objections described in Section 5 of RFC 3405. Best regards, Amanda Baber IANA Operations Manager |
2023-12-21
|
21 | Eliot Lear | ISE state changed to In IESG Review from Response to Review Needed |
2023-12-21
|
21 | Eliot Lear | IETF conflict review initiated - see conflict-review-spinosa-urn-lex |
2023-12-21
|
21 | Eliot Lear | draft-spinoza-urn-lex has been presented to the ISE for publication as an Informational RFC on the Independent Stream. ==Purpose== This memo specifies a process for uniquely … draft-spinoza-urn-lex has been presented to the ISE for publication as an Informational RFC on the Independent Stream. ==Purpose== This memo specifies a process for uniquely identifying legislation. == History== This document was first considered by the IETF in 2009(!). After quite some time, it was AD sponsored. It was reviewed, DISCUSSED, revised, and then hit the ISE queue in April of 2021. During this period it went through extensive review and revision. ==Non-IETF Work== This document has received a positive review from Cornell's Legal Information Institute. Resolution and assignment processes will be handled outside IANA (apart from URN.ARPA). ==Security Considerations== See Section 11 of the document. ==IANA== An entry in URN.ARPA has already been assigned. See Section 12 of the documenmt. ==Reviews== Numerous people have reviewed this work, both inside and outside the IETF. Peter Saint-Andre provided the URN review. |
2023-12-15
|
21 | PierLuigi Spinosa | New version available: draft-spinosa-urn-lex-21.txt |
2023-12-15
|
21 | (System) | New version approved |
2023-12-15
|
21 | (System) | Request for posting confirmation emailed to previous authors: Caterina Lupo , Enrico Francesconi , PierLuigi Spinosa |
2023-12-15
|
21 | PierLuigi Spinosa | Uploaded new revision |
2023-11-14
|
20 | (System) | Revised I-D Needed tag cleared |
2023-11-14
|
20 | PierLuigi Spinosa | New version available: draft-spinosa-urn-lex-20.txt |
2023-11-14
|
20 | (System) | New version approved |
2023-11-14
|
20 | (System) | Request for posting confirmation emailed to previous authors: Caterina Lupo , Enrico Francesconi , PierLuigi Spinosa |
2023-11-14
|
20 | PierLuigi Spinosa | Uploaded new revision |
2023-11-06
|
19 | Eliot Lear | Tag Revised I-D Needed set. |
2023-09-19
|
19 | (System) | Revised I-D Needed tag cleared |
2023-09-19
|
19 | Enrico Francesconi | New version available: draft-spinosa-urn-lex-19.txt |
2023-09-19
|
19 | (System) | New version approved |
2023-09-19
|
19 | (System) | Request for posting confirmation emailed to previous authors: Caterina Lupo , Enrico Francesconi , PierLuigi Spinosa |
2023-09-19
|
19 | Enrico Francesconi | Uploaded new revision |
2023-09-08
|
18 | (System) | Document has expired |
2023-03-07
|
18 | Eliot Lear | Tag Revised I-D Needed set. Tag Awaiting Reviews cleared. |
2023-03-07
|
18 | Eliot Lear | ISE state changed to Response to Review Needed from In ISE Review |
2023-03-07
|
18 | Eliot Lear | Tag Awaiting Reviews set. |
2023-03-07
|
18 | PierLuigi Spinosa | New version available: draft-spinosa-urn-lex-18.txt |
2023-03-07
|
18 | (System) | New version approved |
2023-03-07
|
18 | (System) | Request for posting confirmation emailed to previous authors: Caterina Lupo , Enrico Francesconi , PierLuigi Spinosa |
2023-03-07
|
18 | PierLuigi Spinosa | Uploaded new revision |
2023-02-10
|
17 | PierLuigi Spinosa | New version available: draft-spinosa-urn-lex-17.txt |
2023-02-10
|
17 | (System) | New version approved |
2023-02-10
|
17 | (System) | Request for posting confirmation emailed to previous authors: Caterina Lupo , Enrico Francesconi , PierLuigi Spinosa |
2023-02-10
|
17 | PierLuigi Spinosa | Uploaded new revision |
2023-01-25
|
16 | Eliot Lear | ISE state changed to In ISE Review from Response to Review Needed |
2023-01-24
|
16 | (System) | Revised ID Needed tag cleared |
2023-01-24
|
16 | PierLuigi Spinosa | New version available: draft-spinosa-urn-lex-16.txt |
2023-01-24
|
16 | (System) | New version approved |
2023-01-24
|
16 | (System) | Request for posting confirmation emailed to previous authors: Caterina Lupo , Enrico Francesconi , PierLuigi Spinosa |
2023-01-24
|
16 | PierLuigi Spinosa | Uploaded new revision |
2022-09-23
|
15 | (System) | Document has expired |
2022-05-05
|
15 | Eliot Lear | Tag Revised I-D Needed set. |
2022-05-05
|
15 | Eliot Lear | ISE state changed to Response to Review Needed from Finding Reviewers |
2022-03-22
|
15 | Eliot Lear | ISE state changed to Finding Reviewers from Response to Review Needed |
2022-03-22
|
15 | (System) | Revised ID Needed tag cleared |
2022-03-22
|
15 | PierLuigi Spinosa | New version available: draft-spinosa-urn-lex-15.txt |
2022-03-22
|
15 | (System) | New version approved |
2022-03-22
|
15 | (System) | Request for posting confirmation emailed to previous authors: Caterina Lupo , Enrico Francesconi , PierLuigi Spinosa |
2022-03-22
|
15 | PierLuigi Spinosa | Uploaded new revision |
2021-11-08
|
14 | (System) | Document has expired |
2021-09-22
|
14 | Adrian Farrel | Tag Revised I-D Needed set. |
2021-09-22
|
14 | Adrian Farrel | ISE state changed to Response to Review Needed from In ISE Review |
2021-05-04
|
14 | Cindy Morgan | Created "Approve" ballot |
2021-05-04
|
14 | Cindy Morgan | Closed "Approve" ballot |
2021-05-01
|
14 | Adrian Farrel | ISE state changed to In ISE Review from Submission Received |
2021-04-27
|
14 | (System) | Revised ID Needed tag cleared |
2021-04-27
|
14 | PierLuigi Spinosa | New version available: draft-spinosa-urn-lex-14.txt |
2021-04-27
|
14 | (System) | New version approved |
2021-04-27
|
14 | (System) | Request for posting confirmation emailed to previous authors: Caterina Lupo , Enrico Francesconi , PierLuigi Spinosa , rfc-ise@rfc-editor.org |
2021-04-27
|
14 | PierLuigi Spinosa | Uploaded new revision |
2021-04-18
|
13 | Adrian Farrel | Tag Revised I-D Needed set. |
2021-04-18
|
13 | Adrian Farrel | ISE state changed to Submission Received |
2021-04-18
|
13 | Adrian Farrel | Notification list changed to rfc-ise@rfc-editor.org because the document shepherd was set |
2021-04-18
|
13 | Adrian Farrel | Document shepherd changed to Adrian Farrel |
2021-04-18
|
13 | Adrian Farrel | Stream changed to ISE from None |
2020-07-27
|
13 | (System) | Document has expired |
2020-07-25
|
13 | Barry Leiba | The document will not be published in the IETF Stream, as there are too many issues with the document that the IESG considers too serious … The document will not be published in the IETF Stream, as there are too many issues with the document that the IESG considers too serious for approval. It has been suggested to the authors that they might pursue publication in the Independent Stream. |
2020-07-25
|
13 | Barry Leiba | IESG state changed to Dead from IESG Evaluation::Revised I-D Needed |
2020-03-22
|
13 | Adrian Farrel | Removed from Independent Stream pending publication request from authors |
2020-03-22
|
13 | Adrian Farrel | Stream changed to None from ISE |
2020-03-20
|
13 | Alexey Melnikov | Stream changed to ISE from IETF |
2020-03-10
|
13 | Alexey Melnikov | Shepherding AD changed to Barry Leiba |
2020-02-21
|
13 | Alexey Melnikov | [Ballot discuss] [Updated. See some extra comments at the end.] I have some small issue which need fixing before I would recommend approval of this … [Ballot 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. |
2020-02-21
|
13 | Alexey Melnikov | [Ballot comment] 1) In 6.7: Note that the value "all" can be expressed by language-dependent equivalents. The ABNF seems to suggest that "all" … [Ballot comment] 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 #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 : 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 : 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 “ 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 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. |
2020-02-21
|
13 | Alexey Melnikov | Ballot comment and discuss text updated for Alexey Melnikov |
2020-02-20
|
13 | Cindy Morgan | Changed consensus to No from Yes |
2020-02-20
|
13 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2020-02-20
|
13 | Cindy Morgan | Changed consensus to Yes from Unknown |
2020-02-20
|
13 | Éric Vyncke | [Ballot comment] Thank you for the authors for this long effort for a useful and valid goal. As I am running out of time to … [Ballot comment] 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... |
2020-02-20
|
13 | Éric Vyncke | [Ballot Position Update] New position, Abstain, has been recorded for Éric Vyncke |
2020-02-19
|
13 | Benjamin Kaduk | [Ballot 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 … [Ballot 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. |
2020-02-19
|
13 | Benjamin Kaduk | [Ballot comment] Section 1.1 document. Even a document that is not available online at all may still have a URN LEX that identifies … [Ballot comment] 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"] 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 element assigned to the sources of law of a specific country or organization, and a assigned Perhaps it's just me, but " 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 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 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 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 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 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 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 . equivalents. To indicate possible features or peculiarities, each main element of the manifestation MAY be followed by further specifications, for example as regards 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 #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 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 - : 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 . 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 .lex.arpa, where 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 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"? - 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. |
2020-02-19
|
13 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2020-02-19
|
13 | Alissa Cooper | [Ballot 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 … [Ballot 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 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 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. |
2020-02-19
|
13 | Alissa Cooper | Ballot discuss text updated for Alissa Cooper |
2020-02-19
|
13 | Alissa Cooper | [Ballot discuss] The original Gen-ART review of this document raised a major issue about how it is "partially specifying a complete system for federating the … [Ballot discuss] The original Gen-ART review of this document 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 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. |
2020-02-19
|
13 | Alissa Cooper | Ballot discuss text updated for Alissa Cooper |
2020-02-19
|
13 | Alissa Cooper | [Ballot discuss] The original Gen-ART review of this document raised a major issue about how it is "partially specifying a complete system for federating the … [Ballot discuss] The original Gen-ART review of this document 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 support Adam's and Roman's DISCUSS positions. |
2020-02-19
|
13 | Alissa Cooper | [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper |
2020-02-19
|
13 | Roman Danyliw | [Ballot discuss] This document does not contain a Security Considerations section. There is only the following text in Section 2: This … [Ballot 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 |
2020-02-19
|
13 | Roman Danyliw | [Ballot comment] The text, as written (particularly Section 8), does not appear to provide sufficient detail to create an interoperable system. However, as this draft … [Ballot comment] 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. |
2020-02-19
|
13 | Roman Danyliw | [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw |
2020-02-19
|
13 | Amanda Baber | IANA is waiting for experts to approve the URN NID registration. In addition, a reviewer had the following comments: "Section 8.1 states that 'ITTIG-CNR will … IANA is waiting for experts to approve the URN NID registration. In addition, a reviewer had the following comments: "Section 8.1 states that 'ITTIG-CNR will maintain the root zone "lex.urn.arpa" (see [RFC3405]) ...' whereas Section 11.1 suggests the organization choice is not settled and/or outside the scope of the RFC, i.e. '... 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.' These should be consistent. Agree that the appointment of specific organizations should be outside the scope of the RFC unless it is essential, because RFCs are meant to be timeless and I think appointments like that are probably IESG actions or similar." Finally, we have a question about this statement: "In the current experimental LEX registration phase, ITTIG-CNR will take care to create and maintain the registry for . As the criteria of the LEX names assignment will be consolidated, after the experimental phase such registry will be maintained by IANA." How will IANA be notified of this? Will another document be published? How long is the experimental phase intended to last? |
2020-02-19
|
13 | Amanda Baber | IANA Experts State changed to Reviews assigned |
2020-02-19
|
13 | Amanda Baber | IANA Review state changed to IANA - Not OK from Version Changed - Review Needed |
2020-02-19
|
13 | Adam Roach | [Ballot discuss] This document refers to itself as a "standard" in approximately 30 different places. This seems problematically misleading for a document being published as … [Ballot 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. |
2020-02-19
|
13 | Adam Roach | [Ballot comment] Section 1.8: Please update this section to use the boilerplate from RFC 8174. I share Barry's concerns, but reach the same conclusion … [Ballot comment] 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. |
2020-02-19
|
13 | Adam Roach | [Ballot Position Update] New position, Discuss, has been recorded for Adam Roach |
2020-02-19
|
13 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2020-02-18
|
13 | Paul Kyzivat | Request for Telechat review by GENART Completed: Ready with Issues. Reviewer: Paul Kyzivat. |
2020-02-13
|
13 | Jean Mahoney | Request for Telechat review by GENART is assigned to Paul Kyzivat |
2020-02-13
|
13 | Jean Mahoney | Request for Telechat review by GENART is assigned to Paul Kyzivat |
2020-02-12
|
13 | Scott Bradner | Request for Telechat review by OPSDIR Completed: Has Issues. Reviewer: Scott Bradner. Sent review to list. |
2020-02-10
|
13 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Scott Bradner |
2020-02-10
|
13 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Scott Bradner |
2020-02-07
|
13 | Amy Vezza | Placed on agenda for telechat - 2020-02-20 |
2020-02-07
|
13 | Alexey Melnikov | [Ballot discuss] I have some small issue which need fixing before I would recommend approval of this document: 1) ABNF for "manifestation" in Attachment A … [Ballot discuss] 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. |
2020-02-07
|
13 | Alexey Melnikov | [Ballot comment] 1) In 6.7: Note that the value "all" can be expressed by language-dependent equivalents. The ABNF seems to suggest that "all" … [Ballot comment] 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 #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! |
2020-02-07
|
13 | Alexey Melnikov | [Ballot Position Update] Position for Alexey Melnikov has been changed to Discuss from Yes |
2020-02-07
|
13 | Barry Leiba | [Ballot comment] As I've explained in extensive reviews of this document over its long, overly delayed history, I think there are serious issues with this … [Ballot comment] 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. |
2020-02-07
|
13 | Barry Leiba | [Ballot Position Update] New position, Abstain, has been recorded for Barry Leiba |
2020-02-07
|
13 | Alexey Melnikov | Ballot has been issued |
2020-02-07
|
13 | Alexey Melnikov | [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov |
2020-02-07
|
13 | Alexey Melnikov | Created "Approve" ballot |
2020-02-07
|
13 | Alexey Melnikov | Ballot writeup was changed |
2020-02-07
|
13 | Alexey Melnikov | IESG state changed to IESG Evaluation from Waiting for Writeup::AD Followup |
2019-11-20
|
13 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'Team Will not Review Version' |
2019-11-20
|
13 | Tero Kivinen | Assignment of request for Last Call review by SECDIR to Russ Mundy was marked no-response |
2018-06-06
|
13 | PierLuigi Spinosa | New version available: draft-spinosa-urn-lex-13.txt |
2018-06-06
|
13 | (System) | New version approved |
2018-06-06
|
13 | (System) | Request for posting confirmation emailed to previous authors: PierLuigi Spinosa , Caterina Lupo , Enrico Francesconi |
2018-06-06
|
13 | PierLuigi Spinosa | Uploaded new revision |
2017-11-16
|
12 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2017-11-16
|
12 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2017-11-16
|
12 | PierLuigi Spinosa | New version available: draft-spinosa-urn-lex-12.txt |
2017-11-16
|
12 | (System) | New version approved |
2017-11-16
|
12 | (System) | Request for posting confirmation emailed to previous authors: PierLuigi Spinosa , Caterina Lupo , Enrico Francesconi |
2017-11-16
|
12 | PierLuigi Spinosa | Uploaded new revision |
2017-09-20
|
11 | Alexey Melnikov | Some very good comments from the GenArt review. I don't agree with all of them, but many of them are similar to comments from my … Some very good comments from the GenArt review. I don't agree with all of them, but many of them are similar to comments from my original review. |
2017-09-20
|
11 | Alexey Melnikov | IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup |
2017-09-20
|
11 | Alexey Melnikov | Removed from agenda for telechat |
2017-09-20
|
11 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Scott Bradner. |
2017-09-14
|
11 | Paul Kyzivat | Request for Last Call review by GENART Completed: Not Ready. Reviewer: Paul Kyzivat. |
2017-09-14
|
11 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2017-09-13
|
11 | Alexey Melnikov | Placed on agenda for telechat - 2017-09-28 |
2017-09-13
|
11 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2017-09-13
|
11 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-spinosa-urn-lex-11. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-spinosa-urn-lex-11. If any part of this review is inaccurate, please let us know. The IANA Services Operator has questions about the actions requested in the IANA Considerations section of this document. The IANA Services Operator understands that, upon approval of this document, there are three actions which we must complete. First, in the Formal URN Namespaces registry on the Uniform Resource Names (URN) Namespaces registry page located at: https://www.iana.org/assignments/urn-namespaces/ a single, new URN will be registered as follows: URN Namespace: lex Template: Reference: [ RFC-to-be ] Because this registry requires Expert Review [RFC 8126] for registration, the IESG-designated experts for Formal URN Namespaces have asked that you send a review request to the mailing list urn@ietf.org. Expert review should be completed before your document can be approved for publication as an RFC. Second, we will request the approval of the IAB to implement the following two NAPTR records: in the URN.ARPA domain: lex IN NAPTR 100 10 "" "" "" lex.ittig.cnr.it. in the URN.URI.ARPA domain: lex IN NAPTR 100 10 "" "" "" lex.ittig.cnr.it. IANA QUESTIONS -> Is the hostname lex.ittig.cnr.it guaranteed to have a long lifetime? Is it appropriate for that to be permanently documented, i.e. not subject to change? It might be better to document the approach in such a way that that exact form of the NAPTR record is not in the I-D. (For example, when we add new .ARPA domains via RFCs, it does not spell out what the NS records would be, that is considered an implementation detail to be managed outside the document.) Third, a new registry is to be created called the Jurisdiction-Code registry. The new registry will be managed using Expert Review as defined by [RFC 8126]. IANA QUESTION -> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols? We understand that there are no initial registrations in the new registry. The IANA Services Operator understands that these three actions are the only ones required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. Thank you, Sabrina Tanamal IANA Services Specialist |
2017-09-07
|
11 | Jean Mahoney | Request for Last Call review by GENART is assigned to Paul Kyzivat |
2017-09-07
|
11 | Jean Mahoney | Request for Last Call review by GENART is assigned to Paul Kyzivat |
2017-09-07
|
11 | Jouni Korhonen | Assignment of request for Last Call review by GENART to Jouni Korhonen was rejected |
2017-08-24
|
11 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Russ Mundy |
2017-08-24
|
11 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Russ Mundy |
2017-08-22
|
11 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Scott Bradner |
2017-08-22
|
11 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Scott Bradner |
2017-08-17
|
11 | Jean Mahoney | Request for Last Call review by GENART is assigned to Jouni Korhonen |
2017-08-17
|
11 | Jean Mahoney | Request for Last Call review by GENART is assigned to Jouni Korhonen |
2017-08-17
|
11 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2017-08-17
|
11 | Amy Vezza | The following Last Call announcement was sent out (ends 2017-09-14): From: The IESG To: IETF-Announce CC: alexey.melnikov@isode.com, andy@arin.net, draft-spinosa-urn-lex@ietf.org Reply-To: ietf@ietf.org Sender: Subject: … The following Last Call announcement was sent out (ends 2017-09-14): From: The IESG To: IETF-Announce CC: alexey.melnikov@isode.com, andy@arin.net, draft-spinosa-urn-lex@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (A Uniform Resource Name (URN) Namespace for Sources of Law (LEX)) to Informational RFC The IESG has received a request from an individual submitter to consider the following document: - 'A Uniform Resource Name (URN) Namespace for Sources of Law (LEX)' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-09-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a Uniform Resource Name (URN) Namespace Identification (NID) convention as prescribed by the World Wide Web Consortium (W3C) for identifying, naming, assigning, and managing persistent resources in the legal domain. The file can be obtained via https://datatracker.ietf.org/doc/draft-spinosa-urn-lex/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-spinosa-urn-lex/ballot/ No IPR declarations have been submitted directly on this I-D. |
2017-08-17
|
11 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2017-08-17
|
11 | Alexey Melnikov | Last call was requested |
2017-08-17
|
11 | Alexey Melnikov | Last call announcement was generated |
2017-08-17
|
11 | Alexey Melnikov | Ballot approval text was generated |
2017-08-17
|
11 | Alexey Melnikov | Ballot writeup was generated |
2017-08-17
|
11 | Alexey Melnikov | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2017-08-09
|
11 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2017-08-09
|
11 | PierLuigi Spinosa | New version available: draft-spinosa-urn-lex-11.txt |
2017-08-09
|
11 | (System) | New version approved |
2017-08-09
|
11 | (System) | Request for posting confirmation emailed to previous authors: PierLuigi Spinosa , Caterina Lupo , Enrico Francesconi |
2017-08-09
|
11 | PierLuigi Spinosa | Uploaded new revision |
2017-05-01
|
10 | Alexey Melnikov | Summary of blocking outstanding issues for draft-spinosa-urn-lex-10: 1) Missing/incomplete registration template for a new URN Namespace "lex". 2) Use of domains not registered in … Summary of blocking outstanding issues for draft-spinosa-urn-lex-10: 1) Missing/incomplete registration template for a new URN Namespace "lex". 2) Use of domains not registered in DNS (like "eec.lex") is confusing. Either they should be change to be under "urn.arpa" domain or the document should change terminology to make it clear that these are not domain names. Maybe use something like "jurisdiction identifier" instead. 3) need a new IANA registry or a deterministic mechanism to find out valid jurisdiction codes. It is probably easier to create a new IANA registry. 4) Text about being able to rename jurisdiction codes need to be deleted, as this breaks URN semantics (i.e. guarantee of their persistence). 5) Section 3 should be split into 2 top level sections: one that talks about general syntax and another one that talks about recommendations that should be done within each specific jurisdiction. For example, the following sub-sections of 3 would be moved to the latter top level section: 3.5 National Characters and Diacritic Signs . . . . . . . . . 15 3.7 Abbreviations . . . . . . . . . . . . . . . . . . . . . . 15 3.8 Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 16 3.10 Ordinal Numbers . . . . . . . . . . . . . . . . . . . . 16 and possibly: 3.6 Spaces, Connectives and Punctuation Marks . . . . . . . . 15 The following sub-section can stay under the current section 3: 3.1 Syntax Used in this Document . . . . . . . . . . . . . . 14 3.2 Allowed and Not Allowed Characters . . . . . . . . . . . 14 3.3 Reserved Characters . . . . . . . . . . . . . . . . . . . 14 3.4 Case sensitivity . . . . . . . . . . . . . . . . . . . . 14 3.9 Date Format . . . . . . . . . . . . . . . . . . . . . . . 16 |
2017-01-04
|
10 | Alexey Melnikov | Further comments/questions sent in reply to editors' comments on my AD review. Another revision is needed. |
2017-01-04
|
10 | Alexey Melnikov | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup |
2016-11-14
|
10 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2016-11-14
|
10 | PierLuigi Spinosa | New version available: draft-spinosa-urn-lex-10.txt |
2016-11-14
|
10 | (System) | New version approved |
2016-11-14
|
10 | (System) | Request for posting confirmation emailed to previous authors: "Caterina Lupo" , "Enrico Francesconi" , "PierLuigi Spinosa" |
2016-11-14
|
10 | PierLuigi Spinosa | Uploaded new revision |
2016-06-24
|
09 | Alexey Melnikov | My AD review of the draft: In addition to issues raised below, I am a bit concerned about use of "$", "@", etc. as delimiters … My AD review of the draft: In addition to issues raised below, I am a bit concerned about use of "$", "@", etc. as delimiters with special meaning, but I need to research a bit more on the subject before I can decide whether it is a valid concern or not. ------------- In 2.3: ABNF (RFC 5234) needs to be a Normative Reference. In 2.4: When talking about jurisdiction codes, the document suggests to use ISO 3166 code in some cases and domain names in other cases. If this is supposed to be normative, you need to pick one of the methods or at least specify what is used when (for example, you can use 2 letter country codes from ISO 3166 and for values which at 3 letters or longer, or contain ".", you use domain names), you can't have unspecified mixture of both. Alternatively (the 3rd choice), you ask for a registry to be created, which is populated by an expert, who will decide on a case by case basis which values are legal. The whole section needs multiple edits to address the above concern. For example: is usually the identification code of the country where the source of law is issued; this code follows the standard [ISO3166] Alpha-2 (it=Italy, fr=France, dk=Denmark, etc.) which usually is identical to the country code Top-Level Domain (ccTLD). In case such codes are not identical (as for United Kingdom, whose ISO 3166 code is .gb while its ccTLD is .uk), one of them is chosen as . Chosen by whom? If you make a statement like this, you need to explain who has the authority to decide. I think use of special .lex domain might be problematic, if this top level domain gets assigned by IETF or ICANN. Suggestion how to handle domain reassignments by appending dates need more work! Again, you need to specify rules who can decide. In 3.3: I assume when you say "case sensitive", you mean case sensitive in ASCII range, right? In 3.4: It would be better to pick a single way of handling Diacritic Signs or at least state the preferred one. In 3.5: This section seems to suggests that in order to generate a URN, generator needs to be language aware, because it needs to suppress articles, prepositions, etc. Being language aware is problematic, because different jurisdictions would use different languages, which would mean supporting all common written languages and maintaining a table of which languages will be used in which jurisdiction. I don't think this is implementable. If this is just a recommendation for jurisdictions, then you should clearly state that the section talks about recommended way of creating URNs, but that the procedure can't be used to create LEX URNs algorithmically. In 3.6: Again, this is not implementable without being language aware and you have MUST level requirement here. In 3.9: Again, similar problem ("Third" ==> "3") 7.6 IANA Considerations According to RFC format rules, this should be a top level section. This document includes a URN NID registration for "lex" for entry in the IANA registry of URN NIDs (see [RFC5226]), as well as the RFC5226 has nothing to do with URN NID registrations, so this is an incorrect reference. See also below. registration of the following NAPTRs record: Please provide full IANA registration template according to the template specified in Appendix A of RFC 3406. You can have references to other sections of your document from the registration template. I see that some subsections of section 5 have relevant information, but you don't provide all information required by the registration template. In 7.7 - this should be another top level section. In Attachment A: The following ABNF productions are not defined. You need to either add them or add a comment how different pieces of LEX URNs related to each other: local-name DIGIT HEXDIG Can you elaborate on the purpose of the following production: encoded = "%" ( 1*6DIGIT / ( "x" 1*6HEXDIG ) ) If it is meant to encoded Unicode characters that are represented as multiple octets in UTF-8, then your syntax is incorrect, because % is only allowed to be followed by 2 hexadecimal digits. See Section 2.1 of RFC 3986, which defines: pct-encoded = "%" HEXDIG HEXDIG C.1.1 - Do you have a recommendation on how can different versions be linked? Maybe link-relation can be used here? |
2016-04-08
|
09 | Alexey Melnikov | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2016-04-08
|
09 | Alexey Melnikov | Shepherding AD changed to Alexey Melnikov |
2015-10-14
|
09 | (System) | Notify list changed from pierluigi.spinosa@ittig.cnr.it, enrico.francesconi@ittig.cnr.it, caterina.lupo@gmail.com, draft-spinosa-urn-lex@ietf.org to (None) |
2014-04-29
|
09 | Barry Leiba | IESG state changed to AD Evaluation from Publication Requested |
2014-04-29
|
09 | Cindy Morgan | IESG process started in state Publication Requested |
2014-04-29
|
09 | Cindy Morgan | Notification list changed to : pierluigi.spinosa@ittig.cnr.it, enrico.francesconi@ittig.cnr.it, caterina.lupo@gmail.com, draft-spinosa-urn-lex@tools.ietf.org, andy@hxr.us |
2014-04-29
|
09 | Cindy Morgan | Intended Status changed to Informational from None |
2014-04-29
|
09 | Cindy Morgan | Changed document writeup |
2014-04-29
|
09 | Cindy Morgan | Document shepherd changed to Andrew Newton |
2014-04-29
|
09 | Cindy Morgan | Stream changed to IETF from None |
2014-03-20
|
09 | PierLuigi Spinosa | New version available: draft-spinosa-urn-lex-09.txt |
2013-09-17
|
08 | PierLuigi Spinosa | New version available: draft-spinosa-urn-lex-08.txt |
2012-10-01
|
07 | PierLuigi Spinosa | New version available: draft-spinosa-urn-lex-07.txt |
2012-04-02
|
06 | PierLuigi Spinosa | New version available: draft-spinosa-urn-lex-06.txt |
2012-03-05
|
05 | PierLuigi Spinosa | New version available: draft-spinosa-urn-lex-05.txt |
2011-09-06
|
04 | (System) | New version available: draft-spinosa-urn-lex-04.txt |
2011-04-05
|
03 | (System) | New version available: draft-spinosa-urn-lex-03.txt |
2011-04-04
|
04 | (System) | Document has expired |
2010-10-01
|
02 | (System) | New version available: draft-spinosa-urn-lex-02.txt |
2010-04-05
|
01 | (System) | New version available: draft-spinosa-urn-lex-01.txt |
2009-11-09
|
00 | (System) | New version available: draft-spinosa-urn-lex-00.txt |