View Javadoc

1   /*
2    *  Licensed to the Apache Software Foundation (ASF) under one
3    *  or more contributor license agreements.  See the NOTICE file
4    *  distributed with this work for additional information
5    *  regarding copyright ownership.  The ASF licenses this file
6    *  to you under the Apache License, Version 2.0 (the
7    *  "License"); you may not use this file except in compliance
8    *  with the License.  You may obtain a copy of the License at
9    *  
10   *    http://www.apache.org/licenses/LICENSE-2.0
11   *  
12   *  Unless required by applicable law or agreed to in writing,
13   *  software distributed under the License is distributed on an
14   *  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
15   *  KIND, either express or implied.  See the License for the
16   *  specific language governing permissions and limitations
17   *  under the License. 
18   *  
19   */
20  
21  package org.apache.directory.server.dns.io.encoder;
22  
23  
24  /**
25   * 4. NAPTR RR Format
26   * 
27   * 4.1 Packet Format
28   * 
29   *    The packet format of the NAPTR RR is given below.  The DNS type code
30   *    for NAPTR is 35.
31   * 
32   *       The packet format for the NAPTR record is as follows
33   *                                        1  1  1  1  1  1
34   *          0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
35   *        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
36   *        |                     ORDER                     |
37   *        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
38   *        |                   PREFERENCE                  |
39   *        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
40   *        /                     FLAGS                     /
41   *        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
42   *        /                   SERVICES                    /
43   *        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
44   *        /                    REGEXP                     /
45   *        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
46   *        /                  REPLACEMENT                  /
47   *        /                                               /
48   *        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
49   * 
50   *    <character-string> and <domain-name> as used here are defined in RFC
51   *    1035 [7].
52   * 
53   *    ORDER
54   *       A 16-bit unsigned integer specifying the order in which the NAPTR
55   *       records MUST be processed in order to accurately represent the
56   *       ordered list of Rules.  The ordering is from lowest to highest.
57   *       If two records have the same order value then they are considered
58   *       to be the same rule and should be selected based on the
59   *       combination of the Preference values and Services offered.
60   * 
61   *    PREFERENCE
62   *       Although it is called "preference" in deference to DNS
63   *       terminology, this field is equivalent to the Priority value in the
64   *       DDDS Algorithm.  It is a 16-bit unsigned integer that specifies
65   *       the order in which NAPTR records with equal Order values SHOULD be
66   *       processed, low numbers being processed before high numbers.  This
67   *       is similar to the preference field in an MX record, and is used so
68   *       domain administrators can direct clients towards more capable
69   *       hosts or lighter weight protocols.  A client MAY look at records
70   *       with higher preference values if it has a good reason to do so
71   *       such as not supporting some protocol or service very well.
72   * 
73   *       The important difference between Order and Preference is that once
74   *       a match is found the client MUST NOT consider records with a
75   *       different Order but they MAY process records with the same Order
76   *       but different Preferences.  The only exception to this is noted in
77   *       the second important Note in the DDDS algorithm specification
78   *       concerning allowing clients to use more complex Service
79   *       determination between steps 3 and 4 in the algorithm.  Preference
80   *       is used to give communicate a higher quality of service to rules
81   *       that are considered the same from an authority standpoint but not
82   *       from a simple load balancing standpoint.
83   * 
84   *       It is important to note that DNS contains several load balancing
85   *       mechanisms and if load balancing among otherwise equal services
86   *       should be needed then methods such as SRV records or multiple A
87   *       records should be utilized to accomplish load balancing.
88   * 
89   *    FLAGS
90   *       A <character-string> containing flags to control aspects of the
91   *       rewriting and interpretation of the fields in the record.  Flags
92   *       are single characters from the set A-Z and 0-9.  The case of the
93   *       alphabetic characters is not significant.  The field can be empty.
94   * 
95   *       It is up to the Application specifying how it is using this
96   *       Database to define the Flags in this field.  It must define which
97   *       ones are terminal and which ones are not.
98   * 
99   *    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 (Mo, 29 Jan 2007) $
135  */
136 public class NameAuthorityPointerEncoder
137 {
138 }