File: rfc2070.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 (2411 lines) | stat: -rw-r--r-- 91,887 bytes parent folder | download | duplicates (8)
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
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411






Network Working Group                                       F. Yergeau
Request for Comments: 2070                           Alis Technologies
Category: Standards Track                                     G. Nicol
                                          Electronic Book Technologies
                                                              G. Adams
                                                              Spyglass
                                                             M. Duerst
                                                  University of Zurich
                                                          January 1997


         Internationalization of the Hypertext Markup Language

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   The Hypertext Markup Language (HTML) is a markup language used to
   create hypertext documents that are platform independent.  Initially,
   the application of HTML on the World Wide Web was seriously
   restricted by its reliance on the ISO-8859-1 coded character set,
   which is appropriate only for Western European languages.  Despite
   this restriction, HTML has been widely used with other languages,
   using other coded character sets or character encodings, at the
   expense of interoperability.

   This document is meant to address the issue of the
   internationalization (i18n, i followed by 18 letters followed by n)
   of HTML by extending the specification of HTML and giving additional
   recommendations for proper internationalization support.  A foremost
   consideration is to make sure that HTML remains a valid application
   of SGML, while enabling its use with all languages of the world.

Table of Contents

   1.  Introduction .................................................. 2
     1.1. Scope ...................................................... 2
     1.2. Conformance ................................................ 3
   2. The document character set ..................................... 4
     2.1. Reference processing model ................................. 4
     2.2. The document character set ................................. 6
     2.3. Undisplayable characters ................................... 8



Yergeau, et. al.            Standards Track                     [Page 1]

RFC 2070               HTML Internationalization            January 1997


   3. The LANG attribute.............................................. 8
   4. Additional entities, attributes and elements ................... 9
     4.1. Full Latin-1 entity set .................................... 9
     4.2. Markup for language-dependent presentation ................ 10
   5. Forms ..........................................................16
     5.1. DTD additions ..............................................16
     5.2. Form submission ............................................17
   6. External character encoding issues .............................18
   7. HTML public text ...............................................20
     7.1. HTML DTD ...................................................20
     7.2. SGML declaration for HTML ..................................35
     7.3. ISO Latin 1 character entity set ...........................37
   8. Security Considerations.........................................40
   Bibliography ......................................................40
   Authors' Addresses ................................................43

1.  Introduction

   The Hypertext Markup Language (HTML) is a markup language used to
   create hypertext documents that are platform independent.  Initially,
   the application of HTML on the World Wide Web was seriously
   restricted by its reliance on the ISO-8859-1 coded character set,
   which is appropriate only for Western European languages.  Despite
   this restriction, HTML has been widely used with other languages,
   using other coded character sets or character encodings, through
   various ad hoc extensions to the language [TAKADA].

   This document is meant to address the issue of the
   internationalization of HTML by extending the specification of HTML
   and giving additional recommendations for proper internationalization
   support.  It is in good part based on a paper by one of the authors
   on multilingualism on the WWW [NICOL].  A foremost consideration is
   to make sure that HTML remains a valid application of SGML, while
   enabling its use with all languages of the world.

   The specific issues addressed are the SGML document character set to
   be used for HTML, the proper treatment of the charset parameter
   associated with the "text/html" content type and the specification of
   some additional elements and entities.

1.1 Scope

   HTML has been in use by the World-Wide Web (WWW) global information
   initiative since 1990.  This specification extends the capabilities
   of HTML 2.0 (RFC 1866), primarily by removing the restriction to the
   ISO-8859-1 coded character set [ISO-8859].





Yergeau, et. al.            Standards Track                     [Page 2]

RFC 2070               HTML Internationalization            January 1997


   HTML is an application of ISO Standard 8879:1986, Information
   Processing Text and Office Systems -- Standard Generalized Markup
   Language (SGML) [ISO-8879]. The HTML Document Type Definition (DTD)
   is a formal definition of the HTML syntax in terms of SGML.  This
   specification amends the DTD of HTML 2.0 in order to make it
   applicable to documents encompassing a character repertoire much
   larger than that of ISO-8859-1, while still remaining SGML
   conformant.

   Both formal and actual development of HTML are advancing very fast.
   The features described in this document are designed so that they can
   (and should) be added to other forms of HTML besides that described
   in RFC 1866. Where indicated, attributes introduced here should be
   extended to the appropriate elements.

1.2 Conformance

   This specification changes slightly the conformance requirements of
   HTML documents and HTML user agents.

1.2.1 Documents

   All HTML 2.0 conforming documents remain conforming with this
   specification.  However, the extensions introduced here make valid
   certain documents that would not be HTML 2.0 conforming, in
   particular those containing characters or character references
   outside of the repertoire of ISO 8859-1, and those containing markup
   introduced herein.

1.2.2. User agents

   In addition to the requirements of RFC 1866, the following
   requirements are placed on HTML user agents.

      To ensure interoperability and proper support for at least ISO-
      8859-1 in an environment where character encoding schemes other
      than ISO-8859-1 are present, user agents MUST correctly interpret
      the charset parameter accompanying an HTML document received from
      the network.

      Furthermore, conforming user-agents MUST at least parse correctly
      all numeric character references within the range of ISO 10646-1
      [ISO-10646].

      Conforming user-agents are required to apply the BIDI presentation
      algorithm if they display right-to-left characters.  If there is
      no displayable right-to-left character in a document, there is no
      need to apply BIDI processing.



Yergeau, et. al.            Standards Track                     [Page 3]

RFC 2070               HTML Internationalization            January 1997


2. The document character set

2.1. Reference processing model

   This overview explains a reference processing model used for HTML,
   and in particular the SGML concept of a document character set. An
   actual implementation may widely differ in its internal workings from
   the model given below, but should behave as described to an outside
   observer.

   Because there are various widely differing encodings of text, SGML
   does not directly address how the sequence of characters that
   constitutes an SGML document in the abstract sense are encoded by
   means of a sequence of octets (or occasionally bit groups of another
   length than 8) in a concrete realization of the document such as a
   computer file. This encoding is called the external character
   encoding of the concrete SGML document, and it should be carefully
   distinguished from the document character set of the abstract HTML
   document.  SGML views the characters as a single set (called a
   "character repertoire"), and a "code set" that assigns an integer
   number (known as "character number") to each character in the
   repertoire.  The document character set declaration defines what each
   of the character numbers represents [GOLD90, p. 451].  In most cases,
   an SGML DTD and all documents that refer to it have a single document
   character set, and all markup and data characters are part of this
   set.

   HTML, as an application of SGML, does not directly address the
   question of the external character encoding. This is deferred to
   mechanisms external to HTML, such as MIME as used by the HTTP
   protocol or by electronic mail.

   For the HTTP protocol [RFC2068], the external character encoding is
   indicated by the "charset" parameter of the "Content-Type" field of
   the header of an HTTP response. For example, to indicate that the
   transmitted document is encoded in the "JUNET" encoding of Japanese
   [RFC1468], the header will contain the following line:

   Content-Type: text/html; charset=ISO-2022-JP

   The term "charset" in MIME is used to designate a character encoding,
   rather than merely a coded character set as the term may suggest.  A
   character encoding is a mapping (possibly many-to-one) of sequences
   of octets to sequences of characters taken from one or more character
   repertoires.

   The HTTP protocol also defines a mechanism for the client to specify
   the character encodings it can accept. Clients and servers are



Yergeau, et. al.            Standards Track                     [Page 4]

RFC 2070               HTML Internationalization            January 1997


   strongly requested to use these mechanisms to assure correct
   transmission and interpretation of any document. Provisions that can
   be taken to help correct interpretation, even in cases where a server
   or client do not yet use these mechanisms, are described in section
   6.

   Similarly, if HTML documents are transferred by electronic mail, the
   external character encoding is defined by the "charset" parameter of
   the "Content-Type" MIME header field [RFC2045], and defaults to US-
   ASCII in its absence.

   No mechanisms are currently standardized for indicating the external
   character encoding of HTML documents transferred by FTP or accessed
   in distributed file systems.

   In the case any other way of transferring and storing HTML documents
   are defined or become popular, it is advised that similar provisions
   be made to clearly identify the character encoding used and/or to use
   a single/default encoding capable of representing the widest range of
   characters used in an international context.

   Whatever the external character encoding may be, the reference
   processing model translates it to the document character set
   specified in Section 2.2 before processing specific to SGML/HTML.
   The reference processing model can be depicted as follows:

    [resource]->[decoder]->[entity ]->[ SGML ]->[application]->[display]
                           [manager]  [parser]
                                ^          |
                                |          |
                                +----------+

   The decoder is responsible for decoding the external representation
   of the resource to the document character set.  The entity manager,
   the parser, and the application deal only with characters of the
    document character set.  A display-oriented part of the application
   or the display machinery itself may again convert characters
   represented in the document character set to some other
   representation more suitable for their purpose. In any case, the
   entity manager, the parser, and the application, as far as character
   semantics are concerned, are using the HTML document character set
   only.

   An actual implementation may choose, or not, to translate the
   document into some encoding of the document character set as
   described above; the behaviour described by this reference processing
   model can be achieved otherwise.  This subject is well out of the
   scope of this specification, however, and the reader is invited to



Yergeau, et. al.            Standards Track                     [Page 5]

RFC 2070               HTML Internationalization            January 1997


   consult the SGML standard [ISO-8879] or an SGML handbook [BRYAN88]
   [GOLD90] [VANH90] [SQ91] for further information.

   The most important consequence of this reference processing model is
   that numeric character references are always resolved with respect to
   the fixed document character set, and thus to the same characters,
   whatever the external encoding actually used. For an example, see
   Section 2.2.

2.2. The document character set

   The document character set, in the SGML sense, is the Universal
   Character Set (UCS) of ISO 10646:1993 [ISO-10646], as amended.
   Currently, this is code-by-code identical with the Unicode standard,
   version 1.1 [UNICODE].

      NOTE -- implementers should be aware that ISO 10646 is amended
      from time to time; 4 amendments have been adopted since the
      initial 1993 publication, none of which significantly affects this
      specification.  A fifth amendment, now under consideration, will
      introduce incompatible changes to the standard: 6556 Korean Hangul
      syllables allocated between code positions 3400 and 4DFF
      (hexadecimal) will be moved to new positions (and 4516 new
      syllables added), thus making references to the old positions
      invalid.  Since the Unicode consortium has already adopted a
      corresponding amendment for inclusion in the forthcoming Unicode
      2.0, adoption of DAM 5 is considered likely and implementers
      should probably consider the old code positions as already
      invalid.  Despite this one-time change, the relevant standard
      bodies have committed themselves not to change any allocated code
      position in the future.  To encode Korean Hangul irrespective of
      these changes, the conjoining Hangul Jamo in the range 1110-11F9
      can be used.

   The adoption of this document character set implies a change in the
   SGML declaration specified in the HTML 2.0 specification (section 9.5
   of [RFC1866]).  The change amounts to removing the first BASESET
   specification and its accompanying DESCSET declaration, replacing
   them with the following declaration:












