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
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
|
Network Working Group S. Hollenbeck
Request for Comments: 3470 VeriSign, Inc.
BCP: 70 M. Rose
Category: Best Current Practice Dover Beach Consulting, Inc.
L. Masinter
Adobe Systems Incorporated
January 2003
Guidelines for the Use of Extensible Markup Language (XML)
within IETF Protocols
Status of this Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
The Extensible Markup Language (XML) is a framework for structuring
data. While it evolved from Standard Generalized Markup Language
(SGML) -- a markup language primarily focused on structuring
documents -- XML has evolved to be a widely-used mechanism for
representing structured data.
There are a wide variety of Internet protocols being developed; many
have need for a representation for structured data relevant to their
application. There has been much interest in the use of XML as a
representation method. This document describes basic XML concepts,
analyzes various alternatives in the use of XML, and provides
guidelines for the use of XML within IETF standards-track protocols.
Table of Contents
Conventions Used In This Document . . . . . . . . . . . . . . . . 2
1. Introduction and Overview . . . . . . . . . . . . . . . . . 2
1.1 Intended Audience. . . . . . . . . . . . . . . . . . . 3
1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 XML Evolution . . . . . . . . . . . . . . . . . . . . 3
1.4 XML Users, Support Groups, and Additional
Information. . . . . . . . . . . . . . . . . . . . . . 4
2. XML Selection Considerations . . . . . . . . . . . . . . . . 4
3. XML Alternatives . . . . . . . . . . . . . . . . . . . . . . 5
Hollenbeck, et al. Best Current Practice [Page 1]
^L
RFC 3470 XML within IETF Protocols January 2003
4. XML Use Considerations and Recommendations . . . . . . . . . 7
4.1 XML Syntax and Well-Formedness . . . . . . . . . . . . 7
4.2 XML Information Set . . . . . . . . . . . . . . . . . 7
4.3 Syntactic Restrictions . . . . . . . . . . . . . . . . 8
4.4 XML Declarations . . . . . . . . . . . . . . . . . . . 9
4.5 XML Processing Instructions . . . . . . . . . . . . . 9
4.6 XML Comments . . . . . . . . . . . . . . . . . . . . . 10
4.7 Validity and Extensibility . . . . . . . . . . . . . . 10
4.8 Semantics as Well as Syntax. . . . . . . . . . . . . . 12
4.9 Namespaces . . . . . . . . . . . . . . . . . . . . . . 12
4.9.1 Namespaces and Attributes. . . . . . . . . . . . 13
4.10 Element and Attribute Design Considerations. . . . . . 14
4.11 Binary Data and Text with Control Characters . . . . . 16
4.12 Incremental Processing . . . . . . . . . . . . . . . . 16
4.13 Entity Declarations and Entity References . . . . . . 16
4.14 External References . . . . . . . . . . . . . . . . . 17
4.15 URI Processing . . . . . . . . . . . . . . . . . . . . 17
4.16 White Space . . . . . . . . . . . . . . . . . . . . . 18
4.17 Interaction with the IANA . . . . . . . . . . . . . . 19
5. Internationalization Considerations . . . . . . . . . . . . 19
5.1 Character Sets and Encodings . . . . . . . . . . . . . 19
5.2 Language Declaration . . . . . . . . . . . . . . . . . 20
5.3 Other Internationalization Considerations . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . 21
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
9. Normative References . . . . . . . . . . . . . . . . . . . . 22
10. Informative References . . . . . . . . . . . . . . . . . . . 23
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 27
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . 28
Conventions Used In This Document
This document recommends, as policy, what specifications for Internet
protocols -- and, in particular, IETF standards track protocol
documents -- should include as normative language within them. The
capitalized keywords "SHOULD", "MUST", "REQUIRED", etc. are used in
the sense of how they would be used within other documents with the
meanings as specified in BCP 14, RFC 2119 [1].
1. Introduction and Overview
The Extensible Markup Language (XML, [8]) is a framework for
structuring data. While it evolved from the Standard Generalized
Markup Language (SGML, [30]) -- a markup language primarily focused
on structuring documents -- XML has evolved to be a widely-used
mechanism for representing structured data in protocol exchanges.
See "XML in 10 points" [47] for an introduction to XML.
Hollenbeck, et al. Best Current Practice [Page 2]
^L
RFC 3470 XML within IETF Protocols January 2003
1.1 Intended Audience
Many Internet protocol designers are considering using XML and XML
fragments within the context of existing and new Internet protocols.
This document is intended as a guide to XML usage and as IETF policy
for standards track documents. Experienced XML practitioners will
likely already be familiar with the background material here, but the
guidelines are intended to be appropriate for those readers as well.
1.2 Scope
This document is intended to give guidelines for the use of XML
content within a larger protocol. The goal is not to suggest that
XML is the "best" or "preferred" way to represent data; rather, the
goal is to lay out the context for the use of XML within a protocol
once other factors point to XML as a possible data representation
solution. The Common Name Resolution Protocol (CNRP, [24]) is an
example of a protocol that would be addressed by these guidelines if
it were being newly defined. This document does not address the use
of protocols like SMTP or HTTP to send XML documents as ordinary
email or web content.
There are a number of protocol frameworks already in use or under
development which focus entirely on "XML protocol" -- the exclusive
use of XML as the data representation in the protocol. For example,
the World Wide Web Consortium (W3C) is developing an XML Protocol
framework based on SOAP ([45] and [46]). The applicability of such
protocols is not part of the scope of this document.
In addition, there are higher-level representation frameworks, based
on XML, that have been designed as carriers of certain classes of
information; for example, the Resource Description Framework (RDF,
[38]) is an XML-based representation for logical assertions. This
document does not provide guidelines for the use of such frameworks.
1.3 XML Evolution
XML 1.0 was originally published as a W3C recommendation in February
1998 [35], and was revised in a 2nd edition [8] in October 2000.
Several additional facilities have also been defined that layer on
the base specification. Although these additions are designed to be
consistent with XML 1.0, they have varying levels of stability,
consensus, and implementation. Accordingly, this document identifies
the major evolutionary features of XML and makes suggestions as to
the circumstances in which each feature should be used.
Hollenbeck, et al. Best Current Practice [Page 3]
^L
RFC 3470 XML within IETF Protocols January 2003
1.4 XML Users, Support Groups, and Additional Information
There are many XML support groups, with some devoted to the entire
XML industry [51], some devoted to developers [52], some devoted to
the business applications of XML [53], and many, many groups devoted
to the use of XML in a particular context.
It is beyond the scope of this document to provide a comprehensive
list of referrals. Interested readers are directed to the three
references above as starting points, as well as their favorite
Internet search engine.
2. XML Selection Considerations
XML is a tool that provides a means towards an end. Choosing the
right tool for a given task is an essential part of ensuring that the
task can be completed in a satisfactory manner. This section
describes factors to be aware of when considering XML as a tool for
use in IETF protocols:
1. XML is a meta-markup language that can be used to define markup
languages for specific domains and problem spaces.
2. XML provides both logical structure and physical structure to
describe data. Data framing is built-in.
3. XML instances can be validated against the formal definition of a
protocol specification.
4. XML supports internationalization.
5. XML is extensible. Unlike some other markup languages (such as
HTML), new tags (and thus new protocol elements) can be defined
without requiring changes to XML itself.
6. XML is still evolving. The formal specifications are still being
influenced and updated as use experience is gained and applied.
7. XML does not provide native mechanisms to support detailed data
typing. Additional mechanisms (such as those described in
Section 4.7) are required to specify abstract protocol data
types.
8. XML is text-based, so XML fragments are easily created, edited,
and managed using common utilities. Further, being text-based
means it more readily supports incremental development,
Hollenbeck, et al. Best Current Practice [Page 4]
^L
RFC 3470 XML within IETF Protocols January 2003
debugging, and logging. A simple "canned" XML fragment can be
embedded within a program as a string constant, rather than
having to be constructed.
9. Binary data has to be encoded into a text-based form to be
represented in XML.
10. XML is verbose when compared with many other structured data
representation languages. A representation with element
extensibility and human readability typically requires more bits
when compared to one optimized for efficient machine processing.
11. XML implementations are still relatively new. As designers and
implementers gain experience, it is not uncommon to find defects
in early and current products.
12. XML support is available in a large number of software
development utilities, available in both open source and
proprietary products.
13. XML processing speed can be an issue in some environments. XML
processing can be slower because XML data streams may be larger
than other representations, and the use of general purpose XML
parsers will add a software layer with its own performance costs
(though these costs can be reduced through consistent use of an
optimized parser). In some situations, processing XML requires
examining every byte of the entire XML data stream, with higher
overhead than with representations where uninteresting segments
can be skipped.
3. XML Alternatives
This document focuses on guidelines for the use of XML. It is useful
to consider why one might use XML as opposed to some other mechanism.
This section considers some other commonly used representation
mechanisms and compares XML to those alternatives.
For many fundamental protocols, the extensibility requirements are
modest, and the performance requirements are high enough that fixed
binary data blocks are the appropriate representation; mechanisms
such as XML merely add bloat. RFC 3252 [23] describes a humorous
example of XML as protocol bloat.
In addition, there are other representation and extensibility
frameworks that have been used successfully within communication
protocols. For example, Abstract Syntax Notation 1 (ASN.1) [28]
along with the corresponding Basic Encoding Rules (BER, [29]) are
part of the OSI communication protocol suite, and have been used in
Hollenbeck, et al. Best Current Practice [Page 5]
^L
RFC 3470 XML within IETF Protocols January 2003
many subsequent communications standards (e.g., the ANSI Information
Retrieval protocol [27] and the Simple Network Management Protocol
(SNMP, [13]). The External Data Representation (XDR, [14]) and
variations of it have been used in many other distributed network
applications (e.g., the Network File System (NFS) protocol [22]).
With some ASN.1 encoding types, data types are explicit in the
representation, while with XDR, the data types of components are
described externally as part of an interface specification.
Many other protocols use data structures directly (without data
encapsulation) by describing the data structure with Backus Normal
Form (BNF, [25]); many IETF protocols use an Augmented Backus-Naur
Form (ABNF, [16]). The Simple Mail Transfer Protocol (SMTP, [21]) is
an example of a protocol specified using ABNF.
ASN.1, XDR, and BNF are described here as examples of alternatives to
XML for use in IETF protocols. There are other alternatives, but a
complete enumeration of all possible alternatives is beyond the scope
of this document.
Other representation methods may differ from XML in several important
ways:
Text Encoding and character sets: the character encoding used to
represent a formal specification. XML defines a consistent character
model based on the Universal Character Set (UCS, [31] and [33]), and
requires that XML parsers accept at least UTF-8 [4] and UTF-16 [20],
and allows for other encodings. While ASN.1 and XDR may carry
strings in any encoding, there is no common mechanism for defining
character encodings within them. Typically, ABNF definitions tend to
be defined in terms of octets or characters in ASCII.
Data Encoding: XML is defined as a sequence of characters, rather
than a sequence of bytes. XML Schema [42] includes mechanisms for
representing some data types (integer, date, array, etc.) but many
binary data types are encoded in Base64 [15] or hexadecimal. ASN.1
and XDR have rich mechanisms for encoding a wide variety of data
types.
Extensibility: XML has a rich extensibility model such that XML
specifications can frequently be versioned independently.
Specifications can be extended by adding new element names and
attributes (if done compatibly); other extensions can be added by
defining new XML namespaces [9], though there is no standard
mechanism in XML to indicating whether or not new extensions are
mandatory to recognize. Similarly, there are several techniques
available to extend ASN.1 specifications. XDR specifications tend to
not be independently extensible by different parties because the
Hollenbeck, et al. Best Current Practice [Page 6]
^L
RFC 3470 XML within IETF Protocols January 2003
framing and data types are implicit and not self-describing. The
extensibility of BNF-based protocol elements needs to be explicitly
planned.
Legibility of protocol elements: As noted above, XML is text-based,
and thus carries the advantages (and disadvantages) of text-based
protocol elements. Typically this is shared with (A)BNF-defined
protocol elements. ASN.1 and XDR use binary encodings which are not
easily human readable.
4. XML Use Considerations and Recommendations
This section notes several aspects of XML and makes recommendations
for use. Since the 1998 publication of XML version 1 [35], an
editorial second edition [8] was published in 2000; this section
refers to the second edition.
4.1 XML Syntax and Well-Formedness
XML [8] is defined in terms of a concrete syntax: a sequence of
characters, using the characters "<", "=", "&", etc. as delimiters.
An instance is XML if and only if it is well-formed, i.e., all
character and markup data conforms to the structural rules defined in
section 2.1 of [8].
Character and markup data that is not well-formed is not XML; well-
formedness is the basis for syntactic compatibility with XML.
Without well-formedness, all of the advantages of using XML
disappear. For this reason, it is recommended that protocol
specifications explicitly require XML well-formedness ("MUST be
well-formed").
The IETF has a long-standing tradition of "be liberal in what you
accept" that might seem to be at odds with this recommendation.
Given that XML requires well-formedness, conforming XML parsers are
intolerant of well-formedness errors. When specifying the handing of
erroneous XML protocol elements, a protocol design must never
recommend attempting to partially interpret non-well-formed instances
of an element which is required to be XML. Reasonable behaviors in
such a scenario could include attempting retransmission or aborting
an in-progress session.
4.2 XML Information Set
In addition to the concrete syntax of XML, there is an abstract model
of XML content known as the "Information Set" (infoset) [37]. One
might think of an XML parser as consuming the concrete syntax and
producing an XML Information Set for further processing.
Hollenbeck, et al. Best Current Practice [Page 7]
^L
RFC 3470 XML within IETF Protocols January 2003
In typical use of XML, the definition of allowable XML documents is
often defined in terms of the Information Set of the XML and not the
concrete syntax. The notion is that any syntactic representation
which yielded the same information set would be treated equivalently.
It some cases, protocols have been defined solely in terms of the XML
Information Set, or by allowing other concrete syntax
representations. However, since the context of XML embedded within
other Internet protocols requires an unambiguous definition of the
concrete syntax, defining an XML protocol element in terms of its XML
Information Set alone and allowing other concrete syntax
representations is out of scope for this document.
4.3 Syntactic Restrictions
In some circumstances a protocol designer may be tempted to define an
XML-based protocol element as "XML", but at the same time imposing
additional restrictions beyond those imposed by the XML
recommendation itself -- for example, restricting the document
character encoding, or avoiding CDATA sections, character entity
references, imposing additional restrictions on use of white space,
etc. The general category of restrictions addressed by this section
are ones that would allow some but not other of the set of syntactic
representations which have the same canonical representation
according to canonical XML described in RFC 3076 [6].
Making these kinds of restrictions in a protocol definition may have
the disadvantage that an implementer of the protocol may not be able
to use an otherwise conforming XML processor to parse the XML-based
protocol elements. In some cases, the motivation for subsetting XML
is to allow implementers to build special-purpose processors that are
lighter weight than a full-scale conforming XML processor. There are
a number of good, conforming XML parsers that are small, fast, and
free, while special-purpose processors have frequently been known to
fail to handle some cases of legal XML syntax.
In general, such syntactic restrictions should be avoided. In
circumstances where restrictions on the variability of the syntactic
representation of XML is necessary for one reason or another,
designers should consider using "Canonical XML" [6] as the definition
of the protocol element, since all such variability has been removed.
Some specific issues are discussed in Section 4.4, Section 4.13, and
Section 5.1 below.
Hollenbeck, et al. Best Current Practice [Page 8]
^L
RFC 3470 XML within IETF Protocols January 2003
4.4 XML Declarations
An XML declaration (defined in section 2.8 of [8]) is a small header
at the beginning of an XML data stream that indicates the XML version
and the character encoding used. For example,
<?xml version="1.0" encoding="UTF-8"?>
specifies the use of XML version 1 and UTF-8 character encoding.
In some uses of XML as an embedded protocol element, the XML used is
a small fragment in a larger context, where the XML version is fixed
at "1.0" and the character encoding is known to be "UTF-8". In those
cases, an XML declaration might add extra overhead. In cases where
the XML is a larger component which may find its way alone as an
external entity body (transported as a MIME message, for example),
the XML declaration is an important marker and is useful for
reliability and extensibility. The XML declaration is also an
important marker for character set/encoding (see Section 5.1), if any
encoding other than UTF-8 or UTF-16 is used. Note that in the case
of UTF-16, XML requires that the entity starts with a Byte Order Mark
(BOM), which is not part of the character data. Note that the XML
Declaration itself is not part of the XML document's Information Set.
Protocol specifications must be clear about use of XML declarations.
XML [8] notes that "XML documents should begin with an XML
declaration which specifies the version of XML being used." In
general, an XML declaration should be encouraged ("SHOULD be
present") and must always be allowed ("MAY be sent"). An XML
declaration should be required in cases where, if allowed, the
character encoding is anything other than UTF-8 or UTF-16.
4.5 XML Processing Instructions
An XML processing instruction (defined in section 2.6 of [8]) is a
component of an XML document that signals extra "out of band"
information to the receiver; a common use of XML processing
instructions are for document applications. For example, the XML2RFC
application used to generate this document and described in RFC 2629
[19] supports a "table of contents" processing instruction:
<?rfc toc="yes"?>
As described in section 2.6 of [8], processing instructions are not
part of the document's character data, but must be passed through to
the application. As a consequence, it is recommended that processing
instructions be ignored when encountered in normal protocol
processing. It is thus also recommended that processing instructions
Hollenbeck, et al. Best Current Practice [Page 9]
^L
RFC 3470 XML within IETF Protocols January 2003
not be used to define normative protocol data structures or
extensions for the following reasons:
o Processing instructions are not namespace aware; there is no way
to qualify a processing instruction target with a namespace.
o Processing instruction use can not be constrained by most schema
languages,
o Character references are not recognized within a processing
instruction.
o Processing instructions don't have any XML-defined structure
beyond the division between the target and everything else. This
means that applications typically have to parse the content of the
processing instruction in a system-dependent way; if the content
was provided within an element instead, the structure could be
expressed in the XML and the parsing could be done by the XML
parser.
4.6 XML Comments
An XML comment (defined in section 2.5 of [8]) is a component of an
XML document that provides descriptive information that is not part
of the document's character data. XML comments, like comments used
in programming languages, are often used to provide explanatory
information in human-understandable terms. An example:
<!-- This is a example comment. -->
XML comments can be ignored by conformant processors. As a
consequence, it is strongly recommended that comments not be used to
define normative protocol data structures or extensions. It is thus
also strongly recommended that comments be ignored if encountered in
normal protocol processing.
4.7 Validity and Extensibility
One important value of XML is that there are formal mechanisms for
defining structural and data content constraints; these constrain the
identity of elements or attributes or the values contained within
them. There is more than one such formalism:
o A "Document Type Definition" (DTD) is defined in section 2.8 of
[8]; the concept came from a similar mechanism for SGML. There is
significant experience with using DTDs, including in IETF
protocols.
Hollenbeck, et al. Best Current Practice [Page 10]
^L
RFC 3470 XML within IETF Protocols January 2003
o XML Schema (defined in [41] and [42]) provides additional features
to allow a tighter and more precise specification of allowable
protocol syntax and data type specifications.
o There are also a number of other mechanisms for describing XML
instance validity; these include, for example, Schematron [49] and
RELAX NG [48]. Part 2 of the ISO/IEC Document Schema Definition
Language (DSDL, [32]) standard is based on RELAX NG.
There is ongoing discussion (and controversy) within the XML
community on the use and applicability of various validity constraint
mechanisms. The choice of tool depends on the needs for
extensibility or for a formal language and mechanism for constraining
permissible values and validating adherence to the constraints.
There are cases where protocols have defined validity using one or
another validity mechanism, but the protocol definitions have not
insisted that all corresponding protocol elements be "valid". The
decision depends in part on the design for protocol extensibility.
Each formalism has different ways of allowing for future extensions;
in addition, a protocol design may have its own versioning mechanism,
way of updating the schema, or pointing to a new one. For example,
the use of XML namespaces (Section 4.9) with XML Schema allows other
kinds of extensibility without compromising schema validity.
No matter what formalism is chosen, there are usually additional
syntactic constraints, and inevitably additional semantic
constraints, on the validity of XML elements that cannot be expressed
in the formalism.
This document makes the following recommendations for the definition
of protocols using XML:
o Protocols should use an appropriate formalism for defining
validity of XML protocol elements.
o Protocols may or may not insist that all corresponding protocol
elements be valid, according to the validity mechanism chosen; in
either case, the extensibility design should be clear. What
happens if the data is not valid?
o As described in Section 3 there is no standard mechanism in XML
for indicating whether or not new extensions are mandatory to
recognize. XML-based protocol specifications should thus
explicitly describe extension mechanisms and requirements to
recognize or ignore extensions.
Hollenbeck, et al. Best Current Practice [Page 11]
^L
RFC 3470 XML within IETF Protocols January 2003
An idealized model for XML processing might first check for well-
formedness; if OK, apply the primary formalism and, if the instances
"passes", apply the other constraints so that the entire set (or as
much as is machine processable) can be checked at the same time.
However, it is reasonable to allow conforming implementations to
avoid doing validation at run-time and rely instead on ad-hoc code to
avoid the higher expense, for example, of schema validation,
especially given that there will likely be additional hand-crafted
semantic validation.
4.8 Semantics as Well as Syntax
While the definition of an XML protocol element using a validity
formalism is useful, it is not sufficient. XML by itself does not
supply semantics. Any document defining a protocol element with XML
MUST also have sufficient prose in the document describing the
semantics of whatever XML the document has elected to define.
4.9 Namespaces
XML namespaces, defined in [9], provide a means of assigning markup
to a specific vocabulary. If two elements or attributes from
different vocabularies have the same name, they can be distinguished
unambiguously if they belong to different namespaces. Additionally,
namespaces provide significant support for protocol extensibility as
they can be defined, reused, and processed dynamically.
Markup vocabulary collisions are very possible when namespaces are
not used to separate and uniquely identify vocabularies. Protocol
definitions should use existing XML namespaces where appropriate.
When a new namespace is needed, the "namespace name" is a URI that is
used to identify the namespace; it's also useful for that URI to
point to a description of the namespace. Typically (and recommended
practice in W3C) is to assign namespace names using persistent http
URIs.
In the case of namespaces in IETF standards-track documents, it would
be useful if there were some permanent part of the IETF's own web
space that could be used for this purpose. In lieu of such, other
permanent URIs can be used, e.g., URNs in the IETF URN namespace (see
[11] and [12]). Although there are instances of IETF specifications
creating new URI schemes to define XML namespaces, this practice is
strongly discouraged.
Hollenbeck, et al. Best Current Practice [Page 12]
^L
RFC 3470 XML within IETF Protocols January 2003
4.9.1 Namespaces and Attributes
There is a frequently misunderstood aspect of the relationship
between unprefixed attributes and the default XML namespace - the
natural assumption is that an unprefixed attribute is qualified by
the default namespace, but this is not true. Rather, the unprefixed
attribute belongs to no namespace at all. Thus, in the following
example:
<ns1:fox a="xxx" ns1:b="qqq"
xmlns="http://example.org"/>
<fox a="xxx" ns1:b="qqq"
xmlns="http://example.org" xmlns:ns1="http://example.org"/>
the attribute "a" is in no namespace, while "ns1:b" is the same
namespace as the containing element. A specific description of the
relationship between default namespaces and attributes can be found
in section 5.2 of [9]. The practical implication of the relationship
between namespaces and attributes is that care must be taken to
ensure that no element contains multiple attributes that have
identical names or have qualified names with the same local part and
with prefixes which have been bound to namespace names that are
identical.
In XML applications, the choice between prefixed and non-prefixed
attributes frequently is based on whether they always appear inside
elements of the same namespace (in which case non-prefixed and
thereby non-namespaced names are used) or whether it's required that
they can be applied to elements in other arbitrary namespaces (in
which case a prefixed name is used). Both situations occur in the
XSLT [43] language: while attributes are unprefixed when they occur
inside elements in the XSLT namespace, such as:
<xsl:value-of select="."/>
Hollenbeck, et al. Best Current Practice [Page 13]
^L
RFC 3470 XML within IETF Protocols January 2003
they are prefixed when they appear in non-XSLT elements, such as the
"xsl:version" attribute when using "literal result element
stylesheets":
<html xsl:version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns="http://www.w3.org/TR/xhtml1/strict">
<head>
<title>Expense Report Summary</title>
</head>
<body>
<p>Total: <xsl:value-of select="exp-rep/total"/></p>
</body>
</html>
4.10 Element and Attribute Design Considerations
XML provides much flexibility in allowing a designer to use either
elements, attributes, or element content to carry data. This section
gives a flavor of the design considerations; there is much written
about this in the XML literature. Consistent use of elements,
attributes, and values is an important characteristic of a sound
design.
Attributes are generally intended to contain meta-data that describes
the element, and as such they are subject to the following
restrictions:
o Attributes are unordered,
o There can be no more than one instance of a given attribute within
a given element, though an attribute may contain several values
separated by white space ([8], section 2.3 and 3.3.1),
o Attribute values can have no internal XML markup for providing
internal structure, and
o Attribute values are normalized ([8], section 3.3) before
processing
Consider the following example that describes an IP address using an
attribute to describe the address value:
<address addrType="ipv4">10.1.2.3</address>
Hollenbeck, et al. Best Current Practice [Page 14]
^L
RFC 3470 XML within IETF Protocols January 2003
One might encode the same information using an <addrType> element
instead of an "addrType" attribute:
<address>
<addrType>ipv4</addrType>
<value>10.1.2.3</value>
</address>
Another way of encoding the same information would be to use markup
for the "addrType":
<address>
<addrType><ipv4/></addrType>
<value>10.1.2.3</value>
</address>
Choosing between these designs involves tradeoffs concerning, among
other considerations, the likely extensibility patterns and the
ability of the formalism to constrain the values appropriately. In
the first example, the attribute can be thought of as meta-data to
the element which it modifies, and provides for a kind of "element
extensibility". The third example allows for a different kind of
extensibility: the "ipv4" space can be extended using other
namespaces, and the <ipv4> element can include additional markup.
Many protocols include parameters that are selected from an
enumerated set of values. Such enumerated values can be encoded as
elements, attributes, or strings within element values. Any protocol
design should consider how the set of enumerated values is to be
extended: by revising the protocol, by including different values in
different XML namespaces, or by establishing an IANA registry (as per
RFC 2434 [18]). In addition, a common practice in XML is to use a
URI as an XML attribute value or content.
Languages that describe syntactic validity (including XML Schema and
DTDs) often provide a mechanism for specifying "default" values for
an attribute. If an element does not specify a value for the
attribute, then the "default" value is used. The use of default
values for attributes is discouraged by this document. Although the
use of this feature can reduce both the size and clutter of XML
documents, it has a negative impact on software which doesn't know
the document's validity constraints (e.g., for packet tracing or
digital signature).
Hollenbeck, et al. Best Current Practice [Page 15]
^L
RFC 3470 XML within IETF Protocols January 2003
4.11 Binary Data and Text with Control Characters
XML is defined as a character stream rather than a stream of octets.
There is no way to embed raw binary data directly within an XML data
stream; all binary data must be encoded as characters. There are a
number of possible encodings; for example, XML Schema [42] defines
encodings using decimal digits for integers, Base64 [15], or
hexadecimal digits. In addition, binary data might be transmitted
using some other communication channel, and referenced within the XML
data itself using a URI.
Protocols that need a container that can hold both structural data
and large quantities of binary data should consider carefully whether
XML is appropriate, since the Base64 and hex encodings are
inefficient. Otherwise, protocols should use the mechanisms of XML
Schema to represent binary data; the Base64 encoding is best for
larger quantities of data.
XML does not allow "control" characters (0x00-0x1F) except for TAB
(0x09), CR (0x0A), and LF (0x0D). They can not be specified even
using character entity references. There is currently no common way
of encoding them within what is otherwise ordinary text. This means
that strings that might be considered "text" within an ABNF-defined
protocol element may need to be treated as binary data within an XML
representation, or some other encoding mechanism might need to be
invented.
4.12 Incremental Processing
In some situations, it is possible to incrementally process an XML
document as each tag is received; this is analogous to the process by
which browsers incrementally render HTML pages as they are received.
Note that incremental processing is difficult to implement if
interspersed across multiple interactions. In other words, if a
protocol requires incremental processing across both directions of a
bidirectional stream, then it may place an unusual burden on protocol
implementers.
4.13 Entity Declarations and Entity References
In addition to its role as a validity mechanism, an XML DTD provides
a facility for "entity declarations" ([8], section 4.2). An entity
declaration defines, in the DTD, a kind of macro capability where an
"entity reference" may be used to call up and include the content of
the entity declaration.
Hollenbeck, et al. Best Current Practice [Page 16]
^L
RFC 3470 XML within IETF Protocols January 2003
This feature adds complexity to XML processing, and seems more
appropriate for use of XML in document processing than in data
representation. As such, this document recommends avoiding entity
declarations in protocol specifications.
On the other hand, there are five standard entity references built
into XML: "&", "<", ">", "'", and """. XML also
has the ability to write character data using numeric entity
references (using the Unicode [33] value for the character). Entity
references are normally expanded before the XML Information Set is
computed. Restricting the use of these entity references would
introduce an additional syntactic restriction (see Section 4.3)
unnecessarily; these entity references should be allowed.
4.14 External References
When using XML in the context of a stateless protocol, be it the
protocol itself (e.g., SOAP), or simply as content transferred by an
existing protocol (e.g., XML/HTTP), care must be taken to not make
the meaning of a message depend on information outside the message
itself. XML provides external entities (see Section 4.13), which are
an easy way to make the meaning of a message depend on something
external. Using schema languages that can change the Infoset, like
XML Schema, is another way.
4.15 URI Processing
The XML Base specification [36] defines an attribute "xml:base" in
the XML namespace that is intended to affect the "base" to be used
for relative URI processing described in RFC 2396 [17]. The
facilities of xml:base for controlling URI processing may be useful
to protocol designers, but if xml:base is allowed the interaction
with any other protocol facilities for establishing URI context must
be specified clearly. Note that use of relative URIs in namespace
declarations has been deprecated by the W3C; some specific issues
with relative URIs in namespace declarations and canonical XML can be
found in section 1.3 of RFC 3076 [6].
Note also that, in many cases, the term "URI" and the syntactic use
of URIs within XML allows non-ASCII characters within URIs. For
example, the XML Schema "anyURI" datatype ([42] section 3.2.17)
allows for direct encoding of characters outside of the US-ASCII
range. Most current IETF protocols and specifications do not allow
this syntax. Protocol specifications should be clear about the range
of characters specified, e.g., by adding a restriction to the range
of characters allowed in the anyURI schema datatype, or by specifying
that characters outside the US-ASCII range should be escaped when
passed to older protocols or APIs.
Hollenbeck, et al. Best Current Practice [Page 17]
^L
RFC 3470 XML within IETF Protocols January 2003
4.16 White Space
XML's prescribed white space handling behavior can be a source of
confusion between protocol designers and implementers. In XML
instances all white space is considered significant and is by default
visible to processing applications. Consider this example from
Section 4.10:
<address>
<addrType><ipv4/></addrType>
<value>10.1.2.3</value>
</address>
This fragment contains an <address> element and two child elements.
It also contains white space for pretty-printing purposes:
o at least three line separators, which will be converted by the XML
processor to newline (U+000A) characters (see section 2.11 of
[8]), and
o one or more white space characters prefixing the <addrType> and
<value> elements, which an XML processor will make visible to
software reading the instance.
Implementers might safely assume that they can ignore the white space
in the example above, but white space used for pretty-printing can be
a source of confusion in other situations. Consider a minor change
to the <value> element:
<value>
10.1.2.3
</value>
where white space is found on both sides of the IP address. XML
processors treat the white space surrounding "10.1.2.3" as an
integral part of the <value> element. A failure to recognize this
behavior can lead to confusion and errors in both design and
implementation.
All white space is considered significant in XML instances. As a
consequence, it is recommended that protocol designers provide
specific guidelines to address white space handling within protocols
that use XML.
Hollenbeck, et al. Best Current Practice [Page 18]
^L
RFC 3470 XML within IETF Protocols January 2003
4.17 Interaction with the IANA
When XML is used in an IETF protocol there are multiple factors that
might require IANA action, including:
o XML media types. A piece of XML in a protocol element is
sometimes intrinsically bound to the protocol context in which it
appears, and in particular might be directly derived from and/or
input to protocol state-machine implementations. In cases where
the XML content has no relevant meaning outside it's original
protocol context, there is no reason to register a MIME type.
When it is possible that XML content can be interpreted outside of
its original context (such as when that XML content is being
stored in a file system or tunneled over another protocol), then a
MIME type can be registered to specify the specific format for the
data and to provide a hint as to how it might be processed.
If MIME labeling is needed, then the advice of RFC 3023 [5]
applies. In particular, if the XML represents a new language or
document type, a new MIME media type should be registered for the
reasons described in RFC 3023 sections 7 and A.1. In situations
where XML is used to encode generic structured data (e.g., a
document-oriented application that involves combining XML with a
stylesheet), "application/xml" might be appropriate ("MAY be
used"). The "text/xml" media type is not recommended ("SHOULD NOT
be used") because of issues involving display behavior and default
charsets.
o URI registration. There is an ongoing effort ([11], [12]) to
create a URN namespace explicitly for defining URIs for namespace
names and other URI-designated protocol elements for use within
IETF standards track documents; it might also establish IETF
policy for such use.
5. Internationalization Considerations
This section describes internationalization considerations for the
use of XML to represent data in IETF protocols. In addition to the
recommendations here, IETF policy on the use of character sets and
languages described in RFC 2277 [3] also applies.
5.1 Character Sets and Encodings
IETF protocols frequently speak of the "character set" or "charset"
of a string, which is used to denote both the character repertoire
and the encoding used to represent sequences of characters as
sequences of bytes.
Hollenbeck, et al. Best Current Practice [Page 19]
^L
RFC 3470 XML within IETF Protocols January 2003
XML performs all character processing in terms of the Universal
Character Set (UCS, [31] and [33]). XML requires all XML processors
to support both the UTF-8 [4] and UTF-16 [20] encodings of UCS,
although other encodings (charsets) compatible with UCS may be
allowed. Documents and external parsed entities encoded in UTF-16
are required to begin with a Byte Order Mark ([8] section 4.3.3).
IETF policy [3] requires that the UTF-8 charset be allowed for all
text.
This document requires that IETF protocols using XML allow for the
UTF-8 encoding of XML data. Since conforming XML processors are
mandated to also accept UTF-16 encoding, also allowing for UTF-16
encoding (with the mandated Byte Order Mark) is recommended. Some
XML applications are using a Byte Order Mark with UTF-8 encoding, but
this use should not be encouraged and isn't appropriate for XML
embedded in other protocols.
Restricting XML data to only be expressed in UTF-8 is an additional
syntactic restriction (see Section 4.3) which, depending on
circumstances, might add additional implementation complexity. When
encodings other than UTF-8 or UTF-16 are used, the encoding must be
specified using an "encoding" attribute in the XML declaration (see
Section 4.4), even if there might be other protocol mechanisms for
designating the encoding.
5.2 Language Declaration
Text encapsulated in XML can be represented in many different human
languages, and it is often useful to explicitly identify the language
used to present the text. XML defines a special attribute in the
"xml" namespace, xml:lang, that can be used to specify the language
used to represent data in an XML document. The xml:lang attribute
(which has to be explicitly declared for use within a DTD or XML
Schema) and the values it can assume are defined in section 2.12 of
[8].
It is strongly recommended that protocols representing data in a
human language mandate use of an xml:lang attribute if the XML
instance might be interpreted in language-dependent contexts.
5.3 Other Internationalization Considerations
There are standard mechanisms in the typography of some human
languages that can be difficult to represent using merely XML
character string data types. For example, pronunciation clues can be
provided using Ruby annotation [39], and embedding controls (such as
those described in section 3.4 of [34]) or an XHTML [40] "dir"
Hollenbeck, et al. Best Current Practice [Page 20]
^L
RFC 3470 XML within IETF Protocols January 2003
attribute can be used to note the proper display direction for
bidirectional text.
There are a number of tricky issues that can arise when using
extended character sets with XML document formats. For example:
o There are different ways of representing characters consisting of
combining characters, and
o There has been some debate about whether URIs should be
represented using a restricted US-ASCII subset or arbitrary
Unicode (e.g., "URI character sequence" vs "original character
sequence" in RFC 2396 [17]).
Some of these issues are discussed, with recommendations, in the
W3C's "Character Model for the World Wide Web" document [44].
It is strongly recommended that protocols representing data in a
human language reuse existing mechanisms as needed to ensure proper
display of human-legible text.
6. IANA Considerations
This memo, per se, has no impact on the IANA. Section 4.17 notes
some factors that might require IANA action when protocols using XML
are defined.
7. Security Considerations
Network protocols face many different kinds of threats, including
unintended disclosure, modification, and replay. Passive attacks,
such as packet sniffing, allow an attacker to capture and view
information intended for someone else. Captured data can be modified
and replayed to the original intended recipient, with the recipient
having no way to know that the information has been compromised,
detect modifications, be assured of the sender's identity, or to
confirm which protocol instance is legitimate.
Several security service options for XML are available to help
mitigate these risks. Though XML does not include any built-in
security services, other protocols and protocol layers provide
services that can be used to protect XML protocols. XML encryption
[10] provides privacy services to prevent unintended disclosure.
Canonical XML [6] and XML digital signatures [7] provide integrity
services to detect modification and authentication services to
confirm the identity of the data source. Other IETF security
protocols (e.g., the Transport Layer Security (TLS) protocol [2]) are
also available to protect data and service endpoints as appropriate.
Hollenbeck, et al. Best Current Practice [Page 21]
^L
RFC 3470 XML within IETF Protocols January 2003
Given the lack of security services in XML, it is imperative that
protocol specifications mandate additional security services to
counter common threats and attacks; the specific required services
will depend on the protocol's threat model.
Experience has shown that code that parses network traffic is often a
"soft target" for blackhats. Accordingly, implementers MUST take
great care to ensure that their XML handling code is robust with
respect to malformed XML, buffer overruns, misuse of entity
declarations, and so on.
XML mechanisms that follow external references (Section 4.14) may
also expose an implementation to various threats by causing the
implementation to access external resources automatically. It is
important to disallow arbitrary access to such external references
within XML data from untrusted sources. Many XML grammars define
constructs using URIs for external references; in such cases, the
same precautions must be taken.
8. Acknowledgements
The authors would like to thank the following people who have
provided significant contributions to the development of this
document:
Mark Baker, Tim Berners-Lee, Tim Bray, James Clark, Josh Cohen, John
Cowan, Alan Crouch, Martin Duerst, Jun Fujisawa, Christian Geuer-
Pollmann, Yaron Goland, Graham Klyne, Dan Kohn, Rick Jeliffe, Chris
Lilley, Murata Makoto, Michael Mealling, Jean-Jacques Moreau, Andrew
Newton, Julian Reschke, Jonathan Rosenberg, Miles Sabin, Rich Salz,
Peter Saint-Andre, Simon St Laurent, Margaret Wasserman, and Daniel
Veillard.
9. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[3] Alvestrand, H., "IETF Policy on Character Sets and Languages",
BCP 18, RFC 2277, January 1998.
[4] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.
Hollenbeck, et al. Best Current Practice [Page 22]
^L
RFC 3470 XML within IETF Protocols January 2003
[5] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC
3023, January 2001.
[6] Boyer, J., "Canonical XML Version 1.0", RFC 3076, March 2001.
[7] Eastlake, D., Reagle, J. and D. Solo, "(Extensible Markup
Language) XML-Signature Syntax and Processing", RFC 3275, March
2002.
[8] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
"Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml,
October 2000, <http://www.w3.org/TR/REC-xml>.
[9] Bray, T., Hollander, D. and A. Layman, "Namespaces in XML", W3C
REC-xml-names, January 1999, <http://www.w3.org/TR/REC-xml-
names>.
[10] Imamura, T., Dillaway, B., Schaad, J. and E. Simon, "XML
Encryption Syntax and Processing", W3C REC-xmlenc-core, October
2001, <http://www.w3.org/TR/xmlenc-core/>.
10. Informative References
[11] Masinter, L., Mealling, M., Klyne, G. and T. Hardie, "An IETF
URN Sub-namespace for Registered Protocol Parameters", Work in
Progress.
[12] Mealling, M., "The IETF XML Registry", Work in Progress.
[13] Case, J., Fedor, M., Schoffstall, M. and C. Davin, "Simple
Network Management Protocol (SNMP)", STD 15, RFC 1157, May
1990.
[14] Srinivasan, R., "XDR: External Data Representation Standard",
RFC 1832, August 1995.
[15] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
[16] Crocker, D. (Ed.) and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[17] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.
Hollenbeck, et al. Best Current Practice [Page 23]
^L
RFC 3470 XML within IETF Protocols January 2003
[18] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.
[19] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June
1999.
[20] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646",
RFC 2781, February 2000.
[21] Klensin, J. (Ed.), "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[22] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame,
C., Eisler, M. and D. Noveck, "NFS version 4 Protocol", RFC
3010, December 2000.
[23] Kennedy, H., "Binary Lexical Octet Ad-hoc Transport", RFC 3252,
April 2002.
[24] Popp, N., Mealling, M. and M. Moseley, "Common Name Resolution
Protocol (CNRP)", RFC 3367, August 2002.
[25] Backus, J., "The syntax and semantics of the proposed
international algebraic language of the Zurich ACM-GAMM
conference", June 1959.
[26] American National Standards Institute, "Code Extension
Techniques for Use with the 7-bit Coded Character Set of
American National Standard Code (ASCII) for Information
Interchange", ANSI X3.41, FIPS PUB 35, 1974.
[27] American National Standards Institute, "Information Retrieval:
Application Service Definition and Protocol Specification",
ANSI Z39.50, ISO Standard 23950, 1995.
[28] International Organization for Standardization, "Information
Processing Systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1)", ISO
Standard 8824, December 1990.
[29] International Organization for Standardization, "Information
Processing Systems - Open Systems Interconnection -
Specification of Basic Encoding Rules for Abstract Syntax
Notation One (ASN.1)", ISO Standard 8825, December 1990.
Hollenbeck, et al. Best Current Practice [Page 24]
^L
RFC 3470 XML within IETF Protocols January 2003
[30] International Organization for Standardization, "Information
processing - Text and office systems - Standard Generalized
Markup Language (SGML)", ISO Standard 8879, 1988.
[31] International Organization for Standardization, "Information
Technology - Universal Multiple-octet coded Character Set (UCS)
- Part 1: Architecture and Basic Multilingual Plane", ISO
Standard 10646-1, May 1993.
[32] International Organization for Standardization, "DSDL Part 0 -
Overview", December 2001, <http://www.jtc1.org/FTP/Public/SC34/
DOCREG/0275.htm>.
[33] Unicode Consortium, "The Unicode Standard, as it may from time
to time be revised or amended", March 2002, <http://
www.unicode.org/unicode/standard/standard.html>.
[34] Duerst, M. and A. Freytag, "Unicode in XML and other Markup
Languages", February 2002, <http://www.w3.org/TR/unicode-xml/>.
[35] Bray, T., Paoli, J. and C. Sperberg-McQueen, "Extensible Markup
Language (XML) 1.0", W3C REC-xml-1998, February 1998, <http://
www.w3.org/TR/1998/REC-xml-19980210/>.
[36] Marsh, J., "XML Base", W3C REC-xmlbase, June 2001, <http://
www.w3.org/TR/xmlbase/>.
[37] Cowan, J. and R. Tobin, "XML Information Set", W3C REC-infoset,
October 2001, <http://www.w3.org/TR/xml-infoset/>.
[38] Lassila, O. and R. Swick, "Resource Description Framework (RDF)
Model and Syntax Specification", W3C REC-rdf-syntax, February
1999, <http://www.w3.org/TR/REC-rdf-syntax>.
[39] Suignard, M., Ishikawa, M., Duerst, M. and T. Texin, "Ruby
Annotation", W3C REC-RUBY, May 2001, <http://www.w3.org/TR/
ruby/>.
[40] Pemberton, S., "XHTML 1.0: The Extensible HyperText Markup
Language", W3C REC-XHTML, January 2000, <http://www.w3.org/TR/
xhtml1/>.
[41] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML
Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001,
<http://www.w3.org/TR/xmlschema-1/>.
[42] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", W3C
REC-xmlschema-2, May 2001, <http://www.w3.org/TR/xmlschema-2/>.
Hollenbeck, et al. Best Current Practice [Page 25]
^L
RFC 3470 XML within IETF Protocols January 2003
[43] Clark, J., "XSL Transformations (XSLT) Version 1.0", W3C REC-
xslt, November 1999, <http://www.w3.org/TR/xslt>.
[44] Duerst, M., Yergeau, F., Ishida, R., Wolf, M., Freytag, A. and
T. Texin, "Character Model for the World Wide Web 1.0", April
2002, <http://www.w3.org/TR/charmod/>.
[45] Gudgin, M., Hadley, M., Moreau, JJ. and H. Nielsen, "SOAP
Version 1.2 Part 1: Messaging Framework", June 2002,
<http://www.w3.org/TR/soap12-part1/>.
[46] Gudgin, M., Hadley, M., Moreau, JJ. and H. Nielsen, "SOAP
Version 1.2 Part 2: Adjuncts", June 2002,
<http://www.w3.org/TR/soap12-part2/>.
[47] W3C Communications Team, "XML in 10 points", November 2001,
<http://www.w3.org/XML/1999/XML-in-10-points>.
[48] OASIS Technical Committee: RELAX NG, "RELAX NG Specification",
December 2001, <http://www.oasis-open.org/committees/relax-ng/
spec-20011203.html>.
[49] Jelliffe, R., "The Schematron", November 2001, <http://
www.ascc.net/xml/schematron/>.
URIs
[50] <http://www.imc.org/ietf-xml-use/>
[51] <http://xml.org/>
[52] <http://xmlhack.com/>
[53] <http://oasis-open.org/>
Hollenbeck, et al. Best Current Practice [Page 26]
^L
RFC 3470 XML within IETF Protocols January 2003
11. Authors' Addresses
Scott Hollenbeck
VeriSign, Inc.
21345 Ridgetop Circle
Dulles, VA 20166-6503
US
Phone: +1 703 948 3257
EMail: shollenbeck@verisign.com
Marshall T. Rose
Dover Beach Consulting, Inc.
POB 255268
Sacramento, CA 95865-5268
US
Phone: +1 916 483 8878
EMail: mrose@dbc.mtview.ca.us
Larry Masinter
Adobe Systems Incorporated
Mail Stop W14
345 Park Ave.
San Jose, CA 95110
US
Phone: +1 408 536 3024
EMail: LMM@acm.org
URI: http://larry.masinter.net
Hollenbeck, et al. Best Current Practice [Page 27]
^L
RFC 3470 XML within IETF Protocols January 2003
12. Full Copyright Statement
Copyright (C) The Internet Society (2003). 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.
Hollenbeck, et al. Best Current Practice [Page 28]
^L
|