As per Relevance of the word standard, we have this rfc below:
Network Working Group F.
Request for Comments: 2070 Alis
Category: Standards Track G.
Electronic Book
G.
M.
University of
January 1997
Internationalization of the Hypertext Markup
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
The Hypertext Markup Language (HTML) is a markup language used
create hypertext documents that are platform independent. Initially
the application of HTML on the World Wide Web was
restricted by its reliance on the ISO-8859-1 coded character set
which is appropriate only for Western European languages.
this restriction, HTML has been widely used with other languages
using other coded character sets or character encodings, at
expense of interoperability
This document is meant to address the issue of
internationalization (i18n, i followed by 18 letters followed by n
of HTML by extending the specification of HTML and giving
recommendations for proper internationalization support. A
consideration is to make sure that HTML remains a valid
of SGML, while enabling its use with all languages of the world
Table of
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.
The Hypertext Markup Language (HTML) is a markup language used
create hypertext documents that are platform independent. Initially
the application of HTML on the World Wide Web was
restricted by its reliance on the ISO-8859-1 coded character set
which is appropriate only for Western European languages.
this restriction, HTML has been widely used with other languages
using other coded character sets or character encodings,
various ad hoc extensions to the language [TAKADA].
This document is meant to address the issue of
internationalization of HTML by extending the specification of
and giving additional recommendations for proper
support. It is in good part based on a paper by one of the
on multilingualism on the WWW [NICOL]. A foremost consideration
to make sure that HTML remains a valid application of SGML,
enabling its use with all languages of the world
The specific issues addressed are the SGML document character set
be used for HTML, the proper treatment of the charset
associated with the "text/html" content type and the specification
some additional elements and entities
1.1
HTML has been in use by the World-Wide Web (WWW) global
initiative since 1990. This specification extends the
of HTML 2.0 (RFC 1866), primarily by removing the restriction to
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,
Processing Text and Office Systems -- Standard Generalized
Language (SGML) [ISO-8879]. The HTML Document Type Definition (DTD
is a formal definition of the HTML syntax in terms of SGML.
specification amends the DTD of HTML 2.0 in order to make
applicable to documents encompassing a character repertoire
larger than that of ISO-8859-1, while still remaining
conformant
Both formal and actual development of HTML are advancing very fast
The features described in this document are designed so that they
(and should) be added to other forms of HTML besides that
in RFC 1866. Where indicated, attributes introduced here should
extended to the appropriate elements
1.2
This specification changes slightly the conformance requirements
HTML documents and HTML user agents
1.2.1
All HTML 2.0 conforming documents remain conforming with
specification. However, the extensions introduced here make
certain documents that would not be HTML 2.0 conforming,
particular those containing characters or character
outside of the repertoire of ISO 8859-1, and those containing
introduced herein
1.2.2. User
In addition to the requirements of RFC 1866, the
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
than ISO-8859-1 are present, user agents MUST correctly
the charset parameter accompanying an HTML document received
the network
Furthermore, conforming user-agents MUST at least parse
all numeric character references within the range of ISO 10646-1
[ISO-10646].
Conforming user-agents are required to apply the BIDI
algorithm if they display right-to-left characters. If there
no displayable right-to-left character in a document, there is
need to apply BIDI processing
Yergeau, et. al. Standards Track [Page 3]
RFC 2070 HTML Internationalization January 1997
2. The document character
2.1. Reference processing
This overview explains a reference processing model used for HTML
and in particular the SGML concept of a document character set.
actual implementation may widely differ in its internal workings
the model given below, but should behave as described to an
observer
Because there are various widely differing encodings of text,
does not directly address how the sequence of characters
constitutes an SGML document in the abstract sense are encoded
means of a sequence of octets (or occasionally bit groups of
length than 8) in a concrete realization of the document such as
computer file. This encoding is called the external
encoding of the concrete SGML document, and it should be
distinguished from the document character set of the abstract
document. SGML views the characters as a single set (called
"character repertoire"), and a "code set" that assigns an
number (known as "character number") to each character in
repertoire. The document character set declaration defines what
of the character numbers represents [GOLD90, p. 451]. In most cases
an SGML DTD and all documents that refer to it have a single
character set, and all markup and data characters are part of
set
HTML, as an application of SGML, does not directly address
question of the external character encoding. This is deferred
mechanisms external to HTML, such as MIME as used by the
protocol or by electronic mail
For the HTTP protocol [RFC2068], the external character encoding
indicated by the "charset" parameter of the "Content-Type" field
the header of an HTTP response. For example, to indicate that
transmitted document is encoded in the "JUNET" encoding of
[RFC1468], the header will contain the following line
Content-Type: text/html; charset=ISO-2022-
The term "charset" in MIME is used to designate a character encoding
rather than merely a coded character set as the term may suggest.
character encoding is a mapping (possibly many-to-one) of
of octets to sequences of characters taken from one or more
repertoires
The HTTP protocol also defines a mechanism for the client to
the character encodings it can accept. Clients and servers
Yergeau, et. al. Standards Track [Page 4]
RFC 2070 HTML Internationalization January 1997
strongly requested to use these mechanisms to assure
transmission and interpretation of any document. Provisions that
be taken to help correct interpretation, even in cases where a
or client do not yet use these mechanisms, are described in
6.
Similarly, if HTML documents are transferred by electronic mail,
external character encoding is defined by the "charset" parameter
the "Content-Type" MIME header field [RFC2045], and defaults to US
ASCII in its absence
No mechanisms are currently standardized for indicating the
character encoding of HTML documents transferred by FTP or
in distributed file systems
In the case any other way of transferring and storing HTML
are defined or become popular, it is advised that similar
be made to clearly identify the character encoding used and/or to
a single/default encoding capable of representing the widest range
characters used in an international context
Whatever the external character encoding may be, the
processing model translates it to the document character
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
of the resource to the document character set. The entity manager
the parser, and the application deal only with characters of
document character set. A display-oriented part of the
or the display machinery itself may again convert
represented in the document character set to some
representation more suitable for their purpose. In any case,
entity manager, the parser, and the application, as far as
semantics are concerned, are using the HTML document character
only
An actual implementation may choose, or not, to translate
document into some encoding of the document character set
described above; the behaviour described by this reference
model can be achieved otherwise. This subject is well out of
scope of this specification, however, and the reader is invited
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
that numeric character references are always resolved with respect
the fixed document character set, and thus to the same characters
whatever the external encoding actually used. For an example,
Section 2.2.
2.2. The document character
The document character set, in the SGML sense, is the
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
from time to time; 4 amendments have been adopted since
initial 1993 publication, none of which significantly affects
specification. A fifth amendment, now under consideration,
introduce incompatible changes to the standard: 6556 Korean
syllables allocated between code positions 3400 and 4
(hexadecimal) will be moved to new positions (and 4516
syllables added), thus making references to the old
invalid. Since the Unicode consortium has already adopted
corresponding amendment for inclusion in the forthcoming
2.0, adoption of DAM 5 is considered likely and
should probably consider the old code positions as
invalid. Despite this one-time change, the relevant
bodies have committed themselves not to change any allocated
position in the future. To encode Korean Hangul irrespective
these changes, the conjoining Hangul Jamo in the range 1110-11F
can be used
The adoption of this document character set implies a change in
SGML declaration specified in the HTML 2.0 specification (section 9.5
of [RFC1866]). The change amounts to removing the first
specification and its accompanying DESCSET declaration,
them with the following declaration
Yergeau, et. al. Standards Track [Page 6]
RFC 2070 HTML Internationalization January 1997
BASESET "ISO Registration Number 177//
ISO/IEC 10646-1:1993 UCS-4 with implementation level 3
//ESC 2/5 2/15 4/6"
DESCSET 0 9
9 2 9
11 2
13 1 13
14 18
32 95 32
127 1
128 32
160 2147483486 160
Making the UCS the document character set does not create non
conformance of any expression, construct or document that
conforming to HTML 2.0. It does make conforming certain
that are not admissible in HTML 2.0. One consequence is that
characters outside the repertoire of ISO-8859-1, but within that
UCS-4 become valid SGML characters. Another is that the upper
of the range of numeric character references is extended from 255
2147483645; thus, И is a valid reference to a "CYRILLIC
LETTER I". [ERCS] is a good source of information on Unicode
SGML, although its scope and technical content differ greatly
this specification
NOTE -- the above SGML declaration, like that of HTML 2.0,
specifies the character numbers 128 to 159 (80 to 9F hex)
UNUSED. This means that numeric character references within
range (e.g. ’) are illegal in HTML. Neither ISO 8859-1
ISO 10646 contain characters in that range, which is reserved
control characters
Another change was made from the HTML 2.0 SGML declaration, in
belief that the latter did not express its authors' true intent.
syntax character set declaration was changed from ISO 646.IRV:1983
the newer ISO 646.IRV:1991, the latter, but not the former,
identical with US-ASCII. In principle, this introduces
incompatibility with HTML 2.0, but in practice it should
interoperability by i) having the SGML declaration say what
thinks and ii) making the syntax character set a proper subset of
document character set. The characters that differ between the
versions of ISO 646.IRV are not actually used to express HTML syntax
ISO 10646-1:1993 is the most encompassing character set
existing, and there is no other character set that could take
place as the document character set for HTML. If nevertheless for
specific application there is a need to use characters outside
standard, this should be done by avoiding any conflicts with
Yergeau, et. al. Standards Track [Page 7]
RFC 2070 HTML Internationalization January 1997
or future versions of ISO 10646, i.e. by assigning these
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
unportable; in many cases, it may be better to use inline bitmaps
2.3. Undisplayable
With the document character set being the full ISO 10646,
possibility that a character cannot be displayed due to lack
appropriate resources (fonts) cannot be avoided. Because there
many different things that can be done in such a case, this
does not prescribe any specific behaviour. Depending on
implementation, this may also be handled by the underlaying
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
rendered, and so showing an alert for each of them is not
right thing to do
- In case a numeric representation of the missing character
given, its hexadecimal (not decimal) form is to be preferred
because this form is used in character set standards [ERCS].
3. The LANG
Language tags can be used to control rendering of a marked
document in various ways: glyph disambiguation, in cases where
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
content markup for purposes such as classification and searching
Since any text can logically be assigned a language, almost all
elements admit the LANG attribute. The DTD reflects this; the
elements in this version of HTML without the LANG attribute are BR
HR, BASE, NEXTID, and META. It is also intended that any new
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
identifies a natural language spoken, written, or otherwise
by human beings for communication of information to other
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
defined by RFC 1766 [RFC1766]. In summary, a language tag is
of one or more parts: A primary language tag and a possibly
series of subtags
language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8
subtag = 1*8
Whitespace is not allowed within the tag and all tags are case
insensitive. The namespace of language tags is administered by
IANA. Example tags include
en, en-US, en-cockney, i-cherokee, x-pig-
In the context of HTML, a language tag is not to be interpreted as
single token, as per RFC 1766, but as a hierarchy. For example,
user agent that adjusts rendering according to language
consider that it has a match when a language tag in a style
entry matches the initial portion of the language tag of an element
An exact match should be preferred. This interpretation allows
element marked up as, for instance, "en-US" to trigger
corresponding to, in order of preference, US-English ("en-US")
'plain' or 'international' English ("en").
NOTE -- using the language tag as a hierarchy does not imply
all languages with a common prefix will be understood by
fluent in one or more of those languages; it simply allows
user to request this commonality when it is true for that user
The rendering of elements may be affected by the LANG attribute.
any element, the value of the LANG attribute overrides the
specified by the LANG attribute of any enclosing element and
value (if any) of the HTTP Content-Language header. If none of
are set, a suitable default, perhaps controlled by user preferences
by automatic context analysis or by the user's locale, should be
to control rendering
4. Additional entities, attributes and
4.1. Full Latin-1 entity
According to the suggestion of section 14 of [RFC1866], the set
Latin-1 entities is extended to cover the whole right part of ISO
8859-1 (all code positions with the high-order bit set),
the already commonly used , © and ®. The names of
entities are taken from the appendices of SGML [ISO-8879]. A list
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
4.2.1.
For the correct presentation of text in certain
(irrespective of formatting issues), some support in the form
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
right-to-left scripts are mixed
- Control of cursive joining behaviour in contexts where
default behaviour is not appropriate
- Language-dependent rendering of short (in-line) quotations
- Better justification control for languages where this
important
- Superscripts and subscripts for languages where they appear
part of general text
Some of the above features need very little additional support
others need more. The additional features are introduced below
brief comments only. Explanations on cursive joining behaviour
bidirectional text follow later. For cursive joining behaviour
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
protocol, this is done in a way that allows
conversion to the lower-level mechanisms defined in [UNICODE].
4.2.2. List of entities, elements, and
First, a generic container is needed to carry the LANG and DIR (
below) attributes in cases where no other element is appropriate;
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
rendering and cursive joining control
These entities can be used in place of the corresponding
characters whenever convenient, for example to ease keyboard entry
when a formatting character is not available in the
encoding of the document
Next, an attribute called DIR is introduced, restricted to the
LTR (left-to-right) and RTL (right-to-left), for the indication
directionality in the context of bidirectional text (see 4.2.4
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
this. It is also intended that any new element introduced in
versions of HTML will admit the DIR attribute, unless there is a
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
left-to-right or right-to-left. This element is required
bidirectional text control; for detailed explanations, see
4.2.4.
The phrase-level element Q is introduced to allow language-
rendering of short quotations depending on language and
capability. As the following examples show (rather poorly, because
the character set restriction of Internet specifications),
quotation marks surrounding the quotation are particularly affected
"a quotation in English", `another, slightly better one', ,,
quotation in German'', << a quotation in French >>. The contents
the Q element does not include quotation marks, which have to
added by the rendering process
NOTE -- Q elements can be nested. Many languages use
quotation styles for outer and inner quotations, and this
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
contents with some kind of quotes, like the plain ASCII
quotes. As this is rather easy to implement, and as the lack
any visible quotes may affect the perceived meaning of the text
user-agent implementors are strongly requested to provide at
this minimal level of support
Many languages require superscript text for proper rendering: as
example, the French "Mlle Dupont" should have "lle" in superscript
The SUP element, and its sibling SUB for subscript text,
introduced to allow proper markup of such text. SUP and SUB
are restricted to PCDATA to avoid nesting problems
Finally, in many languages text justification is much more
than it is in Western languages, and justifies markup. The
attribute, admitting values of LEFT, RIGHT, CENTER and JUSTIFY,
added to a selection of elements where it makes sense (the block-
P, HR, H1 to H6, OL, UL, DIR, MENU, LI, BLOCKQUOTE and ADDRESS).
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
should treat an end of line as a word space, except
preformatted text. This should be interpreted in the context
the script being processed, as the way words are separated
writing is script-dependent. For some scripts (e.g. Latin),
word space is just a space, but in other scripts (e.g. Thai) it
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
from user-agent implementers. It is present in many
sets (including the whole ISO 8859 series and, of course,
10646), and can always be included by means of the
. Its semantics are different from the plain HYPHEN:
indicates a point in a word where a line break is allowed. If
line is indeed broken there, a hyphen must be displayed at the
of the first line. If not, the character is not dispalyed at all
In operations like searching and sorting, it must always
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
parameter entity called attrs. To parallel RFC 1942 [RFC1942],
ID and CLASS attributes are also included in attrs. The ID and
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
for naming positions within documents as the destination of
hypertext link. It may also be used by style sheets
rendering an element in a unique style. An ID attribute value
an SGML NAME token. NAME tokens are formed by an
letter followed by letters, digits, "-" and "." characters.
letters are restricted to A-Z and a-z
CLASS A space separated list of SGML NAME tokens. CLASS
specify that the element belongs to the corresponding
classes. It allows authors to distinguish different
played by the same tag. The classes may be used by
sheets to provide different renderings as appropriate
these roles
4.2.3. Cursive joining
Markup is needed in some cases to force cursive joining behavior
contexts in which it would not normally occur, or to block it when
would normally occur
The zero-width joiner and non-joiner ( and ) are used
control cursive joining behaviour. For example, ARABIC LETTER HEH
used in isolation to abbreviate "Hijri" (the Islamic
system); however, the initial form of the letter is desired,
the isolated form of HEH looks like the digit five as employed
Arabic script. This is obtained by following the HEH with a zero
width joiner whose only effect is to provide context. In
texts, there are cases where a letter that normally would join
subsequent letter in a cursive connection does not. Here a zero
width non- joiner is used
4.2.4. Bidirectional
Many languages are written in horizontal lines from left to right
while others are written from right to left. When both
directions are present, one talks of bidirectional text (BIDI
short). BIDI text requires markup in special circumstances
ambiguities as to the directionality of some characters have to
resolved. This markup affects the ability to render BIDI text in
semantically legible fashion. That is, without this special
markup, cases arise which would prevent *any* rendering
Yergeau, et. al. Standards Track [Page 13]
RFC 2070 HTML Internationalization January 1997
that reflected the basic meaning of the text. Plain text may
BIDI markup in the form of special-purpose formatting characters
This is also possible in HTML, which includes the five BIDI-
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
display sequences has to be done according to the algorithm
character properties specified in [UNICODE]. Here, explanations
given only as far as they are needed to understand the necessity
the features introduced and to define their exact semantics
The Unicode BIDI algorithm is based on the individual characters of
text being stored in logical order, that is the order in which
are normally input and in which the corresponding sounds are
spoken. To make rendering of logical order text possible,
algorithm assigns a directionality property to each character, e.g
Latin letters are specified to have a left-to-right direction,
and Hebrew characters have a right-to-left direction
The left-to-right and right-to-left marks ( and ) are
to disambiguate directionality of neutral characters. For example
when a double quote sits between an Arabic and a Latin letter,
direction is ambiguous; if a directional mark is added on one
such that the quotation mark is surrounded by characters of only
directionality, the ambiguity is removed. These characters are
zero width spaces which have a directional property (but no word/
break property).
Nested embeddings of contra-directional text runs, due to
quotations or to the pasting of text from one BIDI context
another, is also a case where the implicit directionality
characters is not sufficient, requiring markup. Also, it
frequently desirable to specify the basic directionality of a
of text. For these purposes, the DIR attribute is used
On block-type elements, the DIR attribute indicates the
directionality of the text in the block; if omitted it is
from the parent element. The default directionality of the
HTML document is left-to-right
On inline elements, it makes the element start a new embedding
(to be explained below); if omitted the inline element does not
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
respect to bidirectional layout, but the BIDI algorithm should
applied to each line of text
Following is an example of a case where embedding is needed,
its effect
Given the following latin (upper case) and arabic (lower case
letters in backing store with the specified embeddings
AB xy CD
EF
One gets the following rendering (with [] showing the
transitions):
[ AB [ wz [ CD ] yx ] EF ]
On the other hand, without this markup and with a base
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
case where the embedding levels are used. Without the
markup one has at most two levels: a base directional level and
single counterflow directional level
The DIR attribute on inline elements is equivalent to the
characters LEFT-TO-RIGHT EMBEDDING (202A) and RIGHT-TO-
EMBEDDING (202B) of ISO 10646. The end tag of the element
equivalent to the POP DIRECTIONAL FORMATTING (202C) character
Directional override, as provided by the BDO element, is needed
deal with unusual short pieces of text in which directionality
be resolved from context in an unambiguous fashion. For example,
can be used to force left-to-right (or right-to-left) display of
numbers composed of Latin letters, digits and Hebrew letters
The effect of BDO is to force the directionality of all
within it to the value of DIR, irrespective of their
directional properties. It is equivalent to using the LEFT-TO-
OVERRIDE (202D) or RIGHT-TO-LEFT OVERRIDE (202E) characters of
10646, the end tag again being equivalent to the POP
FORMATTING (202C) character
Yergeau, et. al. Standards Track [Page 15]
RFC 2070 HTML Internationalization January 1997
NOTE -- authors and authoring software writers should be
that conflicts can arise if the DIR attribute is used on
elements (including BDO) concurrently with the use of
corresponding ISO 10646 formatting characters
Preferably one or the other should be used exclusively; the
method is better able to guarantee document structural integrity
and alleviates some problems when editing bidirectional HTML
with a simple text editor, but some software may be more apt
using the 10646 characters. If both methods are used, great
should be exercised to insure proper nesting of markup
directional embedding or override; otherwise, rendering
are undefined
5.
5.1. DTD
It is natural to expect input in any language in forms, as
provide one of the only ways of obtaining user input. While this
primarily a UI issue, there are some things that should be
at the HTML level to guide behavior and promote interoperability
To ensure full interoperability, it is necessary for the user
(and the user) to have an indication of the character encoding(s
that the server providing a form will be able to handle
submission of the filled-in form. Such an indication is provided
the ACCEPT-CHARSET attribute of the INPUT and TEXTAREA elements
modeled on the HTTP Accept-Charset header (see [HTTP-1.1]),
contains a space and/or comma delimited list of character
acceptable to the server. A user agent may want to somehow
the user of the contents of this attribute, or to restrict
possibility to enter characters outside the repertoires of the
character sets
NOTE -- The list of character sets is to be interpreted as
EXCLUSIVE-OR list; the server announces that it is ready to
any ONE of these character encoding schemes for each part of
multipart entity. The client may perform character
translation to satisfy the server if necessary
NOTE -- The default value for the ACCEPT-CHARSET attribute of
INPUT or TEXTAREA element is the reserved value "UNKNOWN". A
agent may interpret that value as the character encoding
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
The HTML 2.0 form submission mechanism, based on the "application/x
www-form-urlencoded" media type, is ill-equipped with regard
internationalization. In fact, since URLs are restricted to
characters, the mechanism is akward even for ISO-8859-1 text
Section 2.2 of [RFC1738] specifies that octets may be encoded
the "%HH" notation, but text submitted from a form is composed
characters, not octets. Lacking a specification of a
encoding scheme, the "%HH" notation has no well-defined meaning
The best solution is to use the "multipart/form-data" media
described in [RFC1867] with the POST method of form submission.
mechanism encapsulates the value part of each name-value pair in
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
character encoding scheme. The changes to the DTD necessary
support this method of form submission have been incorporated in
DTD included in this specification
A less satisfactory solution is to add a MIME charset parameter
the "application/x-www-form-urlencoded" media type specifier
along with a POST method form submission, with the understanding
the URL encoding of [RFC1738] is applied on top of the
character encoding, as a kind of implicit Content-Transfer-Encoding
One problem with both solutions above is that current browsers do
generally allow for bookmarks to specify the POST method; this
be improved. Conversely, the GET method could be used with the
data transmitted in the body instead of in the URL. Nothing in
protocol seems to prevent it, but no implementations appear to
at present
How the user agent determines the encoding of the text entered by
user is outside the scope of this specification
NOTE -- Designers of forms and their handling scripts should
aware of an important caveat: when the default value of a
(the VALUE attribute) is returned upon form submission (i.e.
user did not modify this value), it cannot be guaranteed to
transmitted as a sequence of octets identical to that in
source document -- only as a possibly different but valid
of the same sequence of text elements. This may be true even
the encoding of the document containing the form and that used
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
represented by various sequences of octets, and also when
composite sequence (a base character plus one or more
diacritics) can be represented by either a different
equivalent composite sequence or by a fully precomposed character
For instance, the UCS-2 sequence 00EA+0323 (LATIN SMALL LETTER
WITH CIRCUMFLEX ACCENT + COMBINING DOT BELOW) may be
into 1EC7 (LATIN SMALL LETTER E WITH CIRCUMFLEX ACCENT AND
BELOW), into 0065+0302+0323 (LATIN SMALL LETTER E +
CIRCUMFLEX ACCENT + COMBINING DOT BELOW), as well as into
equivalent composite sequences
6. External character encoding
Proper interpretation of a text document requires that the
encoding scheme be known. Current HTTP servers, however, do
generally include an appropriate charset parameter with the Content
Type header. This is bad behaviour, which is even encouraged by
continued existence of browsers that declare an unrecognized
type when they receive a charset parameter. User
implementators are strongly encouraged to make their
tolerant of this parameter, even if they cannot take advantage of it
Proper labelling is highly desirable, but some preventive
can be taken to minimize the detrimental effects of its absence
In the case where a document is accessed from a hyperlink in
origin HTML document, a CHARSET attribute is added to the
list of elements with link semantics (A and LINK), specifically
adding it to the linkExtraAttributes entity. The value of
attribute is to be considered a hint to the User Agent as to
character encoding scheme used by the resource pointed to by
hyperlink; it should be the appropriate value of the MIME
parameter for that resource
In any document, it is possible to include an indication of
encoding scheme like the following, as early as possible within
HEAD of the document
This is not foolproof, but will work if the encoding scheme is
that ASCII-valued octets stand for ASCII characters only at
until the META element is parsed. Note that there are better
for a server to obtain character encoding information, instead of
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
the document should be considered the most authoritative, followed
order of preference by the contents of a META element such as
above, and finally the CHARSET parameter of the anchor that
followed (if any).
When HTML text is transmitted directly in UCS-2 or UCS-4 form,
question of byte order arises: does the high-order byte of
multi-byte character come first or last? For definiteness,
specification recommends that UCS-2 and UCS-4 be transmitted in big
endian byte order (high order byte first), which corresponds to
established network byte order for two- and four-byte quantities,
the ISO 10646 requirement and Unicode recommendation for
text data and to RFC 1641. Furthermore, to maximize chances
proper interpretation, it is recommended that documents
as UCS-2 or UCS-4 always begin with a ZERO-WIDTH NON-BREAKING
character (hexadecimal FEFF or 0000FEFF) which, when byte-
becomes number FFFE or FFFE0000, a character guaranteed to be
assigned. Thus, a user-agent receiving an FFFE as the first
of a text would know that bytes have to be reversed for the
of the text
There exist so-called UCS Transformation Formats than can be used
transmit UCS data, in addition to UCS-2 and UCS-4. UTF-7 [RFC1642]
and UTF-8 [UTF-8] have favorable properties (no byte-
problem, different flavours of ASCII compatibility) that make
worthy of consideration, especially for transmission of
text. Another encoding scheme, MNEM [RFC1345], also has
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,
should not be used
Yergeau, et. al. Standards Track [Page 19]
RFC 2070 HTML Internationalization January 1997
7. HTML Public
7.1. HTML
This section contains a DTD for HTML based on the HTML 2.0 DTD of
1866, incorporating the changes for file upload as specified in
1867, and the changes deriving from this document
"-//IETF//DTD HTML i18n//EN
-- Typical usage
...
--
>
Recommended "IGNORE
-- Certain features of the language are necessary
compatibility with widespread usage, but they
compromise the structural integrity of a document
This feature test entity enables a more
document type definition that
those features
-->
Recommended [
Deprecated "IGNORE">
]]>
Yergeau, et. al. Standards Track [Page 20]
RFC 2070 HTML Internationalization January 1997
Deprecated "INCLUDE
-- Certain features of the language are necessary
compatibility with earlier versions of the specification
but they tend to be used and implemented inconsistently
and their use is deprecated. This feature test
enables a document type definition that
these features
-->
-- Use this feature test entity to validate that
document uses no highlighting tags, which may
ignored on minimal implementations
-->
-- Use this feature test entity to validate that a
contains no forms, which may not be supported in
-->
-- meaning an internet media
(aka MIME content type, as per RFC2045)
-->
-- as per HTTP specification, RFC2068
-->
elements --
"LANG NAME #IMPLIED -- RFC 1766 language tag --
DIR (ltr|rtl) #IMPLIED -- text directionnality --
ID ID #IMPLIED -- element
(from RFC1942) --
CLASS NAMES #IMPLIED -- for subclassing
(from RFC1942) --">
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 -- >
"ISO 8879-1986//ENTITIES Added Latin 1//EN//HTML">
%ISOlat1;
-- one to one mapping -->
-- context-sensitive mapping -->
-- generated text prefix -->
-- generated text suffix -->
Yergeau, et. al. Standards Track [Page 22]
RFC 2070 HTML Internationalization January 1997
-- suspend transform process -->
%attrs
%SDAFORM; "Lit
>
%attrs
%SDAFORM; "B
>
%attrs
%SDAFORM; "It
>
]]>
Yergeau, et. al. Standards Track [Page 23]
RFC 2070 HTML Internationalization January 1997
%SDAPREF; "&#RE;"
>
%attrs
%SDAFORM; "other #Attlist
>
%attrs
%SDAPREF; '"'
%SDASUFF; '"'
>
LANG NAME #
DIR (ltr|rtl) #
ID ID #
CLASS NAMES #
%SDAPREF "Bidi Override #Attval(DIR): "
%SDASUFF "End Bidi
>
%attrs
%SDAPREF "Superscript(#content)"
>
%attrs
%SDAPREF "Subscript(#content)"
>
Yergeau, et. al. Standards Track [Page 24]
RFC 2070 HTML Internationalization January 1997
"REL %linkType #
REV %linkType #
URN CDATA #
TITLE CDATA #
METHODS NAMES #
CHARSET NAME #
">
Recommended [
--
is preferred
Heading
-->
]]>
%attrs
HREF CDATA #
NAME CDATA #
%linkExtraAttributes
%SDAPREF; ""
>
Yergeau, et. al. Standards Track [Page 25]
RFC 2070 HTML Internationalization January 1997
%attrs
SRC CDATA #
ALT CDATA #
ALIGN (top|middle|bottom) #
ISMAP (ISMAP) #
%SDAPREF; "#AttVal(Alt)"
>
%attrs
%just
%SDAFORM; "Para
>
%just
%SDAPREF; "&#RE;&#RE;"
>
%attrs
%just
%SDAFORM; "H1"
Yergeau, et. al. Standards Track [Page 26]
RFC 2070 HTML Internationalization January 1997
>
%attrs
%just
%SDAFORM; "H2"
>
%attrs
%just
%SDAFORM; "H3"
>
%attrs
%just
%SDAFORM; "H4"
>
%attrs
%just
%SDAFORM; "H5"
>
%attrs
%just
%SDAFORM; "H6"
>
]]>
Deprecated [
]]>
Yergeau, et. al. Standards Track [Page 27]
RFC 2070 HTML Internationalization January 1997
| %
| %block.forms">
%attrs
WIDTH NUMBER #
%SDAFORM; "Lit
>
Deprecated [
-- historical, non-conforming parsing mode
the only markup signal is the end
in
-->
%attrs
%SDAFORM; "Lit
%SDAPREF; "Example:&#RE;"
>
%attrs
%SDAFORM; "Lit
%SDAPREF; "Listing:&#RE;"
>
PLAINTEXT - O %literal
%attrs
%SDAFORM; "Lit
Yergeau, et. al. Standards Track [Page 28]
RFC 2070 HTML Internationalization January 1997
>
]]>
%attrs
COMPACT (COMPACT) #
%SDAFORM; "List
%SDAPREF; "Definition List:"
>
%attrs
%SDAFORM; "Term
>
%attrs
%SDAFORM; "LItem
>
%attrs
%just
COMPACT (COMPACT) #
%SDAFORM; "List
>
%attrs
%just
COMPACT (COMPACT) #
%SDAFORM; "List
>
Yergeau, et. al. Standards Track [Page 29]
RFC 2070 HTML Internationalization January 1997
%attrs
%just
COMPACT (COMPACT) #
%SDAFORM; "List
%SDAPREF; "Directory"
>
%attrs
%just
COMPACT (COMPACT) #
%SDAFORM; "List
%SDAPREF; "Menu"
>
%attrs
%just
%SDAFORM; "LItem
>
Recommended [
-- Heading
Text ...
is preferred
Heading
Text ...
-->
]]>
HR | ADDRESS)*">
%attrs
Yergeau, et. al. Standards Track [Page 30]
RFC 2070 HTML Internationalization January 1997
>
%attrs
%just
%SDAFORM; "BQ
>
%attrs
%just
%SDAFORM; "Lit
%SDAPREF; "Address:&#RE;"
>
%attrs
ACTION CDATA #
METHOD (%HTTP-Method)
ENCTYPE %Content-Type; "application/x-www-form-urlencoded
%SDAPREF; "Form:"
%SDASUFF; "Form End."
>
PASSWORD | CHECKBOX |
Yergeau, et. al. Standards Track [Page 31]
RFC 2070 HTML Internationalization January 1997
RADIO | SUBMIT | RESET |
IMAGE | HIDDEN | FILE )">
%attrs
TYPE %InputType
NAME CDATA #
VALUE CDATA #
SRC CDATA #
CHECKED (CHECKED) #
SIZE CDATA #
MAXLENGTH NUMBER #
ALIGN (top|middle|bottom) #
ACCEPT CDATA #IMPLIED --list of content types --
ACCEPT-CHARSET CDATA #IMPLIED --list of charsets accepted --
%SDAPREF; "Input: "
>
%attrs
NAME CDATA #
SIZE NUMBER #
MULTIPLE (MULTIPLE) #
%SDAFORM; "List
%SDAPREF
"Select #AttVal(Multiple)"
>
Yergeau, et. al. Standards Track [Page 32]
RFC 2070 HTML Internationalization January 1997
%attrs
SELECTED (SELECTED) #
VALUE CDATA #
%SDAFORM; "LItem
%SDAPREF
"Option: #AttVal(Value) #AttVal(Selected)"
>
%attrs
NAME CDATA #
ROWS NUMBER #
COLS NUMBER #
ACCEPT-CHARSET CDATA #IMPLIED -- list of charsets accepted --
%SDAFORM; "Para
%SDAPREF; "Input Text -- #AttVal(Name): "
>
]]>
Recommended [
]]>
