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
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
|
<pre>Network Working Group S. Hollenbeck
Request for Comments: 3735 VeriSign, Inc.
Category: Informational March 2004
<span class="h1">Guidelines for Extending the Extensible Provisioning Protocol (EPP)</span>
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
The Extensible Provisioning Protocol (EPP) is an application layer
client-server protocol for the provisioning and management of objects
stored in a shared central repository. Specified in XML, the
protocol defines generic object management operations and an
extensible framework that maps protocol operations to objects. This
document presents guidelines for use of EPP's extension mechanisms to
define new features and object management capabilities.
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-1.1">1.1</a>. Conventions Used In This Document. . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-2">2</a>. Principles of Protocol Extension . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2.1">2.1</a>. Documenting Extensions . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2.2">2.2</a>. Identifying Extensions . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2.2.1">2.2.1</a>. Standards Track Extensions . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2.2.2">2.2.2</a>. Other Extensions . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-2.3">2.3</a>. Extension Announcement and Selection . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-2.4">2.4</a>. Protocol-level Extension . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-2.5">2.5</a>. Object-level Extension . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-2.6">2.6</a>. Command-Response Extension . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-2.7">2.7</a>. Authentication Information Extension . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3">3</a>. Selecting an Extension Mechanism . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-3.1">3.1</a>. Mapping and Extension Archives . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-4">4</a>. Internationalization Considerations . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-5">5</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-6">6</a>. Security Considerations . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-7">7</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-7.1">7.1</a>. Normative References . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<span class="grey">Hollenbeck Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc3735">RFC 3735</a> Guidelines for Extending the EPP March 2004</span>
<a href="#section-7.2">7.2</a>. Informative References . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-8">8</a>. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-9">9</a>. Author's Address . . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-10">10</a>. Full Copyright Statement . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The Extensible Provisioning Protocol (EPP, [<a href="#ref-2" title=""Extensible Provisioning Protocol (EPP)"">2</a>]) was originally
designed to provide a standard Internet domain name registration
protocol for use between Internet domain name registrars and domain
name registries. However, specific design decisions were made to
ensure that the protocol could also be used in other provisioning
environments. Specifically:
o Extensibility has been a design goal from the very beginning. EPP
is represented in the Extensible Markup Language (XML, [<a href="#ref-3" title=""Extensible Markup Language (XML) 1.0 (2nd ed)"">3</a>]), and
is specified in XML Schema ([<a href="#ref-4" title=""XML Schema Part 1: Structures"">4</a>] and [<a href="#ref-5" title=""XML Schema Part 2: Datatypes"">5</a>]) with XML namespaces [<a href="#ref-6" title=""Namespaces in XML"">6</a>]
used to identify protocol grammars.
o The EPP core protocol specification describes general protocol
functions, not objects to be managed by the protocol. Managed
object definitions, such as the mapping for Internet domain names
[<a href="#ref-10" title=""Extensible Provisioning Protocol (EPP) Domain Name Mapping"">10</a>] (itself a protocol extension), are loosely coupled to the
core specification.
o A concentrated effort was made to separate required minimum
protocol functionality from object management operating logic.
o Several extension mechanisms were included to allow designers to
add new features or to customize existing features for different
operating environments.
This document describes EPP's extensibility features in detail and
provides guidelines for their use. Though written specifically for
protocol designers considering EPP as the solution to a provisioning
problem, anyone interested in using XML to represent IETF protocols
might find these guidelines useful.
XML is case sensitive. Unless stated otherwise, XML instances and
examples provided in this document MUST be interpreted in the
character case presented to develop a conforming implementation.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Conventions Used In This Document</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <a href="./rfc2119">RFC 2119</a> [<a href="#ref-1" title=""Key words for use in RFCs to Indicate Requirement Levels"">1</a>].
<span class="grey">Hollenbeck Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc3735">RFC 3735</a> Guidelines for Extending the EPP March 2004</span>
In examples, "C:" represents lines sent by a protocol client and "S:"
represents lines returned by a protocol server. Indentation and
white space in examples is provided only to illustrate element
relationships and is not a REQUIRED feature of this specification.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Principles of Protocol Extension</span>
The EPP extension model is based on the XML representation for a
wildcard schema component using an <any> element information item (as
described in section 3.10.2 of [<a href="#ref-4" title=""XML Schema Part 1: Structures"">4</a>]) and XML namespaces [<a href="#ref-6" title=""Namespaces in XML"">6</a>]. This
section provides guidelines for the development of protocol
extensions and describes the extension model in detail.
Extending a protocol implies the addition of features without
changing the protocol itself. In EPP that means that an extension
MUST NOT alter an existing protocol schema as changes may result in
new versions of an existing schema, not extensions of an existing
schema. For example, a designer MUST NOT add new elements to an
existing schema and call the result an "extension" of the protocol.
The result is a new, non-backwards-compatible version of an existing
schema. Extensions MUST adhere to the principles described in this
section to be considered valid protocol extensions.
EPP extensions MUST be specified in XML. This ensures that parsers
capable of processing EPP structures will also be capable of
processing EPP extensions. Guidelines for the use of XML in IETF
protocols (thus good information for extension designers) can be
found in <a href="./rfc3470">RFC 3470</a> [<a href="#ref-11" title=""Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols"">11</a>].
A designer MUST remember that extensions themselves MAY also be
extensible. A good chain of extensions is one in which the protocol
schemas evolve from general functionality to more specific (perhaps
even more limited) functionality.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Documenting Extensions</span>
The EPP core specification [<a href="#ref-2" title=""Extensible Provisioning Protocol (EPP)"">2</a>] has an appendix that contains a
suggested outline to document protocol extensions. Designers are
free to use this template or any other format as they see fit, but
the extension document SHOULD at a minimum address all of the topics
listed in the template.
Extension designers need to consider the intended audience and
consumers of their extensions. Extensions MAY be documented as
Internet-Draft and RFC documents if the designer is facing
requirements for coordination, interoperability, and broad
distribution, though the intended maturity level (informational,
proposed standard, etc.) largely depends on what is being extended
<span class="grey">Hollenbeck Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc3735">RFC 3735</a> Guidelines for Extending the EPP March 2004</span>
and the amount of general interest in the extension. An extension to
a standards-track specification with broad interest might well be a
candidate for standards track publication, whereas an extension to a
standards track specification with limited interest might be better
suited for informational publication.
Extensions need not be published as Internet-Draft or RFC documents
if they are intended for operation in a closed environment or are
otherwise intended for a limited audience. In such cases extensions
MAY be documented in a file and structural format that is appropriate
for the intended audience.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Identifying Extensions</span>
An EPP extension is uniquely identified by a Uniform Resource
Identifier (URI, defined in <a href="./rfc2396">RFC 2396</a> [<a href="#ref-7" title=""Uniform Resource Identifiers (URI): Generic Syntax"">7</a>]). The URI used to identify
the extension MUST also be used to identify the XML namespace
associated with the extension. Any valid URI MAY be used to identify
an EPP extension, though the selection of a URI form (Uniform
Resource Locator (URL) vs. Uniform Resource Name (URN), hierarchical
vs. relative, etc.) SHOULD depend on factors such as organizational
policies on change control and a balance between locating resources
and requirements for persistence. An extension namespace MAY
describe multiple extension mechanisms, such as definition of new
protocol features, objects, or elements, within the schema used to
define the namespace.
The following are sample extension-identifying URIs:
urn:ietf:params:xml:ns:foo-ext1
<a href="http://custom/obj1ext-1.0">http://custom/obj1ext-1.0</a>
Extension designers MAY include version information in the URI used
to identify an extension. If version information is included in the
URI, the URI itself will need to change as the extension is revised
or updated.
<span class="h4"><a class="selflink" id="section-2.2.1" href="#section-2.2.1">2.2.1</a>. Standards Track Extensions</span>
URIs for extensions intended for IETF standards track use MUST
conform to the URN syntax specifications and registration procedures
described in [<a href="#ref-8" title=""The IETF XML Registry"">8</a>].
<span class="grey">Hollenbeck Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc3735">RFC 3735</a> Guidelines for Extending the EPP March 2004</span>
<span class="h4"><a class="selflink" id="section-2.2.2" href="#section-2.2.2">2.2.2</a>. Other Extensions</span>
URIs for extensions that are not intended for IETF standards track
use MUST conform to the URI syntax specifications described in <a href="./rfc2396">RFC</a>
<a href="./rfc2396">2396</a>.
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Extension Announcement and Selection</span>
An EPP server MUST announce extensions that are available for client
use as part of a <greeting> element that is sent to a client before
the client establishes an interactive session with the server. The
<greeting> element contains zero or more <svcExtension> elements
that, if present, contain a URI identifying an available extension:
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
S: epp-1.0.xsd">
S: <greeting>
S: <svID>Example EPP server epp.example.com</svID>
S: <svDate>2000-06-08T22:00:00.0Z</svDate>
S: <svcMenu>
S: <version>1.0</version>
S: <lang>en</lang>
S: <lang>fr</lang>
S: <objURI>urn:ietf:params:xml:ns:obj1</objURI>
S: <objURI>urn:ietf:params:xml:ns:obj2</objURI>
S: <objURI>urn:ietf:params:xml:ns:obj3</objURI>
S: <svcExtension>
S: <extURI>urn:ietf:params:xml:ns:foo-ext1</extURI>
S: <extURI>http://custom/obj1ext-1.0</extURI>
S: </svcExtension>
S: </svcMenu>
S: <dcp>
S: <access><all/></access>
S: <statement>
S: <purpose><admin/><prov/></purpose>
S: <recipient><ours/><public/></recipient>
S: <retention><stated/></retention>
S: </statement>
S: </dcp>
S: </greeting>
S:</epp>
In the example above, the server is announcing the availability of
two extensions:
<span class="grey">Hollenbeck Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc3735">RFC 3735</a> Guidelines for Extending the EPP March 2004</span>
urn:ietf:params:xml:ns:foo-ext1, and
<a href="http://custom/obj1ext-1.0">http://custom/obj1ext-1.0</a>
An EPP client MUST establish a session with an EPP server using the
EPP <login> command before attempting to use any standard commands or
extensions. The <login> command contains zero or more <svcExtension>
elements that, if present, contain a URI identifying an available
extension that the client wishes to use during the course of the
session:
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
C: epp-1.0.xsd">
C: <command>
C: <login>
C: <clID>ClientX</clID>
C: <pw>foo-BAR2</pw>
C: <newPW>bar-FOO2</newPW>
C: <options>
C: <version>1.0</version>
C: <lang>en</lang>
C: </options>
C: <svcs>
C: <objURI>urn:ietf:params:xml:ns:obj1</objURI>
C: <objURI>urn:ietf:params:xml:ns:obj2</objURI>
C: <objURI>urn:ietf:params:xml:ns:obj3</objURI>
C: <svcExtension>
C: <extURI>http://custom/obj1ext-1.0</extURI>
C: </svcExtension>
C: </svcs>
C: </login>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
In the example above, the client indicates that it wishes to use an
extension identified by the <a href="http://custom/obj1ext-1.0">http://custom/obj1ext-1.0</a> URI during the
session established upon successful completion of the <login>
command.
An EPP server MUST announce all extensions that are publicly
available for client use. An EPP client MUST NOT request an
extension that has not been announced by the server. An EPP server
MAY restrict a client's ability to select an extension based on a
client's identity and authorizations granted by the server operator.
<span class="grey">Hollenbeck Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc3735">RFC 3735</a> Guidelines for Extending the EPP March 2004</span>
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. Protocol-level Extension</span>
EPP defines a set of structures for client-server command-response
interaction, but additional structures MAY be added to the protocol.
New structure definition is a matter of defining a schema for the
structures that defines needed functionality and assigning a URI to
uniquely identify the object namespace and schema. Specific
protocol-level extension mechanisms are described in <a href="#section-2.7.1">section 2.7.1</a> of
the EPP core protocol specification [<a href="#ref-2" title=""Extensible Provisioning Protocol (EPP)"">2</a>].
<span class="h3"><a class="selflink" id="section-2.5" href="#section-2.5">2.5</a>. Object-level Extension</span>
EPP commands and responses do not contain attributes that are
specific to any managed object. Every command and response MUST
contain elements bound to an object namespace. Object definition is
a matter of defining a schema for the object that defines
functionality for each needed command and associated response, and
assigning a URI to uniquely identify the object namespace and schema.
Specific object-level extension mechanisms are described in <a href="#section-2.7.2">section</a>
<a href="#section-2.7.2">2.7.2</a> of the EPP core protocol specification [<a href="#ref-2" title=""Extensible Provisioning Protocol (EPP)"">2</a>].
<span class="h3"><a class="selflink" id="section-2.6" href="#section-2.6">2.6</a>. Command-Response Extension</span>
EPP command and response structures defined in existing object
mappings MAY also be extended. For example, an object mapping that
describes general functionality for the provisioning of Internet
domain names can be extended to included additional command and
response elements needed for the provisioning of domain names that
represent E.164 telephone numbers [<a href="#ref-12" title=""Extensible Provisioning Protocol E.164 Number Mapping"">12</a>]. Specific command-response
extension mechanisms are described in <a href="#section-2.7.3">section 2.7.3</a> of the EPP core
protocol specification [<a href="#ref-2" title=""Extensible Provisioning Protocol (EPP)"">2</a>].
<span class="h3"><a class="selflink" id="section-2.7" href="#section-2.7">2.7</a>. Authentication Information Extension</span>
Some EPP object mappings, such as the Internet domain name mapping
[<a href="#ref-10" title=""Extensible Provisioning Protocol (EPP) Domain Name Mapping"">10</a>], include elements to associate authentication information (such
as a password) with an object. The schema for any object mapping
that supports authentication information SHOULD be flexible enough to
specify multiple forms of authentication information. With XML
Schema ([<a href="#ref-4" title=""XML Schema Part 1: Structures"">4</a>] and [<a href="#ref-5" title=""XML Schema Part 2: Datatypes"">5</a>]), this can be accomplished by offering an element
choice that includes an <any> element information item:
<any namespace="##other"/>
<span class="grey">Hollenbeck Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc3735">RFC 3735</a> Guidelines for Extending the EPP March 2004</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Selecting an Extension Mechanism</span>
Extensibility is a powerful feature of XML, but it also provides
multiple opportunities to make poor design decisions. There are
typically several different ways to accomplish a single task, and
while all may "work" (for some definition of "work") one extension
form will usually be more appropriate than others to complete a given
task. The following sequence of steps can be followed to select an
appropriate extension form to solve an extension problem:
o Command-Response Extension: Adding elements to an existing object
mapping is the simplest form of extension available, and is thus
the form that should be explored before any other form is
considered. The first question to ask when considering an
extension form is thus:
Can the task be accomplished by adding to an existing object
mapping or changing an existing object mapping slightly?
If the answer to this question is "yes", you should consider
extending an existing object mapping to complete your task.
Knowing where to find object mappings is critical to being able to
answer this question; see section <a href="#section-3.1">Section 3.1</a> for information
describing mapping archives. If the answer to this question is
"no", consider an object-level extension next.
o Object-level Extension: If there is no existing object mapping
that can be extended to meet your requirements, consider
developing a new object mapping. The second question to ask when
considering an extension form is thus:
Can the task be accomplished using the existing EPP command and
response structures applied to a new object?
If the answer to this question is "yes", you should consider
developing a new object mapping to complete your task. A new
object mapping should differ significantly from existing object
mappings; if you find that a new mapping is replicating a
significant number of structures found in an existing mapping you
probably answered the command-response question incorrectly. If
the answer to this question is "no", consider a protocol-level
extension next.
o Protocol-level Extension: If there is no existing object mapping
that can be extended to meet your requirements and the existing
EPP command and response structures are insufficient, consider
<span class="grey">Hollenbeck Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc3735">RFC 3735</a> Guidelines for Extending the EPP March 2004</span>
developing new protocol commands, responses, or other structures.
The third and final question to ask when considering an extension
form is thus:
Can the task be accomplished by adding new EPP commands,
responses, or other structures applied to new or existing
objects?
If the answer to this question is "no", EPP can not be used
directly to complete your task. If the answer to this question is
"yes", extend the protocol by defining new operational structures.
The extension forms and decision points listed here are presented in
order of complexity. Selecting an extension form without careful
consideration of the available extension options can add complexity
without any gain in functionality.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Mapping and Extension Archives</span>
Existing object mappings are a critical resource when trying to
select an appropriate extension form. Existing mappings or
extensions can provide a solid basis for further extension, but
designers have to know where to find them to consider them for use.
Several organizations maintain archives of XML structures that can be
useful extension platforms. These include:
o The IETF: Object mappings and other extensions have been
documented in RFCs and Internet-Drafts.
o IANA: Guidelines and registration procedures for an IANA XML
registry used by the IETF are described in "The IETF XML Registry"
[<a href="#ref-8" title=""The IETF XML Registry"">8</a>].
o OASIS [<a href="#ref-16">16</a>]: OASIS maintains an XML archive containing schema
definitions for use in the business applications of XML.
o XML.org [<a href="#ref-17">17</a>]: XML.org maintains an XML archive containing schema
definitions for use in multiple industries.
o Other archives are likely in the future. Consult your favorite
Internet search engine for additional resources.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Internationalization Considerations</span>
EPP is represented in XML [<a href="#ref-3" title=""Extensible Markup Language (XML) 1.0 (2nd ed)"">3</a>], which requires conforming parsers to
recognize both UTF-8 [<a href="#ref-13" title=""UTF-8, a transformation format of ISO 10646"">13</a>] and UTF-16 [<a href="#ref-14" title=""UTF-16, an encoding of ISO 10646"">14</a>]; support for other
character encodings is also possible. EPP extensions MUST observe
<span class="grey">Hollenbeck Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc3735">RFC 3735</a> Guidelines for Extending the EPP March 2004</span>
both the Internationalization Considerations described in the EPP
core protocol specification [<a href="#ref-2" title=""Extensible Provisioning Protocol (EPP)"">2</a>] and IETF policy on the use of
character sets and languages described in <a href="./rfc2277">RFC 2277</a> [<a href="#ref-9" title=""IETF Policy on Character Sets and Languages"">9</a>].
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. IANA Considerations</span>
This memo has no direct impact on the IANA. Guidelines for
extensions that require IANA action are described in <a href="#section-2.2.1">Section 2.2.1</a>.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
EPP extensions inherit the security services of the protocol
structure that's being extended. For example, an extension of an
object mapping inherits all of the security services of the object
mapping. Extensions MAY specify additional security services, such
as services for peer entity authentication, confidentiality, data
integrity, authorization, access control, or non-repudiation.
Extensions MUST NOT mandate removal of security services available in
the protocol structure being extended.
Protocol designers developing EPP extensions need to be aware of the
security threats to be faced in their intended operating environment
so that appropriate security services can be provided. Guidelines
for designers to consider and suggestions for writing an appropriate
Security Considerations section can be found in <a href="./rfc3552">RFC 3552</a> [<a href="#ref-15" title=""Guidelines for Writing RFC Text on Security Considerations"">15</a>].
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. References</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Normative References</span>
[<a id="ref-1">1</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-2">2</a>] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", <a href="./rfc3730">RFC</a>
<a href="./rfc3730">3730</a>, March 2004.
[<a id="ref-3">3</a>] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
"Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml,
October 2000, <<a href="http://www.w3.org/TR/REC-xml">http://www.w3.org/TR/REC-xml</a>>.
[<a id="ref-4">4</a>] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML
Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001,
<<a href="http://www.w3.org/TR/xmlschema-1/">http://www.w3.org/TR/xmlschema-1/</a>>.
[<a id="ref-5">5</a>] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", W3C
REC-xmlschema-2, May 2001, <<a href="http://www.w3.org/TR/xmlschema-2/">http://www.w3.org/TR/xmlschema-2/</a>>.
<span class="grey">Hollenbeck Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc3735">RFC 3735</a> Guidelines for Extending the EPP March 2004</span>
[<a id="ref-6">6</a>] Bray, T., Hollander, D. and A. Layman, "Namespaces in XML", W3C
REC-xml-names, January 1999, <<a href="http://www.w3.org/TR/REC-xml-names">http://www.w3.org/TR/REC-xml-</a>
<a href="http://www.w3.org/TR/REC-xml-names">names</a>>.
[<a id="ref-7">7</a>] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", <a href="./rfc2396">RFC 2396</a>, August 1998.
[<a id="ref-8">8</a>] Mealling, M., "The IETF XML Registry", <a href="https://www.rfc-editor.org/bcp/bcp81">BCP 81</a>, <a href="./rfc3688">RFC 3688</a>, January
2004.
[<a id="ref-9">9</a>] Alvestrand, H., "IETF Policy on Character Sets and Languages",
<a href="https://www.rfc-editor.org/bcp/bcp18">BCP 18</a>, <a href="./rfc2277">RFC 2277</a>, January 1998.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Informative References</span>
[<a id="ref-10">10</a>] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain
Name Mapping", <a href="./rfc3731">RFC 3731</a>, March 2004.
[<a id="ref-11">11</a>] Hollenbeck, S., Rose, M. and L. Masinter, "Guidelines for the
Use of Extensible Markup Language (XML) within IETF Protocols",
<a href="https://www.rfc-editor.org/bcp/bcp70">BCP 70</a>, <a href="./rfc3470">RFC 3470</a>, January 2003.
[<a id="ref-12">12</a>] Hollenbeck, S., "Extensible Provisioning Protocol E.164 Number
Mapping", Work in Progress, February 2003.
[<a id="ref-13">13</a>] Yergeau, F., "UTF-8, a transformation format of ISO 10646", <a href="./rfc2279">RFC</a>
<a href="./rfc2279">2279</a>, January 1998.
[<a id="ref-14">14</a>] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646",
<a href="./rfc2781">RFC 2781</a>, February 2000.
[<a id="ref-15">15</a>] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on
Security Considerations", <a href="https://www.rfc-editor.org/bcp/bcp72">BCP 72</a>, <a href="./rfc3552">RFC 3552</a>, July 2003.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. URIs</span>
[<a id="ref-16">16</a>] <<a href="http://oasis-open.org/">http://oasis-open.org/</a>>
[<a id="ref-17">17</a>] <<a href="http://xml.org/">http://xml.org/</a>>
<span class="grey">Hollenbeck Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc3735">RFC 3735</a> Guidelines for Extending the EPP March 2004</span>
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Author's Address</span>
Scott Hollenbeck
VeriSign, Inc.
21345 Ridgetop Circle
Dulles, VA 20166-6503
USA
EMail: shollenbeck@verisign.com
<span class="grey">Hollenbeck Informational [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc3735">RFC 3735</a> Guidelines for Extending the EPP March 2004</span>
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Full Copyright Statement</span>
Copyright (C) The Internet Society (2004). 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 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.
Hollenbeck Informational [Page 13]
</pre>
|
