4) We note that the ISO reference has been withdrawn and is no longer
available. There are two updated versions: ISO 8601-1:2019
(https://www.iso.org/standard/70907.html) and ISO 8601-2:2019
(https://www.iso.org/standard/70908.html). Would you like to update to use one
or the other? Or both?
Current:
[ISO.8601.1988]
ISO, "Data elements and interchange formats - Information
interchange - Representation of dates and times",
ISO 8601:1988, June 1988.
Perhaps:
[ISO.8601-1.2019]
ISO, "Date and time - Representations for information interchange",
ISO 8601-1:2019, February 2019.
[ISO.8601-2.2019]
ISO, "Data elements and interchange formats - Information
interchange - Representation of dates and times",
ISO 8601-2:2019, February 2019.
We think that including both is the best choice.
On Apr 13, 2025, at 12:42 PM, ENRICO FRANCESCONI<enrico.francesc...@cnr.it>
wrote:
Dear Madison,
thanks a lot for your collaboration!
We have double checked the latest version and we found the following issues:
1) At the end of section 3.4. "Unicode Characters Outside the ASCII Range"
- at Munich circular, the UTF-8 code still includes %xC3%xBC instead of %C3%BC,
- at Law of the Russian Federation, the UTF-8 code still includes
%xD1%x81%xD0... instead of %D1%81%D0… (it holds for all the 3 lines)
2) At section 3.6. "Date Format", at the very end of the section, after the
line:
"The characters that are not allowed (e.g., "/") or reserved (e.g., ",") cannot exist inside
the date-loc and therefore MUST be turned into "."."
we would add the following:
"To be aligned with ISO format, any blank between day, month and year MUST be converted into
"-"."
3) At section 5.7., at point "PDF format (vers. 1.7) of the whole act edited by the
Italian Parliament:"
In the example ending as follows
...application-pdf;1.7:
the colon (:) is to be removed.
As for the Hebrew dates, in html and pdf the ISO date and the Hebrew one are
correctly oriented, while in the txt they are not
As for your updates, please find in-line below our replies.
Best
Pierluigi and Enrico
On 2 Apr 2025, at 23:29, Madison Church<mchu...@staff.rfc-editor.org> wrote:
Hi All,
Thank you for your continued patience as we move forward with this document! We
have updated the files as requested to use hyphens in the Hebrew date example.
Additionally, the UTF-8 and U+ notations have been updated to reflect those
changes. We ask that you review the updates to ensure correctness.
Some additional updates we wanted to point out:
1) For the date example in Section 3.6, we have added a description containing
the order of the characters and how they should appear. This is due to the fact
that the Hebrew date may be displayed differently depending on different
document presentation environments.
OK
2) Pierluigi and Enrico noted the following on Feb 20th:
4) As for the example at the end of sect. 3.6, there is a mismatch between the
HTML format and PDF, as well as TXT, formats:
• in HTML we have: 1999-09-02|ט״נשת לוּלאֱבֶּ א״כ
• in PDF (at the top of pag. 17) the same dates appear as swapped
• in TXT the same dates appear:
• as in the HTML, if read via browser
• as swapped, if read locally via some text editors (in few cases even aligned
right)
Although most of these issues have been resolved due to the corrected PDF
output, we unfortunately do not have control over the .txt output or right
alignment in this case since the .txt output can vary depending on which
tool/browser is used. For example, Safari and Google Chrome display the date
correctly (1999-09-02|כ״א-בֶּאֱלוּל-תשנ״ט) while Firefox displays the date in
reverse (the Hebrew string followed by 1999-09-02).
OK
3) We also wanted to point out that the date itself has been updated as follows
since the previous version was displayed backwards upon further review. The RTL
characters now appear in the correct order.
Original:
ט״נשת לוּלאֱבֶּ א״כ
Current:
כ״א-בֶּאֱלוּל-תשנ״ט
OK
4) We note that the ISO reference has been withdrawn and is no longer
available. There are two updated versions: ISO 8601-1:2019
(https://www.iso.org/standard/70907.html) and ISO 8601-2:2019
(https://www.iso.org/standard/70908.html). Would you like to update to use one
or the other? Or both?
Current:
[ISO.8601.1988]
ISO, "Data elements and interchange formats - Information
interchange - Representation of dates and times",
ISO 8601:1988, June 1988.
Perhaps:
[ISO.8601-1.2019]
ISO, "Date and time - Representations for information interchange",
ISO 8601-1:2019, February 2019.
[ISO.8601-2.2019]
ISO, "Data elements and interchange formats - Information
interchange - Representation of dates and times",
ISO 8601-2:2019, February 2019.
We think that including both is the best choice.
The 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 relevant diff files have been posted here (please refresh):
https://www.rfc-editor.org/authors/rfc9676-diff.html (comprehensive diff)
https://www.rfc-editor.org/authors/rfc9676-rfcdiff.html (side by side view)
https://www.rfc-editor.org/authors/rfc9676-auth48diff.html (all changes made in
AUTH48)
https://www.rfc-editor.org/authors/rfc9676-auth48rfcdiff.html (side by side
view of all AUTH48 changes)
https://www.rfc-editor.org/authors/rfc9676-lastdiff.html (most recent updates)
https://www.rfc-editor.org/authors/rfc9676-lastrfcdiff.html (side by side view
of most recent updates)
For the AUTH48 status of this document, please see:
https://www.rfc-editor.org/auth48/rfc9676
Thank you,
RFC Editor/mc
On Mar 31, 2025, at 3:56 PM, Madison Church<mchu...@staff.rfc-editor.org> wrote:
Hi Eliot and Enrico,
Thank you both for your messages and apologies for the delayed response on our
end!
At the moment, we are currently waiting for a tools update that will fix the
PDF output of the left-to-right and right-to-left text in Section 3.6. The
tools update that includes this fix is planned for this week. Once the update
is complete, we will send updated files that incorporate Enrico’s requested
updates regarding spaces in the Hebrew date.
Thank you for your patience!
Best,
RFC Editor/mc
On Mar 31, 2025, at 2:49 PM, ENRICO FRANCESCONI<enrico.francesc...@cnr.it>
wrote:
Dear Eliot,
the latest email of ours was on March 6th about spaces in Hebrew dates. In our
opinion it was the last issue to fix. We are now waiting for feedback.
Best
Enrico
On 31 Mar 2025, at 20:25, Independent Submissions Editor (Eliot
Lear)<rfc-...@rfc-editor.org> wrote:
Madison, Enrico, where are we?
Eliot
On 06.03.2025 06:12, ENRICO FRANCESCONI wrote:
Dear Madison and Eliot,
thanks for your feedback about dates and different conversion formats.
In this respect, we noticed a potential issue in the fact that the Hebrew date
is written using spaces. Now, the LEX specifications suggest to replace spaces
with dots. On the other hand in the dates in ISO format the separator is a dash
(“-”).
This should apply for the Hebrew format too, as well as for its U+ and utf-8
versions. Therefore, we think that one of such characters (“-” or “.”) is to be
included in the Hebrew format and converted in U+ and utf-8.
Our preference would be to use “-” for dates, anyway even the version with “.”
can be ok.
Therefore, the Hebrew example would become:
ט״נשת-לוּלאֱב-א״כ (for us to be preferred) or ט״נשת.לוּלאֱב.א״כ
Sorry for this additional burden, anyway it seems that we are close to finalise
the RFC!
Best
Pierluigi and Enrico
On 5 Mar 2025, at 10:23, Independent Submissions Editor (Eliot
Lear)<rfc-...@rfc-editor.org> wrote:
On 20.02.2025 22:18, ENRICO FRANCESCONI wrote:
Dear Madison and Eliot,
we were preparing an answer to the previous message, when we received two new
emails of yours.
We report in the following our reply which partially addresses the issue on
Hebrew characters you underline in your message.
As for the alternatives you propose, we agree with Eliot that option 2), using
the workaround described, is to be preferred.
Now, please, see the answer we had prepared:
Dear Madison and Eliot,
we read again the whole document, and we found the following residual four
issues:
---
• We checked the conversion of the Hebrew characters and it seems to us that
the U+ conversion reported in the RFC is not correct:
ט״נשת לוּלאֱבֶּ א״כ in U+ should be:
U+05D8U+05F4U+05E0U+05E9U+05EAU+0020U+05DCU+05D5U+05BCU+05DCU+05D0U+05B1U+05D1U+05B6U+05BCU+0020U+05D0U+05F4U+05DB
According tohttps://r12a.github.io/app-conversion/, your correction is correct.
Please double check and fix it in the draft
---
• As for the conversion of the same date into UTF-8, it seems that it is wrong
as well, because it includes also the conversion of the U+ (%x55%x2b).
The correct one should be:
%xd7%x98%xd7%xb4%xd7%xa0%xd7%xa9%xd7%xaa%x20%xd7%x9c%xd7%x95%xd6%xbc%xd7%x9c%xd7%x90%xd6%xb1%xd7%x91%xd6%xb6%xd6%xbc%x20%xd7%x90%xd7%xb4%xd7%x9b
Same web site, this seems correct, assuming the x is appropriate.
Eliot
Please double check as well, and fix it in the draft
---
3) In general, and in the reported example in particular, if "data-loc" is
used internally, the following value can be kept: ט״נשת לוּלאֱבֶּ א״כ , but if it is to
be transmitted over the network, it is to be converted into UTF-8.
The example at the end of section 3.6 should, therefore, be written as follows:
"For example, 1999-09-02 will be written in ISO plus Hebrew format as:
1999-09-02|ט״נשת לוּלאֱבֶּ א״כ
which, see Section 3.4, is to be converted in UTF-8 for network protocols and for
resolution."
---
4) As for the example at the end of sect. 3.6, there is a mismatch between
the HTML format and PDF, as well as TXT, formats:
• in HTML we have: 1999-09-02|ט״נשת לוּלאֱבֶּ א״כ
• in PDF (at the top of pag. 17) the same dates appear as swapped
• in TXT the same dates appear:
• as in the HTML, if read via browser
• as swapped, if read locally via some text editors (in few cases even aligned
right)
---
Please let us know if you need more clarifications
Thanks for your attention!
Best regards
Pierluigi and Enrico
On 20 Feb 2025, at 21:24, Independent Submissions Editor (Eliot
Lear)<rfc-...@rfc-editor.org> wrote:
Madison,
Here's my view: I think your suggestion directly below is better than an
indefinite hold on a document. I would like the authors to weigh in.
Eliot
On 20.02.2025 21:21, Madison Church wrote:
If TI state is not favorable due to the unpredictable timeframe, another option
for a workaround would be to describe the order of the characters in the date
example and how they should appear (for a visual, see the Hebrew string that
appears in Section A.3 of RFC 9290 [4]).
For example:
"The following example uses right-to-left (RTL) script, which in the context of
this specification may be rendered differently by different document presentation
environments. The descriptive text may be more reliable to follow than the
necessarily device- and application-specific rendering. For example, 1999-09-02 will
be written in ISO plus Hebrew format:
1999-09-02|ט״נשת לוּלאֱבֶּ א״כ
where in direction of reading, the sequence of characters is…"
As always, if there are any additional questions, please feel free to reach
out. In the meantime, please let us know which option is preferred: 1) move
forward with placing the document into TI state, or 2) use the proposed
workaround above. If option 2 is preferred, we will make the update and send
files along for the authors and Eliot to approve.
[1]https://www.rfc-editor.org/auth48/rfc9676
[2]https://www.rfc-editor.org/about/queue/flowchart/
[3]https://github.com/ietf-tools/xml2rfc/issues/1226
[4]https://www.rfc-editor.org/rfc/rfc9290.html#appendix-A.3
Thank you!
RFC Editor/mc
On Feb 15, 2025, at 5:25 AM, Independent Submissions Editor (Eliot
Lear)<rfc-...@rfc-editor.org> wrote:
Madison, authors,
Let's be clear on what is being requested at this stage:
• Authors should review all versions of the document (text/html/pdf) for any
issues, and promptly report them. The exception is the one issue below
regarding Hebrew dates.
• The document will be held in TI state until such time as the tools team can
fix the formatting issue.
• Once that issue is resolved, the document will be regenerated.
• After that, authors will signal their approval.
• After that I will perform my final review.
• After that the RFC Editor will publish the RFC.
I want to confirm that this is what is expected. Do we have any estimate as to
how long the document will remain in TI state? I do not want this document
languishing longer than it already has. If it will take an extended period to
make correction (months), then we should look at other alternatives.
Eliot
On 13.02.2025 17:21, Madison Church wrote:
Hi Authors,
Thank you for your patience as we work through this issue.
We have updated the document as requested and incorporated the new U+ and UTF-8
notations for the Hebrew date. We ask that you verify the changes to ensure our
updates are correct.
After some further testing on our end, we are still unable to get the Hebrew
date to align correctly in the text output. Moving forward, we believe the best
solution is to 1) ensure that all changes in the document are approved by each
party, and 2) place this document into Tools Improvement (TI) state once AUTH48
is complete. As of right now, the formatting of the Hebrew date is the only
outstanding issue.
Please review the document carefully to ensure satisfaction as we do not make
changes once it has been published as an RFC. Contact us with any further
updates or with your approval of the document in its current form. We will
await approvals from each party prior to moving forward resolving this issue in
the publication process.
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)
The AUTH48 status page can be found
here:https://www.rfc-editor.org/auth48/rfc9676
To track the issue in GitHub, please
see:https://github.com/ietf-tools/xml2rfc/issues/1224
Thank you,
RFC Editor/mc
On Feb 7, 2025, at 6:38 AM, ENRICO FRANCESCONI<enrico.francesc...@cnr.it> wrote:
P {margin-top:0;margin-bottom:0;} Dear Madison, Dear Eliot,
thanks for your suggestions. As for the conversion Latin --> Hebrew of the
example date, we have probably used a wrong converter, so we agree to use the
conversion you suggest.
As for the rest, please find in-line our replies.
Thanks!
Pierluigi and Enrico
From: Madison Church<mchu...@staff.rfc-editor.org>
Sent: 05 February 2025 18:28
To: Independent Submissions Editor (Eliot Lear)<rfc-...@rfc-editor.org>; ENRICO
FRANCESCONI<enrico.francesc...@cnr.it>;pierluigi.spin...@gmail.com
<pierluigi.spin...@gmail.com>;caterina.l...@gmail.com <caterina.l...@gmail.com>
Cc: 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 and Eliot,
Thank you for your replies!
Authors - To confirm, you are suggesting that the example be shown as the
following (Removing the U+ notation and keeping the Hebrew format):
(e.g., "September 2, 99" will be written in ISO plus Hebrew format as
"1999-09-02|אלול,תשנ"ט.21").
Fine to remove the U+ format and keep the Hebrew format as in the example above
(end of Section 3.6).
Obviously, the right conversion into Hebrew characters (you suggest here below)
is to be used.
Please consider that in Section 3.6, all the occurrences of the example Hebrew
date, in Hebrew, U+ and UTF-8 notations, have to be updated accordingly, so
that they are all aligned with the new conversion you suggest.
Please note that this calendar converter [1] translates 1999-09-02 to כ״א
בֶּאֱלוּל תשנ״ט, and it does not use Arabic numerals nor punctuation in the
translation. Please confirm the use of Arabic numerals and punctuation for the
date-loc format.
[1]https://www.hebcal.com/converter?gd=2&gm=9&gy=1999&g2h=1
Thank you,
RFC Editor/mc
On Feb 2, 2025, at 1:38 PM, Independent Submissions Editor (Eliot
Lear)<rfc-...@rfc-editor.org> wrote:
My view:
On 02.02.2025 19:52, ENRICO FRANCESCONI wrote:
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
I don't like any of these options because none of them provide an example that
people going left to right would actually use. I am also concerned about
Chinese, fwiw.
Eliot
<image.png> <image.png> <image.png> <image.png> <image.png> Enrico Francesconi
CNR, INSTITUTE OF LEGAL INFORMATICS AND JUDICIAL SYSTEMS
Research Director
Tel. +390554399611
enrico.francesc...@cnr.it
enrico.francesc...@igsg.cnr.it
via de' Barucci, 20, 50127 – Florence (Italy)
www.cnr.it
Devolvi il 5×1000 al CNR
CF 80054330586
