Congratulations - RFC 9676 was announced! https://mailarchive.ietf.org/arch/msg/rfc-dist/Ptm9SWrtGLc3gvosfuFriRIJaAw/ https://mailarchive.ietf.org/arch/msg/ietf-announce/tRyB0X9lomsUhsW-4i1zsCNevi0/
Thank you for your reviews and patience as we worked through the various issues! RFC Editor/sg > On May 20, 2025, at 9:02 AM, Sandy Ginoza <sgin...@staff.rfc-editor.org> > wrote: > > Hi Eliot, > > We expect to publish the RFC later today, assuming we don’t run into any > further issues. > > Thanks, > RFC Editor/sg > > >> On May 15, 2025, at 9:16 AM, Independent Submissions Editor (Eliot Lear) >> <rfc-...@rfc-editor.org> wrote: >> >> Sandy, >> >> I think this is a fine solution. Please proceed with publication. >> >> Eliot >> >> On 09.05.2025 23:11, Sandy Ginoza wrote: >>> Hi again, >>> >>> We believe we have found a workaround to get the text to display as >>> expected. You can see the details here: >>> >>> https://mailarchive.ietf.org/arch/msg/rpat/U0cMkxnPVmk5gcH5dz7LUbStUWU/ >>> >>> We are waiting a few more days to understand if there are better >>> alternatives. >>> >>> As this workaround required the use of <br>, we noticed some other >>> unconventional uses of <br> that were reintroduced into the XML during >>> AUTH48. Please review the following updates in >>> >>> <https://www.rfc-editor.org/authors/rfc9676br.txt> >>> : >>> >>> a) Section 2.1, example for "jurisdiction-unit” - we removed the use of >>> <br> in the example. >>> >>> b) Section 8 - we combined the ABNF into one <sourcecode> block and >>> condensed the groupings of ABNF with their explanatory comments. >>> >>> Please review and let us know if you have any major objections. >>> >>> Thank you, >>> RFC Editor/sg >>> >>> >>> >>>> On May 5, 2025, at 3:05 PM, Sandy Ginoza <sgin...@staff.rfc-editor.org> >>>> wrote: >>>> >>>> Ack - thanks for confirming, Eliot. >>>> >>>> Thanks, >>>> Sandy >>>> >>>> >>>>> On May 5, 2025, at 2:50 PM, Independent Submissions Editor (Eliot Lear) >>>>> <rfc-...@rfc-editor.org> >>>>> wrote: >>>>> >>>>> Ok, I clicked wrong. I see what you're talking about. >>>>> >>>>> On 05.05.2025 23:46, Sandy Ginoza wrote: >>>>> >>>>>> Hi Eliot, >>>>>> >>>>>> Are you using Firefox? It seems to be an issue with the text (.txt) >>>>>> display in Firefox. Please let me know if you are seeing something >>>>>> different. We have been pointed to these BiDi issues >>>>>> >>>>>> <https://bugzilla.mozilla.org/buglist.cgi?quicksearch=BiDi&list_id=17541332> >>>>>> >>>>>> so there is suspicion that the issue is wider spread. >>>>>> >>>>>> We’re discussing the issue with the tools team. >>>>>> Thanks, >>>>>> Sandy >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On May 5, 2025, at 2:32 PM, Independent Submissions Editor (Eliot Lear) >>>>>>> <rfc-...@rfc-editor.org> >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>> Sandy, oddly that link looks okay to me. What am I missing? >>>>>>> >>>>>>> On 05.05.2025 23:25, Sandy Ginoza wrote: >>>>>>> >>>>>>> >>>>>>>> Greetings all, >>>>>>>> >>>>>>>> Please note that the PDF/A-3 we created previously indicated an error: >>>>>>>> Text cannot be mapped to Unicode. >>>>>>>> We have been working with the tools team to rectify the issue. We >>>>>>>> have eliminated the error by moving the explanatory text about the >>>>>>>> sequence of characters into a later paragraph - see >>>>>>>> >>>>>>>> >>>>>>>> <https://www.rfc-editor.org/authors/rfc9676-lastrfcdiff.html>. >>>>>>>> However, when viewed in Firefox, the first two characters in the >>>>>>>> explanatory paragraph of the resulting text file display in reverse >>>>>>>> order (see <https://www.rfc-editor.org/authors/rfc9676.txt> >>>>>>>> >>>>>>>> >>>>>>>> ). We are currently discussing options for getting this RFC >>>>>>>> published. We will send an update soon. >>>>>>>> >>>>>>>> The current files are available here: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> https://www.rfc-editor.org/authors/rfc9676.xml >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> https://www.rfc-editor.org/authors/rfc9676.txt >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> https://www.rfc-editor.org/authors/rfc9676.pdf >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> https://www.rfc-editor.org/authors/rfc9676.html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Diffs of the most recent update only: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> https://www.rfc-editor.org/authors/rfc9676-lastdiff.html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> https://www.rfc-editor.org/authors/rfc9676-lastrfcdiff.html >>>>>>>> >>>>>>>> >>>>>>>> (side by side) >>>>>>>> >>>>>>>> AUTH48 diffs: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> https://www.rfc-editor.org/authors/rfc9676-auth48diff.html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> https://www.rfc-editor.org/authors/rfc9676-auth48rfcdiff.html >>>>>>>> >>>>>>>> >>>>>>>> (side by side) >>>>>>>> >>>>>>>> Comprehensive diffs: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> https://www.rfc-editor.org/authors/rfc9676-diff.html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> https://www.rfc-editor.org/authors/rfc9676-rfcdiff.html >>>>>>>> >>>>>>>> >>>>>>>> (side by side) >>>>>>>> >>>>>>>> Please let us know if you have any questions. >>>>>>>> >>>>>>>> Thank you for your patience! >>>>>>>> RFC Editor/sg >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Apr 25, 2025, at 7:43 AM, Madison Church >>>>>>>>> <mchu...@staff.rfc-editor.org> >>>>>>>>> >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> Caterina - Thank you for your response! We’ve marked your approval on >>>>>>>>> the AUTH48 status page (see >>>>>>>>> >>>>>>>>> >>>>>>>>> https://www.rfc-editor.org/auth48/rfc9676 >>>>>>>>> >>>>>>>>> >>>>>>>>> ). >>>>>>>>> >>>>>>>>> We have now received all necessary approvals and consider AUTH48 >>>>>>>>> complete. Thank you all for your time and patience throughout this >>>>>>>>> process! We will prepare the document for publication shortly. >>>>>>>>> >>>>>>>>> Best, >>>>>>>>> RFC Editor/mc >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Apr 23, 2025, at 12:02 PM, Caterina Lupo <caterina.l...@gmail.com> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> dear Madison, >>>>>>>>>> I approve. >>>>>>>>>> I apologize for my late response. >>>>>>>>>> Many thanks to all of you ! >>>>>>>>>> Caterina >>>>>>>>>> >>>>>>>>>> Il giorno lun 21 apr 2025 alle 23:41 PierLuigi Spinosa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> <pierluigi.spin...@gmail.com> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ha scritto: >>>>>>>>>> Dear Madison >>>>>>>>>> I approve. >>>>>>>>>> >>>>>>>>>> A great thank you to all! >>>>>>>>>> Pierluigi >>>>>>>>>> >>>>>>>>>> Il giorno lun 21 apr 2025 alle ore 21:26 Madison Church >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> <mchu...@staff.rfc-editor.org> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ha scritto: >>>>>>>>>> Hi Enrico and Eliot, >>>>>>>>>> >>>>>>>>>> Thank you both for your replies! We have noted your approvals for >>>>>>>>>> this document (see >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9676 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ). >>>>>>>>>> >>>>>>>>>> Once we receive approvals from Pierluigi and Caterina, we will move >>>>>>>>>> this document forward in the publication process. >>>>>>>>>> >>>>>>>>>> Thank you! >>>>>>>>>> RFC Editor/mc >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Apr 20, 2025, at 10:49 AM, Independent Submissions Editor (Eliot >>>>>>>>>>> Lear) <rfc-...@rfc-editor.org> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Approved. A special thank you, Madison, to you and the entire team >>>>>>>>>>> on this one. >>>>>>>>>>> Eliot >>>>>>>>>>> On 20.04.2025 17:21, ENRICO FRANCESCONI wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Hi Madison, >>>>>>>>>>>> we double checked the latest changes and everything seems ok. So >>>>>>>>>>>> for us we can proceed. >>>>>>>>>>>> >>>>>>>>>>>> Thanks again for your collaboration! >>>>>>>>>>>> Pierluigi and Enrico >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On 15 Apr 2025, at 17:43, Madison Church >>>>>>>>>>>>> <mchu...@staff.rfc-editor.org> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Enrico, >>>>>>>>>>>>> >>>>>>>>>>>>> Thank you for your reply! We have updated the document as >>>>>>>>>>>>> requested. Please take a moment to review the changes and ensure >>>>>>>>>>>>> they appear as desired. >>>>>>>>>>>>> >>>>>>>>>>>>> For the following: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> 4) We note that the ISO reference has been withdrawn and is no >>>>>>>>>>>>>>> longer available. There are two updated versions: ISO >>>>>>>>>>>>>>> 8601-1:2019 (https://www.iso.org/standard/70907.html) and ISO >>>>>>>>>>>>>>> 8601-2:2019 (https://www.iso.org/standard/70908.html >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ). Would you like to update to use one or the other? Or both? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Current: >>>>>>>>>>>>>>> [ISO.8601.1988] >>>>>>>>>>>>>>> ISO, "Data elements and interchange formats - Information >>>>>>>>>>>>>>> interchange - Representation of dates and times", >>>>>>>>>>>>>>> ISO 8601:1988, June 1988. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>>>> [ISO.8601-1.2019] >>>>>>>>>>>>>>> ISO, "Date and time - Representations for information >>>>>>>>>>>>>>> interchange", >>>>>>>>>>>>>>> ISO 8601-1:2019, February 2019. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [ISO.8601-2.2019] >>>>>>>>>>>>>>> ISO, "Data elements and interchange formats - Information >>>>>>>>>>>>>>> interchange - Representation of dates and times", >>>>>>>>>>>>>>> ISO 8601-2:2019, February 2019. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> We think that including both is the best choice. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> Note that we’ve also updated the following sentence that >>>>>>>>>>>>> originally cited [ISO.8601.1988] in Section 3.6. Although the >>>>>>>>>>>>> update is straightforward, please review and let us know if you >>>>>>>>>>>>> agree. >>>>>>>>>>>>> >>>>>>>>>>>>> Original: >>>>>>>>>>>>> [ISO.8601.1988] describes the international >>>>>>>>>>>>> format for representing dates. >>>>>>>>>>>>> >>>>>>>>>>>>> Current: >>>>>>>>>>>>> [ISO.8601-1.2019] and [ISO.8601-2.2019] describe the international >>>>>>>>>>>>> format for representing dates. >>>>>>>>>>>>> >>>>>>>>>>>>> With these changes in place, we believe that there are no further >>>>>>>>>>>>> outstanding items. Please review the document carefully to ensure >>>>>>>>>>>>> satisfaction as we do not make changes once it has been published >>>>>>>>>>>>> as an RFC. Contact us with any further updates or with your >>>>>>>>>>>>> approval of the document in its current form. We will await >>>>>>>>>>>>> approvals from each author prior to moving forward in the >>>>>>>>>>>>> publication process. >>>>>>>>>>>>> >>>>>>>>>>>>> The files have been posted here (please refresh): >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9676.txt >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9676.pdf >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9676.html >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9676.xml >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> The relevant diff files have been posted here (please refresh): >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9676-diff.html >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> (comprehensive diff) >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9676-rfcdiff.html >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> (side by side view) >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9676-auth48diff.html >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> (all changes made in AUTH48) >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9676-auth48rfcdiff.html >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> (side by side view of all AUTH48 changes) >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9676-lastdiff.html >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> (most recent updates) >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9676-lastrfcdiff.html >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> (side by side view of most recent updates) >>>>>>>>>>>>> >>>>>>>>>>>>> For the AUTH48 status of this document, please see: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9676 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thank you, >>>>>>>>>>>>> RFC Editor/mc >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On Apr 13, 2025, at 12:42 PM, ENRICO FRANCESCONI >>>>>>>>>>>>>> <enrico.francesc...@cnr.it> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Dear Madison, >>>>>>>>>>>>>> thanks a lot for your collaboration! >>>>>>>>>>>>>> We have double checked the latest version and we found the >>>>>>>>>>>>>> following issues: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1) At the end of section 3.4. "Unicode Characters Outside the >>>>>>>>>>>>>> ASCII Range" >>>>>>>>>>>>>> - at Munich circular, the UTF-8 code still includes %xC3%xBC >>>>>>>>>>>>>> instead of %C3%BC, >>>>>>>>>>>>>> - at Law of the Russian Federation, the UTF-8 code still >>>>>>>>>>>>>> includes %xD1%x81%xD0... instead of %D1%81%D0… (it holds for all >>>>>>>>>>>>>> the 3 lines) >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2) At section 3.6. "Date Format", at the very end of the >>>>>>>>>>>>>> section, after the line: >>>>>>>>>>>>>> "The characters that are not allowed (e.g., "/") or reserved >>>>>>>>>>>>>> (e.g., ",") cannot exist inside the date-loc and therefore MUST >>>>>>>>>>>>>> be turned into "."." >>>>>>>>>>>>>> >>>>>>>>>>>>>> we would add the following: >>>>>>>>>>>>>> "To be aligned with ISO format, any blank between day, month and >>>>>>>>>>>>>> year MUST be converted into "-"." >>>>>>>>>>>>>> >>>>>>>>>>>>>> 3) At section 5.7., at point "PDF format (vers. 1.7) of the >>>>>>>>>>>>>> whole act edited by the Italian Parliament:" >>>>>>>>>>>>>> In the example ending as follows >>>>>>>>>>>>>> ...application-pdf;1.7: >>>>>>>>>>>>>> the colon (:) is to be removed. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> As for the Hebrew dates, in html and pdf the ISO date and the >>>>>>>>>>>>>> Hebrew one are correctly oriented, while in the txt they are not >>>>>>>>>>>>>> >>>>>>>>>>>>>> As for your updates, please find in-line below our replies. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Best >>>>>>>>>>>>>> Pierluigi and Enrico >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 2 Apr 2025, at 23:29, Madison Church >>>>>>>>>>>>>>> <mchu...@staff.rfc-editor.org> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thank you for your continued patience as we move forward with >>>>>>>>>>>>>>> this document! We have updated the files as requested to use >>>>>>>>>>>>>>> hyphens in the Hebrew date example. Additionally, the UTF-8 and >>>>>>>>>>>>>>> U+ notations have been updated to reflect those changes. We ask >>>>>>>>>>>>>>> that you review the updates to ensure correctness. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Some additional updates we wanted to point out: >>>>>>>>>>>>>>> 1) For the date example in Section 3.6, we have added a >>>>>>>>>>>>>>> description containing the order of the characters and how they >>>>>>>>>>>>>>> should appear. This is due to the fact that the Hebrew date may >>>>>>>>>>>>>>> be displayed differently depending on different document >>>>>>>>>>>>>>> presentation environments. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> OK >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2) Pierluigi and Enrico noted the following on Feb 20th: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 4) As for the example at the end of sect. 3.6, there is a >>>>>>>>>>>>>>>> mismatch between the HTML format and PDF, as well as TXT, >>>>>>>>>>>>>>>> formats: >>>>>>>>>>>>>>>> • in HTML we have: 1999-09-02|ט״נשת לוּלאֱבֶּ א״כ >>>>>>>>>>>>>>>> • in PDF (at the top of pag. 17) the same dates appear as >>>>>>>>>>>>>>>> swapped >>>>>>>>>>>>>>>> • in TXT the same dates appear: >>>>>>>>>>>>>>>> • as in the HTML, if read via browser >>>>>>>>>>>>>>>> • as swapped, if read locally via some text editors (in few >>>>>>>>>>>>>>>> cases even aligned right) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Although most of these issues have been resolved due to the >>>>>>>>>>>>>>> corrected PDF output, we unfortunately do not have control over >>>>>>>>>>>>>>> the .txt output or right alignment in this case since the .txt >>>>>>>>>>>>>>> output can vary depending on which tool/browser is used. For >>>>>>>>>>>>>>> example, Safari and Google Chrome display the date correctly >>>>>>>>>>>>>>> (1999-09-02|כ״א-בֶּאֱלוּל-תשנ״ט) while Firefox displays the >>>>>>>>>>>>>>> date in reverse (the Hebrew string followed by 1999-09-02). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> OK >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> 3) We also wanted to point out that the date itself has been >>>>>>>>>>>>>>> updated as follows since the previous version was displayed >>>>>>>>>>>>>>> backwards upon further review. The RTL characters now appear in >>>>>>>>>>>>>>> the correct order. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>> ט״נשת לוּלאֱבֶּ א״כ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Current: >>>>>>>>>>>>>>> כ״א-בֶּאֱלוּל-תשנ״ט >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> OK >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> 4) We note that the ISO reference has been withdrawn and is no >>>>>>>>>>>>>>> longer available. There are two updated versions: ISO >>>>>>>>>>>>>>> 8601-1:2019 (https://www.iso.org/standard/70907.html) and ISO >>>>>>>>>>>>>>> 8601-2:2019 (https://www.iso.org/standard/70908.html >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ). Would you like to update to use one or the other? Or both? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Current: >>>>>>>>>>>>>>> [ISO.8601.1988] >>>>>>>>>>>>>>> ISO, "Data elements and interchange formats - Information >>>>>>>>>>>>>>> interchange - Representation of dates and times", >>>>>>>>>>>>>>> ISO 8601:1988, June 1988. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>>>> [ISO.8601-1.2019] >>>>>>>>>>>>>>> ISO, "Date and time - Representations for information >>>>>>>>>>>>>>> interchange", >>>>>>>>>>>>>>> ISO 8601-1:2019, February 2019. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [ISO.8601-2.2019] >>>>>>>>>>>>>>> ISO, "Data elements and interchange formats - Information >>>>>>>>>>>>>>> interchange - Representation of dates and times", >>>>>>>>>>>>>>> ISO 8601-2:2019, February 2019. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> We think that including both is the best choice. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> The files have been posted here (please refresh): >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9676.txt >>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9676.pdf >>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9676.html >>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9676.xml >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The relevant diff files have been posted here (please refresh): >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9676-diff.html >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> (comprehensive diff) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9676-rfcdiff.html >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> (side by side view) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9676-auth48diff.html >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> (all changes made in AUTH48) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9676-auth48rfcdiff.html >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> (side by side view of all AUTH48 changes) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9676-lastdiff.html >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> (most recent updates) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9676-lastrfcdiff.html >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> (side by side view of most recent updates) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> For the AUTH48 status of this document, please see: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9676 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thank you, >>>>>>>>>>>>>>> RFC Editor/mc >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Mar 31, 2025, at 3:56 PM, Madison Church >>>>>>>>>>>>>>> <mchu...@staff.rfc-editor.org> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Eliot and Enrico, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thank you both for your messages and apologies for the delayed >>>>>>>>>>>>>>> response on our end! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> At the moment, we are currently waiting for a tools update that >>>>>>>>>>>>>>> will fix the PDF output of the left-to-right and right-to-left >>>>>>>>>>>>>>> text in Section 3.6. The tools update that includes this fix is >>>>>>>>>>>>>>> planned for this week. Once the update is complete, we will >>>>>>>>>>>>>>> send updated files that incorporate Enrico’s requested updates >>>>>>>>>>>>>>> regarding spaces in the Hebrew date. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thank you for your patience! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Best, >>>>>>>>>>>>>>> RFC Editor/mc >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Mar 31, 2025, at 2:49 PM, ENRICO FRANCESCONI >>>>>>>>>>>>>>>> <enrico.francesc...@cnr.it> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Dear Eliot, >>>>>>>>>>>>>>>> the latest email of ours was on March 6th about spaces in >>>>>>>>>>>>>>>> Hebrew dates. In our opinion it was the last issue to fix. We >>>>>>>>>>>>>>>> are now waiting for feedback. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Best >>>>>>>>>>>>>>>> Enrico >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 31 Mar 2025, at 20:25, Independent Submissions Editor >>>>>>>>>>>>>>>>> (Eliot Lear) <rfc-...@rfc-editor.org> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Madison, Enrico, where are we? >>>>>>>>>>>>>>>>> Eliot >>>>>>>>>>>>>>>>> On 06.03.2025 06:12, ENRICO FRANCESCONI wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Dear Madison and Eliot, >>>>>>>>>>>>>>>>>> thanks for your feedback about dates and different >>>>>>>>>>>>>>>>>> conversion formats. >>>>>>>>>>>>>>>>>> In this respect, we noticed a potential issue in the fact >>>>>>>>>>>>>>>>>> that the Hebrew date is written using spaces. Now, the LEX >>>>>>>>>>>>>>>>>> specifications suggest to replace spaces with dots. On the >>>>>>>>>>>>>>>>>> other hand in the dates in ISO format the separator is a >>>>>>>>>>>>>>>>>> dash (“-”). >>>>>>>>>>>>>>>>>> This should apply for the Hebrew format too, as well as for >>>>>>>>>>>>>>>>>> its U+ and utf-8 versions. Therefore, we think that one of >>>>>>>>>>>>>>>>>> such characters (“-” or “.”) is to be included in the Hebrew >>>>>>>>>>>>>>>>>> format and converted in U+ and utf-8. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Our preference would be to use “-” for dates, anyway even >>>>>>>>>>>>>>>>>> the version with “.” can be ok. >>>>>>>>>>>>>>>>>> Therefore, the Hebrew example would become: >>>>>>>>>>>>>>>>>> ט״נשת-לוּלאֱב-א״כ (for us to be preferred) or >>>>>>>>>>>>>>>>>> ט״נשת.לוּלאֱב.א״כ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Sorry for this additional burden, anyway it seems that we >>>>>>>>>>>>>>>>>> are close to finalise the RFC! >>>>>>>>>>>>>>>>>> Best >>>>>>>>>>>>>>>>>> Pierluigi and Enrico >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 5 Mar 2025, at 10:23, Independent Submissions Editor >>>>>>>>>>>>>>>>>>> (Eliot Lear) <rfc-...@rfc-editor.org> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 20.02.2025 22:18, ENRICO FRANCESCONI wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Dear Madison and Eliot, >>>>>>>>>>>>>>>>>>>> we were preparing an answer to the previous message, when >>>>>>>>>>>>>>>>>>>> we received two new emails of yours. >>>>>>>>>>>>>>>>>>>> We report in the following our reply which partially >>>>>>>>>>>>>>>>>>>> addresses the issue on Hebrew characters you underline in >>>>>>>>>>>>>>>>>>>> your message. >>>>>>>>>>>>>>>>>>>> As for the alternatives you propose, we agree with Eliot >>>>>>>>>>>>>>>>>>>> that option 2), using the workaround described, is to be >>>>>>>>>>>>>>>>>>>> preferred. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Now, please, see the answer we had prepared: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Dear Madison and Eliot, >>>>>>>>>>>>>>>>>>>> we read again the whole document, and we found the >>>>>>>>>>>>>>>>>>>> following residual four issues: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>>> • We checked the conversion of the Hebrew characters and >>>>>>>>>>>>>>>>>>>> it seems to us that the U+ conversion reported in the RFC >>>>>>>>>>>>>>>>>>>> is not correct: >>>>>>>>>>>>>>>>>>>> ט״נשת לוּלאֱבֶּ א״כ in U+ should be: >>>>>>>>>>>>>>>>>>>> U+05D8U+05F4U+05E0U+05E9U+05EAU+0020U+05DCU+05D5U+05BCU+05DCU+05D0U+05B1U+05D1U+05B6U+05BCU+0020U+05D0U+05F4U+05DB >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> According to https://r12a.github.io/app-conversion/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> , your correction is correct. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Please double check and fix it in the draft >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>>> • As for the conversion of the same date into UTF-8, it >>>>>>>>>>>>>>>>>>>> seems that it is wrong as well, because it includes also >>>>>>>>>>>>>>>>>>>> the conversion of the U+ (%x55%x2b). >>>>>>>>>>>>>>>>>>>> The correct one should be: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> %xd7%x98%xd7%xb4%xd7%xa0%xd7%xa9%xd7%xaa%x20%xd7%x9c%xd7%x95%xd6%xbc%xd7%x9c%xd7%x90%xd6%xb1%xd7%x91%xd6%xb6%xd6%xbc%x20%xd7%x90%xd7%xb4%xd7%x9b >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Same web site, this seems correct, assuming the x is >>>>>>>>>>>>>>>>>>> appropriate. >>>>>>>>>>>>>>>>>>> Eliot >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Please double check as well, and fix it in the draft >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>>> 3) In general, and in the reported example in particular, >>>>>>>>>>>>>>>>>>>> if "data-loc" is used internally, the following value can >>>>>>>>>>>>>>>>>>>> be kept: ט״נשת לוּלאֱבֶּ א״כ , but if it is to be >>>>>>>>>>>>>>>>>>>> transmitted over the network, it is to be converted into >>>>>>>>>>>>>>>>>>>> UTF-8. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> The example at the end of section 3.6 should, therefore, >>>>>>>>>>>>>>>>>>>> be written as follows: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> "For example, 1999-09-02 will be written in ISO plus >>>>>>>>>>>>>>>>>>>> Hebrew format as: >>>>>>>>>>>>>>>>>>>> 1999-09-02|ט״נשת לוּלאֱבֶּ א״כ >>>>>>>>>>>>>>>>>>>> which, see Section 3.4, is to be converted in UTF-8 for >>>>>>>>>>>>>>>>>>>> network protocols and for resolution." >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 4) As for the example at the end of sect. 3.6, there is a >>>>>>>>>>>>>>>>>>>> mismatch between the HTML format and PDF, as well as TXT, >>>>>>>>>>>>>>>>>>>> formats: >>>>>>>>>>>>>>>>>>>> • in HTML we have: 1999-09-02|ט״נשת לוּלאֱבֶּ א״כ >>>>>>>>>>>>>>>>>>>> • in PDF (at the top of pag. 17) the same dates appear as >>>>>>>>>>>>>>>>>>>> swapped >>>>>>>>>>>>>>>>>>>> • in TXT the same dates appear: >>>>>>>>>>>>>>>>>>>> • as in the HTML, if read via browser >>>>>>>>>>>>>>>>>>>> • as swapped, if read locally via some text editors (in >>>>>>>>>>>>>>>>>>>> few cases even aligned right) >>>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Please let us know if you need more clarifications >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks for your attention! >>>>>>>>>>>>>>>>>>>> Best regards >>>>>>>>>>>>>>>>>>>> Pierluigi and Enrico >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On 20 Feb 2025, at 21:24, Independent Submissions Editor >>>>>>>>>>>>>>>>>>>>> (Eliot Lear) <rfc-...@rfc-editor.org> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Madison, >>>>>>>>>>>>>>>>>>>>> Here's my view: I think your suggestion directly below is >>>>>>>>>>>>>>>>>>>>> better than an indefinite hold on a document. I would >>>>>>>>>>>>>>>>>>>>> like the authors to weigh in. >>>>>>>>>>>>>>>>>>>>> Eliot >>>>>>>>>>>>>>>>>>>>> On 20.02.2025 21:21, Madison Church wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> If TI state is not favorable due to the unpredictable >>>>>>>>>>>>>>>>>>>>>> timeframe, another option for a workaround would be to >>>>>>>>>>>>>>>>>>>>>> describe the order of the characters in the date example >>>>>>>>>>>>>>>>>>>>>> and how they should appear (for a visual, see the Hebrew >>>>>>>>>>>>>>>>>>>>>> string that appears in Section A.3 of RFC 9290 [4]). >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> For example: >>>>>>>>>>>>>>>>>>>>>> "The following example uses right-to-left (RTL) script, >>>>>>>>>>>>>>>>>>>>>> which in the context of this specification may be >>>>>>>>>>>>>>>>>>>>>> rendered differently by different document presentation >>>>>>>>>>>>>>>>>>>>>> environments. The descriptive text may be more reliable >>>>>>>>>>>>>>>>>>>>>> to follow than the necessarily device- and >>>>>>>>>>>>>>>>>>>>>> application-specific rendering. For example, 1999-09-02 >>>>>>>>>>>>>>>>>>>>>> will be written in ISO plus Hebrew format: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 1999-09-02|ט״נשת לוּלאֱבֶּ א״כ >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> where in direction of reading, the sequence of >>>>>>>>>>>>>>>>>>>>>> characters is…" >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> As always, if there are any additional questions, please >>>>>>>>>>>>>>>>>>>>>> feel free to reach out. In the meantime, please let us >>>>>>>>>>>>>>>>>>>>>> know which option is preferred: 1) move forward with >>>>>>>>>>>>>>>>>>>>>> placing the document into TI state, or 2) use the >>>>>>>>>>>>>>>>>>>>>> proposed workaround above. If option 2 is preferred, we >>>>>>>>>>>>>>>>>>>>>> will make the update and send files along for the >>>>>>>>>>>>>>>>>>>>>> authors and Eliot to approve. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> [1] >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9676 >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> [2] >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/about/queue/flowchart/ >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> [3] >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> https://github.com/ietf-tools/xml2rfc/issues/1226 >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> [4] >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/rfc/rfc9290.html#appendix-A.3 >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thank you! >>>>>>>>>>>>>>>>>>>>>> RFC Editor/mc >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On Feb 15, 2025, at 5:25 AM, Independent Submissions >>>>>>>>>>>>>>>>>>>>>>> Editor (Eliot Lear) <rfc-...@rfc-editor.org> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Madison, authors, >>>>>>>>>>>>>>>>>>>>>>> Let's be clear on what is being requested at this stage: >>>>>>>>>>>>>>>>>>>>>>> • Authors should review all versions of the document >>>>>>>>>>>>>>>>>>>>>>> (text/html/pdf) for any issues, and promptly report >>>>>>>>>>>>>>>>>>>>>>> them. The exception is the one issue below regarding >>>>>>>>>>>>>>>>>>>>>>> Hebrew dates. >>>>>>>>>>>>>>>>>>>>>>> • The document will be held in TI state until such time >>>>>>>>>>>>>>>>>>>>>>> as the tools team can fix the formatting issue. >>>>>>>>>>>>>>>>>>>>>>> • Once that issue is resolved, the document will be >>>>>>>>>>>>>>>>>>>>>>> regenerated. >>>>>>>>>>>>>>>>>>>>>>> • After that, authors will signal their approval. >>>>>>>>>>>>>>>>>>>>>>> • After that I will perform my final review. >>>>>>>>>>>>>>>>>>>>>>> • After that the RFC Editor will publish the RFC. >>>>>>>>>>>>>>>>>>>>>>> I want to confirm that this is what is expected. Do we >>>>>>>>>>>>>>>>>>>>>>> have any estimate as to how long the document will >>>>>>>>>>>>>>>>>>>>>>> remain in TI state? I do not want this document >>>>>>>>>>>>>>>>>>>>>>> languishing longer than it already has. If it will take >>>>>>>>>>>>>>>>>>>>>>> an extended period to make correction (months), then we >>>>>>>>>>>>>>>>>>>>>>> should look at other alternatives. >>>>>>>>>>>>>>>>>>>>>>> Eliot >>>>>>>>>>>>>>>>>>>>>>> On 13.02.2025 17:21, Madison Church wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Hi Authors, >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Thank you for your patience as we work through this >>>>>>>>>>>>>>>>>>>>>>>> issue. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> We have updated the document as requested and >>>>>>>>>>>>>>>>>>>>>>>> incorporated the new U+ and UTF-8 notations for the >>>>>>>>>>>>>>>>>>>>>>>> Hebrew date. We ask that you verify the changes to >>>>>>>>>>>>>>>>>>>>>>>> ensure our updates are correct. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> After some further testing on our end, we are still >>>>>>>>>>>>>>>>>>>>>>>> unable to get the Hebrew date to align correctly in >>>>>>>>>>>>>>>>>>>>>>>> the text output. Moving forward, we believe the best >>>>>>>>>>>>>>>>>>>>>>>> solution is to 1) ensure that all changes in the >>>>>>>>>>>>>>>>>>>>>>>> document are approved by each party, and 2) place this >>>>>>>>>>>>>>>>>>>>>>>> document into Tools Improvement (TI) state once AUTH48 >>>>>>>>>>>>>>>>>>>>>>>> is complete. As of right now, the formatting of the >>>>>>>>>>>>>>>>>>>>>>>> Hebrew date is the only outstanding issue. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Please review the document carefully to ensure >>>>>>>>>>>>>>>>>>>>>>>> satisfaction as we do not make changes once it has >>>>>>>>>>>>>>>>>>>>>>>> been published as an RFC. Contact us with any further >>>>>>>>>>>>>>>>>>>>>>>> updates or with your approval of the document in its >>>>>>>>>>>>>>>>>>>>>>>> current form. We will await approvals from each party >>>>>>>>>>>>>>>>>>>>>>>> prior to moving forward resolving this issue in the >>>>>>>>>>>>>>>>>>>>>>>> publication process. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> The updated files have been posted here (please >>>>>>>>>>>>>>>>>>>>>>>> refresh): >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9676.txt >>>>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9676.pdf >>>>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9676.html >>>>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9676.xml >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> The updated diff files have been posted here: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9676-diff.html >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> (comprehensive diff) >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9676-rfcdiff.html >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> (side by side) >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9676-auth48diff.html >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> (AUTH48 changes only) >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9676-auth48rfcdiff.html >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> (side by side) >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> The AUTH48 status page can be found here: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9676 >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> To track the issue in GitHub, please see: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> https://github.com/ietf-tools/xml2rfc/issues/1224 >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Thank you, >>>>>>>>>>>>>>>>>>>>>>>> RFC Editor/mc >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> On Feb 7, 2025, at 6:38 AM, ENRICO FRANCESCONI >>>>>>>>>>>>>>>>>>>>>>>>> <enrico.francesc...@cnr.it> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> P {margin-top:0;margin-bottom:0;} Dear Madison, Dear >>>>>>>>>>>>>>>>>>>>>>>>> Eliot, >>>>>>>>>>>>>>>>>>>>>>>>> thanks for your suggestions. As for the conversion >>>>>>>>>>>>>>>>>>>>>>>>> Latin --> Hebrew of the example date, we have >>>>>>>>>>>>>>>>>>>>>>>>> probably used a wrong converter, so we agree to use >>>>>>>>>>>>>>>>>>>>>>>>> the conversion you suggest. >>>>>>>>>>>>>>>>>>>>>>>>> As for the rest, please find in-line our replies. >>>>>>>>>>>>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Pierluigi and Enrico >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> From: Madison Church >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> <mchu...@staff.rfc-editor.org> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Sent: 05 February 2025 18:28 >>>>>>>>>>>>>>>>>>>>>>>>> To: Independent Submissions Editor (Eliot Lear) >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> <rfc-...@rfc-editor.org>; ENRICO FRANCESCONI >>>>>>>>>>>>>>>>>>>>>>>>> <enrico.francesc...@cnr.it>; >>>>>>>>>>>>>>>>>>>>>>>>> pierluigi.spin...@gmail.com >>>>>>>>>>>>>>>>>>>>>>>>> <pierluigi.spin...@gmail.com>; >>>>>>>>>>>>>>>>>>>>>>>>> caterina.l...@gmail.com <caterina.l...@gmail.com> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Cc: RFC Editor >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> <rfc-edi...@rfc-editor.org>; superu...@gmail.com >>>>>>>>>>>>>>>>>>>>>>>>> <superu...@gmail.com>; auth48archive@rfc-editor.org >>>>>>>>>>>>>>>>>>>>>>>>> <auth48archive@rfc-editor.org> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9676 >>>>>>>>>>>>>>>>>>>>>>>>> <draft-spinosa-urn-lex-24> for your review >>>>>>>>>>>>>>>>>>>>>>>>> Hi Authors and Eliot, >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Thank you for your replies! >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Authors - To confirm, you are suggesting that the >>>>>>>>>>>>>>>>>>>>>>>>> example be shown as the following (Removing the U+ >>>>>>>>>>>>>>>>>>>>>>>>> notation and keeping the Hebrew format): >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> (e.g., "September 2, 99" will be written in ISO plus >>>>>>>>>>>>>>>>>>>>>>>>> Hebrew format as >>>>>>>>>>>>>>>>>>>>>>>>> "1999-09-02|אלול,תשנ"ט.21"). >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Fine to remove the U+ format and keep the Hebrew >>>>>>>>>>>>>>>>>>>>>>>>> format as in the example above (end of Section 3.6). >>>>>>>>>>>>>>>>>>>>>>>>> Obviously, the right conversion into Hebrew >>>>>>>>>>>>>>>>>>>>>>>>> characters (you suggest here below) is to be used. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Please consider that in Section 3.6, all the >>>>>>>>>>>>>>>>>>>>>>>>> occurrences of the example Hebrew date, in Hebrew, U+ >>>>>>>>>>>>>>>>>>>>>>>>> and UTF-8 notations, have to be updated accordingly, >>>>>>>>>>>>>>>>>>>>>>>>> so that they are all aligned with the new conversion >>>>>>>>>>>>>>>>>>>>>>>>> you suggest. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Please note that this calendar converter [1] >>>>>>>>>>>>>>>>>>>>>>>>> translates 1999-09-02 to כ״א בֶּאֱלוּל תשנ״ט, and it >>>>>>>>>>>>>>>>>>>>>>>>> does not use Arabic numerals nor punctuation in the >>>>>>>>>>>>>>>>>>>>>>>>> translation. Please confirm the use of Arabic >>>>>>>>>>>>>>>>>>>>>>>>> numerals and punctuation for the date-loc format. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> [1] >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> https://www.hebcal.com/converter?gd=2&gm=9&gy=1999&g2h=1 >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Thank you, >>>>>>>>>>>>>>>>>>>>>>>>> RFC Editor/mc >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Feb 2, 2025, at 1:38 PM, Independent Submissions >>>>>>>>>>>>>>>>>>>>>>>>>> Editor (Eliot Lear) <rfc-...@rfc-editor.org> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> My view: >>>>>>>>>>>>>>>>>>>>>>>>>> On 02.02.2025 19:52, ENRICO FRANCESCONI wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> 1) to remove "date-loc" and keep only the ISO >>>>>>>>>>>>>>>>>>>>>>>>>>> version of any date >>>>>>>>>>>>>>>>>>>>>>>>>>> 2) to keep "date-loc" including, as example, a >>>>>>>>>>>>>>>>>>>>>>>>>>> Hebrew date transformed into ISO latin characters >>>>>>>>>>>>>>>>>>>>>>>>>>> (ex: 21.Elul,5759) >>>>>>>>>>>>>>>>>>>>>>>>>>> 3) to keep "date-loc" including just the Unicode U+ >>>>>>>>>>>>>>>>>>>>>>>>>>> version, without using Hebrew characters >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Please let us know what do you prefer and we >>>>>>>>>>>>>>>>>>>>>>>>>>> proceed with the update of the document >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I don't like any of these options because none of >>>>>>>>>>>>>>>>>>>>>>>>>> them provide an example that people going left to >>>>>>>>>>>>>>>>>>>>>>>>>> right would actually use. I am also concerned about >>>>>>>>>>>>>>>>>>>>>>>>>> Chinese, fwiw. >>>>>>>>>>>>>>>>>>>>>>>>>> Eliot >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> <image.png> <image.png> <image.png> <image.png> >>>>>>>>>>>>>>>>>>>>>>>>> <image.png> Enrico Francesconi >>>>>>>>>>>>>>>>>>>>>>>>> CNR, INSTITUTE OF LEGAL INFORMATICS AND JUDICIAL >>>>>>>>>>>>>>>>>>>>>>>>> SYSTEMS >>>>>>>>>>>>>>>>>>>>>>>>> Research Director >>>>>>>>>>>>>>>>>>>>>>>>> Tel. +390554399611 >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> enrico.francesc...@cnr.it >>>>>>>>>>>>>>>>>>>>>>>>> enrico.francesc...@igsg.cnr.it >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> via de' Barucci, 20, 50127 – Florence (Italy) >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> www.cnr.it >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Devolvi il 5×1000 al CNR >>>>>>>>>>>>>>>>>>>>>>>>> CF 80054330586 >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> ing. Pierluigi Spinosa >>>>>>>>>> Via Zanardelli, 15 >>>>>>>>>> 50136 - Firenze >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
