Dear Madison,
thanks for your additional remarks! Please find below (in-line) our comments
and proposals.
Best regards
Pierluigi and Enrico
________________________________
From: Madison Church <mchu...@staff.rfc-editor.org>
Sent: 29 January 2025 22:52
To: ENRICO FRANCESCONI <enrico.francesc...@cnr.it>; pierluigi.spin...@gmail.com
<pierluigi.spin...@gmail.com>; caterina.l...@gmail.com <caterina.l...@gmail.com>
Cc: Independent Submissions Editor (Eliot Lear) <rfc-...@rfc-editor.org>; RFC
Editor <rfc-edi...@rfc-editor.org>; 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 Authors,
Thank you for your reply! We have updated the document per your response.
Please see below for comments, followup questions, and updated files.
> 1) For Section 3.6 (Date Format), we are having trouble with the added
> Hebrew characters because the text mixes LTR (left to right) and RTL (right
> to left) scripts, which will cause errors when preparing this document for
> publication. We are currently experimenting with workarounds and will update
> you soon on potential solutions.
>
> That's fine. We wait for your updates
1) After some testing on our end, we believe the best path forward is to remove
the Hebrew characters that were added during AUTH48. We've been advised to
avoid mixing LTR (left to right) and RTL (right to left) text in the same
element since it causes issues at publication. We also noticed a mismatch
between the date given in Hebrew and in the U+ notation. The date in U+
notation below is "כ״א.א ֱלו ל.תשנ״ט", which translates to "2019-09-11" or
"11.Elul.5779". May we update as follows?
Current:
(e.g. the date in the previous example would be אלול,תשנ"ט.21
(21.Elul,5759), that is:
* in Hebrew characters "אלול,תשנ"ט.21":
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
Perhaps (using the date that is given in the U+ notation in the lead-in
sentence and removing the Hebrew):
For example, the date 11.Elul.5779 (2019-09-11) is the following in
Unicode U+ notation, which encodes the Hebrew:
U+05DBU+05F4U+05D0.U+05D0U+05B1U+05DCU+05D5U+05BCU+05DC.U+05EA
U+05E9U+05E0U+05F4U+05D8
And which is the following in UTF-8 percent-encoding:
%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
2) As RTL and LTR characters cannot be combined in one XML element, could the
following example be updated to use Cyrillic instead?
Current:
(e.g., "September 2, 99" will be written in ISO plus Hebrew format
as:
"1999-09-02|U+05D0U+05DCU+05D5U+05DC,U+05EAU+05E9U+05E0"U+05D8.21"
(אלול,תשנ"ט.21)).
Actually in v.18 of the URN:LEX draft, a reviewer explicitly asked to consider
the difficulties of conversion and interpretation of the ISO date for dates
belonging to non-Gregorian calendars.
For this reason, in v.19, we introduced an additional local date element
("date-loc") which makes sense only if it is referred to a different calendar,
like in the Hebrew case. Therefore, using a Cyrillic example does not fit for
purpose.
Therefore, we introduced a Hebrew date using the Latin Alphabet (as in the
example 21.Elul,5759), but a reviewer argued that people using the Hebrew
calendar would like to use the Hebrew script.
Another example of a non-Gregorian calendar is the Islamic one, which however
presents the same problem of RTL writing.
Now, to solve the issue related to left-to-right and right-to-left order, we
propose one of the following solutions:
1) to remove "date-loc" and keep only the ISO version of any date
2) to keep "date-loc" including, as example, a Hebrew date transformed into ISO
latin characters (ex: 21.Elul,5759)
3) to keep "date-loc" including just the Unicode U+ version, without using
Hebrew characters
Please let us know what do you prefer and we proceed with the update of the
document
> 2) For the following question:
> 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
> [rfced] Eliot is correct - we are not referring to an office, but "refers to
> a place, like a web site, in which records are stored."Based on our previous
> feedback, please verify that the term "register" is being used correctly or
> let us know if any updates are needed.
> No the terminology is not correct in at least one place. While the authors
> may call this new thing a register or a registry, what is certainly the case
> is that our terminology is "IANA registry". I would suggest a global change
> from register to registry, but I too would like the authors to confirm.
> Eliot
>
> As previously specified, we refer to a database of jurisdiction codes not to
> an office.
> In order to decide for “register" or “registry" we referred to English
> dictionaries and typical usage found on the Web. According to them we found
> the following distinction summed up here below:
>
> - Register: official list or record, for example of births, marriages, and
> deaths, of shipping, or of historic places. a book or record of attendance,
> for example of students in a class or school or guests in a hotel.
> - Registry: a place or office where registers or records are kept.
>
> That’s why at first we choose the term “register”. But if IANA uses the term
> “registry” to indicate a database, we rely on it and on native speakers'
> decision.
[rfced] Thank you for the clarification! We have updated the document to use
"registry" for consistency.
Ok, thanks!
> 3) Thank you for taking the time to update terms for consistency throughout
> the document! For the following term:local-name vs. local name Please let us
> know how we can update for consistency throughout the document or if the term
> is used correctly as is in each instance. For example, should "local name"
> appear with a space when the term is used on its own (e.g., "the remainder
> ("local name") is intended for local use…") and with a hyphen when the term
> modifies a noun (e.g., local-name components)?
>
> In our intention “local-name” (with hyphen) refers to a component of a LEX
> identifier: it is basically a non-terminal symbol (a variable) of an ABNF
> grammar.
> It is splitted into:
> local-name = work ["@" expression] ["$" manifestation]
>
> For this reason, we’d rather write it with hyphen, so the following changes
> have to be made:
>
> - "the remainder ("local name") is intended for local use…” —> "the
> remainder (“local-name") is intended for local use…”
> - "5.3. Structure of the Local Name” —> "5.3. Structure of the Local-Name”
> - "Therefore, the more general structure of the local name appears as
> follows:” —> "Therefore, the more general structure of the local-name
> appears as follows:”
> - "the local names considering the characteristics of its own state or
> institution organization.”—> "the local-name considering the characteristics
> of its own state or institution organization.”
> - "for defining formal parameters to guarantee local name uniqueness” —>
> "for defining formal parameters to guarantee local-name uniqueness"
[rfced] All remaining instances of "local name" (with a space) have been
updated to "local-name" (with a hyphen) per your reply.
The updated files have been posted here (please refresh):
https://www.rfc-editor.org/authors/rfc9676.txt
https://www.rfc-editor.org/authors/rfc9676.pdf
https://www.rfc-editor.org/authors/rfc9676.html
https://www.rfc-editor.org/authors/rfc9676.xml
The updated diff files have been posted here:
https://www.rfc-editor.org/authors/rfc9676-diff.html (comprehensive diff)
https://www.rfc-editor.org/authors/rfc9676-rfcdiff.html (side by side)
https://www.rfc-editor.org/authors/rfc9676-auth48diff.html (AUTH48 changes
only)
https://www.rfc-editor.org/authors/rfc9676-auth48rfcdiff.html (side by side)
Ok, thanks!
The AUTH48 status page can be found here:
https://www.rfc-editor.org/auth48/rfc9676
Thank you,
RFC Editor/mc
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
