Hi Pierluigi, Thank you for your reply! We have noted your approval on the AUTH48 status page (see https://www.rfc-editor.org/auth48/rfc9676).
Once we receive approval from Caterina, we will move this document forward in the publication process. Thank you! RFC Editor/mc > On Apr 21, 2025, at 4:40 PM, PierLuigi Spinosa <pierluigi.spin...@gmail.com> > wrote: > > 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
