On Mon, Apr 7, 2025 at 7:19 PM Carsten Bormann <cabo@xxxxxxx> wrote:
>> [...LF and CR...]
>
> I think these have to be allowed given that they are built into ABNF (see LWSP etc).
> https://datatracker.ietf.org/doc/html/rfc5234
Allowed for what?
I think ABNF authors expect to be able to use these.
I don’t want to have newlines in most of my identifiers, which generally are one data type for which I need to set the repertoire.
Well, then you don't need this document. But Section 2.2 covers this well enough.
Maybe the PRECIS IdentiferClass is a better fit?
Before making these repertoire decisions, you first need to say what kind of text you want to describe:
I don't agree with your categories here.
Surely the YANG example is good enough. Identifiers:
and then, as linked before, human readable text:
So, "Unicode Assignables" can appear in a more restricted container easily enough.
> I consider this a feature. There's nothing that says these ABNF productions have to cover the whole protocol. Maybe something like this:
>
> FF = %x0C
> paginated_unicode_text = (unicode-assignable *(FF unicode-assignable))
Yes, but the repertoire of the protocol includes FF now,
Yes, I believe that I just wrote that these productions don't have to cover the whole protocol.
(You ABNF is problematic, because your pages will be very short [...]
Yes, I will not win awards for that one :), I just dashed it off to make the point.
thanks,
Rob
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
