Dear Sandy, thanks for your feedback! After a new double check, we found the following minor issue to fix at section 2.1:
jurisdiction-unit The possible administrative hierarchical —> jurisdiction-unit: The possible administrative hierarchical As for the points you addressed > > 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. We actually didn’t found differences with the last few versions. As for the RTL issue of the Hebrew strings, at section 3.6 the Hebrew date is still visualised differently in Chrome (aligned left) or Firefox (aligned right). It seems just a visualisation issue, therefore it shouldn’t be a problem of the document. Thanks for your collaboration! Best regards Pierluigi and Enrico > On 9 May 2025, at 23:11, Sandy Ginoza <sgin...@staff.rfc-editor.org> 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