Yergeau, et. al.            Standards Track                     [Page 6]

RFC 2070               HTML Internationalization            January 1997


     BASESET "ISO Registration Number 177//CHARSET
              ISO/IEC 10646-1:1993 UCS-4 with implementation level 3
              //ESC 2/5 2/15 4/6"
     DESCSET  0   9     UNUSED
              9   2     9
              11  2     UNUSED
              13  1     13
              14  18    UNUSED
              32  95    32
              127 1     UNUSED
              128 32    UNUSED
              160 2147483486 160

   Making the UCS the document character set does not create non-
   conformance of any expression, construct or document that is
   conforming to HTML 2.0.  It does make conforming certain constructs
   that are not admissible in HTML 2.0.  One consequence is that data
   characters outside the repertoire of ISO-8859-1, but within that of
   UCS-4 become valid SGML characters.  Another is that the upper limit
   of the range of numeric character references is extended from 255 to
   2147483645; thus, И is a valid reference to a "CYRILLIC CAPITAL
   LETTER I".  [ERCS] is a good source of information on Unicode and
   SGML, although its scope and technical content differ greatly from
   this specification.

      NOTE -- the above SGML declaration, like that of HTML 2.0,
      specifies the character numbers 128 to 159 (80 to 9F hex) as
      UNUSED.  This means that numeric character references within that
      range (e.g.  ’) are illegal in HTML. Neither ISO 8859-1 nor
      ISO 10646 contain characters in that range, which is reserved for
      control characters.

   Another change was made from the HTML 2.0 SGML declaration, in the
   belief that the latter did not express its authors' true intent. The
   syntax character set declaration was changed from ISO 646.IRV:1983 to
   the newer ISO 646.IRV:1991, the latter, but not the former, being
   identical with US-ASCII.  In principle, this introduces an
   incompatibility with HTML 2.0, but in practice it should increase
   interoperability by i) having the SGML declaration say what everyone
   thinks and ii) making the syntax character set a proper subset of the
   document character set.  The characters that differ between the two
   versions of ISO 646.IRV are not actually used to express HTML syntax.

   ISO 10646-1:1993 is the most encompassing character set currently
   existing, and there is no other character set that could take its
   place as the document character set for HTML. If nevertheless for a
   specific application there is a need to use characters outside this
   standard, this should be done by avoiding any conflicts with present



Yergeau, et. al.            Standards Track                     [Page 7]

RFC 2070               HTML Internationalization            January 1997


   or future versions of ISO 10646, i.e. by assigning these characters
   to a private zone of the UCS-4 coding space [ISO-10646 section 11].
   Also, it should be borne in mind that such a use will be highly
   unportable; in many cases, it may be better to use inline bitmaps.

2.3. Undisplayable characters

   With the document character set being the full ISO 10646, the
   possibility that a character cannot be displayed due to lack of
   appropriate resources (fonts) cannot be avoided. Because there are
   many different things that can be done in such a case, this document
   does not prescribe any specific behaviour. Depending on the
   implementation, this may also be handled by the underlaying display
   system and not the application itself.  The following considerations,
   however, may be of help:

   -  A clearly visible, but unobtrusive behaviour should be preferred.
      Some documents may contain many characters that cannot be
      rendered, and so showing an alert for each of them is not the
      right thing to do.

   -  In case a numeric representation of the missing character is
      given, its hexadecimal (not decimal) form is to be preferred,
      because this form is used in character set standards [ERCS].

3. The LANG attribute

   Language tags can be used to control rendering of a marked up
   document in various ways: glyph disambiguation, in cases where the
   character encoding is not sufficient to resolve to a specific glyph;
   quotation marks; hyphenation; ligatures; spacing; voice synthesis;
   etc.  Independently of rendering issues, language markup is useful as
   content markup for purposes such as classification and searching.

   Since any text can logically be assigned a language, almost all HTML
   elements admit the LANG attribute.  The DTD reflects this; the only
   elements in this version of HTML without the LANG attribute are BR,
   HR, BASE, NEXTID, and META.  It is also intended that any new element
   introduced in later versions of HTML will admit the LANG attribute,
   unless there is a good reason not to do so.

   The language attribute, LANG, takes as its value a language tag that
   identifies a natural language spoken, written, or otherwise conveyed
   by human beings for communication of information to other human
   beings. Computer languages are explicitly excluded.






Yergeau, et. al.            Standards Track                     [Page 8]

RFC 2070               HTML Internationalization            January 1997


   The syntax and registry of HTML language tags is the same as that
   defined by RFC 1766 [RFC1766]. In summary, a language tag is composed
   of one or more parts: A primary language tag and a possibly empty
   series of subtags:

        language-tag  = primary-tag *( "-" subtag )
        primary-tag   = 1*8ALPHA
        subtag        = 1*8ALPHA

   Whitespace is not allowed within the tag and all tags are case-
   insensitive. The namespace of language tags is administered by the
   IANA. Example tags include:

       en, en-US, en-cockney, i-cherokee, x-pig-latin

   In the context of HTML, a language tag is not to be interpreted as a
   single token, as per RFC 1766, but as a hierarchy. For example, a
   user agent that adjusts rendering according to language should
   consider that it has a match when a language tag in a style sheet
   entry matches the initial portion of the language tag of an element.
   An exact match should be preferred. This interpretation allows an
   element marked up as, for instance, "en-US" to trigger styles
   corresponding to, in order of preference, US-English ("en-US") or
   'plain' or 'international' English ("en").

      NOTE -- using the language tag as a hierarchy does not imply that
      all languages with a common prefix will be understood by those
      fluent in one or more of those languages; it simply allows the
      user to request this commonality when it is true for that user.

   The rendering of elements may be affected by the LANG attribute.  For
   any element, the value of the LANG attribute overrides the value
   specified by the LANG attribute of any enclosing element and the
   value (if any) of the HTTP Content-Language header. If none of these
   are set, a suitable default, perhaps controlled by user preferences,
   by automatic context analysis or by the user's locale, should be used
   to control rendering.

4. Additional entities, attributes and elements

4.1. Full Latin-1 entity set

   According to the suggestion of section 14 of [RFC1866], the set of
   Latin-1 entities is extended to cover the whole right part of ISO-
   8859-1 (all code positions with the high-order bit set), including
   the already commonly used  , © and ®.  The names of the
   entities are taken from the appendices of SGML [ISO-8879].  A list is
   provided in section 7.3 of this specification.



Yergeau, et. al.            Standards Track                     [Page 9]

RFC 2070               HTML Internationalization            January 1997


4.2. Markup for language-dependent presentation

4.2.1. Overview

   For the correct presentation of text in certain languages
   (irrespective of formatting issues), some support in the form of
   additional entities and elements is needed.

   In particular, the following features are dealt with:

   -  Markup of bidirectional text, i.e. text where left-to-right and
      right-to-left scripts are mixed.

   -  Control of cursive joining behaviour in contexts where the
      default behaviour is not appropriate.

   -  Language-dependent rendering of short (in-line) quotations.

   -  Better justification control for languages where this is
      important.

   -  Superscripts and subscripts for languages where they appear as
      part of general text.

   Some of the above features need very little additional support;
   others need more. The additional features are introduced below with
   brief comments only. Explanations on cursive joining behaviour and
   bidirectional text follow later.  For cursive joining behaviour and
   bidirectional text, this document follows [UNICODE] in that: i)
   character semantics, where applicable, are identical to [UNICODE],
   and ii) where functionality is moved to HTML as a higher level
   protocol, this is done in a way that allows straightforward
   conversion to the lower-level mechanisms defined in [UNICODE].

4.2.2. List of entities, elements, and attributes

   First, a generic container is needed to carry the LANG and DIR (see
   below) attributes in cases where no other element is appropriate; the
   SPAN element is introduced for that purpose.












Yergeau, et. al.            Standards Track                    [Page 10]

