idnits 2.17.1 draft-seantek-constrained-abnf-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5234, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5234, updated by this document, for RFC5378 checks: 2007-04-24) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 13, 2017) is 2601 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Leonard 3 Internet-Draft Penango, Inc. 4 Updates: 5234 (if approved) P. Kyzivat 5 Intended Status: Standards Track 6 Expires: September 14, 2017 March 13, 2017 8 Constrained ABNF 9 draft-seantek-constrained-abnf-02 11 Abstract 13 This document extends the base definition of ABNF (Augmented Backus- 14 Naur Form) to express a rule that is constrained by another rule. If 15 a rule B is constrained by rule A, then every production generated by 16 rule B must also be generated by rule A. By creating subordinate 17 production forms, ABNF-using specifications can formally denote the 18 relationship between a general rule and specific subsets of that 19 rule, while preserving ABNF's context-free nature. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute working 28 documents as Internet-Drafts. The list of current Internet-Drafts is 29 at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 14, 2017. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 1. Introduction 55 Augmented Backus-Naur Form (ABNF) [RFC5234] is a formal syntax that 56 is popular among many Internet specifications. As a context-free 57 grammar, all rules heretofore are expressible in the form: 59 rule = elements 61 where a rule can be applied regardless of the context of the 62 elements. 64 Many Internet documents employ this syntax. However, many 65 specifications define protocols with extension points where certain 66 rules identify a field that can take on different productions with 67 different semantics. For example, a field might generally 68 permit any , but when the field has "IPv6:" *VCHAR, it 69 has a peculiar meaning. The traditional ABNF approach is to enumerate 70 a long list of production rules that comply with the general pattern, 71 in the alternative, and then to tack on the generic pattern named as 72 the . This syntax works okay for a base specification 73 but makes it difficult to extend a rule in subsequent specifications 74 in a way that formally names the conformance to the (as 75 opposed to extending the rule with novel syntax). Furthermore, since 76 ABNF does not imply an order of operations, a production that matches 77 a specific rule will also match the generic catch-all rule. The 78 traditional approach constructs an ambiguous grammar, even though the 79 standards authors do not intend the grammar to be ambiguous. These 80 limitations hamper computational ABNF parsers as well as ABNF efforts 81 for services such as syntax highlighting, automatic grammar checking, 82 and compiling into target computer languages. 84 2. Constrained Grammar 86 This document provides a syntax for an ABNF rule that is constrained 87 by another rule. We observe the following relation: 89 If rule B is constrained by rule A, then every production 90 generated by rule B must also be generated by rule A. 92 A few comments are in order with this proposal. First of all, ABNF is 93 a context-free grammar; this proposal attempts to preserve this 94 nature. There are other ways to express "constraints" that are 95 context-sensitive, but extending ABNF in such ways would make it a 96 context-sensitive grammar (which implies more capable automata for 97 parsing and generating such languages). 99 Second of all, the relation "A constrains B" can, in other contexts, 100 be understood as a "subclassing", "subtyping", or "conjunctive" 101 operation. As with conjunction, the underlying operation is 102 commutative: a rule "B-constrained-by-A" produces the same results as 103 "A-constrained-by-B". However, from a rule-naming perspective, the 104 first name (the constrained) is the name; the second name (the 105 constraint) is the ternary operand. Therefore, the syntax proposed in 106 Section 3 is not commutative. 108 Third of all, it is possible to express a constraint relationship 109 that cannot generate any production--not even the empty string. This 110 is consonant with [RFC5234] ABNF. With generic [RFC5234] ABNF, it is 111 possible to repeat rule definitions in a way that makes them 112 impossible to be satisfied, such as followed by 113 . This syntax behaves exactly the same way, except 114 that it permits creating new rule names. 116 3. Constraint Syntax 118 To write a constrained rule, use the ternary syntax 119 rulename ^ constraint = elements. The constraint can be a list of 120 elements, but in most formulations will simply be another rulename. 121 The reflective case where constraint is rulename has no effect and is 122 analogous to duplicating a rule in a list of rules as in [RFC5234] 123 ABNF. The following enhancement to [RFC5234] permits this referenced- 124 rule syntax as an incremental element: 126 rulelist =/ constrainedrule 128 constrainedrule = rulename constrained-by constraint 129 *c-wsp "=" *c-wsp elements c-nl 131 constraint = elements 133 constrained-by = *c-wsp "^" *c-wsp 135 In the constrained-rule production (constrainedrule), the "^" and "=" 136 production is a ternary operator that takes the name of the rule, the 137 constraint, and the elements. 139 A processor that wishes to reduce constrainedrule to an [RFC5234] 140 rule, can do so by conjoining the constraint with the elements. The 141 synthesized rule is then appended in situ to the constraining rule in 142 the alternative (with "/"), in elements where the constraining rule 143 is named. A basic [RFC5234] processor will match or generate 144 productions to both the constraining and constrained rules. [[NB: 145 This synthesis demonstrates that constraint syntax amounts to 146 syntactic sugar, rather than a fundamental change to ABNF.]] 148 A rule is defined either regularly ("=") or as constrained("^" "="). 149 The incremental alternative cannot be used with the constraint 150 syntax. [[NB: This is a change from -00 to -01.]] However, a rule 151 first defined as a constrained rule can be further refined with 152 incremental alternatives. 154 While this syntax suggests that a binary "^" operator could be 155 defined, such an operator is undesirable for a couple of reasons. 157 Firstly, arbitrary syntax serves no parsing or 158 generating purpose: it would be clearer for an author to combine the 159 two prior to writing a specification. A hypothetical 160 is better written in 161 the first place. Similarly, is 162 better written in the first place. [[NB: From 163 this perspective, idealized ABNF can be understood as being in 164 Disjunctive Normal Form, given the existence of "=/".]] 166 Secondly, conjunction inverts the dependency relationship between 167 symbols in ABNF, reversing the directionality of edges in the 168 reachability graph. In [RFC5234] ABNF, every nonterminal symbol (rule 169 name) declares its dependent symbols, which are known at the time of 170 parsing to be terminal or nonterminal. Having parsed a rule, an ABNF 171 parser knows exactly which nonterminal symbols to look for before 172 returning. Therefore, the parsing of subsequent rule definitions that 173 do not have sought-after names can be skipped. The existence of a 174 general-purpose conjunctive operator, however, implies that any rule 175 definition could name a rule that constrains the subject rule, 176 meaning that an ABNF parser would have to parse every rule to 177 completion before returning. By moving the constraint to the left- 178 hand-side of the "=", a parser need not parse the right-hand side of 179 every rule. (Notably, a parser will have to parse all of the elements 180 of the constraint, which is a reason why authors should exercise 181 REstraint by limiting the constraint to a single named rule.) 183 Stylistically, authors are encouraged to put constraint syntax below 184 the rule that defines the constraint. If the constraining rule refers 185 to novel rules, those rules may be defined prior the constrained 186 rules. For example, the relevant parts of [RFC5322] could be written: 188 ; trace is not relevant to this example 189 fields = *(trace *field / *resent-field) *field 190 resent-field = "Resent-" field-name ":" unstructured CRLF 192 field = field-name ":" unstructured CRLF 194 field-name = 1*ftext 196 ftext = %d33-57 / %d59-126 198 ; obs-unstruct removed 199 unstructured = (*([FWS] VCHAR) *WSP) 201 resent-date ^ resent-field = "Resent-Date:" date-time CRLF 203 resent-from ^ resent-field = "Resent-From:" mailbox-list CRLF 205 resent-sender ^ resent-field = "Resent-Sender:" mailbox CRLF 207 resent-to ^ resent-field = "Resent-To:" address-list CRLF 209 resent-cc ^ resent-field = "Resent-Cc:" address-list CRLF 211 resent-bcc ^ resent-field = "Resent-Bcc:" 212 [address-list / CFWS] CRLF 214 resent-msg-id ^ resent-field = "Resent-Message-ID:" msg-id CRLF 216 orig-date ^ field = "Date:" date-time CRLF 218 from ^ field = "From:" mailbox-list CRLF 220 sender ^ field = "Sender:" mailbox CRLF 222 reply-to ^ field = "Reply-To:" address-list CRLF 224 to ^ field = "To:" address-list CRLF 226 cc ^ field = "Cc:" address-list CRLF 228 bcc ^ field = "Bcc:" [address-list / CFWS] CRLF 230 message-id ^ field = "Message-ID:" msg-id CRLF 232 in-reply-to ^ field = "In-Reply-To:" 1*msg-id CRLF 234 references ^ field = "References:" 1*msg-id CRLF 236 subject ^ field = "Subject:" unstructured CRLF 237 comments ^ field = "Comments:" unstructured CRLF 239 keywords ^ field = "Keywords:" phrase *("," phrase) CRLF 241 4. Effects on RFC 5234 243 Formally, this document updates [RFC5234] but does not modify it in 244 situ. Authors need to reference this document if they want to include 245 these enhancements; bare references to [RFC5234] do not include this 246 specification. This directive follows a model whereby document 247 authors can choose whether to invoke particular enhancements to ABNF. 248 As time goes on, the IETF can determine how often these enhancements 249 are invoked, and can decide whether to include them as part of a 250 revision to the base [RFC5234]. 252 5. IANA Considerations 254 This document implies no IANA considerations. 256 6. Security Considerations 258 Security is truly believed to be irrelevant to this document. 260 7. References 262 7.1. Normative References 264 [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for 265 Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 266 10.17487/RFC5234, January 2008, . 269 7.2. Informative References 271 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 272 10.17487/RFC5322, October 2008, . 275 Authors' Addresses 277 Sean Leonard 278 Penango, Inc. 279 5900 Wilshire Boulevard 280 21st Floor 281 Los Angeles, CA 90036 282 USA 284 EMail: dev+ietf@seantek.com 285 URI: http://www.penango.com/ 287 Paul Kyzivat 288 Massachusetts 289 United States 291 EMail: pkyzivat@alum.mit.edu