Carsten is obviously right. I had missed the parenthetical in § 3.8.3.1. of RFC8610:
> […] (Note that this also means that there is one level of > string escaping before the XSD escaping rules are applied.) Thanks for spotting it! Cheers, t On 06/02/2023, 23:46, "Carsten Bormann" <c...@tzi.org> wrote: This is hilarious — the errata reporting form apparently ate my double backslashes. Here is the corrected Corrected Text: oid = text .regexp "([0-2])((\\.0)|(\\.[1-9][0-9]*))*” And here is how I would write this, having been bitten by backslashes in RFCs before: oid = text .regexp "([0-2])(([.]0)|([.][1-9][0-9]*))*” (Actually, I would write this: oid = text .regexp "[0-2]([.](0|([1-9][0-9]*)))*” …but this is a style issue.) Grüße, Carsten > On 2023-02-07, at 00:35, RFC Errata System <rfc-edi...@rfc-editor.org> wrote: > > The following errata report has been submitted for RFC9115, > "An Automatic Certificate Management Environment (ACME) Profile for > Generating Delegated Certificates". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid7336 > > -------------------------------------- > Type: Technical > Reported by: Carsten Bormann <c...@tzi.org> > > Section: Appendix A > > Original Text > ------------- > oid = text .regexp "([0-2])((\.0)|(\.[1-9][0-9]*))*" > > > Corrected Text > -------------- > oid = text .regexp "([0-2])((\.0)|(\.[1-9][0-9]*))*" > > > Notes > ----- > Backslashes need to be doubled in CDDL strings (as they are done in Appendix > B). > > An alternative fix would be to replace \. by [.] > > Note that the equivalent fix is not required for > > regtext = text .regexp "([^\*].*)|([\*][^\*].*)|([\*][\*].+)" > > as the fact that the single backslashes have no effect is irrelevant here — > the backslashes are not needed in the character classes [...]. > As an editorial enhancement, the backslashes could be entirely removed from > this line. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC9115 (draft-ietf-acme-star-delegation-09) > -------------------------------------- > Title : An Automatic Certificate Management Environment (ACME) > Profile for Generating Delegated Certificates > Publication Date : September 2021 > Author(s) : Y. Sheffer, D. López, A. Pastor Perales, T. Fossati > Category : PROPOSED STANDARD > Source : Automated Certificate Management Environment > Area : Security > Stream : IETF > Verifying Party : IESG IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
