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
