Paul Leach   Microsoft   1 Microsoft Way   Redmond, WA  98052   EMail: paulle@microsoft.com   Chris Newman   Innosoft International, Inc.   1050 Lakes Drive   West Covina, CA 91790 USA   EMail: chris.newman@innosoft.com7  ABNF   What follows is the definition of the notation as is used in the   HTTP/1.1 specification (RFC 2616) and the HTTP authentication   specification (RFC 2617); it is reproduced here for ease of   reference. Since it is intended that a single Digest implementation   can support both HTTP and SASL-based protocols, the same notation is   used in both to facilitate comparison and prevention of unwanted   differences. Since it is cut-and-paste from the HTTP specifications,   not all productions may be used in this specification. It is also not   quite legal ABNF; again, the errors were copied from the HTTP   specifications.7.1   Augmented BNF   All of the mechanisms specified in this document are described in   both prose and an augmented Backus-Naur Form (BNF) similar to that   used by RFC 822 [RFC 822]. Implementers will need to be familiar with   the notation in order to understand this specification.Leach & Newman              Standards Track                    [Page 21]RFC 2831                 Digest SASL Mechanism                  May 2000   The augmented BNF includes the following constructs:   name = definition      The name of a rule is simply the name itself (without any      enclosing "<" and ">") and is separated from its definition by the      equal "=" character. White space is only significant in that      indentation of continuation lines is used to indicate a rule      definition that spans more than one line. Certain basic rules are      in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle      brackets are used within definitions whenever their presence will      facilitate discerning the use of rule names.   "literal"      Quotation marks surround literal text. Unless stated otherwise,      the text is case-insensitive.   rule1 | rule2      Elements separated by a bar ("|") are alternatives, e.g., "yes |      no" will accept yes or no.   (rule1 rule2)      Elements enclosed in parentheses are treated as a single element.      Thus, "(elem (foo | bar) elem)" allows the token sequences      "elem foo elem" and "elem bar elem".   *rule      The character "*" preceding an element indicates repetition. The      full form is "<n>*<m>element" indicating at least <n> and at most      <m> occurrences of element. Default values are 0 and infinity so      that "*(element)" allows any number, including zero; "1*element"      requires at least one; and "1*2element" allows one or two.   [rule]      Square brackets enclose optional elements; "[foo bar]" is      equivalent to "*1(foo bar)".   N rule      Specific repetition: "<n>(element)" is equivalent to      "<n>*<n>(element)"; that is, exactly <n> occurrences of (element).      Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three      alphabetic characters.   #rule      A construct "#" is defined, similar to "*", for defining lists of      elements. The full form is "<n>#<m>element" indicating at least      <n> and at most <m> elements, each separated by one or more commas      (",") and OPTIONAL linear white space (LWS). This makes the usual      form of lists very easy; a rule such asLeach & Newman              Standards Track                    [Page 22]RFC 2831                 Digest SASL Mechanism                  May 2000        ( *LWS element *( *LWS "," *LWS element ))      can be shown as        1#element      Wherever this construct is used, null elements are allowed, but do      not contribute to the count of elements present. That is,      "(element), , (element) " is permitted, but counts as only two      elements.  Therefore, where at least one element is required, at      least one non-null element MUST be present. Default values are 0      and infinity so that "#element" allows any number, including zero;      "1#element" requires at least one; and "1#2element" allows one or      two.   ; comment      A semi-colon, set off some distance to the right of rule text,      starts a comment that continues to the end of line. This is a      simple way of including useful notes in parallel with the      specifications.   implied *LWS      The grammar described by this specification is word-based. Except      where noted otherwise, linear white space (LWS) can be included      between any two adjacent words (token or quoted-string), and      between adjacent words and separators, without changing the      interpretation of a field. At least one delimiter (LWS and/or      separators) MUST exist between any two tokens (for the definition      of "token" below), since they would otherwise be interpreted as a      single token.7.2   Basic Rules   The following rules are used throughout this specification to   describe basic parsing constructs. The US-ASCII coded character set   is defined by ANSI X3.4-1986 [USASCII].       OCTET          = <any 8-bit sequence of data>       CHAR           = <any US-ASCII character (octets 0 - 127)>       UPALPHA        = <any US-ASCII uppercase letter "A".."Z">       LOALPHA        = <any US-ASCII lowercase letter "a".."z">       ALPHA          = UPALPHA | LOALPHA       DIGIT          = <any US-ASCII digit "0".."9">       CTL            = <any US-ASCII control character                        (octets 0 - 31) and DEL (127)>       CR             = <US-ASCII CR, carriage return (13)>       LF             = <US-ASCII LF, linefeed (10)>       SP             = <US-ASCII SP, space (32)>       HT             = <US-ASCII HT, horizontal-tab (9)>       <">            = <US-ASCII double-quote mark (34)>       CRLF           = CR LFLeach & Newman              Standards Track                    [Page 23]RFC 2831                 Digest SASL Mechanism                  May 2000   All linear white space, including folding, has the same semantics as   SP. A recipient MAY replace any linear white space with a single SP   before interpreting the field value or forwarding the message   downstream.       LWS            = [CRLF] 1*( SP | HT )   The TEXT rule is only used for descriptive field contents and values   that are not intended to be interpreted by the message parser. Words   of *TEXT MAY contain characters from character sets other than   ISO-8859-1 [ISO 8859] only when encoded according to the rules of RFC   2047 [RFC 2047].       TEXT           = <any OCTET except CTLs,                        but including LWS>   A CRLF is allowed in the definition of TEXT only as part of a header   field continuation. It is expected that the folding LWS will be   replaced with a single SP before interpretation of the TEXT value.   Hexadecimal numeric characters are used in several protocol elements.       HEX            = "A" | "B" | "C" | "D" | "E" | "F"                      | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT   Many HTTP/1.1 header field values consist of words separated by LWS   or special characters. These special characters MUST be in a quoted   string to be used within a parameter value.       token          = 1*<any CHAR except CTLs or separators>       separators     = "(" | ")" | "<" | ">" | "@"                      | "," | ";" | ":" | "\" | <">                      | "/" | "[" | "]" | "?" | "="                      | "{" | "}" | SP | HT   A string of text is parsed as a single word if it is quoted using   double-quote marks.      quoted-string  = ( <"> qdstr-val <"> )      qdstr-val      = *( qdtext | quoted-pair )      qdtext         = <any TEXT except <">>   Note that LWS is NOT implicit between the double-quote marks (<">)   surrounding a qdstr-val and the qdstr-val; any LWS will be considered   part of the qdstr-val.  This is also the case for quotation marks   surrounding any other construct.Leach & Newman              Standards Track                    [Page 24]RFC 2831                 Digest SASL Mechanism                  May 2000   The backslash character ("\") MAY be used as a single-character   quoting mechanism only within qdstr-val and comment constructs.       quoted-pair    = "\" CHAR   The value of this construct is CHAR. Note that an effect of this rule   is that backslash must be quoted.8  Sample Code   The sample implementation in [Digest] also applies to DIGEST-MD5.   The following code implements the conversion from UTF-8 to 8859-1 if   necessary.    /* if the string is entirely in the 8859-1 subset of UTF-8, then     * translate to 8859-1 prior to MD5     */    void MD5_UTF8_8859_1(MD5_CTX *ctx, const unsigned char *base,        int len)    {        const unsigned char *scan, *end;        unsigned char cbuf;        end = base + len;        for (scan = base; scan < end; ++scan) {            if (*scan > 0xC3) break; /* abort if outside 8859-1 */            if (*scan >= 0xC0 && *scan <= 0xC3) {                if (++scan == end || *scan < 0x80 || *scan > 0xBF)                    break;            }        }        /* if we found a character outside 8859-1, don't alter string         */        if (scan < end) {            MD5Update(ctx, base, len);            return;        }        /* convert to 8859-1 prior to applying hash         */        do {            for (scan = base; scan < end && *scan < 0xC0; ++scan)                ;            if (scan != base) MD5Update(ctx, base, scan - base);            if (scan + 1 >= end) break;            cbuf = ((scan[0] & 0x3) << 6) | (scan[1] & 0x3f);            MD5Update(ctx, &cbuf, 1);Leach & Newman              Standards Track                    [Page 25]RFC 2831                 Digest SASL Mechanism                  May 2000            base = scan + 2;        } while (base < end);    }Leach & Newman              Standards Track                    [Page 26]RFC 2831                 Digest SASL Mechanism                  May 20009  Full Copyright Statement   Copyright (C) The Internet Society (2000).  All Rights Reserved.   This document and translations of it may be copied and furnished to   others, and derivative works that comment on or otherwise explain it   or assist in its implementation may be prepared, copied, published   and distributed, in whole or in part, without restriction of any   kind, provided that the above copyright notice and this paragraph are   included on all such copies and derivative works.  However, this   document itself may not be modified in any way, such as by removing   the copyright notice or references to the Internet Society or other   Internet organizations, except as needed for the purpose of   developing Internet standards in which case the procedures for   copyrights defined in the Internet Standards process must be   followed, or as required to translate it into languages other than   English.   The limited permissions granted above are perpetual and will not be   revoked by the Internet Society or its successors or assigns.   This document and the information contained herein is provided on an   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Acknowledgement   Funding for the RFC Editor function is currently provided by the   Internet Society.Leach & Newman              Standards Track                    [Page 27]