Hi again, We believe we have found a workaround to get the text to display as expected. You can see the details here: https://mailarchive.ietf.org/arch/msg/rpat/U0cMkxnPVmk5gcH5dz7LUbStUWU/ We are waiting a few more days to understand if there are better alternatives.
As this workaround required the use of <br>, we noticed some other unconventional uses of <br> that were reintroduced into the XML during AUTH48. Please review the following updates in <https://www.rfc-editor.org/authors/rfc9676br.txt>: a) Section 2.1, example for "jurisdiction-unit” - we removed the use of <br> in the example. b) Section 8 - we combined the ABNF into one <sourcecode> block and condensed the groupings of ABNF with their explanatory comments. Please review and let us know if you have any major objections. Thank you, RFC Editor/sg > On May 5, 2025, at 3:05 PM, Sandy Ginoza <sgin...@staff.rfc-editor.org> wrote: > > 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