RFC 2070               HTML Internationalization            January 1997


   A set of named character entities is added for use with bidirectional
   rendering and cursive joining control:

   <!ENTITY zwnj CDATA "&#8204;"--=zero width non-joiner-->
   <!ENTITY zwj  CDATA "&#8205;"--=zero width joiner-->
   <!ENTITY lrm  CDATA "&#8206;"--=left-to-right mark-->
   <!ENTITY rlm  CDATA "&#8207;"--=right-to-left mark-->

   These entities can be used in place of the corresponding formatting
   characters whenever convenient, for example to ease keyboard entry or
   when a formatting character is not available in the character
   encoding of the document.

   Next, an attribute called DIR is introduced, restricted to the values
   LTR (left-to-right) and RTL (right-to-left), for the indication of
   directionality in the context of bidirectional text (see 4.2.4 below
   for details).  Since any text and many other elements (e.g. tables)
   can logically be assigned a directionality, all elements except BR,
   HR, BASE, NEXTID, and META admit this attribute.  The DTD reflects
   this.  It is also intended that any new element introduced in later
   versions of HTML will admit the DIR attribute, unless there is a good
   reason not to do so.

   A new phrase-level element called BDO (BIDI Override) is introduced,
   which requires the DIR attribute to specify whether the override is
   left-to-right or right-to-left.  This element is required for
   bidirectional text control; for detailed explanations, see section
   4.2.4.

   The phrase-level element Q is introduced to allow language-dependent
   rendering of short quotations depending on language and platform
   capability. As the following examples show (rather poorly, because of
   the character set restriction of Internet specifications), the
   quotation marks surrounding the quotation are particularly affected:
   "a quotation in English", `another, slightly better one', ,,a
   quotation in German'', << a quotation in French >>. The contents of
   the Q element does not include quotation marks, which have to be
   added by the rendering process.

      NOTE -- Q elements can be nested. Many languages use different
      quotation styles for outer and inner quotations, and this should
      be respected by user-agents implementing this element.









Yergeau, et. al.            Standards Track                    [Page 11]

RFC 2070               HTML Internationalization            January 1997


      NOTE -- minimal support for the Q element is to surround the
      contents with some kind of quotes, like the plain ASCII double
      quotes.  As this is rather easy to implement, and as the lack of
      any visible quotes may affect the perceived meaning of the text,
      user-agent implementors are strongly requested to provide at least
      this minimal level of support.

   Many languages require superscript text for proper rendering: as an
   example, the French "Mlle Dupont" should have "lle" in superscript.
   The SUP element, and its sibling SUB for subscript text, are
   introduced to allow proper markup of such text.  SUP and SUB contents
   are restricted to PCDATA to avoid nesting problems.

   Finally, in many languages text justification is much more important
   than it is in Western languages, and justifies markup.  The ALIGN
   attribute, admitting values of LEFT, RIGHT, CENTER and JUSTIFY, is
   added to a selection of elements where it makes sense (the block-like
   P, HR, H1 to H6, OL, UL, DIR, MENU, LI, BLOCKQUOTE and ADDRESS).  If
   a user-agent chooses to have LEFT as a default for blocks of left-
   to-right directionality, it should use RIGHT for blocks of right-to-
   left directionality.

      NOTE -- RFC 1866 section 4.2.2 specifies that an HTML user agent
      should treat an end of line as a word space, except in
      preformatted text.  This should be interpreted in the context of
      the script being processed, as the way words are separated in
      writing is script-dependent.  For some scripts (e.g. Latin), a
      word space is just a space, but in other scripts (e.g. Thai) it is
      a zero-width word separator, whereas in yet other scripts (e.g.
      Japanese) it is nothing at all, i.e. totally ignored.

      NOTE -- the SOFT HYPHEN character (U+00AD) needs special attention
      from user-agent implementers.  It is present in many character
      sets (including the whole ISO 8859 series and, of course, ISO
      10646), and can always be included by means of the reference
      &shy;.  Its semantics are different from the plain HYPHEN: it
      indicates a point in a word where a line break is allowed.  If the
      line is indeed broken there, a hyphen must be displayed at the end
      of the first line.  If not, the character is not dispalyed at all.
      In operations like searching and sorting, it must always be
      ignored.










Yergeau, et. al.            Standards Track                    [Page 12]

RFC 2070               HTML Internationalization            January 1997


   In the DTD, the LANG and DIR attributes are grouped together in a
   parameter entity called attrs.  To parallel RFC 1942 [RFC1942], the
   ID and CLASS attributes are also included in attrs. The ID and CLASS
   attributes are required for use with style sheets, and RFC 1942
   defines them as follows:

ID      Used to define a document-wide identifier. This can be used
        for naming positions within documents as the destination of a
        hypertext link. It may also be used by style sheets for
        rendering an element in a unique style. An ID attribute value is
        an SGML NAME token. NAME tokens are formed by an initial
        letter followed by letters, digits, "-" and "." characters. The
        letters are restricted to A-Z and a-z.

CLASS   A space separated list of SGML NAME tokens. CLASS names
        specify that the element belongs to the corresponding named
        classes. It allows authors to distinguish different roles
        played by the same tag. The classes may be used by style
        sheets to provide different renderings as appropriate to
        these roles.

4.2.3. Cursive joining behaviour

   Markup is needed in some cases to force cursive joining behavior in
   contexts in which it would not normally occur, or to block it when it
   would normally occur.

   The zero-width joiner and non-joiner (&zwj; and &zwnj;) are used to
   control cursive joining behaviour.  For example, ARABIC LETTER HEH is
   used in isolation to abbreviate "Hijri" (the Islamic calendrical
   system); however, the initial form of the letter is desired, because
   the isolated form of HEH looks like the digit five as employed in
   Arabic script.  This is obtained by following the HEH with a zero-
   width joiner whose only effect is to provide context.  In Persian
   texts, there are cases where a letter that normally would join a
   subsequent letter in a cursive connection does not.  Here a zero-
   width non- joiner is used.

4.2.4. Bidirectional text

   Many languages are written in horizontal lines from left to right,
   while others are written from right to left.  When both writing
   directions are present, one talks of bidirectional text (BIDI for
   short). BIDI text requires markup in special circumstances where
   ambiguities as to the directionality of some characters have to be
   resolved.  This markup affects the ability to render BIDI text in a
   semantically legible fashion.  That is, without this special BIDI
   markup, cases arise which would prevent *any* rendering whatsoever



Yergeau, et. al.            Standards Track                    [Page 13]

RFC 2070               HTML Internationalization            January 1997


   that reflected the basic meaning of the text. Plain text may contain
   BIDI markup in the form of special-purpose formatting characters.

   This is also possible in HTML, which includes the five BIDI-related
   formatting characters (202A - 202E) of ISO 10646.  As an alternative,
   HTML provides equivalent SGML markup.

   BIDI is a complex issue, and conversion of logical text sequences to
   display sequences has to be done according to the algorithm and
   character properties specified in [UNICODE]. Here, explanations are
   given only as far as they are needed to understand the necessity of
   the features introduced and to define their exact semantics.

   The Unicode BIDI algorithm is based on the individual characters of a
   text being stored in logical order, that is the order in which they
   are normally input and in which the corresponding sounds are normally
   spoken. To make rendering of logical order text possible, the
   algorithm assigns a directionality property to each character, e.g.
   Latin letters are specified to have a left-to-right direction, Arabic
   and Hebrew characters have a right-to-left direction.

   The left-to-right and right-to-left marks (&lrm; and &rlm;) are used
   to disambiguate directionality of neutral characters. For example,
   when a double quote sits between an Arabic and a Latin letter, its
   direction is ambiguous; if a directional mark is added on one side
   such that the quotation mark is surrounded by characters of only one
   directionality, the ambiguity is removed. These characters are like
   zero width spaces which have a directional property (but no word/line
   break property).

   Nested embeddings of contra-directional text runs, due to nested
   quotations or to the pasting of text from one BIDI context to
   another, is also a case where the implicit directionality of
   characters is not sufficient, requiring markup.  Also, it is
   frequently desirable to specify the basic directionality of a block
   of text. For these purposes, the DIR attribute is used.

   On block-type elements, the DIR attribute indicates the base
   directionality of the text in the block; if omitted it is inherited
   from the parent element.  The default directionality of the overall
   HTML document is left-to-right.

   On inline elements, it makes the element start a new embedding level
   (to be explained below); if omitted the inline element does not start
   a new embedding level.






Yergeau, et. al.            Standards Track                    [Page 14]

RFC 2070               HTML Internationalization            January 1997


      NOTE -- the PRE, XMP and LISTING elements admit the DIR attribute.
      Their contents should not be considered as preformatted with
      respect to bidirectional layout, but the BIDI algorithm should be
      applied to each line of text.

   Following is an example of a case where embedding is needed, showing
   its effect:

      Given the following latin (upper case) and arabic (lower case)
      letters in backing store with the specified embeddings:

      <SPAN DIR=LTR> AB <SPAN DIR=RTL> xy <SPAN DIR=LTR> CD </SPAN> zw
      </SPAN> EF </SPAN>

      One gets the following rendering (with [] showing the directional
      transitions):

      [ AB [ wz [ CD ] yx ] EF ]

      On the other hand, without this markup and with a base direction
      of LTR one gets the following rendering:

      [ AB [ yx ] CD [ wz ] EF ]

      Notice that yx is on the left and wz on the right unlike the above
      case where the embedding levels are used.  Without the embedding
      markup one has at most two levels: a base directional level and a
      single counterflow directional level.

   The DIR attribute on inline elements is equivalent to the formatting
   characters  LEFT-TO-RIGHT EMBEDDING (202A) and RIGHT-TO-LEFT
   EMBEDDING (202B) of ISO 10646.  The end tag of the element is
   equivalent to the POP DIRECTIONAL FORMATTING (202C) character.

   Directional override, as provided by the BDO element, is needed to
   deal with unusual short pieces of text in which directionality cannot
   be resolved from context in an unambiguous fashion. For example, it
   can be used to force left-to-right (or right-to-left) display of part
   numbers composed of Latin letters, digits and Hebrew letters.

   The effect of BDO is to force the directionality of all characters
   within it to the value of DIR, irrespective of their intrinsic
   directional properties.  It is equivalent to using the LEFT-TO-RIGHT
   OVERRIDE (202D) or RIGHT-TO-LEFT OVERRIDE (202E) characters of ISO
   10646, the end tag again being equivalent to the POP DIRECTIONAL
   FORMATTING (202C) character.





Yergeau, et. al.            Standards Track                    [Page 15]

RFC 2070               HTML Internationalization            January 1997


      NOTE -- authors and authoring software writers should be aware
      that conflicts can arise if the DIR attribute is used on inline
      elements (including BDO) concurrently with the use of the
      corresponding ISO 10646 formatting characters.

      Preferably one or the other should be used exclusively; the markup
      method is better able to guarantee document structural integrity,
      and alleviates some problems when editing bidirectional HTML text
      with a simple text editor, but some software may be more apt at
      using the 10646 characters.  If both methods are used, great care
      should be exercised to insure proper nesting of markup and
      directional embedding or override; otherwise, rendering results
      are undefined.

5. Forms

5.1. DTD additions

   It is natural to expect input in any language in forms, as they
   provide one of the only ways of obtaining user input. While this is
   primarily a UI issue, there are some things that should be specified
   at the HTML level to guide behavior and promote interoperability.

   To ensure full interoperability, it is necessary for the user agent
   (and the user) to have an indication of the character encoding(s)
   that the server providing a form will be able to handle upon
   submission of the filled-in form.  Such an indication is provided by
   the ACCEPT-CHARSET attribute of the INPUT and TEXTAREA elements,
   modeled on the HTTP Accept-Charset header (see [HTTP-1.1]), which
   contains a space and/or comma delimited list of character sets
   acceptable to the server.  A user agent may want to somehow advise
   the user of the contents of this attribute, or to restrict his
   possibility to enter characters outside the repertoires of the listed
   character sets.

      NOTE -- The list of character sets is to be interpreted as an
      EXCLUSIVE-OR list; the server announces that it is ready to accept
      any ONE of these character encoding schemes for each part of a
      multipart entity.  The client may perform character encoding
      translation to satisfy the server if necessary.

      NOTE -- The default value for the ACCEPT-CHARSET attribute of an
      INPUT or TEXTAREA element is the reserved value "UNKNOWN".  A user
      agent may interpret that value as the character encoding scheme
      that was used to transmit the document containing that element.






Yergeau, et. al.            Standards Track                    [Page 16]

RFC 2070               HTML Internationalization            January 1997


5.2. Form submission

   The HTML 2.0 form submission mechanism, based on the "application/x-
   www-form-urlencoded" media type, is ill-equipped with regard to
   internationalization.  In fact, since URLs are restricted to ASCII
   characters, the mechanism is akward even for ISO-8859-1 text.
   Section 2.2 of [RFC1738] specifies that octets may be encoded using
   the "%HH" notation, but text submitted from a form is composed of
   characters, not octets.  Lacking a specification of a character
   encoding scheme, the "%HH" notation has no well-defined meaning.

   The best solution is to use the "multipart/form-data" media type
   described in [RFC1867] with the POST method of form submission.  This
   mechanism encapsulates the value part of each name-value pair in a
   body-part of a multipart MIME body that is sent as the HTTP entity;
   each body part can be labeled with an appropriate Content-Type,
   including if necessary a charset parameter that specifies the
   character encoding scheme.  The changes to the DTD necessary to
   support this method of form submission have been incorporated in the
   DTD included in this specification.

   A less satisfactory solution is to add a MIME charset parameter to
   the "application/x-www-form-urlencoded" media type specifier sent
   along with a POST method form submission, with the understanding that
   the URL encoding of [RFC1738] is applied on top of the specified
   character encoding, as a kind of implicit Content-Transfer-Encoding.

   One problem with both solutions above is that current browsers do not
   generally allow for bookmarks to specify the POST method; this should
   be improved.  Conversely, the GET method could be used with the form
   data transmitted in the body instead of in the URL.  Nothing in the
   protocol seems to prevent it, but no implementations appear to exist
   at present.

   How the user agent determines the encoding of the text entered by the
   user is outside the scope of this specification.

      NOTE -- Designers of forms and their handling scripts should be
      aware of an important caveat: when the default value of a field
      (the VALUE attribute) is returned upon form submission (i.e. the
      user did not modify this value), it cannot be guaranteed to be
      transmitted as a sequence of octets identical to that in the
      source document -- only as a possibly different but valid encoding
      of the same sequence of text elements.  This may be true even if
      the encoding of the document containing the form and that used for
      submission are the same.





Yergeau, et. al.            Standards Track                    [Page 17]

RFC 2070               HTML Internationalization            January 1997


      Differences can occur when a sequence of characters can be
      represented by various sequences of octets, and also when a
      composite sequence (a base character plus one or more combining
      diacritics) can be represented by either a different but
      equivalent composite sequence or by a fully precomposed character.
      For instance, the UCS-2 sequence 00EA+0323 (LATIN SMALL LETTER E
      WITH CIRCUMFLEX ACCENT + COMBINING DOT BELOW) may be transformed
      into 1EC7 (LATIN SMALL LETTER E WITH CIRCUMFLEX ACCENT AND DOT
      BELOW), into 0065+0302+0323 (LATIN SMALL LETTER E + COMBINING
      CIRCUMFLEX ACCENT + COMBINING DOT BELOW), as well as into other
      equivalent composite sequences.

6. External character encoding issues

   Proper interpretation of a text document requires that the character
   encoding scheme be known.  Current HTTP servers, however, do not
   generally include an appropriate charset parameter with the Content-
   Type header.  This is bad behaviour, which is even encouraged by the
   continued existence of browsers that declare an unrecognized media
   type when they receive a charset parameter.  User agent
   implementators are strongly encouraged to make their software
   tolerant of this parameter, even if they cannot take advantage of it.
   Proper labelling is highly desirable, but some preventive measures
   can be taken to minimize the detrimental effects of its absence:

   In the case where a document is accessed from a hyperlink in an
   origin HTML document, a CHARSET attribute is added to the attribute
   list of elements with link semantics (A and LINK), specifically by
   adding it to the linkExtraAttributes entity.  The value of that
   attribute is to be considered a hint to the User Agent as to the
   character encoding scheme used by the resource pointed to by the
   hyperlink; it should be the appropriate value of the MIME charset
   parameter for that resource.

   In any document, it is possible to include an indication of the
   encoding scheme like the following, as early as possible within the
   HEAD of the document:

    <META HTTP-EQUIV="Content-Type"
     CONTENT="text/html; charset=ISO-2022-JP">

   This is not foolproof, but will work if the encoding scheme is such
   that ASCII-valued octets stand for ASCII characters only at least
   until the META element is parsed.  Note that there are better ways
   for a server to obtain character encoding information, instead of the
   unreliable META above; see [NICOL2] for some details and a proposal.





Yergeau, et. al.            Standards Track                    [Page 18]

RFC 2070               HTML Internationalization            January 1997


   For definiteness, the "charset" parameter received from the source of
   the document should be considered the most authoritative, followed in
   order of preference by the contents of a META element such as the
   above, and finally the CHARSET parameter of the anchor that was
   followed (if any).

   When HTML text is transmitted directly in UCS-2 or UCS-4 form, the
   question of byte order arises: does the high-order byte of each
   multi-byte character come first or last?  For definiteness, this
   specification recommends that UCS-2 and UCS-4 be transmitted in big-
   endian byte order (high order byte first), which corresponds to the
   established network byte order for two- and four-byte quantities, to
   the ISO 10646 requirement and Unicode recommendation for serialized
   text data and to RFC 1641.  Furthermore, to maximize chances of
   proper interpretation, it is recommended that documents transmitted
   as UCS-2 or UCS-4 always begin with a ZERO-WIDTH NON-BREAKING SPACE
   character (hexadecimal FEFF or 0000FEFF) which, when byte-reversed
   becomes number FFFE or FFFE0000, a character guaranteed to be never
   assigned.  Thus, a user-agent receiving an FFFE as the first octets
   of a text would know that bytes have to be reversed for the remainder
   of the text.

   There exist so-called UCS Transformation Formats than can be used to
   transmit UCS data, in addition to UCS-2 and UCS-4.  UTF-7 [RFC1642]
   and UTF-8 [UTF-8] have favorable properties (no byte-ordering
   problem, different flavours of ASCII compatibility) that make them
   worthy of consideration, especially for transmission of multilingual
   text.  Another encoding scheme, MNEM [RFC1345], also has interesting
   properties and the capability to transmit the full UCS.  The UTF-1
   transformation format of ISO 10646:1993 (registered by IANA as ISO-
   10646-UTF-1), has been removed from ISO 10646 by amendment 4, and
   should not be used.



















Yergeau, et. al.            Standards Track                    [Page 19]

RFC 2070               HTML Internationalization            January 1997


7. HTML Public Text

7.1. HTML DTD

   This section contains a DTD for HTML based on the HTML 2.0 DTD of RFC
   1866, incorporating the changes for file upload as specified in RFC
   1867, and the changes deriving from this document.

   <!--    html.dtd

           Document Type Definition for the HyperText Markup Language,
           extended for internationalisation (HTML DTD)

           Last revised: 96/08/07

        Authors: Daniel W. Connolly <connolly@w3.org>
                    Francois Yergeau <yergeau@alis.com>
        See Also:
          http://www.w3.org/hypertext/WWW/MarkUp/MarkUp.html
   -->

   <!ENTITY % HTML.Version
           "-//IETF//DTD HTML i18n//EN"

           -- Typical usage:

               <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML i18n//EN">
               <html>
               ...
               </html>
           --
           >


   <!--============ Feature Test Entities ========================-->

   <!ENTITY % HTML.Recommended "IGNORE"
        -- Certain features of the language are necessary for
           compatibility with widespread usage, but they may
           compromise the structural integrity of a document.
           This feature test entity enables a more prescriptive
           document type definition that eliminates
           those features.
        -->

   <![ %HTML.Recommended [
           <!ENTITY % HTML.Deprecated "IGNORE">
   ]]>



Yergeau, et. al.            Standards Track                    [Page 20]

RFC 2070               HTML Internationalization            January 1997


   <!ENTITY % HTML.Deprecated "INCLUDE"
        -- Certain features of the language are necessary for
           compatibility with earlier versions of the specification,
           but they tend to be used and implemented inconsistently,
           and their use is deprecated. This feature test entity
           enables a document type definition that eliminates
           these features.
        -->

   <!ENTITY % HTML.Highlighting "INCLUDE"
        -- Use this feature test entity to validate that a
           document uses no highlighting tags, which may be
           ignored on minimal implementations.
        -->

   <!ENTITY % HTML.Forms "INCLUDE"
           -- Use this feature test entity to validate that a document
              contains no forms, which may not be supported in minimal
              implementations
           -->

   <!--============== Imported Names ==============================-->

   <!ENTITY % Content-Type "CDATA"
           -- meaning an internet media type
              (aka MIME content type, as per RFC2045)
           -->

   <!ENTITY % HTTP-Method "GET | POST"
           -- as per HTTP specification, RFC2068
           -->

   <!--========= DTD "Macros" =====================-->

   <!ENTITY % heading "H1|H2|H3|H4|H5|H6">

   <!ENTITY % list " UL | OL | DIR | MENU " >

   <!ENTITY % attrs -- common attributes for elements --
            "LANG  NAME      #IMPLIED  -- RFC 1766 language tag --
             DIR  (ltr|rtl)  #IMPLIED  -- text directionnality --
             ID      ID      #IMPLIED  -- element identifier
                                          (from RFC1942) --
             CLASS   NAMES   #IMPLIED  -- for subclassing elements
                                          (from RFC1942) --">

   <!ENTITY % just -- an attribute for text justification --
            "ALIGN  (left|right|center|justify)  #IMPLIED"



Yergeau, et. al.            Standards Track                    [Page 21]

RFC 2070               HTML Internationalization            January 1997


            -- default is left for ltr paragraphs, right for rtl -- >

   <!--======= Character mnemonic entities =================-->

   <!ENTITY % ISOlat1 PUBLIC
     "ISO 8879-1986//ENTITIES Added Latin 1//EN//HTML">
   %ISOlat1;

   <!ENTITY amp CDATA "&#38;"     -- ampersand          -->
   <!ENTITY gt CDATA "&#62;"      -- greater than       -->
   <!ENTITY lt CDATA "&#60;"      -- less than          -->
   <!ENTITY quot CDATA "&#34;"    -- double quote       -->

   <!--Entities for language-dependent presentation (BIDI and
       contextual analysis) -->
   <!ENTITY zwnj CDATA "&#8204;"-- zero width non-joiner-->
   <!ENTITY zwj  CDATA "&#8205;"-- zero width joiner-->
   <!ENTITY lrm  CDATA "&#8206;"-- left-to-right mark-->
   <!ENTITY rlm  CDATA "&#8207;"-- right-to-left mark-->


   <!--========= SGML Document Access (SDA) Parameter Entities =====-->

   <!-- HTML contains SGML Document Access (SDA) fixed attributes
   in support of easy transformation to the International Committee
   for Accessible Document Design (ICADD) DTD
         "-//EC-USA-CDA/ICADD//DTD ICADD22//EN".
   ICADD applications are designed to support usable access to
   structured information by print-impaired individuals through
   Braille, large print and voice synthesis.  For more information on
   SDA & ICADD:
           - ISO 12083:1993, Annex A.8, Facilities for Braille,
          large print and computer voice
           - ICADD ListServ
          <ICADD%ASUACAD.BITNET@ARIZVM1.ccit.arizona.edu>
           - Usenet news group bit.listserv.easi
           - Recording for the Blind, +1 800 221 4792
   -->

   <!ENTITY % SDAFORM  "SDAFORM  CDATA  #FIXED"
          -- one to one mapping        -->
   <!ENTITY % SDARULE  "SDARULE  CDATA  #FIXED"
          -- context-sensitive mapping -->
   <!ENTITY % SDAPREF  "SDAPREF  CDATA  #FIXED"
          -- generated text prefix     -->
   <!ENTITY % SDASUFF  "SDASUFF  CDATA  #FIXED"
          -- generated text suffix     -->
   <!ENTITY % SDASUSP  "SDASUSP  NAME   #FIXED"



Yergeau, et. al.            Standards Track                    [Page 22]

RFC 2070               HTML Internationalization            January 1997


          -- suspend transform process -->


   <!--========== Text Markup =====================-->

   <![ %HTML.Highlighting [

   <!ENTITY % font " TT | B | I ">

   <!ENTITY % phrase "EM | STRONG | CODE | SAMP | KBD | VAR | CITE ">

   <!ENTITY % text "#PCDATA|A|IMG|BR|%phrase|%font|SPAN|Q|BDO|SUP|SUB">

   <!ELEMENT (%font;|%phrase) - - (%text)*>
   <!ATTLIST ( TT | CODE | SAMP | KBD | VAR )
           %attrs;
           %SDAFORM; "Lit"
           >

   <!ATTLIST ( B | STRONG )
           %attrs;
           %SDAFORM; "B"
           >
   <!ATTLIST ( I | EM | CITE )
           %attrs;
           %SDAFORM; "It"
           >

   <!-- <TT>       Typewriter text                         -->
   <!-- <B>        Bold text                               -->
   <!-- <I>        Italic text                             -->

   <!-- <EM>       Emphasized phrase                       -->
   <!-- <STRONG>   Strong emphasis                         -->
   <!-- <CODE>     Source code phrase                      -->
   <!-- <SAMP>     Sample text or characters               -->
   <!-- <KBD>      Keyboard phrase, e.g. user input        -->
   <!-- <VAR>      Variable phrase or substitutable        -->
   <!-- <CITE>     Name or title of cited work             -->

   <!ENTITY % pre.content "#PCDATA|A|HR|BR|%font|%phrase|SPAN|BDO">

   ]]>

   <!ENTITY % text "#PCDATA|A|IMG|BR|SPAN|Q|BDO|SUP|SUB">

   <!ELEMENT BR    - O EMPTY>
   <!ATTLIST BR



Yergeau, et. al.            Standards Track                    [Page 23]

RFC 2070               HTML Internationalization            January 1997


           %SDAPREF; "&#RE;"
           >

   <!-- <BR>       Line break      -->

   <!ELEMENT SPAN - - (%text)*>
   <!ATTLIST SPAN
           %attrs;
           %SDAFORM; "other #Attlist"
   >

   <!-- <SPAN>             Generic inline container  -->
   <!-- <SPAN DIR=...>     New counterflow embedding -->
   <!-- <SPAN LANG="...">  Language of contents      -->

   <!ELEMENT Q - - (%text)*>
   <!ATTLIST Q
           %attrs;
           %SDAPREF; '"'
           %SDASUFF; '"'
           >

   <!-- <Q>         Short quotation              -->
   <!-- <Q LANG=xx> Language of quotation is xx  -->
   <!-- <Q DIR=...> New conterflow embedding     -->

   <!ELEMENT BDO - - (%text)+>
   <!ATTLIST BDO
           LANG   NAME      #IMPLIED
           DIR    (ltr|rtl) #REQUIRED
           ID     ID        #IMPLIED
           CLASS  NAMES     #IMPLIED
           %SDAPREF "Bidi Override #Attval(DIR): "
           %SDASUFF "End Bidi"
           >

   <!-- <BDO DIR=...>   Override directionality of text to value of DIR -->
   <!-- <BDO LANG=...>  Language of contents                            -->

   <!ELEMENT (SUP|SUB) - - (#PCDATA)>
   <!ATTLIST (SUP)
           %attrs;
           %SDAPREF "Superscript(#content)"
           >
   <!ATTLIST (SUB)
           %attrs;
           %SDAPREF "Subscript(#content)"
           >



Yergeau, et. al.            Standards Track                    [Page 24]

RFC 2070               HTML Internationalization            January 1997


   <!-- <SUP>      Superscript              -->
   <!-- <SUB>      Subscript                -->

   <!--========= Link Markup ======================-->

   <!ENTITY % linkType "NAMES">

   <!ENTITY % linkExtraAttributes
           "REL %linkType #IMPLIED
           REV %linkType #IMPLIED
           URN CDATA #IMPLIED
           TITLE CDATA #IMPLIED
           METHODS NAMES #IMPLIED
           CHARSET NAME #IMPLIED
           ">

   <![ %HTML.Recommended [
           <!ENTITY % A.content   "(%text)*"

           -- <H1><a name="xxx">Heading</a></H1>
                   is preferred to
              <a name="xxx"><H1>Heading</H1></a>
           -->
   ]]>

   <!ENTITY % A.content   "(%heading|%text)*">

   <!ELEMENT A     - - %A.content -(A)>
   <!ATTLIST A
           %attrs;
           HREF CDATA #IMPLIED
           NAME CDATA #IMPLIED
           %linkExtraAttributes;
           %SDAPREF; "<Anchor: #AttList>"
           >
   <!-- <A>       Anchor; source/destination of link -->
   <!-- <A NAME="..."> Name of this anchor           -->
   <!-- <A HREF="..."> Address of link destination        -->
   <!-- <A URN="...">  Permanent address of destination   -->
   <!-- <A REL=...>    Relationship to destination        -->
   <!-- <A REV=...>    Relationship of destination to this     -->
   <!-- <A TITLE="...">     Title of destination (advisory)         -->
   <!-- <A METHODS="...">   Operations on destination (advisory)    -->
   <!-- <A CHARSET="...">   Charset of destination (advisory)  -->
   <!-- <A LANG="...">     Language of contents btw <A> and </A>   -->
   <!-- <A DIR=...>        Contents is a new counterflow embedding -->

   <!--========== Images ==========================-->



Yergeau, et. al.            Standards Track                    [Page 25]

RFC 2070               HTML Internationalization            January 1997


   <!ELEMENT IMG    - O EMPTY>
   <!ATTLIST IMG
           %attrs;
           SRC CDATA  #REQUIRED
           ALT CDATA #IMPLIED
           ALIGN (top|middle|bottom) #IMPLIED
           ISMAP (ISMAP) #IMPLIED
           %SDAPREF; "<Fig><?SDATrans Img: #AttList>#AttVal(Alt)</Fig>"
           >

   <!-- <IMG>              Image; icon, glyph or illustration      -->
   <!-- <IMG SRC="...">    Address of image object                 -->
   <!-- <IMG ALT="...">    Textual alternative                     -->
   <!-- <IMG ALIGN=...>    Position relative to text               -->
   <!-- <IMG LANG=...>     Image contains "text" in that language  -->
   <!-- <IMG DIR=...>      Inline image acts as a RTL or LTR
                           embedding w/r to BIDI algorithm         -->
   <!-- <IMG ISMAP>        Each pixel can be a link                -->

   <!--========== Paragraphs=======================-->

   <!ELEMENT P     - O (%text)*>
   <!ATTLIST P
           %attrs;
           %just;
           %SDAFORM; "Para"
           >

   <!-- <P>             Paragraph                           -->
   <!-- <P LANG="...">  Language of paragraph text          -->
   <!-- <P DIR=...>     Base directionality of paragraph    -->
   <!-- <P ALIGN=...>   Paragraph alignment (justification) -->

   <!--========== Headings, Titles, Sections ===============-->

   <!ELEMENT HR    - O EMPTY>
   <!ATTLIST HR
           %just;
           %SDAPREF; "&#RE;&#RE;"
           >

   <!-- <HR>       Horizontal rule -->

   <!ELEMENT ( %heading )  - -  (%text;)*>
   <!ATTLIST H1
           %attrs;
           %just;
           %SDAFORM; "H1"



Yergeau, et. al.            Standards Track                    [Page 26]

RFC 2070               HTML Internationalization            January 1997


           >
   <!ATTLIST H2
           %attrs;
           %just;
           %SDAFORM; "H2"
           >
   <!ATTLIST H3
           %attrs;
           %just;
           %SDAFORM; "H3"
           >
   <!ATTLIST H4
           %attrs;
           %just;
           %SDAFORM; "H4"
           >
   <!ATTLIST H5
           %attrs;
           %just;
           %SDAFORM; "H5"
           >
   <!ATTLIST H6
           %attrs;
           %just;
           %SDAFORM; "H6"
           >

   <!-- <H1>       Heading, level 1 -->
   <!-- <H2>       Heading, level 2 -->
   <!-- <H3>       Heading, level 3 -->
   <!-- <H4>       Heading, level 4 -->
   <!-- <H5>       Heading, level 5 -->
   <!-- <H6>       Heading, level 6 -->


   <!--========== Text Flows ======================-->

   <![ %HTML.Forms [
           <!ENTITY % block.forms "BLOCKQUOTE | FORM | ISINDEX">
   ]]>

   <!ENTITY % block.forms "BLOCKQUOTE">

   <![ %HTML.Deprecated [
           <!ENTITY % preformatted "PRE | XMP | LISTING">
   ]]>

   <!ENTITY % preformatted "PRE">



Yergeau, et. al.            Standards Track                    [Page 27]

RFC 2070               HTML Internationalization            January 1997


   <!ENTITY % block "P | %list | DL
           | %preformatted
           | %block.forms">

   <!ENTITY % flow "(%text|%block)*">

   <!ENTITY % pre.content "#PCDATA | A | HR | BR | SPAN | BDO">
   <!ELEMENT PRE - - (%pre.content)*>
   <!ATTLIST PRE
           %attrs;
           WIDTH NUMBER #implied
           %SDAFORM; "Lit"
           >

   <!-- <PRE>              Preformatted text                    -->
   <!-- <PRE WIDTH=...>    Maximum characters per line          -->
   <!-- <PRE DIR=...>      Base direction of preformatted block -->
   <!-- <PRE LANG=...>     Language of contents                 -->

   <![ %HTML.Deprecated [

   <!ENTITY % literal "CDATA"
           -- historical, non-conforming parsing mode where
              the only markup signal is the end tag
              in full
           -->

   <!ELEMENT (XMP|LISTING) - -  %literal>
   <!ATTLIST XMP
           %attrs;
           %SDAFORM; "Lit"
           %SDAPREF; "Example:&#RE;"
           >
   <!ATTLIST LISTING
           %attrs;
           %SDAFORM; "Lit"
           %SDAPREF; "Listing:&#RE;"
           >

   <!-- <XMP>              Example section         -->
   <!-- <LISTING>          Computer listing        -->

   <!ELEMENT PLAINTEXT - O %literal>
   <!-- <PLAINTEXT>        Plain text passage      -->

   <!ATTLIST PLAINTEXT
           %attrs;
           %SDAFORM; "Lit"



Yergeau, et. al.            Standards Track                    [Page 28]

RFC 2070               HTML Internationalization            January 1997


           >
   ]]>


   <!--========== Lists ==================-->

   <!ELEMENT DL    - -  (DT | DD)+>
   <!ATTLIST DL
           %attrs;
           COMPACT (COMPACT) #IMPLIED
           %SDAFORM; "List"
           %SDAPREF; "Definition List:"
           >

   <!ELEMENT DT    - O (%text)*>
   <!ATTLIST DT
           %attrs;
           %SDAFORM; "Term"
           >

   <!ELEMENT DD    - O %flow>
   <!ATTLIST DD
           %attrs;
           %SDAFORM; "LItem"
           >

   <!-- <DL>               Definition list, or glossary    -->
   <!-- <DL COMPACT>       Compact style list              -->
   <!-- <DT>               Term in definition list         -->
   <!-- <DD>               Definition of term              -->

   <!ELEMENT (OL|UL) - -  (LI)+>
   <!ATTLIST OL
           %attrs;
           %just;
           COMPACT (COMPACT) #IMPLIED
           %SDAFORM; "List"
           >
   <!ATTLIST UL
           %attrs;
           %just;
           COMPACT (COMPACT) #IMPLIED
           %SDAFORM; "List"
           >
   <!-- <UL>               Unordered list                  -->
   <!-- <UL COMPACT>       Compact list style              -->
   <!-- <OL>               Ordered, or numbered list       -->
   <!-- <OL COMPACT>       Compact list style              -->



Yergeau, et. al.            Standards Track                    [Page 29]

RFC 2070               HTML Internationalization            January 1997


   <!ELEMENT (DIR|MENU) - -  (LI)+ -(%block)>
   <!ATTLIST DIR
           %attrs;
           %just;
           COMPACT (COMPACT) #IMPLIED
           %SDAFORM; "List"
           %SDAPREF; "<LHead>Directory</LHead>"
           >
   <!ATTLIST MENU
           %attrs;
           %just;
           COMPACT (COMPACT) #IMPLIED
           %SDAFORM; "List"
           %SDAPREF; "<LHead>Menu</LHead>"
           >

   <!-- <DIR>              Directory list                  -->
   <!-- <DIR COMPACT>      Compact list style              -->
   <!-- <MENU>             Menu list                       -->
   <!-- <MENU COMPACT>     Compact list style              -->

   <!ELEMENT LI    - O %flow>
   <!ATTLIST LI
           %attrs;
           %just;
           %SDAFORM; "LItem"
           >

   <!-- <LI>               List item                       -->

   <!--========== Document Body ===================-->

   <![ %HTML.Recommended [
        <!ENTITY % body.content "(%heading|%block|HR|ADDRESS|IMG)*"
        -- <h1>Heading</h1>
           <p>Text ...
             is preferred to
           <h1>Heading</h1>
           Text ...
        -->
   ]]>

   <!ENTITY % body.content "(%heading | %text | %block |
                        HR | ADDRESS)*">

   <!ELEMENT BODY O O  %body.content>
   <!ATTLIST BODY
           %attrs;



Yergeau, et. al.            Standards Track                    [Page 30]

RFC 2070               HTML Internationalization            January 1997


           >

   <!-- <BODY>          Document body                -->
   <!-- <BODY DIR=...>  Base direction of whole body -->
   <!-- <BODY LANG=...> Language of contents         -->

   <!ELEMENT BLOCKQUOTE - - %body.content>
   <!ATTLIST BLOCKQUOTE
           %attrs;
           %just;
           %SDAFORM; "BQ"
           >

   <!-- <BLOCKQUOTE>       Quoted passage  -->

   <!ELEMENT ADDRESS - - (%text|P)*>
   <!ATTLIST  ADDRESS
           %attrs;
           %just;
           %SDAFORM; "Lit"
           %SDAPREF; "Address:&#RE;"
           >

   <!-- <ADDRESS> Address, signature, or byline -->


   <!--======= Forms ====================-->

   <![ %HTML.Forms [

   <!ELEMENT FORM - - %body.content -(FORM) +(INPUT|SELECT|TEXTAREA)>
   <!ATTLIST FORM
           %attrs;
           ACTION CDATA #IMPLIED
           METHOD (%HTTP-Method) GET
           ENCTYPE %Content-Type; "application/x-www-form-urlencoded"
           %SDAPREF; "<Para>Form:</Para>"
           %SDASUFF; "<Para>Form End.</Para>"
           >

   <!-- <FORM>                     Fill-out or data-entry form     -->
   <!-- <FORM ACTION="...">        Address for completed form      -->
   <!-- <FORM METHOD=...>          Method of submitting form       -->
   <!-- <FORM ENCTYPE="...">       Representation of form data     -->
   <!-- <FORM DIR=...>             Base direction of form          -->
   <!-- <FORM LANG=...>            Language of contents            -->

   <!ENTITY % InputType "(TEXT | PASSWORD | CHECKBOX |



Yergeau, et. al.            Standards Track                    [Page 31]

RFC 2070               HTML Internationalization            January 1997


                           RADIO | SUBMIT | RESET |
                           IMAGE | HIDDEN | FILE )">
   <!ELEMENT INPUT - O EMPTY>
   <!ATTLIST INPUT
           %attrs;
        TYPE %InputType TEXT
        NAME CDATA #IMPLIED
        VALUE CDATA #IMPLIED
        SRC CDATA #IMPLIED
        CHECKED (CHECKED) #IMPLIED
        SIZE CDATA #IMPLIED
        MAXLENGTH NUMBER #IMPLIED
        ALIGN (top|middle|bottom) #IMPLIED
           ACCEPT CDATA #IMPLIED --list of content types --
           ACCEPT-CHARSET CDATA #IMPLIED --list of charsets accepted --
           %SDAPREF; "Input: "
        >

   <!-- <INPUT>               Form input datum        -->
   <!-- <INPUT TYPE=...>           Type of input interaction    -->
   <!-- <INPUT NAME=...>           Name of form datum           -->
   <!-- <INPUT VALUE="...">   Default/initial/selected value -->
   <!-- <INPUT SRC="...">          Address of image        -->
   <!-- <INPUT CHECKED>            Initial state is "on"        -->
   <!-- <INPUT SIZE=...>           Field size hint         -->
   <!-- <INPUT MAXLENGTH=...>      Data length maximum          -->
   <!-- <INPUT ALIGN=...>          Image alignment         -->
   <!-- <INPUT ACCEPT="...">         List of desired media types    -->
   <!-- <INPUT ACCEPT-CHARSET="..."> List of acceptable charsets    -->

   <!ELEMENT SELECT - - (OPTION+) -(INPUT|SELECT|TEXTAREA)>
   <!ATTLIST SELECT
           %attrs;
           NAME CDATA #REQUIRED
           SIZE NUMBER #IMPLIED
           MULTIPLE (MULTIPLE) #IMPLIED
           %SDAFORM; "List"
           %SDAPREF;
           "<LHead>Select #AttVal(Multiple)</LHead>"
        >

   <!-- <SELECT>            Selection of option(s)        -->
   <!-- <SELECT NAME=...>        Name of form datum       -->
   <!-- <SELECT SIZE=...>        Options displayed at a time   -->
   <!-- <SELECT MULTIPLE>        Multiple selections allowed   -->

   <!ELEMENT OPTION - O (#PCDATA)*>
   <!ATTLIST OPTION



Yergeau, et. al.            Standards Track                    [Page 32]

RFC 2070               HTML Internationalization            January 1997


           %attrs;
           SELECTED (SELECTED) #IMPLIED
           VALUE CDATA #IMPLIED
           %SDAFORM; "LItem"
           %SDAPREF;
           "Option: #AttVal(Value) #AttVal(Selected)"
        >

   <!-- <OPTION>            A selection option       -->
   <!-- <OPTION SELECTED>        Initial state            -->
   <!-- <OPTION VALUE="...">     Form datum value for this option-->

   <!ELEMENT TEXTAREA - - (#PCDATA)* -(INPUT|SELECT|TEXTAREA)>
   <!ATTLIST TEXTAREA
           %attrs;
           NAME CDATA #REQUIRED
           ROWS NUMBER #REQUIRED
           COLS NUMBER #REQUIRED
           ACCEPT-CHARSET CDATA #IMPLIED -- list of charsets accepted --
           %SDAFORM; "Para"
           %SDAPREF; "Input Text -- #AttVal(Name): "
           >

   <!-- <TEXTAREA>               An area for text input        -->
   <!-- <TEXTAREA NAME=...> Name of form datum       -->
   <!-- <TEXTAREA ROWS=...> Height of area           -->
   <!-- <TEXTAREA COLS=...> Width of area            -->

   ]]>


   <!--======= Document Head ======================-->

   <![ %HTML.Recommended [
        <!ENTITY % head.extra "">
   ]]>
   <!ENTITY % head.extra "& NEXTID?">

   <!ENTITY % head.content "TITLE & ISINDEX? & BASE? %head.extra">

   <!ELEMENT HEAD O O  (%head.content) +(META|LINK)>
   <!ATTLIST HEAD
           %attrs;           >

   <!-- <HEAD>     Document head   -->

   <!ELEMENT TITLE - -  (#PCDATA)*  -(META|LINK)>
   <!ATTLIST TITLE



Yergeau, et. al.            Standards Track                    [Page 33]

RFC 2070               HTML Internationalization            January 1997


           %attrs;
           %SDAFORM; "Ti"    >

   <!-- <TITLE>    Title of document -->

   <!ELEMENT LINK - O EMPTY>
   <!ATTLIST LINK
           %attrs;
           HREF CDATA #REQUIRED
           %linkExtraAttributes;
           %SDAPREF; "Linked to : #AttVal (TITLE) (URN) (HREF)>"    >

   <!-- <LINK>         Link from this document            -->
   <!-- <LINK HREF="...">   Address of link destination        -->
   <!-- <LINK URN="...">    Lasting name of destination        -->
   <!-- <LINK REL=...> Relationship to destination        -->
   <!-- <LINK REV=...> Relationship of destination to this     -->
   <!-- <LINK TITLE="...">  Title of destination (advisory)         -->
   <!-- <LINK CHARSET="..."> Charset of destination (advisory)      -->
   <!-- <LINK METHODS="..."> Operations allowed (advisory)          -->

   <!ELEMENT ISINDEX - O EMPTY>
   <!ATTLIST ISINDEX
           %attrs;
           %SDAPREF;
      "<Para>[Document is indexed/searchable.]</Para>">

   <!-- <ISINDEX>          Document is a searchable index          -->

   <!ELEMENT BASE - O EMPTY>
   <!ATTLIST BASE
           HREF CDATA #REQUIRED     >

   <!-- <BASE>             Base context document                   -->
   <!-- <BASE HREF="...">  Address for this document               -->

   <!ELEMENT NEXTID - O EMPTY>
   <!ATTLIST NEXTID
           N CDATA #REQUIRED     >

   <!-- <NEXTID>       Next ID to use for link name       -->
   <!-- <NEXTID N=...> Next ID to use for link name       -->

   <!ELEMENT META - O EMPTY>
   <!ATTLIST META
           HTTP-EQUIV  NAME    #IMPLIED
           NAME        NAME    #IMPLIED
           CONTENT     CDATA   #REQUIRED    >



Yergeau, et. al.            Standards Track                    [Page 34]

RFC 2070               HTML Internationalization            January 1997


   <!-- <META>                     Generic Meta-information        -->
   <!-- <META HTTP-EQUIV=...>      HTTP response header name       -->
   <!-- <META NAME=...>          Meta-information name           -->
   <!-- <META CONTENT="...">       Associated information          -->

   <!--======= Document Structure =================-->

   <![ %HTML.Deprecated [
           <!ENTITY % html.content "HEAD, BODY, PLAINTEXT?">
   ]]>
   <!ENTITY % html.content "HEAD, BODY">

   <!ELEMENT HTML O O  (%html.content)>
   <!ENTITY % version.attr "VERSION CDATA #FIXED '%HTML.Version;'">

   <!ATTLIST HTML
           %attrs;
           %version.attr;
           %SDAFORM; "Book"
           >

   <!-- <HTML>              HTML Document  -->

7.2. SGML Declaration for HTML

   <!SGML  "ISO 8879:1986"
   --
        SGML Declaration for HyperText Markup Language version 2.x
           (HTML 2.x = HTML 2.0 + i18n).

   --

   CHARSET
            BASESET  "ISO Registration Number 177//CHARSET
                      ISO/IEC 10646-1:1993 UCS-4 with
                      implementation level 3//ESC 2/5 2/15 4/6"
            DESCSET  0   9     UNUSED
                     9   2     9
                     11  2     UNUSED
                     13  1     13
                     14  18    UNUSED
                     32  95    32
                     127 1     UNUSED
                     128 32    UNUSED
                     160 2147483486 160
   --
       In ISO 10646, the positions with hexadecimal
       values 0000D800 - 0000DFFF, used in the UTF-16



Yergeau, et. al.            Standards Track                    [Page 35]

RFC 2070               HTML Internationalization            January 1997


       encoding of UCS-4, are reserved, as well as the last
       two code values in each plane of UCS-4, i.e. all
       values of the hexadecimal form xxxxFFFE or xxxxFFFF.
       These code values or the corresponding numeric
       character references must not be included when
       generating a new HTML document, and they should be
       ignored if encountered when processing a HTML
       document.
   --

   CAPACITY        SGMLREF
                   TOTALCAP        150000
                   GRPCAP          150000
             ENTCAP         150000

   SCOPE    DOCUMENT

   SYNTAX
            SHUNCHAR CONTROLS 0 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 127

            BASESET  "ISO 646IRV:1991//CHARSET
                      International Reference Version
                      (IRV)//ESC 2/8 4/2"
            DESCSET  0 128 0

            FUNCTION
                     RE            13
                     RS            10
                     SPACE         32
                     TAB SEPCHAR    9

            NAMING   LCNMSTRT ""
                     UCNMSTRT ""
                     LCNMCHAR ".-"
                     UCNMCHAR ".-"
                     NAMECASE GENERAL YES
                              ENTITY  NO
            DELIM    GENERAL  SGMLREF
                     SHORTREF SGMLREF
            NAMES    SGMLREF
            QUANTITY SGMLREF
                     ATTSPLEN 2100
                     LITLEN   1024
                     NAMELEN  72    -- somewhat arbitrary; taken from
                                   internet line length conventions --
                     PILEN    1024
                     TAGLVL   100



Yergeau, et. al.            Standards Track                    [Page 36]

RFC 2070               HTML Internationalization            January 1997


                     TAGLEN   2100
                     GRPGTCNT 150
                     GRPCNT   64

   FEATURES
     MINIMIZE
       DATATAG  NO
       OMITTAG  YES
       RANK     NO
       SHORTTAG YES
     LINK
       SIMPLE   NO
       IMPLICIT NO
       EXPLICIT NO
     OTHER
       CONCUR   NO
       SUBDOC   NO
       FORMAL   YES
     APPINFO    "SDA"  -- conforming SGML Document Access application
                 --
   >

7.3. ISO Latin 1 entity set

   The following public text lists each of the characters specified in
   the Added Latin 1 entity set, along with its name, syntax for use,
   and description. This list is derived from ISO Standard
   8879:1986//ENTITIES Added Latin 1//EN. HTML includes the entire
   entity set, and adds entities for all missing characters in the right
   part of ISO-8859-1.

    <!-- (C) International Organization for Standardization 1986
         Permission to copy in any form is granted for use with
         conforming SGML systems and applications as defined in
         ISO 8879, provided this notice is included in all copies.
      -->
    <!-- Character entity set. Typical invocation:
         <!ENTITY % ISOlat1 PUBLIC
           "ISO 8879-1986//ENTITIES Added Latin 1//EN//HTML">
         %ISOlat1;
      -->
    <!ENTITY nbsp   CDATA "&#160;" -- no-break space -->
    <!ENTITY iexcl  CDATA "&#161;" -- inverted exclamation mark -->
    <!ENTITY cent   CDATA "&#162;" -- cent sign -->
    <!ENTITY pound  CDATA "&#163;" -- pound sterling sign -->
    <!ENTITY curren CDATA "&#164;" -- general currency sign -->
    <!ENTITY yen    CDATA "&#165;" -- yen sign -->
    <!ENTITY brvbar CDATA "&#166;" -- broken (vertical) bar -->



Yergeau, et. al.            Standards Track                    [Page 37]

RFC 2070               HTML Internationalization            January 1997


    <!ENTITY sect   CDATA "&#167;" -- section sign -->
    <!ENTITY uml    CDATA "&#168;" -- umlaut (dieresis) -->
    <!ENTITY copy   CDATA "&#169;" -- copyright sign -->
    <!ENTITY ordf   CDATA "&#170;" -- ordinal indicator, feminine -->
    <!ENTITY laquo  CDATA "&#171;" -- angle quotation mark, left -->
    <!ENTITY not    CDATA "&#172;" -- not sign -->
    <!ENTITY shy    CDATA "&#173;" -- soft hyphen -->
    <!ENTITY reg    CDATA "&#174;" -- registered sign -->
    <!ENTITY macr   CDATA "&#175;" -- macron -->
    <!ENTITY deg    CDATA "&#176;" -- degree sign -->
    <!ENTITY plusmn CDATA "&#177;" -- plus-or-minus sign -->
    <!ENTITY sup2   CDATA "&#178;" -- superscript two -->
    <!ENTITY sup3   CDATA "&#179;" -- superscript three -->
    <!ENTITY acute  CDATA "&#180;" -- acute accent -->
    <!ENTITY micro  CDATA "&#181;" -- micro sign -->
    <!ENTITY para   CDATA "&#182;" -- pilcrow (paragraph sign) -->
    <!ENTITY middot CDATA "&#183;" -- middle dot -->
    <!ENTITY cedil  CDATA "&#184;" -- cedilla -->
    <!ENTITY sup1   CDATA "&#185;" -- superscript one -->
    <!ENTITY ordm   CDATA "&#186;" -- ordinal indicator, masculine -->
    <!ENTITY raquo  CDATA "&#187;" -- angle quotation mark, right -->
    <!ENTITY frac14 CDATA "&#188;" -- fraction one-quarter -->
    <!ENTITY frac12 CDATA "&#189;" -- fraction one-half -->
    <!ENTITY frac34 CDATA "&#190;" -- fraction three-quarters -->
    <!ENTITY iquest CDATA "&#191;" -- inverted question mark -->
    <!ENTITY Agrave CDATA "&#192;" -- capital A, grave accent -->
    <!ENTITY Aacute CDATA "&#193;" -- capital A, acute accent -->
    <!ENTITY Acirc  CDATA "&#194;" -- capital A, circumflex accent -->
    <!ENTITY Atilde CDATA "&#195;" -- capital A, tilde -->
    <!ENTITY Auml   CDATA "&#196;" -- capital A, dieresis or umlaut -->
    <!ENTITY Aring  CDATA "&#197;" -- capital A, ring -->
    <!ENTITY AElig  CDATA "&#198;" -- capital AE diphthong (ligature) -->
    <!ENTITY Ccedil CDATA "&#199;" -- capital C, cedilla -->
    <!ENTITY Egrave CDATA "&#200;" -- capital E, grave accent -->
    <!ENTITY Eacute CDATA "&#201;" -- capital E, acute accent -->
    <!ENTITY Ecirc  CDATA "&#202;" -- capital E, circumflex accent -->
    <!ENTITY Euml   CDATA "&#203;" -- capital E, dieresis or umlaut -->
    <!ENTITY Igrave CDATA "&#204;" -- capital I, grave accent -->
    <!ENTITY Iacute CDATA "&#205;" -- capital I, acute accent -->
    <!ENTITY Icirc  CDATA "&#206;" -- capital I, circumflex accent -->
    <!ENTITY Iuml   CDATA "&#207;" -- capital I, dieresis or umlaut -->
    <!ENTITY ETH    CDATA "&#208;" -- capital Eth, Icelandic -->
    <!ENTITY Ntilde CDATA "&#209;" -- capital N, tilde -->
    <!ENTITY Ograve CDATA "&#210;" -- capital O, grave accent -->
    <!ENTITY Oacute CDATA "&#211;" -- capital O, acute accent -->
    <!ENTITY Ocirc  CDATA "&#212;" -- capital O, circumflex accent -->
    <!ENTITY Otilde CDATA "&#213;" -- capital O, tilde -->
    <!ENTITY Ouml   CDATA "&#214;" -- capital O, dieresis or umlaut -->



Yergeau, et. al.            Standards Track                    [Page 38]

RFC 2070               HTML Internationalization            January 1997


    <!ENTITY times  CDATA "&#215;" -- multiply sign -->
    <!ENTITY Oslash CDATA "&#216;" -- capital O, slash -->
    <!ENTITY Ugrave CDATA "&#217;" -- capital U, grave accent -->
    <!ENTITY Uacute CDATA "&#218;" -- capital U, acute accent -->
    <!ENTITY Ucirc  CDATA "&#219;" -- capital U, circumflex accent -->
    <!ENTITY Uuml   CDATA "&#220;" -- capital U, dieresis or umlaut -->
    <!ENTITY Yacute CDATA "&#221;" -- capital Y, acute accent -->
    <!ENTITY THORN  CDATA "&#222;" -- capital Thorn, Icelandic -->
    <!ENTITY szlig  CDATA "&#223;" -- small sharp s, German (sz ligature) -->
    <!ENTITY agrave CDATA "&#224;" -- small a, grave accent -->
    <!ENTITY aacute CDATA "&#225;" -- small a, acute accent -->
    <!ENTITY acirc  CDATA "&#226;" -- small a, circumflex accent -->
    <!ENTITY atilde CDATA "&#227;" -- small a, tilde -->
    <!ENTITY auml   CDATA "&#228;" -- small a, dieresis or umlaut -->
    <!ENTITY aring  CDATA "&#229;" -- small a, ring -->
    <!ENTITY aelig  CDATA "&#230;" -- small ae diphthong (ligature) -->
    <!ENTITY ccedil CDATA "&#231;" -- small c, cedilla -->
    <!ENTITY egrave CDATA "&#232;" -- small e, grave accent -->
    <!ENTITY eacute CDATA "&#233;" -- small e, acute accent -->
    <!ENTITY ecirc  CDATA "&#234;" -- small e, circumflex accent -->
    <!ENTITY euml   CDATA "&#235;" -- small e, dieresis or umlaut -->
    <!ENTITY igrave CDATA "&#236;" -- small i, grave accent -->
    <!ENTITY iacute CDATA "&#237;" -- small i, acute accent -->
    <!ENTITY icirc  CDATA "&#238;" -- small i, circumflex accent -->
    <!ENTITY iuml   CDATA "&#239;" -- small i, dieresis or umlaut -->
    <!ENTITY eth    CDATA "&#240;" -- small eth, Icelandic -->
    <!ENTITY ntilde CDATA "&#241;" -- small n, tilde -->
    <!ENTITY ograve CDATA "&#242;" -- small o, grave accent -->
    <!ENTITY oacute CDATA "&#243;" -- small o, acute accent -->
    <!ENTITY ocirc  CDATA "&#244;" -- small o, circumflex accent -->
    <!ENTITY otilde CDATA "&#245;" -- small o, tilde -->
    <!ENTITY ouml   CDATA "&#246;" -- small o, dieresis or umlaut -->
    <!ENTITY divide CDATA "&#247;" -- divide sign -->
    <!ENTITY oslash CDATA "&#248;" -- small o, slash -->
    <!ENTITY ugrave CDATA "&#249;" -- small u, grave accent -->
    <!ENTITY uacute CDATA "&#250;" -- small u, acute accent -->
    <!ENTITY ucirc  CDATA "&#251;" -- small u, circumflex accent -->
    <!ENTITY uuml   CDATA "&#252;" -- small u, dieresis or umlaut -->
    <!ENTITY yacute CDATA "&#253;" -- small y, acute accent -->
    <!ENTITY thorn  CDATA "&#254;" -- small thorn, Icelandic -->
    <!ENTITY yuml   CDATA "&#255;" -- small y, dieresis or umlaut -->










Yergeau, et. al.            Standards Track                    [Page 39]

RFC 2070               HTML Internationalization            January 1997


8. Security Considerations

   Anchors, embedded images, and all other elements which contain URIs
   as parameters may cause the URI to be dereferenced in response to
   user input. In this case, the security considerations of [RFC1738]
   apply.

   The widely deployed methods for submitting form requests -- HTTP and
   SMTP -- provide little assurance of confidentiality.  Information
   providers who request sensitive information via forms -- especially
   by way of the `PASSWORD' type input field (see section 8.1.2 in
   [RFC1866]) -- should be aware and make their users aware of the lack
   of confidentiality.

