Hi Pierluigi and Enrico, Thank you for your reply and apologies for any confusion on our end!
For the following: > In order to avoid any additional misunderstanding, we kindly ask you to > confirm that if we have to update > https://www.rfc-editor.org/authors/rfc9676.xml by amending it with the > changes already reported in the xml we sent you. That is correct! Additionally, if you have any comments regarding a certain change (for example, if you disagree with a proposed update and wish to provide corrected text of your own), please feel free to let us know by either 1) responding directly to the question in the XML in the form of a comment, or 2) let us know via email using the following format: Section # (or indicate Global) OLD: old text NEW: new text Please let us know if you have any additional questions or comments. We will prioritize moving this document forward once we hear back from you. We appreciate your efforts to move this document forward! RFC Editor/mc > On Jan 11, 2025, at 4:34 AM, ENRICO FRANCESCONI <enrico.francesc...@cnr.it> > wrote: > > Dear Madison, Eliot, > thanks for your remarks, it is actually our interest to have the document > finalised and sorry for this additional trouble. > > As for the previous submission, the instructions email reported what follows: > > > You may submit your changes in one of two ways: > > > > An update to the provided XML file > > — OR — > > An explicit list of changes in this format > > > > Section # (or indicate Global) > > > > OLD: > > old text > > > > NEW: > > new text > > > > We have actually chosen the first option "An update to the provided XML > file”. We have erroneusly started from our markdown format and we have > produced the XML, then we reported all the changes in it. > The source of misunderstanding was the fact that we have used our version to > include changes, instead of https://www.rfc-editor.org/authors/rfc9676.xml , > very sorry for that. > In order to avoid any additional misunderstanding, we kindly ask you to > confirm that if we have to update > https://www.rfc-editor.org/authors/rfc9676.xml by amending it with the > changes already reported in the xml we sent you. > > An example is the following: > > <title abbrev="URN LEX Namespace for Sources of Law">A Uniform Resource Name > (URN) Namespace for Sources of Law (LEX)</title> > <seriesInfo name="RFC" value="9676”/> > > According to your comments it must become: > > <title abbrev="LEX: URN Namespace for Sources of Law">LEX: A Uniform Resource > Name (URN) Namespace for Sources of Law</title> > <seriesInfo name="RFC" value="9676"/> > > > Thanks a lot, and again sorry for such a trouble. We will move on as soon as > possible. > Best > Pierluigi and Enrico > > > From: Independent Submissions Editor (Eliot Lear) <rfc-...@rfc-editor.org> > Sent: 11 January 2025 08:30 > To: Madison Church <mchu...@staff.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 > Enrico, Pierluigi, > I would like to see this document finished, but you must understand that > there are many documents in the RFC editor queue. Please follow Madison's > instructions and complete your work. I am not willing to have them go > through many more revisions with you. > Eliot > On 10.01.2025 17:21, Madison Church wrote: > Hi Authors, > > [Please note that this email is coming to you from a new email address on our > end.] > > Thank you for your patience and apologies for the delay in response! > > Regarding the updated file you sent, we were unable to merge these changes > because this file was missing updates that were made during the editorial > process. Please incorporate the updates into the current XML file that > contains our editorial updates > (https://www.rfc-editor.org/authors/rfc9676.xml). > > If you have any questions, please feel free to let us know. > > Thank you! > RFC Editor/mc > > > On Jan 2, 2025, at 2:18 PM, Madison Church <mchu...@amsl.com> wrote: > > Hi Pierluigi and Enrico, > > Thank you for your reply! We wanted to let you know that we have received the > updated XML file and will send updated files back to you for review in the > next few days. > > We hope you had a wonderful holiday season! > > Thank you, > RFC Editor/mc > > > On Dec 24, 2024, at 4:30 AM, ENRICO FRANCESCONI <enrico.francesc...@cnr.it> > wrote: > > Dear Madison, Eliot and All, > as required, we have fixed all the issues highlighted in your most recent > review, including the address of the jurisdiction-codes register (it will be > "lex-urn.nic.it"). We have worked directly on the XML format, considering > that it's your source for RFC publication; please find it in attachment. > > Please let us know if you have any additional remarks, > meanwhile we wish you a very Merry Christmas and Happy New Year! > > Best regards > Pierluigi and Enrico > > > > From: Madison Church <mchu...@amsl.com> > Sent: 16 December 2024 16:22 > To: ENRICO FRANCESCONI <enrico.francesc...@cnr.it>; > pierluigi.spin...@gmail.com<pierluigi.spin...@gmail.com>; > caterina.l...@gmail.com <caterina.l...@gmail.com> > Cc: Independent Submissions Editor (Eliot Lear) <rfc-...@rfc-editor.org>; 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 > Pierluigi and Enrico, > > Thank you for your review. If we understand correctly, you are updating your > markdown source file to match the RPC-edited file. You mentioned "can submit > the new, and hopefully final, version" - we are unsure what is meant by > "final version". Please note that while you may use markdown to create the > Internet-Draft, the RPC uses XML as the source for RFC publication. Also, > note that you do not need to submit a new version to the Datatracker. To > update your document, please do one of the following: > > • share your updated markdown once the updates are complete, > • if you are updating the markdown in a GitHub repo, please point us to the > repo, or > • provide your updates via mail. > > We have left some notes below in this thread. Please let us know if any > further clarification is needed or if you have any questions! > > > On Dec 16, 2024, at 5:58 AM, Independent Submissions Editor (Eliot Lear) > <rfc-...@rfc-editor.org> wrote: > > Please do not upload a new version. We are done with drafts at this stage. > Now there is a draft RFC from which further work must proceed. Instead, > please respond directly to the RFC Editor's questions, either in the > positive, in the negative, or with an alternate propose of the form: > > Section #: > > OLD: > {old text} > > NEW: > {new text} > > Thanks very much, > > Eliot > > On 16.12.2024 12:46, ENRICO FRANCESCONI wrote: > > Dear Eliot, > thanks for your feedback. Below in-line our remarks. If all is good, we will > upload the next version (25), where all the remaining issues are fixed. > > Thanks! > Pierluigi and Enrico > > From: Independent Submissions Editor (Eliot Lear) <rfc-...@rfc-editor.org> > Sent: 12 December 2024 09:38 > To: ENRICO FRANCESCONI <enrico.francesc...@cnr.it>; rfc-edi...@rfc-editor.org > <rfc-edi...@rfc-editor.org>; > pierluigi.spin...@gmail.com<pierluigi.spin...@gmail.com>; > caterina.l...@gmail.com <caterina.l...@gmail.com> > Cc: 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 Enrico, > > Please see below. > > On 10.12.2024 20:19, ENRICO FRANCESCONI wrote:Dear Colleagues, > thanks a lot for your extensive review of the URN:LEX draft and sorry for our > delay. > We have reported in a new draft all your remarks accepting your proposals, > except the ones still in doubts. Please find them, in-line, here below. Once > clarified these last doubts, we can submit the new, and hopefully final, > version. > > Thanks for your collaboration! > best > Pierluigi and Enrico > > > 15) <!-- [rfced] We have a few questions about the text below. > > Original: > 2.2. Jurisdiction-code Register > > A new jurisdiction-code registry has been created. Each entry > contains the following elements: > > a) Should the title read "Jurisdiction-Code Registry" ("Registry" rather than > "Register")? > > No, it is actually a database, not the office managing such a database > > The RFC Editor will correct me if I am wrong, but registry in this case > refers to a place, like a web site, in which records are stored, not so much > the office. > > Actually, in our view, it is both the things: an archive of the jurisdiction > codes and a website in which jurisdiction code records can be queried. > Anyway, let's wait for RFC Editors feedback > > [rfced] Eliot is correct - we are not referring to an office, but "refers to > a place, like a web site, in which records are stored." > > > c) Would it be helpful to include a citation or URL so readers can access the > new jurisdiction-code registry? > --> > > We said already that it did not exist yet and we would create it when the rfc > would be approved. The reviewers accepted that… > See also next period at section 2.2 (end of [page 10]): “The table is > initially empty.” > > For intents and purposes, we are at that point. There is value in providing > the URL, so my suggestion would be to do that, to get the initial link up and > running, and then issue the RFC. That way, people won't have to go hunting > around for a link on the web. Better to be authoritative now if we can be. > HOWEVER, any link listed should indicate that it might change (assuming it > might change ;-). > > We have just asked our colleagues at IIT-CNR (dealing with URN:LEX technical > infrastructure) to provide such URL and related page > about jurisdiction-code register > > 17) <!-- [rfced] Would including either a URL or a citation with a > corresponding > reference entry for "CNR website dedicated to the LEX governance" be > helpful to readers here? If so, please provide the necessary information. > > Original: > A new Jurisdictional Registrar will contact CNR or the Designated > Expert(s) according to the established rules of governance (published > in the CNR website dedicated to the LEX governance). > --> > > Currently such website is not available. As soon as the draft will be > approved we will contact experts and create the Designated Expert(s) board > > > Same as above. Even if the link indicates "under construction, contact > so-and-so for more information", that would be better than nothing. > > OK > > [rfced] Regarding questions 15c and 17, please let us know when the URLs for > the registries are available and we will update the document accordingly. > > > 40) <!-- [rfced] Please review each instance of U+ notation and let us know if > you would like to replace with the character itself. > > The <u> element (which can be used to provide the U+ notation) is only > required for cases where the non-ASCII characters are needed for correct > protocol operation. > > For more information, please see: > https://authors.ietf.org/en/non-ascii-characters-in-rfcxml > https://www.rfc-editor.org/styleguide/part2/#nonascii > > For examples from published RFCs, please see (search for "non-ASCII"): > https://www.rfc-editor.org/rpc/wiki/doku.php?id=v3_feature_usage > > Some examples from this document: > > Example 1 (from Section 3.4): > > Original: > (e.g., > the Italian term "sanitU+00E0" replaced into "sanita", the French > term "ministU+00E8re" replaced into "ministere"), in case by > transliteration (e.g. "MU+00FCnchen" replaced into "muenchen”). > > Perhaps: > For example, > the Italian term "sanità” is replaced by "sanita", the French > term "ministère” is replaced by "ministere”, and > "München” is replaced by “muenchen” (transliteration). > > > Example 2 (from Section 3.4): > > Original: > - unicode = urn:lex:de:stadt.mU+00FCnchen:rundschreiben: ... > > Perhaps no changes are needed when the U+ notation appears in a "urn:lex" > string like this. > --> > > The problem here is that non-ASCII characters are not accepted in the txt > version (derived from mkd which is our source file) > > That is not entirely the case. You CAN have certain non-ASCII characters in > text that doesn't impact the protocol operation. So the RFC Editor's change > in example 1 is acceptable (and they ought to know!). > > OK, we have done so. > In updating the document we have followed the indications of the latest draft > regarding non-ASCII characters, > i.e.https://datatracker.ietf.org/doc/html/draft-rswg-rfc7997bis-03, which, > although not yet approved, brings some non-substantial changes to RFC7997. > Basically, we have operated as follows: > words with the non-ASCII characters are inserted directly into the document, > followed in brackets by the same words with the non-ASCII characters indicated > in the form U+nnnn (a modality already provided for by RFC7997). > Example: > > OLD: > ...the Italian term sanitU+00E0 replaced... > > NEW: > ...the Italian term "sanità" (sanitU+00E0) replaced… > > [rfced] For clarification, the non-ASCII characters can be included and > displayed correctly in the text output. Please let us know if any further > updates are needed. See > <https://authors.ietf.org/non-ascii-characters-in-rfcxml> for more details. > > > 41) <!-- [rfced] Sourcecode > > a) We updated <artwork> to <sourcecode type="abnf"> in Section 8. We also > updated the ABNF snippets throughout the document from <artwork> to > <sourcecode type="abnf">. Please review. > > > b) In Section 2.1, we changed the following from <artwork> to > <sourcecode>. Please confirm that this is correct. If so, should the "type" > attribute be set? > > Original: > "urn:lex:" NSS > > Note: The current list of preferred values for "type" is available here: > https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types. If this list > does not contain an applicable type, then feel free to let us know. Also, it > is acceptable to leave the "type" attribute not set. > > > c) In Section 5.8, we changed the following from <artwork> to > <sourcecode>. We set the type to "abnf", but please confirm this is > correct. We do not see this in Section 8. > > Original: > URN-reference = URN-document ["~" partition-id] > ... > --> > > We couldn't find how to include<sourcecode type="abnf"> in the mkd document, > which is our source file.In this case "sourcecode" is a tag not necessarily > pointing to the location of the source. > > We had used ~~~~~ (converted to <artwork> in the xml version) only to > highlight more some parts of the text, and in particular: ABNF formulas, > examples, list of reserved characters. > The solution we have conceived is the following: > - converted ~~~~~ (<artwork> in xml) into ``` (<tt> in xml) in all the ABNF > formula, where actually we deal with codes, highlighted in the text; > - kept ~~~~~ (<artwork> in xml) in all the examples and in the list of the > reserved characters, which are not actual codes but are to be highlighed in > the text. > In our opinion, it’s not appropriate to change them as unnumbered lists > (<ul>), because it makes us lose the text highlighting. > > [rfced] We are unsure whether the markdown you are using supports sourcecode > types, but it can be set in the XML file. > The XML file is available here: https://www.rfc-editor.org/authors/rfc9676.xml > > You can view what has been tagged as <artwork> and <sourcecode> by searching > for those terms in the file. We are asking you to a) review whether the tags > have been set correctly or if updates are needed, and b) indicate whether > "type" should be set for any <sourcecode>. See > <https://authors.ietf.org/rfcxml-vocabulary#sourcecode> for more information; > information about "type" is available from the Attributes tab. > > Thank you, > RFC Editor/mc<draft-spinosa-urn-lex-25b.xml> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
