Hi Eliot, We expect to publish the RFC later today, assuming we don’t run into any further issues.
Thanks, RFC Editor/sg > On May 15, 2025, at 9:16 AM, Independent Submissions Editor (Eliot Lear) > <rfc-...@rfc-editor.org> wrote: > > Sandy, > > I think this is a fine solution. Please proceed with publication. > > Eliot > > On 09.05.2025 23:11, Sandy Ginoza wrote: >> 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
