Ack - thanks for confirming, Eliot. Thanks, Sandy
> On May 5, 2025, at 2:50 PM, Independent Submissions Editor (Eliot Lear) > <rfc-...@rfc-editor.org> wrote: > > Ok, I clicked wrong. I see what you're talking about. > > On 05.05.2025 23:46, Sandy Ginoza wrote: >> Hi Eliot, >> >> Are you using Firefox? It seems to be an issue with the text (.txt) display >> in Firefox. Please let me know if you are seeing something different. We >> have been pointed to these BiDi issues >> <https://bugzilla.mozilla.org/buglist.cgi?quicksearch=BiDi&list_id=17541332> >> so there is suspicion that the issue is wider spread. >> >> We’re discussing the issue with the tools team. >> Thanks, >> Sandy >> >> >> >> >>> On May 5, 2025, at 2:32 PM, Independent Submissions Editor (Eliot Lear) >>> <rfc-...@rfc-editor.org> >>> wrote: >>> >>> Sandy, oddly that link looks okay to me. What am I missing? >>> >>> On 05.05.2025 23:25, Sandy Ginoza wrote: >>> >>>> Greetings all, >>>> >>>> Please note that the PDF/A-3 we created previously indicated an error: >>>> Text cannot be mapped to Unicode. >>>> We have been working with the tools team to rectify the issue. We have >>>> eliminated the error by moving the explanatory text about the sequence of >>>> characters into a later paragraph - see >>>> >>>> <https://www.rfc-editor.org/authors/rfc9676-lastrfcdiff.html>. However, >>>> when viewed in Firefox, the first two characters in the explanatory >>>> paragraph of the resulting text file display in reverse order (see >>>> <https://www.rfc-editor.org/authors/rfc9676.txt> >>>> >>>> ). We are currently discussing options for getting this RFC published. >>>> We will send an update soon. >>>> >>>> The current files are available here: >>>> >>>> >>>> https://www.rfc-editor.org/authors/rfc9676.xml >>>> >>>> >>>> >>>> >>>> https://www.rfc-editor.org/authors/rfc9676.txt >>>> >>>> >>>> >>>> >>>> https://www.rfc-editor.org/authors/rfc9676.pdf >>>> >>>> >>>> >>>> >>>> https://www.rfc-editor.org/authors/rfc9676.html >>>> >>>> >>>> >>>> Diffs of the most recent update only: >>>> >>>> >>>> https://www.rfc-editor.org/authors/rfc9676-lastdiff.html >>>> >>>> >>>> >>>> >>>> https://www.rfc-editor.org/authors/rfc9676-lastrfcdiff.html >>>> >>>> (side by side) >>>> >>>> AUTH48 diffs: >>>> >>>> >>>> https://www.rfc-editor.org/authors/rfc9676-auth48diff.html >>>> >>>> >>>> >>>> >>>> https://www.rfc-editor.org/authors/rfc9676-auth48rfcdiff.html >>>> >>>> (side by side) >>>> >>>> Comprehensive diffs: >>>> >>>> >>>> https://www.rfc-editor.org/authors/rfc9676-diff.html >>>> >>>> >>>> >>>> >>>> https://www.rfc-editor.org/authors/rfc9676-rfcdiff.html >>>> >>>> (side by side) >>>> >>>> Please let us know if you have any questions. >>>> >>>> Thank you for your patience! >>>> RFC Editor/sg >>>> >>>> >>>> >>>> >>>>> On Apr 25, 2025, at 7:43 AM, Madison Church <mchu...@staff.rfc-editor.org> >>>>> >>>>> wrote: >>>>> >>>>> Hi All, >>>>> >>>>> Caterina - Thank you for your response! We’ve marked your approval on the >>>>> AUTH48 status page (see >>>>> >>>>> https://www.rfc-editor.org/auth48/rfc9676 >>>>> >>>>> ). >>>>> >>>>> We have now received all necessary approvals and consider AUTH48 >>>>> complete. Thank you all for your time and patience throughout this >>>>> process! We will prepare the document for publication shortly. >>>>> >>>>> Best, >>>>> RFC Editor/mc >>>>> >>>>> >>>>> >>>>>> On Apr 23, 2025, at 12:02 PM, Caterina Lupo <caterina.l...@gmail.com> >>>>>> >>>>>> wrote: >>>>>> >>>>>> dear Madison, >>>>>> I approve. >>>>>> I apologize for my late response. >>>>>> Many thanks to all of you ! >>>>>> Caterina >>>>>> >>>>>> Il giorno lun 21 apr 2025 alle 23:41 PierLuigi Spinosa >>>>>> >>>>>> <pierluigi.spin...@gmail.com> >>>>>> >>>>>> ha scritto: >>>>>> Dear Madison >>>>>> I approve. >>>>>> >>>>>> A great thank you to all! >>>>>> Pierluigi >>>>>> >>>>>> Il giorno lun 21 apr 2025 alle ore 21:26 Madison Church >>>>>> >>>>>> <mchu...@staff.rfc-editor.org> >>>>>> >>>>>> ha scritto: >>>>>> Hi Enrico and Eliot, >>>>>> >>>>>> Thank you both for your replies! We have noted your approvals for this >>>>>> document (see >>>>>> >>>>>> https://www.rfc-editor.org/auth48/rfc9676 >>>>>> >>>>>> ). >>>>>> >>>>>> Once we receive approvals from Pierluigi and Caterina, we will move this >>>>>> document forward in the publication process. >>>>>> >>>>>> Thank you! >>>>>> RFC Editor/mc >>>>>> >>>>>> >>>>>> >>>>>>> On Apr 20, 2025, at 10:49 AM, Independent Submissions Editor (Eliot >>>>>>> Lear) <rfc-...@rfc-editor.org> >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>> Approved. A special thank you, Madison, to you and the entire team on >>>>>>> this one. >>>>>>> Eliot >>>>>>> On 20.04.2025 17:21, ENRICO FRANCESCONI wrote: >>>>>>> >>>>>>> >>>>>>>> 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 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>> >>>>>> -- >>>>>> ing. Pierluigi Spinosa >>>>>> Via Zanardelli, 15 >>>>>> 50136 - Firenze >>>>>> >>>>>> >> -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
