idnits 2.17.1 draft-kyzivat-abnf-import-00.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 abstract seems to contain references ([RFC5234]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC5234, but the abstract doesn't seem to directly say this. It does mention RFC5234 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. (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 (January 3, 2013) is 4123 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: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Kyzivat 3 Internet-Draft Huawei 4 Updates: 5234 (if approved) January 3, 2013 5 Intended status: Standards Track 6 Expires: July 7, 2013 8 ABNF Extensions for Importing and Scoping 9 draft-kyzivat-abnf-import-00 11 Abstract 13 This document proposes extensions to the ABNF defined in [RFC5234] to 14 support importation of ABNF from other documents, and multiple naming 15 scopes for rulenames. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on July 7, 2013. 34 Copyright Notice 36 Copyright (c) 2013 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 1. Introduction 51 The intent of this proposal is to better support current practice 52 where one draft or RFC extends the ABNF from another draft or RFC, or 53 references ABNF rules defined elsewhere when defining something new. 55 Currently that is done using comments that identify the source of the 56 referenced definitions. Formally processing this requires manual 57 actions to cut and paste definitions from multiple documents to 58 create a single ABNF source that can be processed for formal tools. 60 With the proposed changes, it will be possible to build ABNF tools 61 that automatically extract the required definitions. 63 The changes that support this are: 64 o A way to assign a name to a rule list within a document 66 This allows multiple independent groups of rules to be defined 67 within a single document and referenced independently. For 68 flexibility, nesting of named rule lists is permitted. 69 o A way to reference a rule defined in a named collection of rules 70 o A way to import rule definitions from another document 72 The reference identifies the document and may name a specific 73 named rule list within that document. When importing a named rule 74 list, it may be imported with or without the name. The 75 definitions are copied into 77 2. Terminology 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in [RFC2119]. 83 3. Extensions to ABNF Syntax 85 The following are additions to the ABNF for ABNF defined in 86 [RFC5234]. 88 rulelist =/ 1*( 89 named-rulelist / rulelist-import / rule/ (*c-wsp c-nl) ) 90 ; this is really a backward compatible replacement definition 92 named-rulelist = 93 rulelist-name *WSP "{" rulelist "}" c-nl 95 rulelist-name = rulename 97 rulelist-import = 98 (basic-import / named-import) c-nl 100 basic-import = "@" docname 101 ; imports all the ABNF from the named document 103 docname = char-val 104 ; format and resolution of the document from the docname 105 ; is defined by the specific tools used. 106 ; At least common URI types should be supported 107 ; E.g. "urn:ietf:rfc:5234", 108 ; "urn:ietf:id:draft-ietf-foo-bar-01", 109 ; "file:foo.xml" 111 named-import = rulelist-name basic-import 112 ; (E.g. CORE@"urn:ietf:rfc:5234") 113 ; This is shorthand for importing into a new named 114 ; rulelist with the given name. 116 element =/ scoped-rulename 118 scoped-rulename = 1*(rulelist-name ".") rulename 120 4. Import Semantics 122 Importing logically replaces the import statement with text from the 123 imported document. Importing may be done in two ways: 124 o The simply inserts all the ABNF from the referenced 125 document. 126 o The is similar, but does the import within a new 127 . This is just syntactic sugar, but is 128 convenient. E.g. the following: 130 CORE@"urn:ietf:rfc:5234" 132 is equivalent to: 134 CORE { 135 @"urn:ietf:rfc:5234" 136 } 138 Note that if the imported rules contain references to rules that are 139 not imported, then the importing document must provide definitions 140 for those. 142 For now, the ABNF syntax of ABNF defines a docname as a string 143 without further syntax. Interpretation of the docname is deferred to 144 the ABNF processing tools. I propose that this should at least 145 support common URI formats, including the urn:ietf format for rfcs 146 and ids. It may also be expedient to support some more concise 147 syntax for ietf documents. 149 The intent is that the import statements only import the ABNF 150 definitions from the referenced document, ignoring any content that 151 is not ABNF. This is so that ABNF from RFCs and drafts can be 152 referenced directly. The xml2rfc notation 153 should be sufficient to support this. If multiple abnf artwork 154 elements are present they should simply be concatenated to form one 155 logical document to be imported. 157 5. Scoping of Names 159 A document containing ABNF has an implicit outermost scope. Each 160 scope has a symbol table for rules and named rulelists defined within 161 that scope. 163 The appearance of a with a particular creates a nested scope with that name within the enclosing 165 scope's symbol table. Once a named rulelist has been closed it may 166 not be reopened. (This ensures that redefinition of a named rulelist 167 is an error, preventing a class of errors.) 169 An element consisting of a is resolved within the symbol 170 table of the scope where it is found. If not found, resolution is 171 attempted successively in each enclosing scope. 173 An element consisting of a is resolved as follows: 174 o The leftmost component of the (the first 175 ) is resolved first. 177 o It is resolved by looking within the symbol table of the scope 178 where it is found. If not found, resolution is attempted 179 successively in each enclosing scope, and must resolve to a 180 . 181 o Then the next component ( or ) is 182 resolved within the symbol table of that rulelist. This continues 183 until the last component has been resolved. 185 I'm undecided whether it should be possible to have both a rule and a 186 rulelist with the same name in the same scope. 188 It is important to maintain the order independence of rule 189 definitions that exists with prior definitions of ABNF. (It must be 190 possible to reference a rule in a named rulelist that is defined 191 later.) 193 6. IANA Considerations 195 Don't think so. 197 7. Security Considerations 199 Security is truly believed to be irrelevant to this document. 201 8. References 203 8.1. Normative References 205 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 206 Requirement Levels", BCP 14, RFC 2119, March 1997. 208 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 209 Specifications: ABNF", STD 68, RFC 5234, January 2008. 211 8.2. Informative References 213 Author's Address 215 Paul Kyzivat 216 Huawei 218 Email: pkyzivat@alum.mit.edu