< draft-kyzivat-case-sensitive-abnf-01.txt   draft-kyzivat-case-sensitive-abnf-02.txt >
Internet Engineering Task Force P. Kyzivat Internet Engineering Task Force P. Kyzivat
Internet-Draft Internet-Draft
Updates: 5234 (if approved) August 18, 2014 Updates: 5234 (if approved) September 10, 2014
Intended status: Standards Track Intended status: Standards Track
Expires: February 19, 2015 Expires: March 14, 2015
Case-Sensitive String Support in ABNF Case-Sensitive String Support in ABNF
draft-kyzivat-case-sensitive-abnf-01 draft-kyzivat-case-sensitive-abnf-02
Abstract Abstract
This document extends the base definition of ABNF (Augmented Mackus- This document extends the base definition of ABNF (Augmented Backus-
Naur Form) to include a way to specify ASCII string literals that are Naur Form) to include a way to specify ASCII string literals that are
matched in a case-sensitive manner. matched in a case-sensitive manner.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 19, 2015. This Internet-Draft will expire on March 14, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 18 skipping to change at page 2, line 18
2. Updates to RFC5234 . . . . . . . . . . . . . . . . . . . . . 2 2. Updates to RFC5234 . . . . . . . . . . . . . . . . . . . . . 2
2.1. Terminal values - literal text strings . . . . . . . . . 2 2.1. Terminal values - literal text strings . . . . . . . . . 2
2.2. ABNF Definition of ABNF - char-val . . . . . . . . . . . 4 2.2. ABNF Definition of ABNF - char-val . . . . . . . . . . . 4
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. Normative References . . . . . . . . . . . . . . . . . . . . 4 5. Normative References . . . . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4
1. Introduction 1. Introduction
The base definition of ABNF (Augmented Mackus-Naur Form) supports The base definition of ABNF (Augmented Backus-Naur Form) supports
ASCII string literals. Matching of these literals is done in a case- ASCII string literals. Matching of these literals is done in a case-
insensitive manner. While this is often the desired behavior, in insensitive manner. While this is often the desired behavior, in
some situations case-sensitive matching of string literals is needed. some situations case-sensitive matching of string literals is needed.
Literals for case-sensitive matching must be specified using the Literals for case-sensitive matching must be specified using the
numeric representation of those characters. That is inconvenient and numeric representation of those characters. That is inconvenient and
error prone both to write and to read. error prone both to write and to read.
This document extends ABNF to have two different types of ASCII This document extends ABNF to have two different types of ASCII
string literals. One type is matched using case-sensitive matching, string literals. One type is matched using case-sensitive matching,
while the other is matched using case-insensitive matching. These while the other is matched using case-insensitive matching. These
skipping to change at page 3, line 19 skipping to change at page 3, line 19
ASCII. ASCII.
Literal text strings in ABNF may be either case sensitive or case Literal text strings in ABNF may be either case sensitive or case
insensitive. The form of matching used with a literal text string is insensitive. The form of matching used with a literal text string is
denoted by a prefix to the quoted string. The following prefixes are denoted by a prefix to the quoted string. The following prefixes are
allowed: allowed:
%s = case-sensitive %s = case-sensitive
%i = case-insensitive %i = case-insensitive
If no prefix is present then the string is case-insensitive. To be consistent with prior implementations of ABNF, having no prefix
means that the string is case-insensitive, and is equivalent to
having the "%i" prefix.
Hence: Hence:
rulename = %i"aBc" rulename = %i"aBc"
and: and:
rulename = "abc" rulename = "abc"
will both match "abc", "Abc", "aBc", "abC", "ABc", "aBC", "AbC", and will both match "abc", "Abc", "aBc", "abC", "ABc", "aBC", "AbC", and
skipping to change at page 3, line 51 skipping to change at page 4, line 6
For example: For example:
rulename = %d97 %d98 %d99 rulename = %d97 %d98 %d99
or or
rulename = %x61.62.63 rulename = %x61.62.63
will match only the string that comprises only the lowercase will match only the string that comprises only the lowercase
characters, abc. This mechanism has a clear readability characters, abc. The new way (using a literal text string with a
disadvantage, with respect to using a literal text string with a prefix) has a clear readability advantage over the old way.
prefix, and new the prefix mechanism is preferred.
2.2. ABNF Definition of ABNF - char-val 2.2. ABNF Definition of ABNF - char-val
char-val = case-insensitive-string / char-val = case-insensitive-string /
case-sensitive-string case-sensitive-string
case-insensitive-string = case-insensitive-string =
[ "%i" ] quoted-string [ "%i" ] quoted-string
case-sensitive-string = case-sensitive-string =
 End of changes. 8 change blocks. 
10 lines changed or deleted 11 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/