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>
> 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>
> Sent: 21 November 2024 17:24
> To: Madison Church <mchu...@amsl.com>; pierluigi.spin...@gmail.com
> <pierluigi.spin...@gmail.com>; caterina.l...@gmail.com
> <caterina.l...@gmail.com>; ENRICO FRANCESCONI <enrico.francesc...@cnr.it>
> 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 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 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>
> 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>
> 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 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>.
>
> * 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 (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, 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 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
