File: rfc3076.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (1571 lines) | stat: -rw-r--r-- 63,955 bytes parent folder | download | duplicates (5)
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                                           J. Boyer
Request for Comments: 3076                       PureEdge Solutions Inc.
Category: Informational                                       March 2001


                       Canonical XML Version 1.0

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 (2001).  All Rights Reserved.

Abstract

   Any XML (Extensible Markup Language) document is part of a set of XML
   documents that are logically equivalent within an application
   context, but which vary in physical representation based on syntactic
   changes permitted by XML 1.0 and Namespaces in XML.  This
   specification describes a method for generating a physical
   representation, the canonical form, of an XML document that accounts
   for the permissible changes.  Except for limitations regarding a few
   unusual cases, if two documents have the same canonical form, then
   the two documents are logically equivalent within the given
   application context.  Note that two documents may have differing
   canonical forms yet still be equivalent in a given context based on
   application-specific equivalence rules for which no generalized XML
   specification could account.



















Boyer                        Informational                      [Page 1]

RFC 3076                     Canonical XML                    March 2001


Table of Contents

   1. Introduction...............................................  2
   1.1 Terminology...............................................  3
   1.2 Applications..............................................  4
   1.3 Limitations...............................................  4
   2. XML Canonicalization.......................................  6
   2.1 Data Model................................................  6
   2.2 Document Order............................................ 10
   2.3 Processing Model.......................................... 10
   2.4 Document Subsets.......................................... 13
   3. Examples of XML Canonicalization........................... 14
   3.1 PIs, Comments, and Outside of Document Element............ 14
   3.2 Whitespace in Document Content............................ 15
   3.3 Start and End Tags........................................ 16
   3.4 Character Modifications and Character References.......... 17
   3.5 Entity References......................................... 19
   3.6 UTF-8 Encoding............................................ 19
   3.7 Document Subsets.......................................... 20
   4. Resolutions................................................ 21
   4.1 No XML Declaration........................................ 21
   4.2 No Character Model Normalization.......................... 21
   4.3 Handling of Whitespace Outside Document Element........... 22
   4.4 No Namespace Prefix Rewriting............................. 22
   4.5 Order of Namespace Declarations and Attributes............ 23
   4.6 Superfluous Namespace Declarations........................ 23
   4.7 Propagation of Default Namespace Declaration in Document
       Subsets................................................... 24
   4.8 Sorting Attributes by Namespace URI....................... 24
   Security Considerations....................................... 24
   References.................................................... 25
   Author's Address.............................................. 26
   Acknowledgements.............................................. 27
   Full Copyright Statement...................................... 28

1. Introduction

   The XML 1.0 Recommendation [XML] specifies the syntax of a class of
   resources called XML documents.  The Namespaces in XML Recommendation
   [Names] specifies additional syntax and semantics for XML documents.
   It is possible for XML documents which are equivalent for the
   purposes of many applications to differ in physical representation.
   For example, they may differ in their entity structure, attribute
   ordering, and character encoding.  It is the goal of this
   specification to establish a method for determining whether two
   documents are identical, or whether an application has not changed a
   document, except for transformations permitted by XML 1.0 and
   Namespaces.



Boyer                        Informational                      [Page 2]

RFC 3076                     Canonical XML                    March 2001


1.1 Terminology

   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 RFC 2119 [Keywords].

   See [Names] for the definition of QName.

   A document subset is a portion of an XML document indicated by a
   node-set that may not include all of the nodes in the document.

   The canonical form of an XML document is physical representation of
   the document produced by the method described in this specification.
   The changes are summarized in the following list:

       * The document is encoded in UTF-8
       * Line breaks normalized to #xA on input, before parsing
       * Attribute values are normalized, as if by a validating
         processor
       * Character and parsed entity references are replaced
       * CDATA sections are replaced with their character content
       * The XML declaration and document type declaration (DTD) are
         removed
       * Empty elements are converted to start-end tag pairs
       * Whitespace outside of the document element and within start and
         end tags is normalized
       * All whitespace in character content is retained (excluding
         characters removed during line feed normalization)
       * Attribute value delimiters are set to quotation marks (double
         quotes)
       * Special characters in attribute values and character content
         are replaced by character references
       * Superfluous namespace declarations are removed from each
         element
       * Default attributes are added to each element
       * Lexicographic order is imposed on the namespace declarations
         and attributes of each element

   The term canonical XML refers to XML that is in canonical form.  The
   XML canonicalization method is the algorithm defined by this
   specification that generates the canonical form of a given XML
   document or document subset.  The term XML canonicalization refers to
   the process of applying the XML canonicalization method to an XML
   document or document subset.

   The XPath 1.0 Recommendation [XPath] defines the term node-set and
   specifies a data model for representing an input XML document as a
   set of nodes of various types (element, attribute, namespace, text,



Boyer                        Informational                      [Page 3]

RFC 3076                     Canonical XML                    March 2001


   comment, processing instruction, and root).  The nodes are included
   in or excluded from a node-set based on the evaluation of an
   expression.  Within this specification, a node-set is used to
   directly indicate whether or not each node should be rendered in the
   canonical form (in this sense, it is used as a formal mathematical
   set).  A node that is excluded from the set is not rendered in the
   canonical form being generated, even if its parent node is included
   in the node-set.  However, an omitted node may still impact the
   rendering of its descendants (e.g., by augmenting the namespace
   context of the descendants).

1.2 Applications

   Since the XML 1.0 Recommendation [XML] and the Namespaces in XML
   Recommendation [Names] define multiple syntactic methods for
   expressing the same information, XML applications tend to take
   liberties with changes that have no impact on the information content
   of the document.  XML canonicalization is designed to be useful to
   applications that require the ability to test whether the information
   content of a document or document subset has been changed.  This is
   done by comparing the canonical form of the original document before
   application processing with the canonical form of the document result
   of the application processing.

   For example, a digital signature over the canonical form of an XML
   document or document subset would allow the signature digest
   calculations to be oblivious to changes in the original document's
   physical representation, provided that the changes are defined to be
   logically equivalent by the XML 1.0 or Namespaces in XML.  During
   signature generation, the digest is computed over the canonical form
   of the document.  The document is then transferred to the relying
   party, which validates the signature by reading the document and
   computing a digest of the canonical form of the received document.
   The equivalence of the digests computed by the signing and relying
   parties (and hence the equivalence of the canonical forms over which
   they were computed) ensures that the information content of the
   document has not been altered since it was signed.

