============================================

   A detailed description of the NAPTR RR will be given later, but to
   give a flavor for the proposal we first give a simple description of
   the record and three examples of its use.

   The key fields in the NAPTR RR are order, preference, service, flags,
   regexp, and replacement:

   * The order field specifies the order in which records MUST be
     processed when multiple NAPTR records are returned in response to a
     single query.  A naming authority may have delegated a portion of
     its namespace to another agency. Evaluating the NAPTR records in
     the correct order is necessary for delegation to work properly.

   * The preference field specifies the order in which records SHOULD be
     processed when multiple NAPTR records have the same value of
     "order".  This field lets a service provider specify the order in
     which resolvers are contacted, so that more capable machines are
     contacted in preference to less capable ones.






 
RFC 2168            Resolution of URIs Using the DNS           June 1997


   * The service field specifies the resolution protocol and resolution
     service(s) that will be available if the rewrite specified by the
     regexp or replacement fields is applied. Resolution protocols are
     the protocols used to talk with a resolver. They will be specified
     in other documents, such as [5]. Resolution services are operations
     such as N2R (URN to Resource), N2L (URN to URL), N2C (URN to URC),
     etc.  These will be discussed in the URN Resolution Services
     document[6], and their behavior in a particular resolution protocol
     will be given in the specification for that protocol (see [5] for a
     concrete example).

   * The flags field contains modifiers that affect what happens in the
     next DNS lookup, typically for optimizing the process. Flags may
     also affect the interpretation of the other fields in the record,
     therefore, clients MUST skip NAPTR records which contain an unknown
     flag value.

   * The regexp field is one of two fields used for the rewrite rules,
     and is the core concept of the NAPTR record. The regexp field is a
     String containing a sed-like substitution expression. (The actual
     grammar for the substitution expressions is given later in this
     draft). The substitution expression is applied to the original URN
     to determine the next domain name to be queried. The regexp field
     should be used when the domain name to be generated is conditional
     on information in the URI. If the next domain name is always known,
     which is anticipated to be a common occurrence, the replacement
     field should be used instead.

   * The replacement field is the other field that may be used for the
     rewrite rule. It is an optimization of the rewrite process for the
     case where the next domain name is fixed instead of being
     conditional on the content of the URI. The replacement field is a
     domain name (subject to compression if a DNS sender knows that a
     given recipient is able to decompress names in this RR type's RDATA
     field). If the rewrite is more complex than a simple substitution
     of a domain name, the replacement field should be set to . and the
     regexp field used.















 
RFC 2168            Resolution of URIs Using the DNS           June 1997


   Note that the client applies all the substitutions and performs all
   lookups, they are not performed in the DNS servers. Note also that it
   is the belief of the developers of this document that regexps should
   rarely be used. The replacement field seems adequate for the vast
   majority of situations. Regexps are only necessary when portions of a
   namespace are to be delegated to different resolvers. Finally, note
   that the regexp and replacement fields are, at present, mutually
   exclusive. However, developers of client software should be aware
   that a new flag might be defined which requires values in both
   fields.

Example 1
---------