likely to signal such an error than a client such as a
          browser). We anticipate that multiple flags will be allowed in
          the future, so implementers MUST NOT assume that the flags
          field can only contain 0 or 1 characters. Finally, if a client
          encounters a record with an unknown flag, it MUST ignore it
          and move to the next record. This test takes precedence even
          over the "order" field. Since flags can control the
          interpretation placed on fields, a novel flag might change the
          interpretation of the regexp and/or replacement fields such
          that it is impossible to determine if a record matched a URN.








 
RFC 2168            Resolution of URIs Using the DNS           June 1997


   Service
          Specifies the resolution service(s) available down this
          rewrite path. It may also specify the particular protocol that
          is used to talk with a resolver. A protocol MUST be specified
          if the flags field states that the NAPTR is terminal. If a
          protocol is specified, but the flags field does not state that
          the NAPTR is terminal, the next lookup MUST be for a NAPTR.
          The client MAY choose not to perform the next lookup if the
          protocol is unknown, but that behavior MUST NOT be relied
          upon.

          The service field may take any of the values below (using the
          Augmented BNF of RFC 822[9]):

           service_field = [ [protocol] *("+" rs)]
           protocol      = ALPHA *31ALPHANUM
           rs            = ALPHA *31ALPHANUM
        // The protocol and rs fields are limited to 32
        // characters and must start with an alphabetic.
        // The current set of "known" strings are:
        // protocol      = "rcds" / "thttp" / "hdl" / "rwhois" / "z3950"
        // rs            = "N2L" / "N2Ls" / "N2R" / "N2Rs" / "N2C"
        //               / "N2Ns" / "L2R" / "L2Ns" / "L2Ls" / "L2C"

          i.e. an optional protocol specification followed by 0 or more
          resolution services. Each resolution service is indicated by
          an initial '+' character.

          Note that the empty string is also a valid service field. This
          will typically be seen at the top levels of a namespace, when
          it is impossible to know what services and protocols will be
          offered by a particular publisher within that name space.

          At this time the known protocols are rcds[7], hdl[10] (binary,
          UDP-based protocols),  thttp[5] (a textual, TCP-based
          protocol), rwhois[11] (textual, UDP or TCP based), and
          Z39.50[12] (binary, TCP-based). More will be allowed later.
          The names of the protocols must be formed from the characters
          [a-Z0-9]. Case of the characters is not significant.

          The service requests currently allowed will be described in
          more detail in [6], but in brief they are:
                N2L  - Given a URN, return a URL
                N2Ls - Given a URN, return a set of URLs
                N2R  - Given a URN, return an instance of the resource.
                N2Rs - Given a URN, return multiple instances of the
                       resource, typically encoded using
                       multipart/alternative.




 
RFC 2168            Resolution of URIs Using the DNS           June 1997


                N2C  - Given a URN, return a collection of meta-
                       information on the named resource. The format of
                       this response is the subject of another document.
                N2Ns - Given a URN, return all URNs that are also
                       identifers for the resource.
                L2R  - Given a URL, return the resource.
                L2Ns - Given a URL, return all the URNs that are
                       identifiers for the resource.
                L2Ls - Given a URL, return all the URLs for instances of
                       of the same resource.
                L2C  - Given a URL, return a description of the
                       resource.

          The actual format of the service request and response will be
          determined by the resolution protocol, and is the subject for
          other documents (e.g. [5]). Protocols need not offer all
          services. The labels for service requests shall be formed from
          the set of characters [A-Z0-9]. The case of the alphabetic
          characters is not significant.

   Regexp
          A STRING containing a substitution expression that is applied