001    /*
002     *  Licensed to the Apache Software Foundation (ASF) under one
003     *  or more contributor license agreements.  See the NOTICE file
004     *  distributed with this work for additional information
005     *  regarding copyright ownership.  The ASF licenses this file
006     *  to you under the Apache License, Version 2.0 (the
007     *  "License"); you may not use this file except in compliance
008     *  with the License.  You may obtain a copy of the License at
009     *  
010     *    http://www.apache.org/licenses/LICENSE-2.0
011     *  
012     *  Unless required by applicable law or agreed to in writing,
013     *  software distributed under the License is distributed on an
014     *  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
015     *  KIND, either express or implied.  See the License for the
016     *  specific language governing permissions and limitations
017     *  under the License. 
018     *  
019     */
020    
021    package org.apache.directory.server.dns.io.encoder;
022    
023    
024    /**
025     * 4. NAPTR RR Format
026     * 
027     * 4.1 Packet Format
028     * 
029     *    The packet format of the NAPTR RR is given below.  The DNS type code
030     *    for NAPTR is 35.
031     * 
032     *       The packet format for the NAPTR record is as follows
033     *                                        1  1  1  1  1  1
034     *          0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
035     *        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
036     *        |                     ORDER                     |
037     *        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
038     *        |                   PREFERENCE                  |
039     *        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
040     *        /                     FLAGS                     /
041     *        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
042     *        /                   SERVICES                    /
043     *        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
044     *        /                    REGEXP                     /
045     *        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
046     *        /                  REPLACEMENT                  /
047     *        /                                               /
048     *        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
049     * 
050     *    <character-string> and <domain-name> as used here are defined in RFC
051     *    1035 [7].
052     * 
053     *    ORDER
054     *       A 16-bit unsigned integer specifying the order in which the NAPTR
055     *       records MUST be processed in order to accurately represent the
056     *       ordered list of Rules.  The ordering is from lowest to highest.
057     *       If two records have the same order value then they are considered
058     *       to be the same rule and should be selected based on the
059     *       combination of the Preference values and Services offered.
060     * 
061     *    PREFERENCE
062     *       Although it is called "preference" in deference to DNS
063     *       terminology, this field is equivalent to the Priority value in the
064     *       DDDS Algorithm.  It is a 16-bit unsigned integer that specifies
065     *       the order in which NAPTR records with equal Order values SHOULD be
066     *       processed, low numbers being processed before high numbers.  This
067     *       is similar to the preference field in an MX record, and is used so
068     *       domain administrators can direct clients towards more capable
069     *       hosts or lighter weight protocols.  A client MAY look at records
070     *       with higher preference values if it has a good reason to do so
071     *       such as not supporting some protocol or service very well.
072     * 
073     *       The important difference between Order and Preference is that once
074     *       a match is found the client MUST NOT consider records with a
075     *       different Order but they MAY process records with the same Order
076     *       but different Preferences.  The only exception to this is noted in
077     *       the second important Note in the DDDS algorithm specification
078     *       concerning allowing clients to use more complex Service
079     *       determination between steps 3 and 4 in the algorithm.  Preference
080     *       is used to give communicate a higher quality of service to rules
081     *       that are considered the same from an authority standpoint but not
082     *       from a simple load balancing standpoint.
083     * 
084     *       It is important to note that DNS contains several load balancing
085     *       mechanisms and if load balancing among otherwise equal services
086     *       should be needed then methods such as SRV records or multiple A
087     *       records should be utilized to accomplish load balancing.
088     * 
089     *    FLAGS
090     *       A <character-string> containing flags to control aspects of the
091     *       rewriting and interpretation of the fields in the record.  Flags
092     *       are single characters from the set A-Z and 0-9.  The case of the
093     *       alphabetic characters is not significant.  The field can be empty.
094     * 
095     *       It is up to the Application specifying how it is using this
096     *       Database to define the Flags in this field.  It must define which
097     *       ones are terminal and which ones are not.
098     * 
099     *    SERVICES
100     *       A <character-string> that specifies the Service Parameters
101     *       applicable to this this delegation path.  It is up to the
102     *       Application Specification to specify the values found in this
103     *       field.
104     * 
105     *    REGEXP
106     *       A <character-string> containing a substitution expression that is
107     *       applied to the original string held by the client in order to
108     *       construct the next domain name to lookup.  See the DDDS Algorithm
109     *       specification for the syntax of this field.
110     * 
111     *       As stated in the DDDS algorithm, The regular expressions MUST NOT
112     *       be used in a cumulative fashion, that is, they should only be
113     *       applied to the original string held by the client, never to the
114     *       domain name produced by a previous NAPTR rewrite.  The latter is
115     *       tempting in some applications but experience has shown such use to
116     *       be extremely fault sensitive, very error prone, and extremely
117     *       difficult to debug.
118     * 
119     *    REPLACEMENT
120     *       A <domain-name> which is the next domain-name to query for
121     *       depending on the potential values found in the flags field.  This
122     *       field is used when the regular expression is a simple replacement
123     *       operation.  Any value in this field MUST be a fully qualified
124     *       domain-name.  Name compression is not to be used for this field.
125     * 
126     *       This field and the REGEXP field together make up the Substitution
127     *       Expression in the DDDS Algorithm.  It is simply a historical
128     *       optimization specifically for DNS compression that this field
129     *       exists.  The fields are also mutually exclusive.  If a record is
130     *       returned that has values for both fields then it is considered to
131     *       be in error and SHOULD be either ignored or an error returned.
132     * 
133     * @author <a href="mailto:dev@directory.apache.org">Apache Directory Project</a>
134     * @version $Rev: 501160 $, $Date: 2007-01-29 20:41:33 +0100 (Mon, 29 Jan 2007) $
135     */
136    public class NameAuthorityPointerEncoder
137    {
138    }