Constrained ABNF
draft-seantek-constrained-abnf-02

Document Type Active Internet-Draft (individual)
Last updated 2017-03-13
Stream (None)
Intended RFC status (None)
Formats plain text pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         S. Leonard
Internet-Draft                                             Penango, Inc.
Updates: 5234 (if approved)                                   P. Kyzivat
Intended Status: Standards Track                                        
Expires: September 14, 2017                               March 13, 2017
                                                                        
                                                                        

                            Constrained ABNF
                   draft-seantek-constrained-abnf-02
                                    
Abstract

   This document extends the base definition of ABNF (Augmented Backus-
   Naur Form) to express a rule that is constrained by another rule. If
   a rule B is constrained by rule A, then every production generated by
   rule B must also be generated by rule A. By creating subordinate
   production forms, ABNF-using specifications can formally denote the
   relationship between a general rule and specific subsets of that
   rule, while preserving ABNF's context-free nature.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF). Note that other groups may also distribute working
   documents as Internet-Drafts. The list of current Internet-Drafts is
   at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 14, 2017.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
 

Leonard & Kyzivat           Standards Track                     [Page 1]
Internet-Draft              Constrained ABNF                  March 2017

   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

1.  Introduction

   Augmented Backus-Naur Form (ABNF) [RFC5234] is a formal syntax that
   is popular among many Internet specifications. As a context-free
   grammar, all rules heretofore are expressible in the form:

      rule = elements

   where a rule can be applied regardless of the context of the
   elements.

   Many Internet documents employ this syntax. However, many
   specifications define protocols with extension points where certain
   rules identify a field that can take on different productions with
   different semantics. For example, a <value> field might generally
   permit any <VCHAR>, but when the <value> field has "IPv6:" *VCHAR, it
   has a peculiar meaning. The traditional ABNF approach is to enumerate
   a long list of production rules that comply with the general pattern,
   in the alternative, and then to tack on the generic pattern named as
   the <other-value>. This syntax works okay for a base specification
   but makes it difficult to extend a rule in subsequent specifications
   in a way that formally names the conformance to the <other-value> (as
   opposed to extending the rule with novel syntax). Furthermore, since
   ABNF does not imply an order of operations, a production that matches
   a specific rule will also match the generic catch-all rule. The
   traditional approach constructs an ambiguous grammar, even though the
   standards authors do not intend the grammar to be ambiguous. These
   limitations hamper computational ABNF parsers as well as ABNF efforts
   for services such as syntax highlighting, automatic grammar checking,
   and compiling into target computer languages.

2.  Constrained Grammar

   This document provides a syntax for an ABNF rule that is constrained
   by another rule. We observe the following relation:

      If rule B is constrained by rule A, then every production
      generated by rule B must also be generated by rule A.

   A few comments are in order with this proposal. First of all, ABNF is
   a context-free grammar; this proposal attempts to preserve this
 

Leonard & Kyzivat           Standards Track                     [Page 2]
Show full document text