1.3 Limitations

   Two XML documents may have differing information content that is
   nonetheless logically equivalent within a given application context.
   Although two XML documents are equivalent (aside from limitations
   given in this section) if their canonical forms are identical, it is
   not a goal of this work to establish a method such that two XML
   documents are equivalent if and only if their canonical forms are
   identical.  Such a method is unachievable, in part due to
   application-specific rules such as those governing unimportant



Boyer                        Informational                      [Page 4]

RFC 3076                     Canonical XML                    March 2001


   whitespace and equivalent data (e.g., <color>black</color> versus
   <color>rgb(0,0,0)</color>).  There are also equivalencies established
   by other W3C Recommendations and Working Drafts.  Accounting for
   these additional equivalence rules is beyond the scope of this work.
   They can be applied by the application or become the subject of
   future specifications.

   The canonical form of an XML document may not be completely
   operational within the application context, though the circumstances
   under which this occurs are unusual.  This problem may be of concern
   in certain applications since the canonical form of a document and
   the canonical form of the canonical form of the document are
   equivalent.  For example, in a digital signature application, the
   canonical form can be substituted for the original document without
   changing the digest calculation.  However, the security risk only
   occurs in the unusual circumstances described below, which can all be
   resolved or at least detected prior to digital signature generation.

   The difficulties arise due to the loss of the following information
   not available in the data model:

      1. base URI, especially in content derived from the replacement
         text of external general parsed entity references
      2. notations and external unparsed entity references
      3. attribute types in the document type declaration

   In the first case, note that a document containing a relative URI
   [URI] is only operational when accessed from a specific URI that
   provides the proper base URI.  In addition, if the document contains
   external general parsed entity references to content containing
   relative URIs, then the relative URIs will not be operational in the
   canonical form, which replaces the entity reference with internal
   content (thereby implicitly changing the default base URI of that
   content).  Both of these problems can typically be solved by adding
   support for the xml:base attribute [XBase] to the application, then
   adding appropriate xml:base attributes to document element and all
   top-level elements in external entities.  In addition, applications
   often have an opportunity to resolve relative URIs prior to the need
   for a canonical form.  For example, in a digital signature
   application, a document is often retrieved and processed prior to
   signature generation.  The processing SHOULD create a new document in
   which relative URIs have been converted to absolute URIs, thereby
   mitigating any security risk for the new document.

   In the second case, the loss of external unparsed entity references
   and the notations that bind them to applications means that canonical
   forms cannot properly distinguish among XML documents that
   incorporate unparsed data via this mechanism.  This is an unusual



Boyer                        Informational                      [Page 5]

RFC 3076                     Canonical XML                    March 2001


   case precisely because most XML processors currently discard the
   document type declaration, which discards the notation, the entity's
   binding to a URI, and the attribute type that binds the attribute
   value to an entity name.  For documents that must be subjected to
   more than one XML processor, the XML design typically indicates a
   reference to unparsed data using a URI in the attribute value.

   In the third case, the loss of attribute types can affect the
   canonical form in different ways depending on the type.  Attributes
   of type ID cease to be ID attributes.  Hence, any XPath expressions
   that refer to the canonical form using the id() function cease to
   operate.  The attribute types ENTITY and ENTITIES are not part of
   this case; they are covered in the second case above.  Attributes of
   enumerated type and of type ID, IDREF, IDREFS, NMTOKEN, NMTOKENS, and
   NOTATION fail to be appropriately constrained during future attempts
   to change the attribute value if the canonical form replaces the
   original document during application processing.  Applications can
   avoid the difficulties of this case by ensuring that an appropriate
   document type declaration is prepended prior to using the canonical
   form in further XML processing.  This is likely to be an easy task
   since attribute lists are usually acquired from a standard external
   DTD subset, and any entity and notation declarations not also in the
   external DTD subset are typically constructed from application
   configuration information and added to the internal DTD subset.

   While these limitations are not severe, it would be possible to
   resolve them in a future version of XML canonicalization if, for
   example, a new version of XPath were created based on the XML
   Information Set [Infoset] currently under development at the W3C.

2. XML Canonicalization

2.1 Data Model

   The data model defined in the XPath 1.0 Recommendation [XPath] is
   used to represent the input XML document or document subset.
   Implementations SHOULD but need not be based on an XPath
   implementation.  XML canonicalization is defined in terms of the
   XPath definition of a node-set, and implementations MUST produce
   equivalent results.

   The first parameter of input to the XML canonicalization method is
   either an XPath node-set or an octet stream containing a well-formed
   XML document.  Implementations MUST support the octet stream input
   and SHOULD also support the document subset feature via node-set
   input.  For the purpose of describing canonicalization in terms of an
   XPath node-set, this section describes how an octet stream is
   converted to an XPath node-set.



Boyer                        Informational                      [Page 6]

RFC 3076                     Canonical XML                    March 2001


   The second parameter of input to the XML canonicalization method is a
   boolean flag indicating whether or not comments should be included in
   the canonical form output by the XML canonicalization method.  If a
   canonical form contains comments corresponding to the comment nodes
   in the input node-set, the result is called canonical XML with
   comments.  Note that the XPath data model does not create comment
   nodes for comments appearing within the document type declaration
   (DTD).  Implementations are REQUIRED to be capable of producing
   canonical XML excluding all comments that may have appeared in the
   input document or document subset.  Support for canonical XML with
   comments is RECOMMENDED.

   If an XML document must be converted to a node-set, XPath REQUIRES
   that an XML processor be used to create the nodes of its data model
   to fully represent the document.  The XML processor performs the
   following tasks in order:

      1. normalize line feeds
      2. normalize attribute values
      3. replace CDATA sections with their character content
      4. resolve character and parsed entity references

   The input octet stream MUST contain a well-formed XML document, but
   the input need not be validated.  However, the attribute value
   normalization and entity reference resolution MUST be performed in
   accordance with the behaviors of a validating XML processor.  As
   well, nodes for default attributes (declared in the ATTLIST with an
   AttValue but not specified) are created in each element.  Thus, the
   declarations in the document type declaration are used to help create
   the canonical form, even though the document type declaration is not
   retained in the canonical form.

   The XPath data model represents data using UCS characters.
   Implementations MUST use XML processors that support UTF-8 and UTF-16
   and translate to the UCS character domain.  For UTF-16, the leading
   byte order mark is treated as an artifact of encoding and stripped
   from the UCS character data (subsequent zero width non-breaking
   spaces appearing within the UTF-16 data are not removed) [UTF-16,
   Section 3.2].  Support for ISO-8859-1 encoding is RECOMMENDED, and
   all other character encodings are OPTIONAL.

   All whitespace within the root document element MUST be preserved
   (except for any #xD characters deleted by line delimiter
   normalization).  This includes all whitespace in external entities.
   Whitespace outside of the root document element MUST be discarded.