Bibliography

   [BRYAN88]      M. Bryan, "SGML -- An Author's Guide to the Standard
                  Generalized Markup Language", Addison-Wesley, Reading,
                  1988.

   [ERCS]         Extended Reference Concrete Syntax for SGML.
                  <http://www.sgmlopen.org/sgml/docs/ercs/ercs-
                  home.html>

   [GOLD90]       C. F. Goldfarb, "The SGML Handbook", Y. Rubinsky, Ed.,
                  Oxford University Press, 1990.

   [HTTP-1.1]     Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
                  and T. Berners-Lee, "Hypertext Transfer Protocol --
                  HTTP/1.1", RFC 2068, January 1997.

   [ISO-639]      ISO 639:1988. International standard -- Code for the
                  representation of the names of languages.  Technical
                  content in <http://www.sil.org/sgml/iso639a.html>

   [ISO-8859]     ISO 8859.  International standard -- Information pro-
                  cessing -- 8-bit single-byte coded graphic character
                  sets -- Part 1: Latin alphabet No. 1 (1987) -- Part 2:
                  Latin alphabet No. 2 (1987) -- Part 3: Latin alphabet
                  No. 3 (1988) -- Part 4: Latin alphabet No. 4 (1988) --
                  Part 5: Latin/Cyrillic alphabet (1988) -- Part 6:
                  Latin/Arabic alphabet (1987) -- Part : Latin/Greek
                  alphabet (1987) -- Part 8: Latin/Hebrew alphabet
                  (1988) -- Part 9: Latin alphabet No. 5 (1989) -- Part
                  10: Latin alphabet No. 6 (1992)






