>> [...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 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. Before making these repertoire decisions, you first need to say what kind of text you want to describe: (1) Entire Languages (YANG, ABNF, JSON, XML, …). These generally need to allow, but summarily ignore, CR in front of LF, because that’s just how they look like when they have been on a Windows system. vs. data items in data representation formats: (2) labels, short descriptions. 1D text. No [CR]LF. (3) longer descriptions. Probably 2D text. Needs [CR]LF for line structure unless that is handled in the representation format; could easily remove CR noise before transmission. (4) generalized text. Like (1). vs. (5) text-based protocols. Depends on what they contain, but [CR]LF is often in use as a protocol element delimiter, so you need to do some gymnastics to get data transparency for (3) and (4), which may make you want to restrict the exact combinations in which CR/LF can be used (such as always requiring both for mail). > 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, which for instance can’t be transported in XML (which need not be a problem as you might want to use XML for the page structure instead of a control character). (You ABNF is problematic, because your pages will be very short, and more seriously you typically will want terminators and not separators.) Grüße, Carsten -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
