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 onhttps://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) :