Yergeau, et. al.            Standards Track                    [Page 40]

RFC 2070               HTML Internationalization            January 1997


   [ISO-8879]     ISO 8879:1986. International standard -- Information
                  processing -- Text and office systems -- Standard gen-
                  eralized markup language (SGML).

   [ISO-10646]    ISO/IEC 10646-1:1993. International standard -- Infor-
                  mation technology -- Universal multiple-octet coded
                  character Sset (UCS) -- Part 1: Architecture and basic
                  multilingual plane.

   [NICOL]        G.T. Nicol, "The Multilingual World Wide Web",
                  Electronic Book Technologies, 1995,
                  <http://www.ebt.com/docs/multling.html>

   [NICOL2]       G.T. Nicol, "MIME Header Supplemented File Type", Work
                  in Progress, EBT, October 1995.

   [RFC1345]      Simonsen, K., "Character Mnemonics & Character Sets",
                  RFC 1345, Rationel Almen Planlaegning, June 1992.

   [RFC1468]      Murai, J., Crispin M., and E. van der Poel,
                  "Japanese Character Encoding for Internet Messages",
                  RFC 1468, Keio University, Panda Programming, June
                  1993.

   [RFC2045]      Freed, N., and N. Borenstein, "Multipurpose Internet
                  Mail Extensions (MIME) Part One: Format of Internet
                  Message Bodies", RFC 2045, Innosoft, First Virtual,
                  November 1996.

   [RFC1641]      Goldsmith, D., and M.Davis, "Using Unicode with MIME",
                  RFC 1641, Taligent inc., July 1994.

   [RFC1642]      Goldsmith, D., and M. Davis, "UTF-7: A Mail-safe
                  Transformation Format of Unicode", RFC 1642, Taligent,
                  Inc., July 1994.

   [RFC1738]      Berners-Lee, T., Masinter, L., and M. McCahill,
                  "Uniform Resource Locators (URL)", RFC 1738, CERN,
                  Xerox PARC, University of Minnesota, October 1994.

   [RFC1766]      Alverstrand, H., "Tags for the Identification of
                  Languages", RFC 1766, UNINETT, March 1995.

   [RFC1866]      Berners-Lee, T., and D. Connolly, "Hypertext Markup
                  Language - 2.0", RFC 1866, MIT/W3C, November 1995.

   [RFC1867]      Nebel, E., and L. Masinter, "Form-based File Upload
                  in HTML", RFC 1867, Xerox Corporation, November 1995.



