Hi Madison, we double checked the latest changes and everything seems ok. So for us we can proceed.
Thanks again for your collaboration! Pierluigi and Enrico > On 15 Apr 2025, at 17:43, Madison Church <mchu...@staff.rfc-editor.org> wrote: > > Hi Enrico, > > Thank you for your reply! We have updated the document as requested. Please > take a moment to review the changes and ensure they appear as desired. > > For the following: >>> 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. > Note that we’ve also updated the following sentence that originally cited > [ISO.8601.1988] in Section 3.6. Although the update is straightforward, > please review and let us know if you agree. > > Original: > [ISO.8601.1988] describes the international > format for representing dates. > > Current: > [ISO.8601-1.2019] and [ISO.8601-2.2019] describe the international > format for representing dates. > > With these changes in place, we believe that there are no further outstanding > items. 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 author prior to moving forward in the > publication process. > > 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 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 to https://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 > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
