[rfc-i] [Json] v3imp #8 Fragment tagging on sourcecode
derhoermi at gmx.net
Fri Jan 30 15:32:06 PST 2015
* Sean Leonard wrote:
>On 1/28/2015 3:02 PM, Nico Williams wrote:
>>> As a broader useful point (not directed specifically to
>>> draft-ietf-json-text-sequence-13), I think it would be nice if
>>> future RFC ABNF can assume that the symbols in RFC 20 for %x00-20 /
>>> %x7F are rules that can be used as-is. Hence NUL = %x00, SUB = %x1A,
>>> DEL = %x7F, etc.
>> I agree. These should be added to RFC5234 (i.e., we should publish an
>> update RFC listing them).
>I would be willing to write up/work on a concise RFC (Internet-Draft)
>that does this, prior to IETF 92. I would not mind adding a few
>additional rules to the Core Rules if there is near-unanimous support
>for such rules. (Hard to think of any in particular, except maybe some
>generic UTF8 character rules. Last I checked, ABNF is still
>octet-oriented and US-ASCII focused.)
It is integer-oriented, you have to define the alphabet in prose and are
free to say it's "octets" or "Unicode scalar values" or whatever else.
I do not think an RFC that updates RFC 5234 just to add names for three
symbols is a good idea. It's very rare that the particular characters
are useful, and ordinarily you will have to define other rules on your
own aswell; on the software side you would then have ABNF tools that do
not know the new Core rules, I would have to update my Parse::ABNF Perl
module for instance, and there is the issue that some specifications may
already be using the symbol names, and dealing with clashes with Core
rules is a bit nasty. I would rather have more explicit imports, be that
by convention like some RFCs already do it.
(Copying abnf-discuss at ietf.org instead of the JSON lists).
Björn Höhrmann · mailto:bjoern at hoehrmann.de · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
Available for hire in Berlin (early 2015) · http://www.websitedev.de/
More information about the rfc-interest