Yergeau, et. al.            Standards Track                    [Page 41]

RFC 2070               HTML Internationalization            January 1997


   [RFC1942]      Raggett, D., "HTML Tables", RFC 1942, W3C, May 1996.

   [RFC2068]      Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
                  and T. Berners-Lee, "Hypertext Transfer Protocol --
                  HTTP/1.1", RFC 2068, January 1997.

   [SQ91]         SoftQuad, "The SGML Primer", 3rd ed., SoftQuad Inc.,
                  1991.

   [TAKADA]       Toshihiro Takada, "Multilingual Information Exchange
                  through the World-Wide Web", Computer Networks and
                  ISDN Systems, Vol. 27, No. 2, Nov. 1994 , p. 235-241.

   [TEI]          TEI Guidelines for Electronic Text Encoding and Inter-
                  change.  <http://etext.virgina.edu/TEI.html>

   [UNICODE]      The Unicode Consortium, "The Unicode Standard --
                  Worldwide Character Encoding -- Version 1.0", Addison-
                  Wesley, Volume 1, 1991, Volume 2, 1992, and Technical
                  Report #4, 1993.  The BIDI algorithm is in appendix A
                  of volume 1, with corrections in appendix D of volume
                  2.

   [UTF-8]        ISO/IEC 10646-1:1993 AMENDMENT 2 (1996). UCS Transfor-
                  mation Format 8 (UTF-8).

   [VANH90]       E. van Hervijnen, "Practical SGML", Kluwer Academicq
                  Publishers Group, Norwell and Dordrecht, 1990.