Boyer                        Informational                      [Page 7]

RFC 3076                     Canonical XML                    March 2001


   In the XPath data model, there exist the following node types: root,
   element, comment, processing instruction, text, attribute and
   namespace.  There exists a single root node whose children are
   processing instruction nodes and comment nodes to represent
   information outside of the document element (and outside of the
   document type declaration).  The root node also has a single element
   node representing the top-level document element.  Each element node
   can have child nodes of type element, text, processing instruction,
   and comment.  The attributes and namespaces associated with an
   element are not considered to be child nodes of the element, but they
   are associated with the element by inclusion in the element's
   attribute and namespace axes.  Note that attribute and namespace axes
   may not directly correspond to the text appearing in the element's
   start tag in the original document.

   Note: An element has attribute nodes to represent the non-namespace
         attribute declarations appearing in its start tag as well as
         nodes to represent the default attributes.

   By virtue of the XPath data model, XML canonicalization is
   namespace-aware [Names].  However, it cannot and therefore does not
   account for namespace equivalencies using namespace prefix rewriting
   (see explanation in Section 4).  In the XPath data model, each
   element and attribute has a name returned by the function name()
   which can, at the discretion of the application, be the QName
   appearing in the original document.  XML canonicalization REQUIRES
   that the XML processor retain sufficient information such that the
   QName of the element as it appeared in the original document can be
   provided.

   Note: An element E has namespace nodes that represent its namespace
         declarations as well as any namespace declarations made by its
         ancestors that have not been overridden in E's declarations,
         the default namespace if it is non-empty, and the declaration
         of the prefix xml.  nn Note: This specification supports the
   recent XML plenary decision to
         deprecate relative namespace URIs as follows: implementations
         of XML canonicalization MUST report an operation failure on
         documents containing relative namespace URIs.  XML
         canonicalization MUST NOT be implemented with an XML parser
         that converts relative URIs to absolute URIs.

   Character content is represented in the XPath data model with text
   nodes.  All consecutive characters are placed into a single text
   node.  Furthermore, the text node's characters are represented in the
   UCS character domain.  The XML canonicalization method does not
   perform character model normalization (see explanation in Section 4).
   However, the XML processor used to prepare the XPath data model input



Boyer                        Informational                      [Page 8]

