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 >>>>>>>>>>>>>>> >>> >> -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
