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 E. Guttman
Request for Comments: 3224 Sun Microsystems
Updates: <a href="./rfc2608">2608</a> January 2002
Category: Standards Track
<span class="h1">Vendor Extensions for Service Location Protocol, Version 2</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 Internet Society (2002). All Rights Reserved.
Abstract
This document specifies how the features of the Service Location
Protocol, Version 2 allow for vendor extensibility safely, with no
possibility of collisions. The specification introduces a new SLPv2
extension: The Vendor Opaque Extension. While proprietary protocol
extensions are not encouraged by IETF standards, it is important that
they not hinder interoperability of compliant implementations when
they are undertaken. This document udpates <a href="./rfc2608">RFC 2608</a>, "The Service
Location Protocol."
Table of Contents
<a href="#section-1.0">1.0</a> Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-1.1">1.1</a> Terminology . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-2.0">2.0</a> Enterprise Numbers . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3.0">3.0</a> Naming Authorities . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-4.0">4.0</a> Vendor Defined Attributes . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-5.0">5.0</a> Vendor Opaque Extension . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-5.1">5.1</a> Vendor Opaque Extension Format . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5.2">5.2</a> Example: Acme Extension for UA Authentication . . . . . . . <a href="#page-6">6</a>
<a href="#section-6.0">6.0</a> Extensions Requiring IETF Action . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-7.0">7.0</a> IANA Considerations . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-8.0">8.0</a> Security Considerations . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<span class="grey">Guttman Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc3224">RFC 3224</a> Vendor Extensions for Service January 2002</span>
<span class="h3"><a class="selflink" id="section-1.0" href="#section-1.0">1.0</a> Introduction</span>
The Service Location Protocol, Version 2 [<a href="#ref-1" title=""Service Location Protocol, Version 2"">1</a>] defines a number of
features which are extensible. This document clarifies exactly which
mechanisms can be used to that end (Sections <a href="#section-3">3</a>-<a href="#section-5">5</a>) and which cannot
(<a href="#section-6">Section 6</a>). This document updates [<a href="#ref-1" title=""Service Location Protocol, Version 2"">1</a>], specifying conventions that
ensure the protocol extension mechanisms in the SLPv2 specification
will not possibly have ambiguous interpretations.
This specification introduces only one new protocol element, the
Vendor Opaque Extension. This Extension makes it possible for a
vendor to extend SLP independently, once the vendor has registered
itself with IANA and obtained an Enterprise Number. This is useful
for vendor-specific applications.
Vendor extensions to standard protocols come at a cost.
- Vendor extensions occur without review from the community.
They may not make good engineering sense in the context of the
protocol they extend, and the engineers responsible may
discover this too late.
- Vendor extensions preclude interoperation with compliant but
non-extended implementations. There is a real danger of
incompatibility if different implementations support different
feature sets.
- By extending SLPv2 privately, ubiquitous automatic
configuration is impossible, which is the primary benefit of a
standard service discovery framework.
For these reasons, registration of service templates with IANA is
strongly encouraged! This process is easy and has proved to be rapid
(taking less than 2 weeks in most cases).
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a> Terminology</span>
In this document, the key words "MAY", "MUST", "MUST NOT",
"optional", "recommended", "SHOULD", and "SHOULD NOT", are to be
interpreted as described in [<a href="#ref-2" title=""Key words for use in RFCs to Indicate Requirement Levels"">2</a>].
Service Location Protocol terminology is defined in [<a href="#ref-1" title=""Service Location Protocol, Version 2"">1</a>]. IANA
registration terminology is defined in [<a href="#ref-5" title="">5</a>].
<span class="grey">Guttman Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc3224">RFC 3224</a> Vendor Extensions for Service January 2002</span>
<span class="h3"><a class="selflink" id="section-2.0" href="#section-2.0">2.0</a> Enterprise Number</span>
Enterprise Numbers are used to distinguish different vendors in IETF
protocols. Vendor Extensions to SLPv2 SHOULD use these values to
avoid any possibility of a name space collision. Each vendor is
responsible for ensuring that vendor extensions under their own
authority are non-conflicting.
IANA maintains a repository of all 'SMI Network Management Private
Enterprise Codes,' whose prefix is
iso.org.dod.internet.private.enterprise (1.3.6.1.4.1). The number
which follows is unique and may be registered by an on-line form [<a href="#ref-3">3</a>].
The complete up-to-date list of Enterprise Numbers is maintained by
IANA [<a href="#ref-3">3</a>].
<span class="h3"><a class="selflink" id="section-3.0" href="#section-3.0">3.0</a> Naming Authorities</span>
Naming Authorities are defined by SLPv2 [<a href="#ref-1" title=""Service Location Protocol, Version 2"">1</a>] as an agency or group
which catalogues Service Types and attributes.
A Service Type is a string representing a service which can be
discovered by SLPv2. Attributes may be associated with a particular
Service Type which is advertised by SLPv2.
Service Type strings and service attributes may be registered with
IANA by creating a Service Template [<a href="#ref-4" title=""Service Templates and URLs"">4</a>]. The template is included in
an internet draft and an email message is sent to srvloc-
list@iana.org requesting that the template be included in the Service
Template registry. In this case, the naming authority for the
service type is IANA.
It is also possible for a Vendor to create their own naming
authority. In this case, any service type or attribute may be used.
SLPv2 allows arbitrary naming authorities to coexist. To use an
explicit naming authority, a vendor simply employs their Enterprise
Number as a naming authority. For example, for the following
(fictitious) Enterprise Number
9999 Acme, Inc. Erik Guttman femur@example.com
the Naming Authority string to use would be "9999". A service: URL
which used this Naming Authority to advertise a Roadrunner Detector
service could look like
service:roadrunner-detector.9999://example.com:9341
<span class="grey">Guttman Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc3224">RFC 3224</a> Vendor Extensions for Service January 2002</span>
Service types which are defined under a naming authority based on an
Enterprise Number are guaranteed not to conflict with other service
type strings which mean something entirely different. That is also
true of attributes defined for service types defined under a naming
authority.
To create a safe naming authority with no possibility of name
collisions, a vendor SHOULD use their Enterprise Number as a naming
authority.
<span class="h3"><a class="selflink" id="section-4.0" href="#section-4.0">4.0</a> Vendor Defined Attributes</span>
SLPv2 [<a href="#ref-1" title=""Service Location Protocol, Version 2"">1</a>] suggests that
Non-standard attribute names SHOULD begin with "x-", because no
standard attribute name will ever have those initial characters.
It is possible that two non-standard attributes will conflict that
both use the "x-" prefix notation. For that reason, vendors SHOULD
use "x-" followed by their Enterprise Number followed by a "-" to
guarantee that the non-standard attribute name's interpretation is
not ambiguous.
For example, Acme, Inc.'s Enterprise Number is 9999. Say the Service
Template for NetHive (a fictitious game) was:
------------------------------------------------------------
template-type=NetHive
template-version=1.0
template-description=
The popular NetHive game.
template-url-syntax=
url-path = ; There is no path for a NetHive service URL.
features= string M O
# The list of optional features the NetHive server supports.
secure session, fast mode
current-users= string M
# The list of users currently playing
------------------------------------------------------------
Acme's server advertises a feature which is not on the list of
standard features, "x-9999-cheat-mode". Only an Acme client would
request this attribute to discover servers, since it is not standard.
<span class="grey">Guttman Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc3224">RFC 3224</a> Vendor Extensions for Service January 2002</span>
<span class="h3"><a class="selflink" id="section-5.0" href="#section-5.0">5.0</a> Vendor Opaque Extension</span>
SLPv2 [<a href="#ref-1" title=""Service Location Protocol, Version 2"">1</a>] defines a protocol extensibility mechanism. SLPv2
Extensions are added at the end of a message and have the following
format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension ID | Next Extension Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset, contd.| Extension Data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the Extension Data depends on the Extension ID. Refer
to [<a href="#ref-4" title=""Service Templates and URLs"">4</a>] for a full description of different mechanisms available for
registration of values with IANA.
SLPv2 may be extended in any of three ways.
(1) Anyone may request the designated expert for SLP to register a
new extension ID with IANA. Send requests to the
svrloc-list@iana.org.
It is recommended that an internet draft specifying this
extension be published, with the intention of publishing the
document as an Informational RFC. This way others can use the
extension as well. This is not a 'vendor extension' - rather
this is the preferred way of extending the protocol in a vendor
neutral manner.
If no specification is published and the extension is intended
for vendor specific use only - the 'Vendor Extension' option
below probably makes more sense than assigning an extension ID.
(2) An experimental extension may be done using the range 0x8000 to
0x8FFF. There is always the risk, however, that another vendor
will use the same ID, since these IDs are not registered.
(3) A Vendor Extension may be used. This extension allows a Vendor
to define their own extensions which are guaranteed to have a
unique interpretation. It is OPTIONAL to implement.
<span class="grey">Guttman Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc3224">RFC 3224</a> Vendor Extensions for Service January 2002</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Vendor Opaque Extension Format</span>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension ID = 0x0003 | Next Extension Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset, contd.| Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ent. #, contd.| Extension Data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Enterprise Number is included in the Extension as a 4 byte
unsigned integer value. The Extension Data following is guaranteed
to have an unambiguous interpretation determined by the vendor.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a> Example: Acme Extension for UA Authentication</span>
The Acme Corporation, whose Enterprise Number is 9999, can define an
extension to SLP. In this example, Acme creates one such extension
to create an application level access control to service information.
This would allow replies to be sent only to clients who could
authenticate themselves.
The engineers at Acme give the Extension Data the following form:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ACME Ext ID = 1| Client ID Length | Client ID ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authenticator ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ACME Ext ID: The ACME engineers decided to define the first byte of
their extension data as an extension ID field. In the future, ACME
may decide to define more than this extension. Since there is 8 bits
in the ID field, ACME can define up to 256 different extensions. If
ACME were to omit this field and begin directly with their 'Extension
for UA Authentication', they would only be able to define one ACME
specific SLP extension. For the 'Extension for UA Authentication,'
the ACME Extension ID is set to 1. This ID has to be managed within
ACME, to make sure that each new extension they invent has a unique
ID assigned to it.
<span class="grey">Guttman Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc3224">RFC 3224</a> Vendor Extensions for Service January 2002</span>
Client ID Length: This declares how many bytes of Client ID data
follow.
Client ID: The Acme application user ID.
Timestamp: # of seconds since January 1, 2000, 0:00 GMT.
Authenticator: a 16 byte MD5 digest [<a href="#ref-6" title=""The MD5 Message-Digest Algorithm"">6</a>] calculated on the following
data fields, concatenated together
- UA request bytes, including the header, but not any extensions.
- UA SECRET PASS PHRASE
- Acme UA Authentication Extension - Client ID
- Acme UA Authentication Extension - Timestamp
The SA or DA which receives this extension and supports this
extension will check if it (1) recognizes the Client ID, (2) has an
associated SECRET PASS PHRASE for it, (3) whether upon calculating an
MD5 digest over the same data as listed above it arrives at the same
Authenticator value as included in the extension. If all 3 of these
steps succeed, the UA has been authenticated.
Note this example is for explanatory purposes only. It would not
work well in practice. It requires a shared secret be configured in
SAs and DAs, for every UA. Furthermore, the UA secret pass phrase
would be susceptible to a dictionary attack.
<span class="h3"><a class="selflink" id="section-6.0" href="#section-6.0">6.0</a> Extensions Requiring IETF Action</span>
Modification or extension of any feature of SLPv2 whatsoever, aside
from those listed in Sections <a href="#section-3">3</a>-<a href="#section-5">5</a> of this document, requires a
standards action as defined in [<a href="#ref-1" title=""Service Location Protocol, Version 2"">1</a>].
Terminology and procedures for IETF Actions related to registration
of IDs with IANA are defined in [<a href="#ref-5" title="">5</a>]. Existing SLPv2 extensions
assignments are registered with IANA [<a href="#ref-3">3</a>].
<span class="h3"><a class="selflink" id="section-7.0" href="#section-7.0">7.0</a> IANA Considerations</span>
This document clarifies procedures described in other documents [<a href="#ref-1" title=""Service Location Protocol, Version 2"">1</a>]
[<a href="#ref-4" title=""Service Templates and URLs"">4</a>]. The Vendor Opaque Extension ID has already been registered [<a href="#ref-3">3</a>].
No additional IANA action is required for publication of this
document.
<span class="grey">Guttman Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc3224">RFC 3224</a> Vendor Extensions for Service January 2002</span>
<span class="h3"><a class="selflink" id="section-8.0" href="#section-8.0">8.0</a> Security Considerations</span>
Vendor extensions may introduce additional security considerations
into SLP.
This memo describes mechanisms which are standardized elsewhere [<a href="#ref-1" title=""Service Location Protocol, Version 2"">1</a>]
[<a href="#ref-4" title=""Service Templates and URLs"">4</a>]. The only protocol mechanism described in this document (see
<a href="#section-5">Section 5</a> above) is no less secure than 'private use' extensions
defined in SLPv2 [<a href="#ref-1" title=""Service Location Protocol, Version 2"">1</a>].
The example in <a href="#section-5.2">Section 5.2</a> above shows how Vendor Opaque Extensions
can be used to include an access control mechanism to SLP so that SAs
can enforce an access control policy using an authentication
mechanism. This is merely an example and protocol details were
intentionally not provided. A vendor could, however, create a
mechanism similar to this one and provide additional security
services to SLPv2 in the manner indicated in the example.
Acknowledgements
I thank the IESG, for their usual persistence and attention to
detail.
References
[<a id="ref-1">1</a>] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
Location Protocol, Version 2", <a href="./rfc2608">RFC 2608</a>, July 1999.
[<a id="ref-2">2</a>] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-3">3</a>] <a href="http://www.iana.org/numbers.html">http://www.iana.org/numbers.html</a>
[<a id="ref-4">4</a>] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and
URLs", <a href="./rfc2609">RFC 2609</a>, July 1999.
[<a id="ref-5">5</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.
[<a id="ref-6">6</a>] Rivest, R., "The MD5 Message-Digest Algorithm", <a href="./rfc1321">RFC 1321</a>, April
1992.
<span class="grey">Guttman Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc3224">RFC 3224</a> Vendor Extensions for Service January 2002</span>
Author's Address
Erik Guttman
Sun Microsystems
Eichhoelzelstr. 7
74915 Waibstadt
Germany
Phone: +49 7263 911 701
Messages: +49 6221 356 202
EMail: erik.guttman@sun.com
<span class="grey">Guttman Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc3224">RFC 3224</a> Vendor Extensions for Service January 2002</span>
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Guttman Standards Track [Page 10]
</pre>
|
