Hi Authors, Thank you for your reply and apologies for the delayed response. We have updated the files as you have requested on our end, but we are still testing out a few potential solutions and workarounds. We hope to send updated files shortly.
In the meantime, for the following: >> • 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 >> >> Please double check as well, and fix it in the draft Thank you for providing the updates! We have reviewed the updated U+ notation (which appears to be correct). However, we are having trouble verifying the UTF-8 encoding. Is there a tool that we could be pointed to in order to double check that it is correct? We appreciate your patience as we work through these issues. As always, please feel free to reach out with any questions! Thank you, RFC Editor/mc >> 3) In general, and in the reported example in particular, if "data-loc" >> is used internally, the following value can be kept: ט״נשת לוּלאֱבֶּ א״כ , >> but if it is to be transmitted over the network, it is to be converted into >> UTF-8. >> >> The example at the end of section 3.6 should, therefore, be written as >> follows: >> >> "For example, 1999-09-02 will be written in ISO plus Hebrew format as: >> 1999-09-02|ט״נשת לוּלאֱבֶּ א״כ >> which, see Section 3.4, is to be converted in UTF-8 for network protocols >> and for resolution." >> >> --- >> >> 4) As for the example at the end of sect. 3.6, there is a mismatch >> between the HTML format and PDF, as well as TXT, formats: >> • in HTML we have: 1999-09-02|ט״נשת לוּלאֱבֶּ א״כ >> • in PDF (at the top of pag. 17) the same dates appear as swapped >> • in TXT the same dates appear: >> • as in the HTML, if read via browser >> • as swapped, if read locally via some text editors (in few cases >> even aligned right) >> --- >> >> Please let us know if you need more clarifications >> >> Thanks for your attention! >> Best regards >> Pierluigi and Enrico >> >> >> >>> On 20 Feb 2025, at 21:24, Independent Submissions Editor (Eliot Lear) >>> <rfc-...@rfc-editor.org> wrote: >>> >>> Madison, >>> Here's my view: I think your suggestion directly below is better than an >>> indefinite hold on a document. I would like the authors to weigh in. >>> Eliot >>> On 20.02.2025 21:21, Madison Church wrote: >>>> >>>> If TI state is not favorable due to the unpredictable timeframe, another >>>> option for a workaround would be to describe the order of the characters >>>> in the date example and how they should appear (for a visual, see the >>>> Hebrew string that appears in Section A.3 of RFC 9290 [4]). >>>> >>>> For example: >>>> "The following example uses right-to-left (RTL) script, which in the >>>> context of this specification may be rendered differently by different >>>> document presentation environments. The descriptive text may be more >>>> reliable to follow than the necessarily device- and application-specific >>>> rendering. For example, 1999-09-02 will be written in ISO plus Hebrew >>>> format: >>>> >>>> 1999-09-02|ט״נשת לוּלאֱבֶּ א״כ >>>> >>>> where in direction of reading, the sequence of characters is…" >>>> >>>> >>>> As always, if there are any additional questions, please feel free to >>>> reach out. In the meantime, please let us know which option is preferred: >>>> 1) move forward with placing the document into TI state, or 2) use the >>>> proposed workaround above. If option 2 is preferred, we will make the >>>> update and send files along for the authors and Eliot to approve. >>>> >>>> [1] https://www.rfc-editor.org/auth48/rfc9676 >>>> [2] https://www.rfc-editor.org/about/queue/flowchart/ >>>> [3] https://github.com/ietf-tools/xml2rfc/issues/1226 >>>> [4] https://www.rfc-editor.org/rfc/rfc9290.html#appendix-A.3 >>>> >>>> Thank you! >>>> RFC Editor/mc >>>> >>>> >>>>> On Feb 15, 2025, at 5:25 AM, Independent Submissions Editor (Eliot Lear) >>>>> <rfc-...@rfc-editor.org> wrote: >>>>> >>>>> Madison, authors, >>>>> Let's be clear on what is being requested at this stage: >>>>> • Authors should review all versions of the document (text/html/pdf) for >>>>> any issues, and promptly report them. The exception is the one issue >>>>> below regarding Hebrew dates. >>>>> • The document will be held in TI state until such time as the tools team >>>>> can fix the formatting issue. >>>>> • Once that issue is resolved, the document will be regenerated. >>>>> • After that, authors will signal their approval. >>>>> • After that I will perform my final review. >>>>> • After that the RFC Editor will publish the RFC. >>>>> I want to confirm that this is what is expected. Do we have any estimate >>>>> as to how long the document will remain in TI state? I do not want this >>>>> document languishing longer than it already has. If it will take an >>>>> extended period to make correction (months), then we should look at other >>>>> alternatives. >>>>> Eliot >>>>> On 13.02.2025 17:21, Madison Church wrote: >>>>> >>>>>> Hi Authors, >>>>>> >>>>>> Thank you for your patience as we work through this issue. >>>>>> >>>>>> We have updated the document as requested and incorporated the new U+ >>>>>> and UTF-8 notations for the Hebrew date. We ask that you verify the >>>>>> changes to ensure our updates are correct. >>>>>> >>>>>> After some further testing on our end, we are still unable to get the >>>>>> Hebrew date to align correctly in the text output. Moving forward, we >>>>>> believe the best solution is to 1) ensure that all changes in the >>>>>> document are approved by each party, and 2) place this document into >>>>>> Tools Improvement (TI) state once AUTH48 is complete. As of right now, >>>>>> the formatting of the Hebrew date is the only outstanding issue. >>>>>> >>>>>> Please review the document carefully to ensure satisfaction as we do not >>>>>> make changes once it has been published as an RFC. Contact us with any >>>>>> further updates or with your approval of the document in its current >>>>>> form. We will await approvals from each party prior to moving forward >>>>>> resolving this issue in the publication process. >>>>>> >>>>>> The updated files have been posted here (please refresh): >>>>>> https://www.rfc-editor.org/authors/rfc9676.txt >>>>>> https://www.rfc-editor.org/authors/rfc9676.pdf >>>>>> https://www.rfc-editor.org/authors/rfc9676.html >>>>>> https://www.rfc-editor.org/authors/rfc9676.xml >>>>>> >>>>>> The updated diff files have been posted here: >>>>>> https://www.rfc-editor.org/authors/rfc9676-diff.html (comprehensive diff) >>>>>> https://www.rfc-editor.org/authors/rfc9676-rfcdiff.html (side by side) >>>>>> https://www.rfc-editor.org/authors/rfc9676-auth48diff.html (AUTH48 >>>>>> changes only) >>>>>> https://www.rfc-editor.org/authors/rfc9676-auth48rfcdiff.html (side by >>>>>> side) >>>>>> >>>>>> The AUTH48 status page can be found here: >>>>>> https://www.rfc-editor.org/auth48/rfc9676 >>>>>> >>>>>> To track the issue in GitHub, please see: >>>>>> https://github.com/ietf-tools/xml2rfc/issues/1224 >>>>>> >>>>>> Thank you, >>>>>> RFC Editor/mc >>>>>> >>>>>> >>>>>> >>>>>>> On Feb 7, 2025, at 6:38 AM, ENRICO FRANCESCONI >>>>>>> <enrico.francesc...@cnr.it> wrote: >>>>>>> >>>>>>> P {margin-top:0;margin-bottom:0;} Dear Madison, Dear Eliot, >>>>>>> thanks for your suggestions. As for the conversion Latin --> Hebrew of >>>>>>> the example date, we have probably used a wrong converter, so we agree >>>>>>> to use the conversion you suggest. >>>>>>> As for the rest, please find in-line our replies. >>>>>>> Thanks! >>>>>>> >>>>>>> Pierluigi and Enrico >>>>>>> >>>>>>> >>>>>>> From: Madison Church <mchu...@staff.rfc-editor.org> >>>>>>> Sent: 05 February 2025 18:28 >>>>>>> To: Independent Submissions Editor (Eliot Lear) >>>>>>> <rfc-...@rfc-editor.org>; ENRICO FRANCESCONI >>>>>>> <enrico.francesc...@cnr.it>; pierluigi.spin...@gmail.com >>>>>>> <pierluigi.spin...@gmail.com>; caterina.l...@gmail.com >>>>>>> <caterina.l...@gmail.com> >>>>>>> Cc: RFC Editor <rfc-edi...@rfc-editor.org>; superu...@gmail.com >>>>>>> <superu...@gmail.com>; auth48archive@rfc-editor.org >>>>>>> <auth48archive@rfc-editor.org> >>>>>>> Subject: Re: AUTH48: RFC-to-be 9676 <draft-spinosa-urn-lex-24> for your >>>>>>> review >>>>>>> Hi Authors and Eliot, >>>>>>> >>>>>>> Thank you for your replies! >>>>>>> >>>>>>> Authors - To confirm, you are suggesting that the example be shown as >>>>>>> the following (Removing the U+ notation and keeping the Hebrew format): >>>>>>> >>>>>>> (e.g., "September 2, 99" will be written in ISO plus Hebrew format as >>>>>>> "1999-09-02|אלול,תשנ"ט.21"). >>>>>>> >>>>>>> Fine to remove the U+ format and keep the Hebrew format as in the >>>>>>> example above (end of Section 3.6). >>>>>>> Obviously, the right conversion into Hebrew characters (you suggest >>>>>>> here below) is to be used. >>>>>>> >>>>>>> Please consider that in Section 3.6, all the occurrences of the example >>>>>>> Hebrew date, in Hebrew, U+ and UTF-8 notations, have to be updated >>>>>>> accordingly, so that they are all aligned with the new conversion you >>>>>>> suggest. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Please note that this calendar converter [1] translates 1999-09-02 to >>>>>>> כ״א בֶּאֱלוּל תשנ״ט, and it does not use Arabic numerals nor >>>>>>> punctuation in the translation. Please confirm the use of Arabic >>>>>>> numerals and punctuation for the date-loc format. >>>>>>> >>>>>>> [1] https://www.hebcal.com/converter?gd=2&gm=9&gy=1999&g2h=1 >>>>>>> >>>>>>> Thank you, >>>>>>> RFC Editor/mc >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Feb 2, 2025, at 1:38 PM, Independent Submissions Editor (Eliot >>>>>>>> Lear) <rfc-...@rfc-editor.org> wrote: >>>>>>>> >>>>>>>> My view: >>>>>>>> On 02.02.2025 19:52, ENRICO FRANCESCONI wrote: >>>>>>>> >>>>>>>> >>>>>>>>> 1) to remove "date-loc" and keep only the ISO version of any date >>>>>>>>> 2) to keep "date-loc" including, as example, a Hebrew date >>>>>>>>> transformed into ISO latin characters (ex: 21.Elul,5759) >>>>>>>>> 3) to keep "date-loc" including just the Unicode U+ version, without >>>>>>>>> using Hebrew characters >>>>>>>>> >>>>>>>>> Please let us know what do you prefer and we proceed with the update >>>>>>>>> of the document >>>>>>>>> >>>>>>>>> >>>>>>>> I don't like any of these options because none of them provide an >>>>>>>> example that people going left to right would actually use. I am also >>>>>>>> concerned about Chinese, fwiw. >>>>>>>> Eliot >>>>>>>> >>>>>>>> >>>>>>> <image.png> <image.png> <image.png> <image.png> <image.png> Enrico >>>>>>> Francesconi >>>>>>> CNR, INSTITUTE OF LEGAL INFORMATICS AND JUDICIAL SYSTEMS >>>>>>> Research Director >>>>>>> Tel. +390554399611 >>>>>>> enrico.francesc...@cnr.it >>>>>>> enrico.francesc...@igsg.cnr.it >>>>>>> via de' Barucci, 20, 50127 – Florence (Italy) >>>>>>> www.cnr.it >>>>>>> Devolvi il 5×1000 al CNR >>>>>>> CF 80054330586 >>>>>>> >>>>>>> >>>>>> >>>> >> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
