rfc2831.txt

中、英文RFC文档大全打包下载完全版 .

   Paul Leach
   Microsoft
   1 Microsoft Way
   Redmond, WA  98052

   EMail: [e-mail]


   Chris Newman
   Innosoft International, Inc.
   1050 Lakes Drive
   West Covina, CA 91790 USA

   EMail: [e-mail]

7  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 as



Leach & 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 LF



Leach & 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 2000


9  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]