1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
|
<pre>Network Working Group L. Daigle
Request for Comments: 4848 Cisco Systems
Category: Standards Track April 2007
<span class="h1">Domain-Based Application Service Location Using URIs and</span>
<span class="h1">the Dynamic Delegation Discovery Service (DDDS)</span>
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The purpose of this document is to define a new, straightforward
Dynamic Delegation Discovery Service (DDDS) application to allow
mapping of domain names to URIs for particular application services
and protocols. Although defined as a new DDDS application, dubbed
U-NAPTR, this is effectively an extension of the Straightforward
NAPTR (S-NAPTR) DDDS Application.
<span class="grey">Daigle Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4848">RFC 4848</a> URI-Enabled NAPTR April 2007</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Straightforward URI-Enabled NAPTR (U-NAPTR) . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2.1">2.1</a>. Permitted Flags . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2.2">2.2</a>. Permitted Regular Expressions . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3">3</a>. Sample U-NAPTR DNS Records . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-4">4</a>. Formal Definition of U-NAPTR Application of DDDS . . . . . . . <a href="#page-5">5</a>
<a href="#section-4.1">4.1</a>. Application Unique String . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4.2">4.2</a>. First Well Known Rule . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4.3">4.3</a>. Expected Output . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4.4">4.4</a>. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4.5">4.5</a>. Service Parameters . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4.5.1">4.5.1</a>. Application Services . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4.5.2">4.5.2</a>. Application Protocols . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4.6">4.6</a>. Valid Rules . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4.7">4.7</a>. Valid Databases . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-5">5</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-6">6</a>. Security Considerations . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-7">7</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-8">8</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-8.1">8.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-8.2">8.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<span class="grey">Daigle Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4848">RFC 4848</a> URI-Enabled NAPTR April 2007</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The purpose of this document is to define a new, straightforward
Dynamic Delegation Discovery Service (DDDS) [<a href="#ref-7" title=""Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS"">7</a>] application to allow
mapping of domain names to URIs for particular application services
and protocols. This allows the "lookup" of particular services
available for given domains, for example.
Although this is defining a new and separate DDDS Application, dubbed
U-NAPTR, it is built from the same principles as the Straightforward
NAPTR (S-NAPTR) application, specified in [<a href="#ref-2" title=""Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)"">2</a>]. This specification is
not an update of S-NAPTR, but the reader is encouraged to review that
document for extensive coverage of motivation and implementation
considerations.
S-NAPTR provides for application service location that does not rely
on rigid domain naming conventions. It is deemed "straightforward"
in part because it rules out the use of regular expressions in NAPTR
records (for the S-NAPTR DDDS Application). However, that also rules
out the possibility of providing a URI as the target of DDDS
resolution. A number of applications, specified (e.g., [<a href="#ref-9" title=""Attaching Meaning to Solicitation Class Keywords"">9</a>]) and
proposed, find the restriction too limiting, making S-NAPTR a near
miss to suit their needs.
This U-NAPTR is effectively a modest extension to S-NAPTR, to
accommodate the use of URIs as targets, without allowing the full
range of possible regular expressions in NAPTR records.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Straightforward URI-Enabled NAPTR (U-NAPTR)</span>
This document assumes the reader is familiar with the S-NAPTR
specification [<a href="#ref-2" title=""Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)"">2</a>]. The intention of U-NAPTR is to provide everything
that S-NAPTR does, except that it allows the use of the "U" flag in
the NAPTR record, and a specific form of REGEXP.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Permitted Flags</span>
U-NAPTR permits the same flags as S-NAPTR ("S", "A", or empty), plus
the "U" Flag. For the U-NAPTR DDDS Application, the presence of the
"U" Flag in the NAPTR record indicates the REGEXP field must be
populated (and, consequently, the REPLACEMENT field is empty). The
regular expression in the REGEXP field must be of the limited form
described below, and the result of the regular expression evaluation
will be a URI that is the result of the DDDS resolution.
<span class="grey">Daigle Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4848">RFC 4848</a> URI-Enabled NAPTR April 2007</span>
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Permitted Regular Expressions</span>
U-NAPTR permits regular expressions of a form that does a complete
replacement of the matched string with a URI, expressed as a constant
string. This is essentially a dodge around the fact that the
REPLACEMENT field in NAPTR is required to produce only a fully
qualified domain name (and, therefore, cannot be used for a URI).
The specific allowed syntax for U-NAPTR regular expressions is:
u-naptr-regexp = "!.*!"<URI>"!"
where <URI> is as defined in STD 66 [<a href="#ref-8" title=""Uniform Resource Identifier (URI): Generic Syntax"">8</a>], the URI syntax
specification.
With this limited form of regular expression, applications using
U-NAPTR need not implement full regular expression parsers.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Sample U-NAPTR DNS Records</span>
In the sample NAPTR RRs for example.com shown below, "WP" is the
imagined application service tag for "white pages", and "EM" is the
application service tag for an imagined "Extensible Messaging"
application service.
example.com.
;; order pref flags
IN NAPTR 100 10 "" "WP:whois++" ( ; service
"" ; regexp
bunyip.example.com. ; replacement
)
IN NAPTR 100 20 "s" "WP:ldap" ( ; service
"" ; regexp
_ldap._tcp.myldap.example.com. ; replacement
)
IN NAPTR 200 10 "u" "EM:protA" ( ; service
"!.*!prota://someisp.example.com!" ; regexp
"" ; replacement
)
IN NAPTR 200 30 "a" "EM:protB" ; service
"" ; regexp
myprotB.example.com.; replacement
)
<span class="grey">Daigle Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4848">RFC 4848</a> URI-Enabled NAPTR April 2007</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Formal Definition of U-NAPTR Application of DDDS</span>
This section formally defines the DDDS Application, as described in
[<a href="#ref-7" title=""Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS"">7</a>].
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Application Unique String</span>
The Application Unique String is a fully qualified domain name (FQDN)
for which an authoritative server for a particular service is sought.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. First Well Known Rule</span>
The "First Well Known Rule" is identity -- that is, the output of the
rule is the Application Unique String, the FQDN for which the
authoritative server for a particular service is sought.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Expected Output</span>
The expected output of this Application is the information necessary
to connect to authoritative server(s) (host, port, protocol, or URI)
for an application service within a given domain.
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. Flags</span>
This DDDS Application uses only 3 of the Flags defined for the URI/
URN Resolution Application [<a href="#ref-5" title=""Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)"">5</a>]: "S", "A", and "U". No other Flags
are valid. If a client obtains a NAPTR RR for a U-NAPTR-using
application that contains any other flag, that NAPTR RR should be
ignored and processing continues with the next record (if any).
These flags are for terminal lookups. This means that the Rule is
the last one and that the flag determines what the next stage should
be. The "S" flag means that the output of this Rule is a FQDN for
which one or more SRV [<a href="#ref-3" title=""A DNS RR for specifying the location of services (DNS SRV)"">3</a>] records exist. "A" means that the output
of the Rule is a domain name and should be used to lookup address
records for that domain. "U" means that the output of the Rule is a
URI that should be resolved in order to obtain access to the
described service.
Consistent with the DDDS algorithm, if the Flag string is empty the
next lookup is for another NAPTR record (for the replacement target).
<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>. Service Parameters</span>
Service Parameters for this Application take the form of a string of
characters that follow this ABNF [<a href="#ref-1" title=""Augmented BNF for Syntax Specifications: ABNF"">1</a>]:
<span class="grey">Daigle Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4848">RFC 4848</a> URI-Enabled NAPTR April 2007</span>
service-parms = [ [app-service] *(":" app-protocol)]
app-service = experimental-service / iana-registered-service
app-protocol = experimental-protocol / iana-registered-protocol
experimental-service = "x-" 1*30ALPHANUMSYM
experimental-protocol = "x-" 1*30ALPHANUMSYM
iana-registered-service = ALPHA *31ALPHANUMSYM
iana-registered-protocol = ALPHA *31ALPHANUMSYM
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9
SYM = %x2B / %x2D / %x2E ; "+" / "-" / "."
ALPHANUMSYM = ALPHA / DIGIT / SYM
; The app-service and app-protocol tags are limited to 32
; characters and must start with an alphabetic character.
; The service-parms are considered case-insensitive.
Thus, the Service Parameters may consist of an empty string, just an
app-service, or an app-service with one or more app-protocol
specifications separated by the ":" symbol.
Note that this is similar to, but not the same as the syntax used in
the URI DDDS application [<a href="#ref-5" title=""Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)"">5</a>]. The DDDS DNS database requires each
DDDS application to define the syntax of allowable service strings.
The syntax here is expanded to allow the characters that are valid in
any URI scheme name (see [<a href="#ref-8" title=""Uniform Resource Identifier (URI): Generic Syntax"">8</a>]). Since "+" (the separator used in the
<a href="./rfc3404">RFC3404</a> service parameter string) is an allowed character for URI
scheme names, ":" is chosen as the separator here.
<span class="h4"><a class="selflink" id="section-4.5.1" href="#section-4.5.1">4.5.1</a>. Application Services</span>
The "app-service" must be an IANA-registered service; see <a href="#section-5">Section 5</a>
for instructions on registering new application service tags.
<span class="h4"><a class="selflink" id="section-4.5.2" href="#section-4.5.2">4.5.2</a>. Application Protocols</span>
The protocol identifiers that are valid for the "app-protocol"
production are standard, registered protocols; see <a href="#section-5">Section 5</a> for
instructions on registering new application protocol tags.
<span class="h3"><a class="selflink" id="section-4.6" href="#section-4.6">4.6</a>. Valid Rules</span>
Permitted rules are substitution rules and regular expressions of the
following syntax (i.e., a regular expression to replace the domain
name with a URI):
u-naptr-regexp = "!.*!"<URI>"!"
where <URI> is as defined in STD 66 [<a href="#ref-8" title=""Uniform Resource Identifier (URI): Generic Syntax"">8</a>], the URI syntax
specification.
<span class="grey">Daigle Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4848">RFC 4848</a> URI-Enabled NAPTR April 2007</span>
<span class="h3"><a class="selflink" id="section-4.7" href="#section-4.7">4.7</a>. Valid Databases</span>
At present, only one DDDS Database is specified for this Application.
[<a href="#ref-4" title=""Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database"">4</a>] specifies a DDDS Database that uses the NAPTR DNS resource record
to contain the rewrite rules. The Keys for this database are encoded
as domain names.
The First Well Known Rule produces a domain name, and this is the Key
that is used for the first lookup -- the NAPTR records for that
domain are requested.
DNS servers MAY interpret Flag values and use that information to
include appropriate NAPTR, SRV, or A records in the Additional
Information portion of the DNS packet. Clients are encouraged to
check for additional information but are not required to do so. See
the Additional Information Processing section of [<a href="#ref-4" title=""Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database"">4</a>] for more
information on NAPTR records and the Additional Information section
of a DNS response packet.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. IANA Considerations</span>
This document does not itself place any requirements on IANA, but
provides the basis upon which U-NAPTR-using services can make use of
the existing IANA registries for application service tags and
application protocol tags (defined in <a href="./rfc3958">RFC 3958</a> [<a href="#ref-2" title=""Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)"">2</a>]).
As is the case for S-NAPTR, all application service and protocol tags
that start with "x-" are considered experimental, and no provision is
made to prevent duplicate use of the same string. Use them at your
own risk.
All other application service and protocol tags are registered based
on the "specification required" option defined in [<a href="#ref-6" title="">6</a>], with the
further stipulation that the "specification" is an RFC (of any
category).
There are no further restrictions placed on the tags other than that
they must conform with the syntax defined above (<a href="#section-4.5">Section 4.5</a>).
The defining RFC must clearly identify and describe, for each tag
being registered:
o Application protocol or service tag
o Intended usage
o Interoperability considerations
<span class="grey">Daigle Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4848">RFC 4848</a> URI-Enabled NAPTR April 2007</span>
o Security considerations (see <a href="#section-6">Section 6</a> of this document for
further discussion of the types of considerations that are
applicable)
o Any relevant related publications
The defining RFC may also include further application-specific
restrictions, such as limitations on the types of URIs that may be
returned for the application service.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
U-NAPTR has the same considerations for security as S-NAPTR; see
Section 8 of [<a href="#ref-2" title=""Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)"">2</a>]. U-NAPTR has the additional consideration that
resolving URIs (from the result of the DDDS resolution) has its own
set of security implications, covered in the URI specification (in
particular, Section 7 of [<a href="#ref-8" title=""Uniform Resource Identifier (URI): Generic Syntax"">8</a>]). In essence, using DNSSEC, client
software can be confident that the URI obtained using U-NAPTR is
indeed the one specified by the administrator of the domain from
which it was retrieved; but the validity of the service reached by
resolving that URI is a matter of URI resolution security practices.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Acknowledgements</span>
Thanks to Martin Thomson, John Klensin, Bernard Aboba, Alfred Hoenes,
Dan Romascanu, Suresh Krishnan, and Lars Eggert for reviewing earlier
versions and catching errors!
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Normative References</span>
[<a id="ref-1">1</a>] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", <a href="./rfc4234">RFC 4234</a>, October 2005.
[<a id="ref-2">2</a>] Daigle, L. and A. Newton, "Domain-Based Application Service
Location Using SRV RRs and the Dynamic Delegation Discovery
Service (DDDS)", <a href="./rfc3958">RFC 3958</a>, January 2005.
[<a id="ref-3">3</a>] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", <a href="./rfc2782">RFC 2782</a>,
February 2000.
[<a id="ref-4">4</a>] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Three: The Domain Name System (DNS) Database", <a href="./rfc3403">RFC 3403</a>,
October 2002.
<span class="grey">Daigle Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4848">RFC 4848</a> URI-Enabled NAPTR April 2007</span>
[<a id="ref-5">5</a>] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Four: The Uniform Resource Identifiers (URI)", <a href="./rfc3404">RFC 3404</a>,
October 2002.
[<a id="ref-6">6</a>] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc2434">RFC 2434</a>, October 1998.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-7">7</a>] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
One: The Comprehensive DDDS", <a href="./rfc3401">RFC 3401</a>, October 2002.
[<a id="ref-8">8</a>] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", <a href="./rfc3986">RFC 3986</a>, STD 66,
January 2005.
[<a id="ref-9">9</a>] Malamud, C., "Attaching Meaning to Solicitation Class Keywords",
<a href="./rfc4095">RFC 4095</a>, May 2005.
Author's Address
Leslie L. Daigle
Cisco Systems
13615 Dulles Technology Drive
Herndon, VA 20171
US
EMail: ledaigle@cisco.com; leslie@thinkingcat.com
<span class="grey">Daigle Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4848">RFC 4848</a> URI-Enabled NAPTR April 2007</span>
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Daigle Standards Track [Page 10]
</pre>
|