Yergeau, et. al.            Standards Track                    [Page 42]

RFC 2070               HTML Internationalization            January 1997


Authors' Addresses

      Frangois Yergeau
      Alis Technologies
      100, boul. Alexis-Nihon, bureau 600
      Montrial  QC  H4M 2P2
      Canada

      Tel: +1 (514) 747-2547
      Fax: +1 (514) 747-2561
      EMail: fyergeau@alis.com


      Gavin Thomas Nicol
      Electronic Book Technologies, Japan
      1-29-9 Tsurumaki,
      Setagaya-ku,
      Tokyo
      Japan

      Tel: +81-3-3230-8161
      Fax: +81-3-3230-8163
      EMail: gtn@ebt.com, gtn@twics.co.jp


      Glenn Adams
      Spyglass
      118 Magazine Street
      Cambridge, MA 02139
      U.S.A.

      Tel: +1 (617) 864-5524
      Fax: +1 (617) 864-4965
      EMail: glenn@spyglass.com


      Martin J. Duerst
      Multimedia-Laboratory
      Department of Computer Science
      University of Zurich
      Winterthurerstrasse 190
      CH-8057 Zurich
      Switzerland

      Tel: +41 1 257 43 16
      Fax: +41 1 363 00 35
      EMail: mduerst@ifi.unizh.ch




Yergeau, et. al.            Standards Track                    [Page 43]