Dear Eliot,
thanks for your feedback. Below in-line our remarks. If all is
good, we will upload the next version (25), where all the remaining
issues are fixed.
Thanks!
Pierluigi and Enrico
------------------------------------------------------------------------
*From:* Independent Submissions Editor (Eliot Lear)
<rfc-...@rfc-editor.org>
*Sent:* 12 December 2024 09:38
*To:* ENRICO FRANCESCONI <enrico.francesc...@cnr.it>;
rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>;
pierluigi.spin...@gmail.com <pierluigi.spin...@gmail.com>;
caterina.l...@gmail.com <caterina.l...@gmail.com>
*Cc:* superu...@gmail.com <superu...@gmail.com>;
auth48archive@rfc-editor.org <auth48archive@rfc-editor.org>
*Subject:* Re: AUTH48: RFC-to-be 9676 <draft-spinosa-urn-lex-24>
for your review
Hi Enrico,
Please see below.
On 10.12.2024 20:19, ENRICO FRANCESCONI wrote:
Dear Colleagues,
thanks a lot for your extensive review of the URN:LEX draft and
sorry for our delay.
We have reported in a new draft all your remarks accepting your
proposals, except the ones still in doubts. Please find them,
in-line, here below. Once clarified these last doubts, we can
submit the new, and hopefully final, version.
Thanks for your collaboration!
best
Pierluigi and Enrico
>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")?
*>No, it is actually a database, not the office managing such a
database*
The RFC Editor will correct me if I am wrong, but registry in this
case refers to a place, like a web site, in which records are
stored, not so much the office.
*Actually, in our view, it is both the things: an archive of the
jurisdiction codes and a website in which jurisdiction code records
can be queried. Anyway, let's wait for RFC Editors feedback*
>
>c) Would it be helpful to include a citation or URL so readers
can access the
>new jurisdiction-code registry?
>-->
*>We said already that it did not exist yet and we would create it
when the rfc would be approved. The reviewers accepted that…*
*>See also next period at section 2.2 (end of [page 10]): “The
table is initially empty.”*
For intents and purposes, we are at that point. There is value in
providing the URL, so my suggestion would be to do that, to get
the initial link up and running, and then issue the RFC. That
way, people won't have to go hunting around for a link on the
web. Better to be authoritative now if we can be. HOWEVER, any
link listed should indicate that it might change (assuming it
might change ;-).
*We have just asked our colleagues at IIT-CNR (dealing with URN:LEX
technical infrastructure) to provide such URL and related page *
*about jurisdiction-code register*
>
>
>
>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).
>-->
>
> *Currently such website is not available. As soon as the draft will be
approved we will contact experts and create the Designated Expert(s)
board*
*>*
Same as above. Even if the link indicates "under construction,
contact so-and-so for more information", that would be better than
nothing.
*OK*
>
>
>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://authors.ietf.org/en/non-ascii-characters-in-rfcxml>
>https://www.rfc-editor.org/styleguide/part2/#nonascii
<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
<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.
>-->
*>The problem here is that non-ASCII characters are not accepted
in the txt version (derived from mkd which is our source file)*
That is not entirely the case. You CAN have certain non-ASCII
characters in text that doesn't impact the protocol operation. So
the RFC Editor's change in example 1 is acceptable (and they ought
to know!).
*OK, we have done so.* *In updating the document we have followed
the indications of the latest draft regarding non-ASCII
characters, i.e.
https://datatracker.ietf.org/doc/html/draft-rswg-rfc7997bis-03,
which, *
*although not yet approved, brings some non-substantial changes to
RFC7997.* *Basically, we have operated as follows: *
*words with the non-ASCII characters are inserted directly into
the document, followed in brackets by the same words with the
non-ASCII characters indicated *
*in the form U+nnnn (a modality already provided for by RFC7997). *
*Example:* *OLD:* *...the Italian term sanitU+00E0 replaced...*
*NEW:* *...the Italian term "sanità" (sanitU+00E0) replaced...*
>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
<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]
>...
>-->
*> We couldn't find how to include<sourcecode type="abnf"> in the
mkd document, which is our source file.*
In this case "sourcecode" is a tag not necessarily pointing to the
location of the source.
*We had used ~~~~~ (converted to <artwork> in the xml version) only to
highlight more some parts of the text, and in particular: ABNF
formulas, examples, list of reserved characters. The solution we have
conceived is the following: - converted ~~~~~ (<artwork> in xml) into
``` (<tt> in xml) in all the ABNF formula, where actually we deal with
codes, highlighted in the text; - kept ~~~~~ (<artwork> in xml) in all
the examples and in the list of the reserved characters, which are not
actual codes but are to be highlighed in the text. In our opinion,
it’s not appropriate to change them as unnumbered lists (<ul>),
because it makes us lose the text highlighting.***
