Dear Eliot, sorry for such a delay: there were several remarks in the last review, and we took a bit more time than expected to clarify and process them. We are basically ready to send our feedback. We'll do that in the next few hours. Thanks for your understanding
Enrico ________________________________ From: Independent Submissions Editor (Eliot Lear) <rfc-...@rfc-editor.org> Sent: 10 December 2024 15:46 To: Madison Church <mchu...@amsl.com>; ENRICO FRANCESCONI <enrico.francesc...@cnr.it>; pierluigi.spin...@gmail.com <pierluigi.spin...@gmail.com>; caterina.l...@gmail.com <caterina.l...@gmail.com> Cc: Murray S. Kucherawy <superu...@gmail.com>; auth48archive@rfc-ed <auth48archive@rfc-editor.org>; RFC Editor <rfc-edi...@rfc-editor.org> Subject: Re: AUTH48: RFC-to-be 9676 <draft-spinosa-urn-lex-24> for your review I'll just add that many people have put a substantial amount of time into this work. Please let's get it finished. Eliot On 10.12.2024 15:40, Madison Church wrote: Hi Authors, This is a friendly reminder that we await answers to the questions below and your review of the document before continuing with the publication process. Thank you, RFC Editor/mc On Nov 21, 2024, at 2:32 PM, ENRICO FRANCESCONI <enrico.francesc...@cnr.it><mailto:enrico.francesc...@cnr.it> wrote: P {margin-top:0;margin-bottom:0;} Dear Colleagues, thanks for the reminder, we are actually processing all the comments and we'll be back to you soon! Best Enrico From: Independent Submissions Editor (Eliot Lear) <rfc-...@rfc-editor.org><mailto:rfc-...@rfc-editor.org> Sent: 21 November 2024 17:24 To: Madison Church <mchu...@amsl.com><mailto:mchu...@amsl.com>; pierluigi.spin...@gmail.com<mailto:pierluigi.spin...@gmail.com> <pierluigi.spin...@gmail.com><mailto:pierluigi.spin...@gmail.com>; caterina.l...@gmail.com<mailto:caterina.l...@gmail.com> <caterina.l...@gmail.com><mailto:caterina.l...@gmail.com>; ENRICO FRANCESCONI <enrico.francesc...@cnr.it><mailto:enrico.francesc...@cnr.it> Cc: Murray S. Kucherawy <superu...@gmail.com><mailto:superu...@gmail.com>; auth48archive@rfc-ed <auth48archive@rfc-editor.org><mailto:auth48archive@rfc-editor.org>; RFC Editor <rfc-edi...@rfc-editor.org><mailto:rfc-edi...@rfc-editor.org> Subject: Re: AUTH48: RFC-to-be 9676 <draft-spinosa-urn-lex-24> for your review Yup! Everyone: let's get this document across the finish line. Eliot On 21.11.2024 15:28, Madison Church wrote: Greetings, This is a friendly weekly reminder that this document awaits your attention. Please review the document-specific questions and AUTH48 announcement. Let us know if we can be of assistance as you begin the AUTH48 review process. The AUTH48 status page of this document is viewable at: http://www.rfc-editor.org/auth48/rfc9676 The AUTH48 FAQs are available at: https://www.rfc-editor.org/faq/#auth48 We look forward to hearing from you at your earliest convenience. Thank you, RFC Editor/mc On Nov 14, 2024, at 3:35 PM, rfc-edi...@rfc-editor.org<mailto:rfc-edi...@rfc-editor.org> wrote: Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file. 1) <!-- [rfced] Document title a) May we update the document title in one of the following ways? The current placement of "(LEX)" makes it seem like LEX is an abbreviation. Current: A Uniform Resource Name (URN) Namespace for Sources of Law (LEX) Perhaps: LEX: A Uniform Resource Name (URN) Namespace for Sources of Law Or: "lex": A Uniform Resource Name (URN) Namespace for Sources of Law b) Similarly, may we update the abbreviated title (appears in the running header at the top of each page in the pdf output) in one of the following ways? Current: URN LEX Namespace for Sources of Law Perhaps: LEX: URN Namespace for Sources of Law Or: "lex": URN Namespace for Sources of Law --> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 3) <!-- [rfced] Would including "LEX" or "lex" in the abstract be helpful to readers? Original: This document describes a Uniform Resource Name (URN) Namespace Identifier for identifying, naming, assigning, and managing persistent resources in the legal domain. Perhaps: This document describes LEX, a Uniform Resource Name (URN) namespace identifier that identifies, names, assigns, and manages persistent resources in the legal domain. Or: This document describes "lex", a Uniform Resource Name (URN) namespace identifier that identifies, names, assigns, and manages persistent resources in the legal domain. --> 4) <!-- [rfced] Please review "legal information knowledge". Would simply "legal information" be correct here? We note that "legal information" is used in the sentence that follows. Original: In today's information society the processes of political, social and economic integration of European Union member states as well as the increasing integration of the world-wide legal and economic processes are causing a growing interest in exchanging legal information knowledge at national and trans-national levels. Perhaps: In today's information society, the processes of political, social and economic integration of European Union (EU) member states, as well as the increasing integration of the worldwide legal and economic processes, are causing a growing interest in the exchange of legal information at national and transnational levels. --> 5) <!-- [rfced] FYI: We updated this long sentences as follows to improve clarity. Let us know any concerns. Original: The need for a unique identifier of sources of law in different EU Member States, based on open standards and able to provide advanced modalities of document hyper-linking, has been expressed in several conferences (as [LVI]) by representatives of the Publications Office of the European Union (OP), with the aim of promoting interoperability among national and European institution information systems. Updated: In several conferences (such as [LVI]), representatives of the Publications Office of the European Union (OP) have expressed the need for a unique identifier for sources of law, based on open standards and able to provide advanced modalities of document hyperlinking, with the aim of promoting interoperability among national and European institution information systems. --> 6) <!-- [rfced] We are having trouble parsing the following sentence. Please clarify. Original: This is acutely felt within both common law systems, where cases are the main law sources, and civil law systems, in order to provide an integrated access to cases and legislation, as well as to track the relationships between them. Perhaps: This need is acutely felt within both common law systems (where cases are the main law sources) and civil law systems, because unique identifiers can provide integrated access to cases and legislation, as well as the ability to track the relationships between them. --> 7) <!-- [rfced] We are having trouble understanding the part of the first sentence below starting with "in view of...". Also, is "In this view" needed in the second sentence? Please review. Original: Similarly the Council of the European Union has underlined the importance of cross-border access to national case law, as well as the need for its standardisation, in view of an integrated access in a decentralized architecture. In this view the Working Party on Legal Data Processing (e-Law) of the Council of the European Union formed a task group to study the possibilities for improving cross- border access to national case law. Perhaps: Similarly, the Council of the European Union has underlined the importance of cross-border access to national case law, as well as the need for its standardization, with a vision of a decentralized architecture with integrated access. The Working Party on Legal Data Processing (e-Law) of the Council of the European Union formed a task group to study the possibilities for improving cross- border access to national case law. --> 8) <!-- [rfced] FYI: We rephrased the following sentence to improve readability. Please review and let us know any concerns. Original: Taking notice of the report of the Working Party's task group, the Council of the EU decided in 2009 to elaborate on a uniform, European system for the identification of case law (ECLI: European Case-Law Identifier) and uniform Dublin Core-based set of metadata. Updated: Taking notice of the report of the Working Party's task group, in 2009, the Council of the European Union decided to elaborate on a uniform European system for the identification of case law (i.e., the European Case-Law Identifier (ECLI)) and a uniform set of metadata based on the Dublin Core. --> 9) <!-- [rfced] May we update "legislative" to "legislation", "legislative document", or something similar? Original: The LEX identifier (also referred in this text as "LEX name") is conceived to be general enough so as to provide guidance at the core of the standard and sufficient flexibility to cover a wide variety of needs for identifying all the legal documents of different nature, namely legislative, case-law and administrative acts. Perhaps: The LEX identifier (also referred in this text as "LEX name") is conceived to be general enough to provide guidance at the core of the standard and offer sufficient flexibility to cover a wide variety of needs for identifying legal documents of different types, namely, legislation, case law, and administrative acts. --> 10) <!-- [rfced] Is "items" the correct word choice here? Would "version" or something else be better in this context? Original: Moreover, it can be effectively used within a federative environment where different publishers (public and private) can provide their own items of a legal document (that is there is more than one manifestation of the same legal document). Perhaps: Moreover, the LEX identifier can be effectively used within a federative environment where different publishers (public and private) can provide their own versions of a legal document (that is, if there is more than one version of the same legal document). --> 11) <!-- [rfced] Is "meta-information" correct here? Or should this be updated to "metadata"? Original: The LEX name is linked to the document through meta-information which may be specified as follows: Perhaps: The LEX name is linked to the document through metadata, which may be specified as follows: --> 12) <!-- [rfced] FYI: We do not see "META" (all caps) in [W3C.HTML]. We have updated to "meta" (all lowercase). Please let us know any concerns. Original: * within the document itself through a specific element within an XML schema or by an [W3C.HTML] META tag; Updated: * Within the document itself through a specific element within an XML schema or by a meta tag [W3C.HTML]. --> 13) <!-- [rfced] Please clarify "through reference parsers of a text". Original: * by automatically constructing (either permanently or temporarily) the link with the uniform name, through reference parsers of a text: this is a more time-saving procedure even if subject to a certain percentage of errors, since references are not always accurate or complete. Perhaps: * Automatically constructing (either permanently or temporarily) the link with the uniform name from references in the text using a parser. This procedure offers more time savings, even if it is subject to a certain percentage of errors, since references are not always accurate or complete. --> 14) <!-- [rfced] Would it be helpful to rephrase this sentence as follows? Original: Therefore acts of the same type issued by similar authorities in different areas differ for the jurisdiction-unit specification. Perhaps: Therefore, the jurisdiction-unit differs for acts of the same type issued by similar authorities in different areas. --> 15) <!-- [rfced] We have a few questions about the text below. Original: 2.2. Jurisdiction-code Register A new jurisdiction-code registry has been created. Each entry contains the following elements: a) Should the title read "Jurisdiction-Code Registry" ("Registry" rather than "Register")? b) Is "jurisdiction-code" the name of the registry? If so, we will enclose in quotation marks. c) Would it be helpful to include a citation or URL so readers can access the new jurisdiction-code registry? --> 16) <!-- [rfced] How may we update these definitions for clarity? a) jurisdiction-code definition Original: * jurisdiction-code: the identifier of jurisdiction, assigned to the country or organisation; Perhaps: jurisdiction-code: The identifier assigned to the jurisdiction (i.e., identifier assigned to the country or organization). b) jurisdiction definition Original: * jurisdiction: the official name of the jurisdiction, country or organisation; Perhaps: jurisdiction: The official name of the jurisdiction (i.e., the country or organization). Or: jurisdiction: The official name of the country or organization. --> 17) <!-- [rfced] Would including either a URL or a citation with a corresponding reference entry for "CNR website dedicated to the LEX governance" be helpful to readers here? If so, please provide the necessary information. Original: A new Jurisdictional Registrar will contact CNR or the Designated Expert(s) according to the established rules of governance (published in the CNR website dedicated to the LEX governance). --> 18) <!-- [rfced] How may we update "global interest" to form a complete sentence? If the suggestion below does not accurately capture your intended meaning, please feel free to provide updated text. Original: Global interest. In fact each body that enacts sources of law can identify them by this scheme. Perhaps: The scope is global. In fact, each body that enacts sources of law can identify them by this scheme. --> 19) <!-- [rfced] We are having trouble understanding "or, in agreement with this one". Please clarify. Original: The most suitable, well-known and widespread mapping system for a given language MUST be chosen by the jurisdiction, or, in agreement with this one, by the jurisdiction-unit in case of different languages in the various regions, also taking into account the choices made for the same language by other jurisdictions. Perhaps: The most suitable, well-known, and widespread mapping system for a given language MUST be chosen by the jurisdiction or by the jurisdiction-unit (in agreement with the jurisdiction) in the case of different languages in various regions, also taking into account the choices made for the same language by other jurisdictions. --> 20) <!-- [rfced] Should "as" be updated to "and" in "as some of its parts"? Original: In this case it should be noted that the generated URN (as some of its parts) cannot be used directly for routing through DNS, and therefore the jurisdiction must adopt one of the following strategies: Perhaps: In this case, it should be noted that the generated URN (and some of its parts) cannot be used directly for routing through the DNS. Therefore, the jurisdiction must adopt one of the following strategies: --> 21) <!-- [rfced] Please clarify the text starting with "(for not having...". Original: * Conversion into basic ASCII, RECOMMENDED solution (for not having to make conversions for network protocols and DNS); Perhaps: * Conversion into basic ASCII is the RECOMMENDED solution (because conversions for network protocols and the DNS are not needed). --> 22) <!-- [rfced] Will readers understand what "To even the representation" means? Original: To even the representation, it is highly RECOMMENDED that any ordinal number included in a component of a document name (e.g., in the description of an institution body) is indicated in Western Arabic numerals, regardless to the original expression: whether in Roman numerals, or with an adjective, or in Arabic numeral with apex, etc. (IV, third, 1U+00B0, 2^, etc.) (e.g., "Department IV" becomes "department.4"). Perhaps: To make the representation consistent, it is highly RECOMMENDED that any ordinal number included in a component of a document name (e.g., in the description of an institution body) is indicated in Western Arabic numerals, regardless the original expression, whether Roman numerals, an adjective, Arabic numerals with an apex, etc. (such as IV, third, 1U+00B0, and 2^). For example, "Department IV" becomes "department.4". --> 23) <!-- [rfced] Please review "our case" here. Is the intent "in this document", "in LEX", or something else? Original: * work: identifies a distinct intellectual creation; in our case, it identifies a source of law both in its original form as amended over time; * expression: identifies a specific intellectual realisation of a work; in our case it identifies every different (original or up- to-date) version of the source of law over time and/or language in which the text is expressed. ... * manifestation: identifies a physical embodiment of an expression of a work; in our case it identifies embodiments in different media (printing, digital, etc.), encoding formats (XML, PDF, etc.), or other publishing characteristics; * item: identifies a specific copy of a manifestation; in our case it identifies individual physical copies as they are found in particular physical locations. --> 24) <!-- [rfced] Please clarify the text starting with "both...". Original: work: identifies a distinct intellectual creation; in our case, it identifies a source of law both in its original form as amended over time; Perhaps: work: Identifies a distinct intellectual creation; in our case, it identifies a source of law in both its original form and its amended form over time. --> 25) <!-- [rfced] The first sentence below mentions "the type of provision" as one of the components, but the ABNF uses "measure". Please review and let us know if any updates are needed. Original: In the legal domain, at "work" level, three components are always present: the enacting authority, the type of provision and the details. A fourth component, the annex, can be added if any. ... work = authority ":" measure ":" details *(":" annex) --> 26) <!-- [rfced] May we update "identifier of the annex adds a suffix" and "identifier of an annex of an annex adds an ending" as follows in these sentences to improve clarity? Original: In case of annexes, both the main document and its annexes have their own uniform name so that they can individually be referenced; the identifier of the annex adds a suffix to that of the main document. In similar way the identifier of an annex of an annex adds an ending to that of the annex which it is attached to. Perhaps: Both the main document and its annexes have their own uniform names so that they can be referenced individually; the identifier of an annex consists of a suffix added to the identifier of the main document. In similar way, the identifier of an annex to another annex consists of another suffix added to the identifier of the previous annex. --> 27) <!-- [rfced] We updated "its Internet domain name" to "the publisher's Internet domain name" for clarity. Please let us know if this is incorrect. Original: * editor: editorial staff who produced it, expressed according to its Internet domain name. Updated: * editor: Editorial staff who produced it, expressed according to the publisher's Internet domain name. --> 28) <!-- [rfced] Will readers know who "them" is in the phrase "for each of them a new manifestation with the new domain name"? Original: 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; Perhaps: In this case, in order to make its materials accessible, the publisher will have to create a new manifestation with a new domain name for each object. Or: In this case, in order to make its materials accessible, the publisher will have to create a new manifestation with a new domain name for each object that is not accessible. --> 29) <!-- [rfced] May we rephrase the following sentence starting at "for example as regards..." as follows to improve clarity? Original: To indicate possible features or peculiarities, each main element of the manifestation MAY be followed by further specifications (separated by ";"), for example as regards editor the archive name and the electronic publisher, for format the version, etc. Perhaps: To indicate possible features or peculiarities, each main element of the manifestation MAY be followed by further specifications (separated by “;”), for example, the archive name and electronic publisher for editor and the version for format. --> 30) <!-- [rfced] How may we clarify "Using a different separator ("~") from the document name" here? Original: 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. Perhaps: If a different separator ("~") is used after the document name, the partition ID is not withheld by the browser but is transmitted to the resolution process. --> 31) <!-- [rfced] How may we update this fragment to be a complete sentence? Also, please clarify "in-force or effectiveness". Original: For example with regard to changes of the in-force or effectiveness of any partition or portion of the text itself (e.g., when the amendments introduced by an act are applied at different times) or different events occurring on the same date. Perhaps: Examples include changes to the in-force or effective version of any partition or portion of the text itself (e.g., when the amendments introduced by an act are applied at different times) or different events occurring on the same date. --> 32) <!-- [rfced] How may we clarify the text starting with "even if the object remains only one"? Original: For a full compatibility, every updating of a text or of the effectiveness of a "multi-version" document implies the creation of a new uniform name, even if the object remains only one, containing the identifier of the virtually generated version, exactly as in the case of a "single-version" document. Perhaps: For full compatibility, every update of text or of the effectiveness of a "multi-version" document implies the creation of a new uniform name, even if there is only one object that contains the identifier of the virtually generated version, as in the case of a "single-version" document. --> 33) <!-- [rfced] We have some questions about the text below. a) The first sentence says a country or jurisdiction "MUST identify a Jurisdictional Registrar" and the second sentence below says "It must appoint a Jurisdictional Registrar". Is this redundant? b) Please clarify the second sentence. Specifically, what should the designated experts be informed about? What is meant by "together with the registration of a jurisdiction code"? Original: Any country or jurisdiction, who intends to adopt this schema, MUST identify a Jurisdictional Registrar, an organization which shares and defines the structure of the optional part (jurisdiction-unit) of the name, according to the organization of the state or institution (for details see Section 2.2). It must appoint a Jurisdictional Registrar and inform the Designed Experts, together with the registration of a jurisdiction code. --> 34) <!-- [rfced] Note that we added numbers to this sentence to aid in readability. Would updating "in correspondence with the adhesion" as suggested below further improve clarity? Original: For the "lex" namespace, CNR will maintain in the lex- nameserver.nic.it (see Section 12) the root zone of the chain resolution (equivalent to "lex.urn.arpa", see [RFC3405]) and, in correspondence with the adhesion (see Section 2.2) of a new country (e.g., "br") or organization, will update the DNS information with a new record to delegate the relative resolution. Current: For the "lex" namespace, CNR will 1) maintain the root zone of the chain resolution, equivalent to "lex.urn.arpa" (see [RFC3405]), in the lex-nameserver.nic.it (see Section 12) and 2) update the DNS information with a new record to delegate the relative resolution in correspondence with the adhesion (see Section 2.2) of a new country (e.g., "br") or organization. Perhaps: For the "lex" namespace, CNR will 1) maintain the root zone of the chain resolution, equivalent to "lex.urn.arpa" (see [RFC3405]), in the lex-nameserver.nic.it (see Section 12) and 2) update the DNS information with a new record to delegate the relative resolution when a new country (e.g., "br") or organization is added (see Section 2.2). --> 35) <!-- [rfced] Will readers understand what "This" refers to here? Original: This may be obtained by a regular expression that matches the initial part of the URN (e.g., "urn:lex:br") and redirects towards the proper zone (e.g., "lex.senado.gov.br"). --> 36) <!-- [rfced] We have updated the sentence below for ease of the reader. Please let us know any objections. Original: Finally, the resolver SHOULD append to URLs the "#" character followed by partition ID, transforming it in a URI fragment for browser pointing. Current: Finally, the resolver SHOULD append the "#" character followed by the partition ID to URLs, to create URI fragments for browser pointing. --> 37) <!-- [rfced] FYI - We alphabetized the references as that seemed to be the intent (only two were out of order). --> 38) <!-- [rfced] Please confirm the correct version of the following reference (2006, 2013, or 2020) and let us know how we should update. Original: [ISO3166-1] International Organization for Standardization, "Codes for the representation of names of countries and their subdivisions - Part 1: Country codes". Perhaps (a): [ISO.3166-1] ISO, "Codes for the representation of names of countries and their subdivisions - Part 1: Country codes", ISO 3166-1:2006, 2006. Perhaps (b): [ISO.3166-1] ISO, "Codes for the representation of names of countries and their subdivisions - Part 1: Country codes", ISO 3166-1:2013, 2013. Perhaps (c): [ISO.3166-1] ISO, "Codes for the representation of names of countries and their subdivisions - Part 1: Country code", ISO 3166-1:2020, 2020. --> 39) <!-- [rfced] We were unable to locate the reference listed below. Please review the reference entry and confirm it is correct. Original: [SPIN] Spinosa, P., "The Assignment of Uniform Names to Italian Legal Documents, URN-NIR 1.4", ITTIG technical Report n. 8/2010., June 2020. --> 40) <!-- [rfced] Please review each instance of U+ notation and let us know if you would like to replace with the character itself. The <u> element (which can be used to provide the U+ notation) is only required for cases where the non-ASCII characters are needed for correct protocol operation. For more information, please see: https://authors.ietf.org/en/non-ascii-characters-in-rfcxml https://www.rfc-editor.org/styleguide/part2/#nonascii For examples from published RFCs, please see (search for "non-ASCII"): https://www.rfc-editor.org/rpc/wiki/doku.php?id=v3_feature_usage Some examples from this document: Example 1 (from Section 3.4): Original: (e.g., the Italian term "sanitU+00E0" replaced into "sanita", the French term "ministU+00E8re" replaced into "ministere"), in case by transliteration (e.g. "MU+00FCnchen" replaced into "muenchen”). Perhaps: For example, the Italian term "sanità” is replaced by "sanita", the French term "ministère” is replaced by "ministere”, and "München” is replaced by “muenchen” (transliteration). Example 2 (from Section 3.4): Original: - unicode = urn:lex:de:stadt.mU+00FCnchen:rundschreiben: ... Perhaps no changes are needed when the U+ notation appears in a "urn:lex" string like this. --> 41) <!-- [rfced] Sourcecode a) We updated <artwork> to <sourcecode type="abnf"> in Section 8. We also updated the ABNF snippets throughout the document from <artwork> to <sourcecode type="abnf">. Please review. b) In Section 2.1, we changed the following from <artwork> to <sourcecode>. Please confirm that this is correct. If so, should the "type" attribute be set? Original: "urn:lex:" NSS Note: The current list of preferred values for "type" is available here: https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types. If this list does not contain an applicable type, then feel free to let us know. Also, it is acceptable to leave the "type" attribute not set. c) In Section 5.8, we changed the following from <artwork> to <sourcecode>. We set the type to "abnf", but please confirm this is correct. We do not see this in Section 8. Original: URN-reference = URN-document ["~" partition-id] d) In Section 8, please review the spacing. For example, would you like to add a blank line after the "alf-dot" definition and remove one of the blank lines after the "alfa" definition? Or is the current spacing okay? Original: alf-dot = alfanum *alfadot alf-dot-hyp = alfanum *(alfadot / "-") alf-dot-oth = alfanum *(alfadot / other) alfadot = alfanum / "." alfa = lowercase / uppercase alfanum = alfa / DIGIT / encoded Perhaps: alf-dot = alfanum *alfadot alf-dot-hyp = alfanum *(alfadot / "-") alf-dot-oth = alfanum *(alfadot / other) alfadot = alfanum / "." alfa = lowercase / uppercase alfanum = alfa / DIGIT / encoded --> 42) <!-- [rfced] We see some mismatches between the ABNF snippets in the document and the corresponding lines in Section 8. Please review and let us know how/if to update. a) NSS/NSS-lex definition Section 2.1: NSS = jurisdiction ":" local-name Section 8: NSS-lex = jurisdiction ":" local-name b) date-iso definition Section 3.6: date-iso = yyyy-mm-dd Section 8: date-iso = year "-" month "-" day c) date definition - note the spaces after "[" and before "]" in Section 3.6 that don't appear in Section 8. Section 3.6: date = date-iso [ "|" date-loc ] Section 8: date = date-iso ["|" date-loc] d) manifestation definition Section 5.7: manifestation = editor ":" format [":" component [":" feature]] Section 8: manifestation = format ":" editor [":" component [":" feature]] e) numbers definition Section 6.3.4: numbers = document-id *("," document-id) Section 8: numbers = (document-id *("," document-id)) / number-lex f) version definition - note the indent of second line Section 7.1.2: version = (amendment-date / specification) *(";" (event-date / event)) Section 8: version = (amendment-date / specification) *(";" (event-date / event)) --> 43) <!-- [rfced] We updated some <artwork> to <ul>. We have noted these instances below along with further edits made to each. Please review these in all output formats (txt, html, pdf) and let us know any concerns. a) Section 3.4: We updated the following <artwork> to be nested lists (<ul>), with just the "urn:lex" part tagged as <artwork>. We also made the following changes: - replaced the "=" with ":" - updated capitalization (of ascii, unicode, and utf-8, and punycode) - updated the text starting with "assuming that..." to be a note in the <aside> element. Original: a circular adopted by the Municipality of Munich (Rundschreiben der Stadt MU+00FCnchen): - ascii = urn:lex:de:stadt.munchen:rundschreiben:... - unicode = urn:lex:de:stadt.mU+00FCnchen:rundschreiben:... - utf-8 = urn:lex:de:stadt.m%xC3%xBCnchen:rundschreiben:... - punycode = urn:lex:de:stadt.xn-mnchen-3ya:rundschreiben:... a state law of the Russian Federation (latin: gosudarstvo zakon; cyrillic: U+0441U+043EU+0441U+0442U+043EU+044FU+043DU+0438U+0435 U+0437U+0430U+043AU+043EU+043D): - ascii = urn:lex:ru:gosudarstvo:zakon:... - unicode = urn:lex:ru:U+0441U+043EU+0441U+0442U+043EU+044FU+043D U+0438U+0435:U+0437U+0430U+043AU+043EU+043D:... - utf-8 = urn:lex:ru:%xD1%x81%xD0%xBE%xD1%x81%xD1%x82%xD0%xBE%xD1 %x8F%xD0%xBD%xD0%xB8%xD0%xB5:%xD0%xB7%xD0%xB0%xD0%xBA %xD0%xBE%xD0%xBD:... - punycode = urn:lex:ru:xn-80aebe3cdmfdkg:xn-80ankme:... assuming that the Russia jurisdiction-code is expressed in ASCII ("ru"), while the Cyrillic version ("U+0440U+0444") has the puny-code "xn-p1ai". b) Section 3.6: We updated the following <artwork> to be <ul>, with just the character strings tagged <artwork>. We also removed the semicolon after the first item, the close parentheses and period after the second item, and the quotation marks. Original: - in Hebrew characters: "U+05DBU+05F4U+05D0.U+05D0U+05B1U+05DCU+05D5U+05BCU+05DC.U+05EA U+05E9U+05E0U+05F4U+05D8"; - in UTF-8 code: "%x5c%x75%x30%x35%x44%x42%x5c%x75%x30%x35%x46%x34%x5c%x75%x30%x35 %x44%x30%x2e%x5c%x75%x30%x35%x44%x30%x5c%x75%x30%x35%x42%x31%x5c %x75%x30%x35%x44%x43%x5c%x75%x30%x35%x44%x35%x5c%x75%x30%x35%x42 %x43%x5c%x75%x30%x35%x44%x43%x2e%x5c%x75%x30%x35%x45%x41%x5c%x75 %x30%x35%x45%x39%x5c%x75%x30%x35%x45%x30%x5c%x75%x30%x35%x46%x34 %x5c%x75%x30%x35%x44%x38"). c) Section 5.4: We updated the following <artwork> to be <ul>, with just the "urn:lex" parts tagged as <artwork>. Original: - 4/59 Judgment of the EEC Court of Justice 04/04/1960, Mannesmann AG and others / ECSC High Authority urn:lex:eec.lex.arpa:court.justice:judgement:1960-04-04;4-59 - 4/59 Order of the EEC Court of Justice 18/05/1960, Mannesmann AG and others / ECSC High Authority urn:lex:eec.lex.arpa:court.justice:order:1960-05-18;4-59 d) Section 5.7: We updated the following <artwork> to be <ul>, with just the "urn:lex" parts tagged as <artwork>. We also removed the quotation marks around the "urn:lex" parts. Original: - PDF format (vers. 1.7) of the whole act edited by the Italian Parliament: "urn:lex:it:stato:legge:2000-04-03;56$application-pdf; 1.7:parlamento.it" - XML format (version 2.2 DTD NIR) of the text of the act and PDF format (version 1.7) of the "Figura 1" (figure 1) contained in the body, edited by the Italian Senate: "urn:lex:it:stato:legge:2000-04-03;56$text-xml;dtd-nir-2.2: senato.it:testo" "urn:lex:it:stato:legge:2000-04-03;56$application-pdf;1.7: senato.it:figura.1" e) Section 5.7: We removed the close parentheses at the end of this artwork block. We also removed the quotation marks. Original: "urn:lex:eu:tribunal.justicia:sentencia:2009-06-11;33-08 @original:es$text-html:juradmin.eu;jurifast:todo:anonimo") Current: "urn:lex:eu:tribunal.justicia:sentencia:2009-06-11;33-08 @original:es$text-html:juradmin.eu;jurifast:todo:anonimo" Perhaps: urn:lex:eu:tribunal.justicia:sentencia:2009-06-11;33-08 @original:es$text-html:juradmin.eu;jurifast:todo:anonimo --> 44) <!-- [rfced] Please review each remaining artwork element in the current xml file. Specifically, should any artwork element be tagged as <sourcecode>, <ul>, <t>, or another element? --> 45) <!-- [rfced] FYI - We have added expansions for the following abbreviation(s) upon first use per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness. Country Code Top-Level Domain (ccTLD) --> 46) <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language><https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. For example, please consider whether the following term should be updated: native Additionally, please consider whether "tradition" should be updated for clarity. While the NIST website <https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1><https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1> indicates that this term is potentially biased, it is also ambiguous. "Tradition" is a subjective term, as it is not the same for everyone. --> 47) <!-- [rfced] Please review the capitalization and use of quotation marks with "lex" and "LEX". Is there a pattern to follow for these? We listed some specific scenarios below; please review and let us know if any updates are needed for consistency. a) We see inconsistency with the following forms: lex schema vs. LEX schema lex URN vs. "lex" URN vs. LEX URN b) We also see these phrases: "lex” namespace "lex” NSS "lex” space "lex” NID syntax LEX identifier LEX name LEX identifier LEX governance LEX naming convention LEX specifications c) We also see "LEX" used by itself in the following: Original: A Uniform Resource Name (URN) Namespace for Sources of Law (LEX) Note: This is the document title. Please also see question #1. LEX does this by splitting the identifier into parts. LEX assumes no particular relationship between the originator of the document, Registration of LEX --> 48) <!-- [rfced] Terminology a) FYI - We updated instances of "URN LEX" to "LEX URN". b) We note inconsistencies in the terms listed below. We chose the form on the right. Please let us know any objections. urn-lex ID vs. urn:lex ID UNICODE vs. Unicode Registrar vs. Jurisdictional Registrar %-encoded vs. percent-encoded c) We note inconsistencies in the terms below throughout the text. Should these be uniform? If so, please let us know which form is preferred. http vs. HTTP (in the context of "http-based") local-name vs. local name body vs. Body jurisdiction code vs. jurisdiction-code Member State vs. member state --> Thank you. RFC Editor/mc/rv On Nov 14, 2024, at 1:28 PM, rfc-edi...@rfc-editor.org<mailto:rfc-edi...@rfc-editor.org> wrote: *****IMPORTANT***** Updated 2024/11/14 RFC Author(s): -------------- Instructions for Completing AUTH48 Your document has now entered AUTH48. Once it has been reviewed and approved by you and all coauthors, it will be published as an RFC. If an author is no longer available, there are several remedies available as listed in the FAQ (https://www.rfc-editor.org/faq/). You and you coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval. Planning your review --------------------- Please review the following aspects of your document: * RFC Editor questions Please review and resolve any questions raised by the RFC Editor that have been included in the XML file as comments marked as follows: <!-- [rfced] ... --> These questions will also be sent in a subsequent email. * Changes submitted by coauthors Please ensure that you review any changes submitted by your coauthors. We assume that if you do not speak up that you agree to changes submitted by your coauthors. * Content Please review the full content of the document, as this cannot change once the RFC is published. Please pay particular attention to: - IANA considerations updates (if applicable) - contact information - references * Copyright notices and legends Please review the copyright notice and legends as defined in RFC 5378 and the Trust Legal Provisions (TLP – https://trustee.ietf.org/license-info). * Semantic markup Please review the markup in the XML file to ensure that elements of content are correctly tagged. For example, ensure that <sourcecode> and <artwork> are set correctly. See details at <https://authors.ietf.org/rfcxml-vocabulary><https://authors.ietf.org/rfcxml-vocabulary>. * Formatted output Please review the PDF, HTML, and TXT files to ensure that the formatted output, as generated from the markup in the XML file, is reasonable. Please note that the TXT will have formatting limitations compared to the PDF and HTML. Submitting changes ------------------ To submit changes, please reply to this email using ‘REPLY ALL’ as all the parties CCed on this message need to see your changes. The parties include: * your coauthors * rfc-edi...@rfc-editor.org<mailto:rfc-edi...@rfc-editor.org> (the RPC team) * other document participants, depending on the stream (e.g., IETF Stream participants are your working group chairs, the responsible ADs, and the document shepherd). * auth48archive@rfc-editor.org<mailto:auth48archive@rfc-editor.org>, which is a new archival mailing list to preserve AUTH48 conversations; it is not an active discussion list: * More info: https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc * The archive itself: https://mailarchive.ietf.org/arch/browse/auth48archive/ * Note: If only absolutely necessary, you may temporarily opt out of the archiving of messages (e.g., to discuss a sensitive matter). If needed, please add a note at the top of the message that you have dropped the address. When the discussion is concluded, auth48archive@rfc-editor.org<mailto:auth48archive@rfc-editor.org> will be re-added to the CC list and its addition will be noted at the top of the message. You may submit your changes in one of two ways: An update to the provided XML file — OR — An explicit list of changes in this format Section # (or indicate Global) OLD: old text NEW: new text You do not need to reply with both an updated XML file and an explicit list of changes, as either form is sufficient. We will ask a stream manager to review and approve any changes that seem beyond editorial in nature, e.g., addition of new text, deletion of text, and technical changes. Information about stream managers can be found in the FAQ. Editorial changes do not require approval from a stream manager. Approving for publication -------------------------- To approve your RFC for publication, please reply to this email stating that you approve this RFC for publication. Please use ‘REPLY ALL’, as all the parties CCed on this message need to see your approval. Files ----- The files are available here: https://www.rfc-editor.org/authors/rfc9676.xml https://www.rfc-editor.org/authors/rfc9676.html https://www.rfc-editor.org/authors/rfc9676.pdf https://www.rfc-editor.org/authors/rfc9676.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9676-diff.html https://www.rfc-editor.org/authors/rfc9676-rfcdiff.html (side by side) Alt-diff of the text (allows you to more easily view changes where text has been deleted or moved): https://www.rfc-editor.org/authors/rfc9676-alt-diff.html Diff of the XML: https://www.rfc-editor.org/authors/rfc9676-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9676 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9676 (draft-spinosa-urn-lex-24) Title : A Uniform Resource Name (URN) Namespace for Sources of Law (LEX) Author(s) : P. Spinosa, E. Francesconi, C. Lupo WG Chair(s) : Area Director(s) :
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