RFC 3076                     Canonical XML                    March 2001


   is REQUIRED to use Normalization Form C [NFC, NFC-Corrigendum] when
   converting an XML document to the UCS character domain from any
   encoding that is not UCS-based (currently, UCS-based encodings
   include UTF-8, UTF-16, UTF-16BE, and UTF-16LE, UCS-2, and UCS-4).

   Since XML canonicalization converts an XPath node-set into a
   canonical form, the first parameter MUST either be an XPath node-set
   or it must be converted from an octet stream to a node-set by
   performing the XML processing necessary to create the XPath nodes
   described above, then setting an initial XPath evaluation context of:

      * A context node, initialized to the root node of the input XML
        document.
      * A context position, initialized to 1.
      * A context size, initialized to 1.
      * Any library of functions conforming to the XPath Recommendation.
      * An empty set of variable bindings.
      * An empty set of namespace declarations.

   and evaluating the following default expression:

     Comment Parameter Value    Default XPath Expression
     -----------------------    ------------------------

     Without (false):
                      (//. | //@* |//namespace::*)[not(self::comment())]

     With (true):
                      (//. | //@* | //namespace::*)

   The expressions in this table generate a node-set containing every
   node of the XML document (except the comments if the comment
   parameter value is false).

   If the input is an XPath node-set, then the node-set must explicitly
   contain every node to be rendered to the canonical form.  For
   example, the result of the XPath expression id("E") is a node-set
   containing only the node corresponding to the element with an ID
   attribute value of "E".  Since none of its descendant nodes,
   attribute nodes and namespace nodes are in the set, the canonical
   form would consist solely of the element's start and end tags, less
   the attribute and namespace declarations, with no internal content.
   Section 3.7 exemplifies how to serialize an identified element along
   with its internal content, attributes and namespace declarations.







Boyer                        Informational                      [Page 9]

RFC 3076                     Canonical XML                    March 2001


2.2 Document Order

   Although an XPath node-set is defined to be unordered, the XPath 1.0
   Recommendation [XPath] defines the term document order to be the
   order in which the first character of the XML representation of each
   node occurs in the XML representation of the document after expansion
   of general entities, except for namespace and attribute nodes whose
   document order is application-dependent.

   The XML canonicalization method processes a node-set by imposing the
   following additional document order rules on the namespace and
   attribute nodes of each element:

       * An element's namespace and attribute nodes have a document
         order position greater than the element but less than any child
         node of the element.
       * Namespace nodes have a lesser document order position than
         attribute nodes.
       * An element's namespace nodes are sorted lexicographically by
         local name (the default namespace node, if one exists, has no
         local name and is therefore lexicographically least).
       * An element's attribute nodes are sorted lexicographically with
         namespace URI as the primary key and local name as the
         secondary key (an empty namespace URI is lexicographically
         least).

   Lexicographic comparison, which orders strings from least to greatest
   alphabetically, is based on the UCS codepoint values, which is
   equivalent to lexicographic ordering based on UTF-8.

2.3 Processing Model

   The XPath node-set is converted into an octet stream, the canonical
   form, by generating the representative UCS characters for each node
   in the node-set in ascending document order, then encoding the result
   in UTF-8 (without a leading byte order mark).  No node is processed
   more than once.  Note that processing an element node E includes the
   processing of all members of the node-set for which E is an ancestor.
   Therefore, directly after the representative text for E is generated,
   E and all nodes for which E is an ancestor are removed from the
   node-set (or some logically equivalent operation occurs such that the
   node-set's next node in document order has not been processed).
   Note, however, that an element node is not removed from the node-set
   until after its children are processed.

   The result of processing a node depends on its type and on whether or
   not it is in the node-set.  If a node is not in the node-set, then no
   text is generated for the node except for the result of processing



Boyer                        Informational                     [Page 10]

RFC 3076                     Canonical XML                    March 2001


   its namespace and attribute axes (elements only) and its children
   (elements and the root node).  If the node is in the node-set, then
   text is generated to represent the node in the canonical form in
   addition to the text generated by processing the node's namespace and
   attribute axes and child nodes.

   Note: The node-set is treated as a set of nodes, not a list of
         subtrees.  To canonicalize an element including its namespaces,
         attributes, and content, the node-set must actually contain all
         of the nodes corresponding to these parts of the document, not
         just the element node.

   The text generated for a node is dependent on the node type and given
   in the following list:

       * Root Node- The root node is the parent of the top-level
         document element.  The result of processing each of its child
         nodes that is in the node-set in document order.  The root node
         does not generate a byte order mark, XML declaration, nor
         anything from within the document type declaration.

       * Element Nodes- If the element is not in the node-set, then the
         result is obtained by processing the namespace axis, then the
         attribute axis, then processing the child nodes of the element
         that are in the node-set (in document order).  If the element
         is in the node-set, then the result is an open angle bracket
         (<), the element QName, the result of processing the namespace
         axis, the result of processing the attribute axis, a close
         angle bracket (>), the result of processing the child nodes of
         the element that are in the node-set (in document order), an
         open angle bracket, a forward slash (/), the element QName, and
         a close angle bracket.

       *
         o Namespace Axis- Consider a list L containing only namespace
           nodes in the axis and in the node-set in lexicographic order
           (ascending).  To begin processing L, if the first node is not
           the default namespace node (a node with no namespace URI and
           no local name), then generate a space followed by xmlns="" if
           and only if the following conditions are met:

            + the element E that owns the axis is in the node-set
            + The nearest ancestor element of E in the node-set has a
              default namespace node in the node-set (default namespace
              nodes always have non-empty values in XPath)






Boyer                        Informational                     [Page 11]

RFC 3076                     Canonical XML                    March 2001


           The latter condition eliminates unnecessary occurrences of
           xmlns="" in the canonical form since an element only receives
           an xmlns="" if its default namespace is empty and if it has
           an immediate parent in the canonical form that has a non-
           empty default namespace.  To finish processing L, simply
           process every namespace node in L, except omit namespace node
           with local name xml, which defines the xml prefix, if its
           string value is http://www.w3.org/XML/1998/namespace.

         o Attribute Axis- In lexicographic order (ascending), process
           each node that is in the element's attribute axis and in the
           node-set.

       * Namespace Nodes- A namespace node N is ignored if the nearest
         ancestor element of the node's parent element that is in the
         node-set has a namespace node in the node-set with the same
         local name and value as N.  Otherwise, process the namespace
         node N in the same way as an attribute node, except assign the
         local name xmlns to the default namespace node if it exists (in
         XPath, the default namespace node has an empty URI and local
         name).

       * Attribute Nodes- a space, the node's QName, an equals sign, an
         open quotation mark (double quote), the modified string value,
         and a close quotation mark (double quote).  The string value of
         the node is modified by replacing all ampersands (&) with
         &amp;, all open angle brackets (<) with &lt;, all quotation
         mark (double quote) characters with &quot;, and the whitespace
         characters #x9, #xA, and #xD, with character references.  The
         character references are written in uppercase hexadecimal with
         no leading zeroes (for example, #xD is represented by the
         character reference &#xD;).

       * Text Nodes- the string value, except all ampersands are
         replaced by &amp;, all open angle brackets (<) are replaced by
         &lt;, all closing angle brackets (>) are replaced by &gt;, and
         all #xD characters are replaced by &#xD;.

       * Processing Instruction (PI) Nodes- The opening PI symbol (<?),
         the PI target name of the node, a leading space and the string
         value if it is not empty, and the closing PI symbol (?>).  If
         the string value is empty, then the leading space is not added.
         Also, a trailing #xA is rendered after the closing PI symbol
         for PI children of the root node with a lesser document order
         than the document element, and a leading #xA is rendered before
         the opening PI symbol of PI children of the root node with a
         greater document order than the document element.




Boyer                        Informational                     [Page 12]

RFC 3076                     Canonical XML                    March 2001


       * Comment Nodes- Nothing if generating canonical XML without
         comments.  For canonical XML with comments, generate the
         opening comment symbol (<!--), the string value of the node,
         and the closing comment symbol (-->).  Also, a trailing #xA is
         rendered after the closing comment symbol for comment children
         of the root node with a lesser document order than the document
         element, and a leading #xA is rendered before the opening
         comment symbol of comment children of the root node with a
         greater document order than the document element.  (Comment
         children of the root node represent comments outside of the
         top-level document element and outside of the document type
         declaration.)

   The QName of a node is either the local name if the namespace prefix
   string is empty or the namespace prefix, a colon, then the local name
   of the element.  The namespace prefix used in the QName MUST be the
   same one which appeared in the input document.

2.4 Document Subsets

   Some applications require the ability to create a physical
   representation for an XML document subset (other than the one
   generated by default, which can be a proper subset of the document if
   the comments are omitted).  Implementations of XML canonicalization
   that are based on XPath can provide this functionality with little
   additional overhead by accepting a node-set as input rather than an
   octet stream.

   The processing of an element node E MUST be modified slightly when an
   XPath node-set is given as input and the element's parent is omitted
   from the node-set.  The method for processing the attribute axis of
   an element E in the node-set is enhanced.  All element nodes along
   E's ancestor axis are examined for nearest occurrences of attributes
   in the xml namespace, such as xml:lang and xml:space (whether or not
   they are in the node-set).  From this list of attributes, remove any
   that are in E's attribute axis (whether or not they are in the node-
   set).  Then, lexicographically merge this attribute list with the
   nodes of E's attribute axis that are in the node-set.  The result of
   visiting the attribute axis is computed by processing the attribute
   nodes in this merged attribute list.

      Note: XML entities can derive application-specific meaning from
            anywhere in the XML markup as well as by rules not expressed
            in XML 1.0 and the Namespaces Recommendations.  Clearly,
            these rules cannot be specified in this document, so the
            creator of the input node-set must be responsible for
            preserving the information necessary to capture the full
            semantics of the members of the resulting node-set.



Boyer                        Informational                     [Page 13]

RFC 3076                     Canonical XML                    March 2001


   The canonical XML generated for an entire XML document is well-
   formed.  The canonical form of an XML document subset may not be
   well-formed XML.  However, since the canonical form may be subjected
   to further XML processing, most XPath node-sets provided for
   canonicalization will be designed to produce a canonical form that is
   a well-formed XML document or external general parsed entity.
   Whether from a full document or a document subset, if the canonical
   form is well-formed XML, then subsequent applications of the same XML
   canonicalization method to the canonical form make no changes.

3. Examples of XML Canonicalization

   The examples in this section assume a non-validating processor,
   primarily so that a document type declaration can be used to declare
   entities as well as default attributes and attributes of various
   types (such as ID and enumerated) without having to declare all
   attributes for all elements in the document.  As well, one example
   contains an element that deliberately violates a validity constraint
   (because it is still well-formed).

3.1 PIs, Comments, and Outside of Document Element

   Input Document
   --------------
   <?xml version="1.0"?>

   <?xml-stylesheet   href="doc.xsl"
      type="text/xsl"   ?>

   <!DOCTYPE doc SYSTEM "doc.dtd">

   <doc>Hello, world!<!-- Comment 1 --></doc>

   <?pi-without-data     ?>

   <!-- Comment 2 -->

   <!-- Comment 3 -->

   Canonical Form (uncommented)
   ----------------------------
   <?xml-stylesheet href="doc.xsl"
      type="text/xsl"   ?>
   <doc>Hello, world!</doc>
   <?pi-without-data?>






Boyer                        Informational                     [Page 14]

RFC 3076                     Canonical XML                    March 2001


   Canonical Form (commented)
   --------------------------
   <?xml-stylesheet href="doc.xsl"
      type="text/xsl"   ?>
   <doc>Hello, world!<!-- Comment 1 --></doc>
   <?pi-without-data?>
   <!-- Comment 2 -->
   <!-- Comment 3 -->

   Demonstrates:

       * Loss of XML declaration
       * Loss of DTD
       * Normalization of whitespace outside of document element (first
         character of both canonical forms is '<'; single line breaks
         separate PIs and comments outside of document element)
       * Loss of whitespace between PITarget and its data * Retention of
         whitespace inside PI data
       * Comment removal from uncommented canonical form, including
         delimiter for comments outside document element (the last
         character in both canonical forms is '>')

3.2 Whitespace in Document Content

   Input Document
   --------------
   <doc>
      <clean>   </clean>
      <dirty>   A   B   </dirty>
      <mixed>
         A
         <clean>   </clean>
         B
         <dirty>   A   B   </dirty>
         C
      </mixed>
   </doc>

   Canonical Form
   --------------
   <doc>
      <clean>   </clean>
      <dirty>   A   B   </dirty>
      <mixed>
         A
         <clean>   </clean>
         B
         <dirty>   A   B   </dirty>



Boyer                        Informational                     [Page 15]

RFC 3076                     Canonical XML                    March 2001


         C
      </mixed>
   </doc>

   Demonstrates:

       * Retain all whitespace between consecutive start tags, clean or
         dirty
       * Retain all whitespace between consecutive end tags, clean or
         dirty
       * Retain all whitespace between end tag/start tag pair, clean or
         dirty
       * Retain all whitespace in character content, clean or dirty

   Note: In this example, the input document and canonical form are
         identical.  Both end with '>' character.

3.3 Start and End Tags

Input Document
--------------
<!DOCTYPE doc [<!ATTLIST e9 attr CDATA "default">]>
<doc>
   <e1   />
   <e2   ></e2>
   <e3    name = "elem3"   id="elem3"    />
   <e4    name="elem4"   id="elem4"    ></e4>
   <e5 a:attr="out" b:attr="sorted" attr2="all" attr="I'm"
       xmlns:b="http://www.ietf.org"
       xmlns:a="http://www.w3.org"
       xmlns="http://example.org"/>
   <e6 xmlns="" xmlns:a="http://www.w3.org">
       <e7 xmlns="http://www.ietf.org">
           <e8 xmlns="" xmlns:a="http://www.w3.org">
               <e9 xmlns="" xmlns:a="http://www.ietf.org"/>
           </e8>
       </e7>
   </e6>
</doc>

Canonical Form
--------------
<doc>
   <e1></e1>
   <e2></e2>
   <e3 id="elem3" name="elem3"></e3>
   <e4 id="elem4" name="elem4"></e4>
   <e5 xmlns="http://example.org" xmlns:a="http://www.w3.org"



Boyer                        Informational                     [Page 16]

RFC 3076                     Canonical XML                    March 2001


xmlns:b="http://www.ietf.org" attr="I'm" attr2="all"
b:attr="sorted" a:attr="out"></e5>
   <e6 xmlns:a="http://www.w3.org">
       <e7 xmlns="http://www.ietf.org">
           <e8 xmlns="">
               <e9 xmlns:a="http://www.ietf.org" attr="default"></e9>
           </e8>
       </e7>
   </e6>
</doc>

   Demonstrates:

         * Empty element conversion to start-end tag pair
         * Normalization of whitespace in start and end tags
         * Relative order of namespace and attribute axes
         * Lexicographic ordering of namespace and attribute axes
         * Retention of namespace prefixes from original document
         * Elimination of superfluous namespace declarations
         * Addition of default attribute

   Note: Some start tags in the canonical form are very long, but each
         start tag in this example is entirely on a single line.

   Note: In e5, b:attr precedes a:attr because the primary key is
         namespace URI not namespace prefix, and attr2 precedes b:attr
         because the default namespace is not applied to unqualified
         attributes (so the namespace URI for attr2 is empty).

3.4 Character Modifications and Character References

Input Document
--------------
<!DOCTYPE doc [
<!ATTLIST normId id ID #IMPLIED>
<!ATTLIST normNames attr NMTOKENS #IMPLIED>
]>
<doc>
   <text>First line&#x0d;&#10;Second line</text>
   <value>&#x32;</value>
   <compute><![CDATA[value>"0" && value<"10" ?"valid":"error"]]>
   </compute>
   <compute expr='value>"0" &amp;&amp; value&lt;"10"
?"valid":"error"'>valid</compute>
   <norm attr=' &apos;   &#x20;&#13;&#xa;&#9;   &apos; '/>
   <normNames attr='   A   &#x20;&#13;&#xa;&#9;   B   '/>
   <normId id=' &apos;   &#x20;&#13;&#xa;&#9;   &apos; '/>
</doc>



Boyer                        Informational                     [Page 17]

RFC 3076                     Canonical XML                    March 2001


Canonical Form
--------------
<doc>
   <text>First line&#xD;
Second line</text>
   <value>2</value>
   <compute>value&gt;"0" &amp;&amp; value&lt;"10" ?"valid":"error"
   </compute>
   <compute expr="value>&quot;0&quot; &amp;&amp; value&lt;&quot;10&quot;
?&quot;
valid&quot;:&quot;error&quot;">valid</compute>
   <norm attr=" '    &#xD;&#xA;&#x9;   ' "></norm>
   <normNames attr="A &#xD;&#xA;&#x9; B"></normNames>
   <normId id="' &#xD;&#xA;&#x9; '"></normId>
</doc>

   Demonstrates:

       * Character reference replacement
       * Attribute value delimiters set to quotation marks (double
         quotes)
       * Attribute value normalization
       * CDATA section replacement
       * Encoding of special characters as character references in
         attribute values (&amp;, &lt;, &quot;, &#xD;, &#xA;, &#x9;)
       * Encoding of special characters as character references in text
         (&amp;, &lt;, &gt;, &#xD;)

   Note: The last element, normId, is well-formed but violates a
         validity constraint for attributes of type ID.  For testing
         canonical XML implementations based on validating processors,
         remove the line containing this element from the input and
         canonical form.  In general, XML consumers should be
         discouraged from using this feature of XML.

   Note: Whitespace characters references other than &#x20; are not
         affected by attribute value normalization [XML].

   Note: In the canonical form, the value of the attribute named attr in
         the element norm begins with a space, a single quote, then four
         spaces before the first character reference.

   Note: The expr attribute of the second compute element contains no
         line breaks.







Boyer                        Informational                     [Page 18]

RFC 3076                     Canonical XML                    March 2001


3.5 Entity References

   Input Document
   --------------
   <!DOCTYPE doc [
   <!ATTLIST doc attrExtEnt ENTITY #IMPLIED>
   <!ENTITY ent1 "Hello">
   <!ENTITY ent2 SYSTEM "world.txt">
   <!ENTITY entExt SYSTEM "earth.gif" NDATA gif>
   <!NOTATION gif SYSTEM "viewgif.exe">
   ]>
   <doc attrExtEnt="entExt">
      &ent1;, &ent2;!
   </doc>

   <!-- Let world.txt contain "world" (excluding the quotes) -->

   Canonical Form (uncommented)
   ----------------------------
   <doc attrExtEnt="entExt">
      Hello, world!
   </doc>

   Demonstrates:

       * Internal parsed entity reference replacement
       * External parsed entity reference replacement (including
         whitespace outside elements and PIs)
       * External unparsed entity reference

3.6 UTF-8 Encoding

   Input Document
   --------------
   <?xml version="1.0" encoding="ISO-8859-1"?>
   <doc>&#169;</doc>

   Canonical Form
   --------------
   <doc>#xC2#xA9</doc>

   Demonstrates:

         * Effect of transcoding from a sample encoding to UTF-8







Boyer                        Informational                     [Page 19]

RFC 3076                     Canonical XML                    March 2001


   Note: The content of the doc element is NOT the string #xC2#xA9 but
         rather the two octets whose hexadecimal values are C2 and A9,
         which is the UTF-8 encoding of the UCS codepoint for the
         copyright symbol (c).

3.7 Document Subsets

Input Document
--------------
<!DOCTYPE doc [
<!ATTLIST e2 xml:space (default|preserve) 'preserve'>
<!ATTLIST e3 id ID #IMPLIED>
]>
<doc xmlns="http://www.ietf.org" xmlns:w3c="http://www.w3.org">
   <e1>
      <e2 xmlns="">
         <e3 id="E3"/>
      </e2>
   </e1>
</doc>

Document Subset Expression
--------------------------
(//. | //@* | //namespace::*)
[ <br/>
   self::ietf:e1 or (parent::ietf:e1 and not(self::text() or self::e2))
   or
   count(id("E3")|ancestor-or-self::node()) =
count(ancestor-or-self::node())
]

Canonical Form
--------------
<e1 xmlns="http://www.ietf.org" xmlns:w3c="http://www.w3.org"><e3
xmlns="" id="E3" xml:space="preserve"></e3></e1>

   Demonstrates:

         * Empty default namespace propagation from omitted parent
         element * Propagation of attributes in xml namespace in
         document subsets * Persistence of omitted namespace
         declarations in descendants

   Note: In the document subset expression, the subexpression (//. |
         //@* | //namespace::*) selects all nodes in the input document,
         subjecting each to the predicate expression in square brackets.
         The expression is true for e1 and its implicit namespace nodes,
         and it is true if the element identified by E3 is in the



Boyer                        Informational                     [Page 20]

RFC 3076                     Canonical XML                    March 2001


         ancestor-or-self path of the context node (such that ancestor-
         or-self stays the same size under union with the element
         identified by E3).

   Note: The canonical form contains no line delimiters.

4. Resolutions

   This section discusses a number of key decision points as well as a
   rationale for each decision.  Although this specification now defines
   XML canonicalization in terms of the XPath data model rather than XML
   Infoset, the canonical form described in this document is quite
   similar in most respects to the canonical form described in the
   January 2000 Canonical XML draft [C14N-20000119].  However, some
   differences exist, and a number of the subsections discuss the
   changes.

4.1 No XML Declaration

   The XML declaration, including version number and character encoding
   is omitted from the canonical form.  The encoding is not needed since
   the canonical form is encoded in UTF-8.  The version is not needed
   since the absence of a version number unambiguously indicates XML
   1.0.

   Future versions of XML will be required to include an XML declaration
   to indicate the version number.  However, canonicalization method
   described in this specification may not be applicable to future
   versions of XML without some modifications.  When canonicalization of
   a new version of XML is required, this specification could be updated
   to include the XML declaration as presumably the absence of the XML
   declaration from the XPath data model can be remedied by that time
   (e.g., by reissuing a new XPath based on the Infoset data model).

4.2 No Character Model Normalization

   The Unicode standard [Unicode] allows multiple different
   representations of certain "precomposed characters" (a simple example
   is +U00E7, "LATIN SMALL LETTER C WITH CEDILLA").  Thus two XML
   documents with content that is equivalent for the purposes of most
   applications may contain differing character sequences.  The W3C is
   preparing a normalized representation [CharModel].  The C14N-20000119
   Canonical XML draft used this normalized form.  However, many XML 1.0
   processors do not perform this normalization.  Furthermore,
   applications that must solve this problem typically enforce character
   model normalization at all times starting when character content is
   created in order to avoid processing failures that could otherwise
   result (e.g., see example from Cowan).  Therefore, character model



Boyer                        Informational                     [Page 21]

RFC 3076                     Canonical XML                    March 2001


   normalization has been moved out of scope for XML canonicalization.
   However, the XML processor used to prepare the XPath data model input
   is required (by the Data Model) to use Normalization Form C [NFC,
   NFC-Corrigendum] when converting an XML document to the UCS character
   domain from any encoding that is not UCS-based (currently, UCS-based
   encodings include UTF-8, UTF-16, UTF-16BE, and UTF-16LE, UCS-2, and
   UCS-4).

4.3 Handling of Whitespace Outside Document Element

   The C14N-20000119 Canonical XML draft placed a #xA after each PI
   outside of the document element as well as a #xA after the end tag of
   the document element.  The method in this specification performs the
   same function except for omitting the final #xA after the last PI (or
   comment or end tag of the document element).  This technique ensures
   that PI (and comment) children of the root are separated from markup
   by a line feed even if root node or the document element are omitted
   from the output node-set.

4.4 No Namespace Prefix Rewriting

   The C14N-20000119 Canonical XML draft described a method for
   rewriting namespace prefixes such that two documents having logically
   equivalent namespace declarations would also have identical namespace
   prefixes.  The goal was to eliminate dependence on the particular
   namespace prefixes in a document when testing for logical
   equivalence.  However, there now exist a number of contexts in which
   namespace prefixes can impart information value in an XML document.
   For example, an XPath expression in an attribute value or element
   content can reference a namespace prefix.  Thus, rewriting the
   namespace prefixes would damage such a document by changing its
   meaning (and it cannot be logically equivalent if its meaning has
   changed).

   More formally, let D1 be a document containing an XPath in an
   attribute value or element content that refers to namespace prefixes
   used in D1.  Further assume that the namespace prefixes in D1 will
   all be rewritten by the canonicalization method.  Let D23D D1, then
   modify the namespace prefixes in D2 and modify the XPath expression's
   references to namespace prefixes such that D2 and D1 remain logically
   equivalent.  Since namespace rewriting does not include occurrences
   of namespace references in attribute values and element content, the
   canonical form of D1 does not equal the canonical form of D2 because
   the XPath will be different.  Thus, although namespace rewriting
   normalizes the namespace declarations, the goal eliminating
   dependence on the particular namespace prefixes in the document is
   not achieved.




Boyer                        Informational                     [Page 22]

RFC 3076                     Canonical XML                    March 2001


   Moreover, it is possible to prove that namespace rewriting is
   harmful, rather than simply ineffective.  Let D1 be a document
   containing an XPath in an attribute value or element content that
   refers to namespace prefixes used in D1.  Further assume that the
   namespace prefixes in D1 will all be rewritten by the
   canonicalization method.  Now let D2 be the canonical form of D1.
   Clearly, the canonical forms of D1 and D2 are equivalent (since D2 is
   the canonical form of the canonical form of D1), yet D1 and D2 are
   not logically equivalent because the aforementioned XPath works in D1
   and doesn't work in D2.

   Note that an argument similar to this can be leveled against the XML
   canonicalization method based on any of the cases in the Limitations,
   the problems cannot easily be fixed in those cases, whereas here we
   have an opportunity to avoid purposefully introducing such a
   limitation.

   Applications that must test for logical equivalence must perform more
   sophisticated tests than mere octet stream comparison.  However, this
   is quite likely to be necessary in any case in order to test for
   logical equivalencies based on application rules as well as rules
   from other XML-related recommendations, working drafts, and future
   works.

4.5 Order of Namespace Declarations and Attributes

   The C14N-20000119 Canonical XML draft alternated between namespace
   declarations and attribute declarations.  This is part of the
   namespace prefix rewriting scheme, which this specification
   eliminates.  This specification follows the XPath data model of
   putting all namespace nodes before all attribute nodes.

4.6 Superfluous Namespace Declarations

   Unnecessary namespace declarations are not made in the canonical
   form.  Whether for an empty default namespace, a non-empty default
   namespace, or a namespace prefix binding, the XML canonicalization
   method omits a declaration if it determines that the immediate parent
   element in the canonical form has an equivalent declaration in scope.
   The root document element is handled specially since it has no parent
   element.  All namespace declarations in it are retained, except the
   declaration of an empty default namespace is automatically omitted.

   Relative to the method of simply rendering the entire namespace
   context of each element, implementations are not hindered by more
   than a constant factor in processing time and memory use.  The
   advantages include:




Boyer                        Informational                     [Page 23]

RFC 3076                     Canonical XML                    March 2001


       * Eliminates overrun of xmlns="" from canonical forms of
         applications that may not even use namespaces, or support them
         only minimally.
       * Eliminates namespace declarations from elements where they may
         not belong according to the application's content model,
         thereby simplifying the task of reattaching a document type
         declaration to a canonical form.

   Note that in document subsets, an element with omissions from its
   ancestral element chain will be rendered to the canonical form with
   namespace declarations that may have been made in its omitted
   ancestors, thus preserving the meaning of the element.

4.7 Propagation of Default Namespace Declaration in Document Subsets

   The XPath data model represents an empty default namespace with the
   absence of a node, not with the presence of a default namespace node
   having an empty value.  Thus, with respect to the fact that element
   e3 in the following examples is not namespace qualified, we cannot
   tell the difference between <e1 xmlns="a:b"><e2
   xmlns=""><e3/></e2></e1> versus <e1 xmlns="a:b"><e2><e3
   xmlns=""/></e2></e1>.  All we know is that e3 was not namespace
   qualified on input, so we preserve this information on output if e2
   is omitted so that e3 does not take on the default namespace
   qualification of e1.

4.8 Sorting Attributes by Namespace URI

   Given the requirement to preserve the namespace prefixes declared in
   a document, sorting attributes with the prefix, rather than the
   namespace URI, as the primary key is viable and easier to implement.

   However, the namespace URI was selected as the primary key because
   this is closer to the intent of the XML Names specification, which is
   to identify namespaces by URI and local name, not by a prefix and
   local name.  The effect of the sort is to group together all
   attributes that are in the same namespace.

Security Considerations

   Security issues are discussed in section 1.3.










Boyer                        Informational                     [Page 24]

RFC 3076                     Canonical XML                    March 2001


References

   [C14N-20000119]        Canonical XML Version 1.0, W3C Working Draft.
                          T.  Bray, J. Clark, J.  Tauber, and J. Cowan.
                          January 19, 2000.
                          http://www.w3.org/TR/2000/WD-xml-c14n-
                          20000119.html.

   [CharModel]            Working Draft. eds.  Martin J. Durst, Francois
                          Yergeau, Misha Wolf, Asmus Freytag, Tex Texin.
                          http://www.w3.org/TR/charmod/.

   [Cowan]                Example of Harmful Effect of Character Model
                          Normalization, Letter in XML Signature Working
                          Group Mail Archive. John Cowan, July 7, 2000
                          http://lists.w3.org/Archives/Public/w3c-ietf-
                          xmldsig/2000JulSep/0038.html.

   [Infoset]              XML Information Set, W3C Working Draft.  John
                          Cowan, Richard Tobin.
                          http://www.w3.org/TR/xml-infoset.

   [ISO-8859-1]           ISO-8859-1 Latin 1 Character Set.
                          http://www.utoronto.ca/webdocs/HTMLdocs/
                          NewHTML/iso_table.html or
                          http://www.iso.ch/cate/cat.html.

   [Keywords]             Bradner, S., "Key words for use in RFCs to
                          Indicate Requirement Levels", BCP 14, RFC
                          2119, March 1997.

   [Namespaces]           Namespaces in XML, W3C Recommendation. eds.
                          Tim Bray, Dave Hollander, and Andrew Layman.
                          http://www.w3.org/TR/REC-xml-names/

   [NFC]                  TR15, Unicode Normalization Forms. M. Davis,
                          M. Durst. Revision 18: November 1999.
                          http://www.unicode.org/unicode/reports/tr15/
                          tr15-18.html.

   [NFC-Corrigendum]      NFC-Corrigendum.  The Unicode Consortium.
                          http://www.unicode.org/unicode/uni2errata/
                          Normalization_Corrigendum.html.

   [Unicode]              The Unicode Standard, version 3.0. The Unicode
                          Consortium. ISBN 0-201-61633-5.
                          http://www.unicode.org/unicode/standard/
                          versions/Unicode3.0.html.



Boyer                        Informational                     [Page 25]

RFC 3076                     Canonical XML                    March 2001


   [UTF-16]               Hoffman, P. and F. Yergeau, "UTF-16, an
                          encoding of ISO 10646", RFC 2781, February
                          2000.

   [UTF-8]                Yergeau, F., "UTF-8, a transformation format
                          of ISO 10646", RFC 2279, January 1998.

   [URI]                  Berners-Lee, T., Fielding, R. and L. Masinter,
                          "Uniform Resource Identifiers (URI): Generic
                          Syntax", RFC 2396, August 1998.

   [XBase]                XML Base ed. Jonathan Marsh. 07 June 2000.
                          http://www.w3.org/TR/xmlbase/.

   [XML]                  Extensible Markup Language (XML) 1.0 (Second
                          Edition), W3C=20 Recommendation. eds. Tim
                          Bray, Jean Paoli, C. M. Sperberg-McQueen and
                          Eve Maler. 6 October 2000.
                          http://www.w3.org/TR/REC-xml.

   [XML DSig]             Eastlake, D., Reagle, J. and D. Solo, "XML-
                          Signature Syntax and Processing", RFC 3075,
                          July 2000.

   [XML Plenary Decision] W3C XML Plenary Decision on relative URI
                          References In namespace declarations, W3C
                          Document. 11 September 2000.
                          http://lists.w3.org/Archives/Public/xml-
                          uri/2000Sep/0083.html.

   [XPath]                XML Path Language (XPath) Version 1.0, , W3C
                          Recommendation. eds.  James Clark and Steven
                          DeRose. 16 November 1999.
                          http://www.w3.org/TR/1999/REC-xpath-19991116.

Author's Address

   John Boyer
   PureEdge Solutions Inc.

   Phone: 1-888-517-2675
   EMail: jboyer@PureEdge.com









Boyer                        Informational                     [Page 26]

RFC 3076                     Canonical XML                    March 2001


Acknowledgements

   The following people provided valuable feedback that improved the
   quality of this specification:

            * Doug Bunting, Ariba
            * John Cowan, Reuters
            * Martin J. Durst, W3C
            * Donald Eastlake 3rd, Motorola
            * Merlin Hughes, Baltimore
            * Gregor Karlinger, IAIK TU Graz
            * Susan Lesch, W3C
            * Jonathan Marsh, Microsoft
            * Joseph Reagle, W3C
            * Petteri Stenius, Done360
            * Kent Tamura, IBM



































Boyer                        Informational                     [Page 27]

RFC 3076                     Canonical XML                    March 2001


Full Copyright Statement

   Copyright (C) The Internet Society (2001).  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.



















Boyer                        Informational                     [Page 28]