Ergebnis für URL: http://www.faqs.org/rfcs/rfc3023.html [1]faqs.org
RFC 3023 - XML Media Types
faqs.org
faqs.org - Internet FAQ Archives
RFC 3023 - XML Media Types
* [2]Internet RFC Index
* [3]Usenet FAQ Index
* [4]Other FAQs
* [5]Documents
* [6]Tools
* Search
* [7]Search FAQs
* [8]Search RFCs
* IFC Home
* [9]Cities
* [10]Countries
* [11]Hospitals
* [12]Web Hosting Ratings
____________________________________________________________________________
Search the RFC Archives
____________________ Search
Or Display the document by number
_________ Display RFC By Number
____________________________________________________________________________
[ [13]RFC Index | [14]Usenet FAQs | [15]Web FAQs | [16]Documents | [17]Cities |
[18]SEC Filings | [19]Restaurant inspections ]
Network Working Group M. Murata
Request for Comments: 3023 IBM Tokyo Research Laboratory
Obsoletes: 2376 S. St.Laurent
Updates: 2048 simonstl.com
Category: Standards Track D. Kohn
Skymoon Ventures
January 2001
XML Media Types
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.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This document standardizes five new media types -- text/xml,
application/xml, text/xml-external-parsed-entity, application/xml-
external-parsed-entity, and application/xml-dtd -- for use in
exchanging network entities that are related to the Extensible Markup
Language (XML). This document also standardizes a convention (using
the suffix '+xml') for naming media types outside of these five types
when those media types represent XML MIME (Multipurpose Internet Mail
Extensions) entities. XML MIME entities are currently exchanged via
the HyperText Transfer Protocol on the World Wide Web, are an
integral part of the WebDAV protocol for remote web authoring, and
are expected to have utility in many domains.
Major differences from [20]RFC 2376 are (1) the addition of text/xml-
external-parsed-entity, application/xml-external-parsed-entity, and
application/xml-dtd, (2) the '+xml' suffix convention (which also
updates the [21]RFC 2048 registration process), and (3) the discussion of
"utf-16le" and "utf-16be".
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4
3. XML Media Types . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Text/xml Registration . . . . . . . . . . . . . . . . . . . 7
3.2 Application/xml Registration . . . . . . . . . . . . . . . . 9
3.3 Text/xml-external-parsed-entity Registration . . . . . . . . 11
3.4 Application/xml-external-parsed-entity Registration . . . . 12
3.5 Application/xml-dtd Registration . . . . . . . . . . . . . . 13
3.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4. The Byte Order Mark (BOM) and Conversions to/from the UTF-16
Charset . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5. Fragment Identifiers . . . . . . . . . . . . . . . . . . . . 15
6. The Base URI . . . . . . . . . . . . . . . . . . . . . . . . 15
7. A Naming Convention for XML-Based Media Types . . . . . . . 16
7.1 Referencing . . . . . . . . . . . . . . . . . . . . . . . . 18
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1 Text/xml with UTF-8 Charset . . . . . . . . . . . . . . . . 19
8.2 Text/xml with UTF-16 Charset . . . . . . . . . . . . . . . . 19
8.3 Text/xml with UTF-16BE Charset . . . . . . . . . . . . . . . 19
8.4 Text/xml with ISO-2022-KR Charset . . . . . . . . . . . . . 20
8.5 Text/xml with Omitted Charset . . . . . . . . . . . . . . . 20
8.6 Application/xml with UTF-16 Charset . . . . . . . . . . . . 20
8.7 Application/xml with UTF-16BE Charset . . . . . . . . . . . 21
8.8 Application/xml with ISO-2022-KR Charset . . . . . . . . . . 21
8.9 Application/xml with Omitted Charset and UTF-16 XML MIME
Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.10 Application/xml with Omitted Charset and UTF-8 Entity . . . 22
8.11 Application/xml with Omitted Charset and Internal Encoding
Declaration . . . . . . . . . . . . . . . . . . . . . . . . 22
8.12 Text/xml-external-parsed-entity with UTF-8 Charset . . . . . 22
8.13 Application/xml-external-parsed-entity with UTF-16 Charset . 23
8.14 Application/xml-external-parsed-entity with UTF-16BE Charset 23
8.15 Application/xml-dtd . . . . . . . . . . . . . . . . . . . . 23
8.16 Application/mathml+xml . . . . . . . . . . . . . . . . . . . 24
8.17 Application/xslt+xml . . . . . . . . . . . . . . . . . . . . 24
8.18 Application/rdf+xml . . . . . . . . . . . . . . . . . . . . 24
8.19 Image/svg+xml . . . . . . . . . . . . . . . . . . . . . . . 24
8.20 INCONSISTENT EXAMPLE: Text/xml with UTF-8 Charset . . . . . 25
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 25
10. Security Considerations . . . . . . . . . . . . . . . . . . 25
References . . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 31
A. Why Use the '+xml' Suffix for XML-Based MIME Types? . . . . 32
A.1 Why not just use text/xml or application/xml and let the XML
processor dispatch to the correct application based on the
referenced DTD? . . . . . . . . . . . . . . . . . . . . . . 32
A.2 Why not create a new subtree (e.g., image/xml.svg) to
represent XML MIME types? . . . . . . . . . . . . . . . . . 32
A.3 Why not create a new top-level MIME type for XML-based media
types? . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
A.4 Why not just have the MIME processor 'sniff' the content to
determine whether it is XML? . . . . . . . . . . . . . . . . 33
A.5 Why not use a MIME parameter to specify that a media type
uses XML syntax? . . . . . . . . . . . . . . . . . . . . . . 33
A.6 How about labeling with parameters in the other direction
(e.g., application/xml; Content-Feature=iotp)? . . . . . . . 34
A.7 How about a new superclass MIME parameter that is defined to
apply to all MIME types (e.g., Content-Type:
application/iotp; $superclass=xml)? . . . . . . . . . . . . 34
A.8 What about adding a new parameter to the Content-Disposition
header or creating a new Content-Structure header to
indicate XML syntax? . . . . . . . . . . . . . . . . . . . . 35
A.9 How about a new Alternative-Content-Type header? . . . . . . 35
A.10 How about using a conneg tag instead (e.g., accept-features:
(syntax=xml))? . . . . . . . . . . . . . . . . . . . . . . . 35
A.11 How about a third-level content-type, such as text/xml/rdf? 35
A.12 Why use the plus ('+') character for the suffix '+xml'? . . 36
A.13 What is the semantic difference between application/foo and
application/foo+xml? . . . . . . . . . . . . . . . . . . . . 36
A.14 What happens when an even better markup language (e.g.,
EBML) is defined, or a new category of data? . . . . . . . . 36
A.15 Why must I use the '+xml' suffix for my new XML-based media
type? . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
B. Changes from [22]RFC 2376 . . . . . . . . . . . . . . . . . . . 37
C. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38
Full Copyright Statement . . . . . . . . . . . . . . . . . . 39
1. Introduction
The World Wide Web Consortium has issued Extensible Markup Language
(XML) 1.0 (Second Edition)[XML]. To enable the exchange of XML
network entities, this document standardizes five new media types --
text/xml, application/xml, text/xml-external-parsed-entity,
application/xml-external-parsed-entity, and application/xml-dtd -- as
well as a naming convention for identifying XML-based MIME media
types.
XML entities are currently exchanged on the World Wide Web, and XML
is also used for property values and parameter marshalling by the
WebDAV[[23]RFC2518] protocol for remote web authoring. Thus, there is a
need for a media type to properly label the exchange of XML network
entities.
Although XML is a subset of the Standard Generalized Markup Language
(SGML) ISO 8879[SGML], which has been assigned the media types
text/sgml and application/sgml, there are several reasons why use of
text/sgml or application/sgml to label XML is inappropriate. First,
there exist many applications that can process XML, but that cannot
process SGML, due to SGML's larger feature set. Second, SGML
applications cannot always process XML entities, because XML uses
features of recent technical corrigenda to SGML. Third, the
definition of text/sgml and application/sgml in [[24]RFC1874] includes
parameters for SGML bit combination transformation format (SGML-
bctf), and SGML boot attribute (SGML-boot). Since XML does not use
these parameters, it would be ambiguous if such parameters were given
for an XML MIME entity. For these reasons, the best approach for
labeling XML network entities is to provide new media types for XML.
Since XML is an integral part of the WebDAV Distributed Authoring
Protocol, and since World Wide Web Consortium Recommendations have
conventionally been assigned IETF tree media types, and since similar
media types (HTML, SGML) have been assigned IETF tree media types,
the XML media types also belong in the IETF media types tree.
Similarly, XML will be used as a foundation for other media types,
including types in every branch of the IETF media types tree. To
facilitate the processing of such types, media types based on XML,
but that are not identified using text/xml or application/xml, SHOULD
be named using a suffix of '+xml' as described in Section 7. This
will allow XML-based tools -- browsers, editors, search engines, and
other processors -- to work with all XML-based media types.
2. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [[25]RFC2119].
As defined in [[26]RFC2781], the three charsets "utf-16", "utf-16le", and
"utf-16be" are used to label UTF-16 text. In this document, "the
UTF-16 family" refers to those three charsets. By contrast, the
phrases "utf-16" or UTF-16 in this document refer specifically to the
single charset "utf-16".
As sometimes happens between two communities, both MIME and XML have
defined the term entity, with different meanings. Section 2.4 of
[[27]RFC2045] says:
"The term 'entity' refers specifically to the MIME-defined header
fields and contents of either a message or one of the parts in the
body of a multipart entity".
Section 4 of [XML] says:
"An XML document may consist of one or many storage units" called
entities that "have content" and are normally "identified by
name".
In this document, "XML MIME entity" is defined as the latter (an XML
entity) encapsulated in the former (a MIME entity).
3. XML Media Types
This document standardizes five media types related to XML MIME
entities: text/xml, application/xml, text/xml-external-parsed-entity,
application/xml-external-parsed-entity, and application/xml-dtd.
Registration information for these media types is described in the
sections below.
Within the XML specification, XML MIME entities can be classified
into four types. In the XML terminology, they are called "document
entities", "external DTD subsets", "external parsed entities", and
"external parameter entities". The media types text/xml and
application/xml MAY be used for "document entities", while text/xml-
external-parsed-entity or application/xml-external-parsed-entity
SHOULD be used for "external parsed entities". The media type
application/xml-dtd SHOULD be used for "external DTD subsets" or
"external parameter entities". application/xml and text/xml MUST NOT
be used for "external parameter entities" or "external DTD subsets",
and MUST NOT be used for "external parsed entities" unless they are
also well-formed "document entities" and are referenced as such.
Note that [[28]RFC2376] (which this document obsoletes) allowed such
usage, although in practice it is likely to have been rare.
Neither external DTD subsets nor external parameter entities parse as
XML documents, and while some XML document entities may be used as
external parsed entities and vice versa, there are many cases where
the two are not interchangeable. XML also has unparsed entities,
internal parsed entities, and internal parameter entities, but they
are not XML MIME entities.
If an XML document -- that is, the unprocessed, source XML document
-- is readable by casual users, text/xml is preferable to
application/xml. MIME user agents (and web user agents) that do not
have explicit support for text/xml will treat it as text/plain, for
example, by displaying the XML MIME entity as plain text.
Application/xml is preferable when the XML MIME entity is unreadable
by casual users. Similarly, text/xml-external-parsed-entity is
preferable when an external parsed entity is readable by casual
users, but application/xml-external-parsed-entity is preferable when
a plain text display is inappropriate.
NOTE: Users are in general not used to text containing tags such
as , and often find such tags quite disorienting or
annoying. If one is not sure, the conservative principle would
suggest using application/* instead of text/* so as not to put
information in front of users that they will quite likely not
understand.
The top-level media type "text" has some restrictions on MIME
entities and they are described in [[29]RFC2045] and [[30]RFC2046]. In
particular, the UTF-16 family, UCS-4, and UTF-32 are not allowed
(except over HTTP[[31]RFC2616], which uses a MIME-like mechanism). Thus,
if an XML document or external parsed entity is encoded in such
character encoding schemes, it cannot be labeled as text/xml or
text/xml-external-parsed-entity (except for HTTP).
Text/xml and application/xml behave differently when the charset
parameter is not explicitly specified. If the default charset (i.e.,
US-ASCII) for text/xml is inconvenient for some reason (e.g., bad web
servers), application/xml provides an alternative (see "Optional
parameters" of application/xml registration in Section 3.2). The
same rules apply to the distinction between text/xml-external-
parsed-entity and application/xml-external-parsed-entity.
XML provides a general framework for defining sequences of structured
data. In some cases, it may be desirable to define new media types
that use XML but define a specific application of XML, perhaps due to
domain-specific security considerations or runtime information.
Furthermore, such media types may allow UTF-8 or UTF-16 only and
prohibit other charsets. This document does not prohibit such media
types and in fact expects them to proliferate. However, developers
of such media types are STRONGLY RECOMMENDED to use this document as
a basis for their registration. In particular, the charset parameter
SHOULD be used in the same manner, as described in Section 7.1, in
order to enhance interoperability.
An XML document labeled as text/xml or application/xml might contain
namespace declarations, stylesheet-linking processing instructions
(PIs), schema information, or other declarations that might be used
to suggest how the document is to be processed. For example, a
document might have the XHTML namespace and a reference to a CSS
stylesheet. Such a document might be handled by applications that
would use this information to dispatch the document for appropriate
processing.
3.1 Text/xml Registration
MIME media type name: text
MIME subtype name: xml
Mandatory parameters: none
Optional parameters: charset
Although listed as an optional parameter, the use of the charset
parameter is STRONGLY RECOMMENDED, since this information can be
used by XML processors to determine authoritatively the character
encoding of the XML MIME entity. The charset parameter can also
be used to provide protocol-specific operations, such as charset-
based content negotiation in HTTP. "utf-8" [[32]RFC2279] is the
recommended value, representing the UTF-8 charset. UTF-8 is
supported by all conforming processors of [XML].
If the XML MIME entity is transmitted via HTTP, which uses a
MIME-like mechanism that is exempt from the restrictions on the
text top-level type (see section 19.4.1 of [[33]RFC2616]), "utf-16"
[[34]RFC2781]) is also recommended. UTF-16 is supported by all
conforming processors of [XML]. Since the handling of CR, LF and
NUL for text types in most MIME applications would cause undesired
transformations of individual octets in UTF-16 multi-octet
characters, gateways from HTTP to these MIME applications MUST
transform the XML MIME entity from text/xml; charset="utf-16" to
application/xml; charset="utf-16".
Conformant with [[35]RFC2046], if a text/xml entity is received with
the charset parameter omitted, MIME processors and XML processors
MUST use the default charset value of "us-ascii"[ASCII]. In cases
where the XML MIME entity is transmitted via HTTP, the default
charset value is still "us-ascii". (Note: There is an
inconsistency between this specification and HTTP/1.1, which uses
ISO-8859-1[ISO8859] as the default for a historical reason. Since
XML is a new format, a new default should be chosen for better
I18N. US-ASCII was chosen, since it is the intersection of UTF-8
and ISO-8859-1 and since it is already used by MIME.)
There are several reasons that the charset parameter is
authoritative. First, some MIME processing engines do transcoding
of MIME bodies of the top-level media type "text" without
reference to any of the internal content. Thus, it is possible
that some agent might change text/xml; charset="iso-2022-jp" to
text/xml; charset="utf-8" without modifying the encoding
declaration of an XML document. Second, text/xml must be
compatible with text/plain, since MIME agents that do not
understand text/xml will fallback to handling it as text/plain.
If the charset parameter for text/xml were not authoritative, such
fallback would cause data corruption. Third, recent web servers
have been improved so that users can specify the charset
parameter. Fourth, [[36]RFC2130] specifies that the recommended
specification scheme is the "charset" parameter.
Since the charset parameter is authoritative, the charset is not
always declared within an XML encoding declaration. Thus, special
care is needed when the recipient strips the MIME header and
provides persistent storage of the received XML MIME entity (e.g.,
in a file system). Unless the charset is UTF-8 or UTF-16, the
recipient SHOULD also persistently store information about the
charset, perhaps by embedding a correct XML encoding declaration
within the XML MIME entity.
Encoding considerations: This media type MAY be encoded as
appropriate for the charset and the capabilities of the underlying
MIME transport. For 7-bit transports, data in UTF-8 MUST be
encoded in quoted-printable or base64. For 8-bit clean transport
(e.g., 8BITMIME[[37]RFC1652] ESMTP or NNTP[[38]RFC0977]), UTF-8 does not
need to be encoded. Over HTTP[[39]RFC2616], no content-transfer-
encoding is necessary and UTF-16 may also be used.
Security considerations: See Section 10.
Interoperability considerations: XML has proven to be interoperable
across WebDAV clients and servers, and for import and export from
multiple XML authoring tools. For maximum interoperability,
validating processors are recommended. Although non-validating
processors may be more efficient, they are not required to handle
all features of XML. For further information, see sub-section 2.9
"Standalone Document Declaration" and section 5 "Conformance" of
[XML].
Published specification: Extensible Markup Language (XML) 1.0 (Second
Edition)[XML].
Applications which use this media type: XML is device-, platform-,
and vendor-neutral and is supported by a wide range of Web user
agents, WebDAV[[40]RFC2518] clients and servers, as well as XML
authoring tools.
Additional information:
Magic number(s): None.
Although no byte sequences can be counted on to always be
present, XML MIME entities in ASCII-compatible charsets
(including UTF-8) often begin with hexadecimal 3C 3F 78 6D 6C
("
"/" / "[" / "]" / "?" / "="
It was thought that "". would not be a good choice since it is
already used as an additional hierarchy delimiter. Also, "*" has a
common wildcard meaning, and "-" and "_" are common word separators
and easily confused. The characters %'`#& are frequently used for
quoting or comments and so are not ideal.
That leaves: ~!$^+{}|
Note that "-" is used heavily in the current registry. "$" and "_"
are used once each. The others are currently unused.
It was thought that '+' expressed the semantics that a MIME type can
be treated (for example) as both scalable vector graphics AND ALSO as
XML; it is both simultaneously.
A.13 What is the semantic difference between application/foo and
application/foo+xml?
MIME processors that are unaware of XML will treat the '+xml' suffix
as completely opaque, so it is essential that no extra semantics be
assigned to its presence. Therefore, application/foo and
application/foo+xml SHOULD be treated as completely independent media
types. Although, for example, text/calendar+xml could be an XML
version of text/calendar[[143]RFC2445], it is possible that this
(hypothetical) new media type would include new semantics as well as
new syntax, and in any case, there would be many applications that
support text/calendar but had not yet been upgraded to support
text/calendar+xml.
A.14 What happens when an even better markup language (e.g., EBML) is
defined, or a new category of data?
In the ten years that MIME has existed, XML is the first generic data
format that has seemed to justify special treatment, so it is hoped
that no further suffixes will be necessary. However, if some are
later defined, and these documents were also XML, they would need to
specify that the '+xml' suffix is always the outermost suffix (e.g.,
application/foo+ebml+xml not application/foo+xml+ebml). If they were
not XML, then they would use a regular suffix (e.g.,
application/foo+ebml).
A.15 Why must I use the '+xml' suffix for my new XML-based media type?
You don't have to, but unless you have a good reason to explicitly
disallow generic XML processing, you should use the suffix so as not
to curtail the options of future users and developers.
Whether the inventors of a media type, today, design it for dispatch
to generic XML processing machinery (and most won't) is not the
critical issue. The core notion is that the knowledge that some
media type happens to use XML syntax opens the door to unanticipated
kinds of processing beyond those envisioned by its inventors, and on
this basis identifying such encoding is a good and useful thing.
Developers of new media types are often tightly focused on a
particular type of processing that meets current needs. But there is
no need to rule out generic processing as well, which could make your
media type more valuable over time. It is believed that registering
with the '+xml' suffix will cause no interoperability problems
whatsoever, while it may enable significant new functionality and
interoperability now and in the future. So, the conservative
approach is to include the '+xml' suffix.
Appendix B. Changes from [144]RFC 2376
There are numerous and significant differences between this
specification and [[145]RFC2376], which it obsoletes. This appendix
summarizes the major differences only.
First, text/xml-external-parsed-entity and application/xml-external-
parsed-entity are added as media types for external parsed entities,
and text/xml and application/xml are now prohibited.
Second, application/xml-dtd is added as a media type for external DTD
subsets and external parameter entities, and text/xml and
application/xml are now prohibited.
Third, "utf-16le" and "utf-16be" are added. [146]RFC 2781 has introduced
these BOM-less variations of the UTF-16 family.
Fourth, a naming convention ('+xml') for XML-based media types has
been added, which also updates [[147]RFC2048] as described in Section 7.
By following this convention, an XML-based media type can be easily
recognized as such.
Appendix C. Acknowledgements
This document reflects the input of numerous participants to the
[148]ietf-xml-mime@imc.org mailing list, though any errors are the
responsibility of the authors. Special thanks to:
Mark Baker, James Clark, Dan Connolly, Martin Duerst, Ned Freed,
Yaron Goland, Rick Jelliffe, Larry Masinter, David Megginson, Keith
Moore, Chris Newman, Gavin Nicol, Marshall Rose, Jim Whitehead and
participants of the XML activity at the W3C.
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
User Contributions:
Comment about this RFC, ask questions, or add new information about this topic:
Name: ____________________
E-mail: ____________________
[ ] Show my email publicly
Public Comment: (50-4000 characters)
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
(BUTTON) Send comment
Previous: [149]RFC 3022 - Traditional IP Network Address Translator (Traditional
NAT)
Next: [150]RFC 3024 - Reverse Tunneling for Mobile IP, revised
[ [151]RFC Index | [152]Usenet FAQs | [153]Web FAQs | [154]Documents |
[155]Cities | [156]Restaurant inspections ]
____________________________________________________________________________
Some parts © 2024 Advameg, Inc. |
References
1. http://www.faqs.org/
2. http://www.faqs.org/rfcs/
3. http://www.faqs.org/faqs/
4. http://www.faqs.org/contrib/
5. http://www.faqs.org/docs/
6. http://www.faqs.org/tools/
7. http://www.faqs.org/faqs/faqsearch.html
8. http://www.faqs.org/rfcs/rfcsearch.html
9. http://www.city-data.com/
10. http://www.country-data.com/
11. http://www.hospital-data.com/
12. http://www.webhostingratings.com/
13. http://www.faqs.org/rfcs/
14. http://www.faqs.org/faqs/
15. http://www.faqs.org/contrib/
16. http://www.faqs.org/docs/
17. http://www.city-data.com/
18. http://www.faqs.org/sec-filings/
19. http://www.city-data.com/restaurant-inspections.html
20. http://www.faqs.org/rfcs/rfc2376.html
21. http://www.faqs.org/rfcs/rfc2048.html
22. http://www.faqs.org/rfcs/rfc2376.html
23. http://www.faqs.org/rfcs/rfc2518.html
24. http://www.faqs.org/rfcs/rfc1874.html
25. http://www.faqs.org/rfcs/rfc2119.html
26. http://www.faqs.org/rfcs/rfc2781.html
27. http://www.faqs.org/rfcs/rfc2045.html
28. http://www.faqs.org/rfcs/rfc2376.html
29. http://www.faqs.org/rfcs/rfc2045.html
30. http://www.faqs.org/rfcs/rfc2046.html
31. http://www.faqs.org/rfcs/rfc2616.html
32. http://www.faqs.org/rfcs/rfc2279.html
33. http://www.faqs.org/rfcs/rfc2616.html
34. http://www.faqs.org/rfcs/rfc2781.html
35. http://www.faqs.org/rfcs/rfc2046.html
36. http://www.faqs.org/rfcs/rfc2130.html
37. http://www.faqs.org/rfcs/rfc1652.html
38. http://www.faqs.org/rfcs/rfc977.html
39. http://www.faqs.org/rfcs/rfc2616.html
40. http://www.faqs.org/rfcs/rfc2518.html
41. mailto:mmurata@trl.ibm.co.jp
42. mailto:simonstl@simonstl.com
43. mailto:dan@dankohn.com
44. mailto:tbray@textuality.com
45. mailto:jeanpa@microsoft.com
46. mailto:cmsmcq@uic.edu
47. mailto:eve.maler@east.sun.com
48. http://www.faqs.org/rfcs/rfc2279.html
49. http://www.faqs.org/rfcs/rfc2781.html
50. http://www.faqs.org/rfcs/rfc2130.html
51. http://www.faqs.org/rfcs/rfc1652.html
52. http://www.faqs.org/rfcs/rfc977.html
53. http://www.faqs.org/rfcs/rfc2616.html
54. http://www.faqs.org/rfcs/rfc2781.html
55. http://www.faqs.org/rfcs/rfc2396.html
56. http://www.w3.org/TR/xptr
57. http://www.faqs.org/rfcs/rfc2396.html
58. http://www.faqs.org/rfcs/rfc2396.html
59. http://www.w3.org/TR/xmlbase
60. http://www.faqs.org/rfcs/rfc2616.html
61. http://www.faqs.org/rfcs/rfc2703.html
62. http://www.faqs.org/rfcs/rfc2048.html
63. http://www.faqs.org/rfcs/rfc3023.html
64. http://www.faqs.org/rfcs/rfc3023.html
65. http://www.faqs.org/rfcs/rfc3023.html
66. http://www.faqs.org/rfcs/rfc821.html
67. http://www.faqs.org/rfcs/rfc2781.html
68. http://www.faqs.org/rfcs/rfc2616.html
69. http://www.faqs.org/rfcs/rfc1557.html
70. http://www.faqs.org/rfcs/rfc1557.html
71. http://www.faqs.org/rfcs/rfc2046.html
72. http://www.faqs.org/rfcs/rfc1557.html
73. http://www.faqs.org/rfcs/rfc1557.html
74. http://www.faqs.org/rfcs/rfc2048.html
75. http://www.faqs.org/rfcs/rfc1874.html
76. http://www.faqs.org/rfcs/rfc1874.html
77. http://www.faqs.org/rfcs/rfc2413.html
78. http://www.w3.org/TR/REC-CSS2/
79. http://www.w3.org/TR/REC-MathML/
80. http://www.w3.org/TR/REC-png
81. http://www.w3.org/TR/REC-rdf-syntax/
82. http://www.faqs.org/rfcs/rfc821.html
83. http://www.faqs.org/rfcs/rfc977.html
84. http://www.faqs.org/rfcs/rfc977.html
85. http://www.faqs.org/rfcs/rfc1557.html
86. http://www.faqs.org/rfcs/rfc1557.html
87. http://www.faqs.org/rfcs/rfc1652.html
88. http://www.faqs.org/rfcs/rfc1652.html
89. http://www.faqs.org/rfcs/rfc1874.html
90. http://www.faqs.org/rfcs/rfc1874.html
91. http://www.faqs.org/rfcs/rfc2045.html
92. http://www.faqs.org/rfcs/rfc2045.html
93. http://www.faqs.org/rfcs/rfc2046.html
94. http://www.faqs.org/rfcs/rfc2046.html
95. http://www.faqs.org/rfcs/rfc2048.html
96. http://www.faqs.org/rfcs/rfc2048.html
97. http://www.faqs.org/rfcs/rfc2060.html
98. http://www.faqs.org/rfcs/rfc2060.html
99. http://www.faqs.org/rfcs/rfc2077.html
100. http://www.faqs.org/rfcs/rfc2077.html
101. http://www.faqs.org/rfcs/rfc2119.html
102. http://www.faqs.org/rfcs/rfc2119.html
103. http://www.faqs.org/rfcs/rfc2130.html
104. http://www.faqs.org/rfcs/rfc2130.html
105. http://www.faqs.org/rfcs/rfc2279.html
106. http://www.faqs.org/rfcs/rfc2279.html
107. http://www.faqs.org/rfcs/rfc2376.html
108. http://www.faqs.org/rfcs/rfc2376.html
109. http://www.faqs.org/rfcs/rfc2396.html
110. http://www.faqs.org/rfcs/rfc2396.html
111. http://www.faqs.org/rfcs/rfc2413.html
112. http://www.faqs.org/rfcs/rfc2413.html
113. http://www.faqs.org/rfcs/rfc2445.html
114. http://www.faqs.org/rfcs/rfc2518.html
115. http://www.faqs.org/rfcs/rfc2518.html
116. http://www.faqs.org/rfcs/rfc2616.html
117. http://www.faqs.org/rfcs/rfc2616.html
118. http://www.faqs.org/rfcs/rfc2629.html
119. http://www.faqs.org/rfcs/rfc2629.html
120. http://www.faqs.org/rfcs/rfc2703.html
121. http://www.faqs.org/rfcs/rfc2703.html
122. http://www.faqs.org/rfcs/rfc2781.html
123. http://www.faqs.org/rfcs/rfc2781.html
124. http://www.faqs.org/rfcs/rfc2801.html
125. http://www.faqs.org/rfcs/rfc2801.html
126. http://www.w3.org/TR/SVG
127. http://www.w3.org/TR/xhtml1
128. http://www.w3.org/TR/REC-xml
129. http://www.w3.org/TR/xslt
130. mailto:mmurata@trl.ibm.co.jp
131. mailto:simonstl@simonstl.com
132. http://www.simonstl.com/
133. mailto:dan@dankohn.com
134. http://www.dankohn.com/
135. http://www.faqs.org/rfcs/rfc2048.html
136. http://www.faqs.org/rfcs/rfc2077.html
137. http://www.faqs.org/rfcs/rfc2060.html
138. http://www.faqs.org/rfcs/rfc2045.html
139. http://www.faqs.org/rfcs/rfc2801.html
140. http://www.faqs.org/rfcs/rfc2703.html
141. http://www.faqs.org/rfcs/rfc2048.html
142. http://www.faqs.org/rfcs/rfc2045.html
143. http://www.faqs.org/rfcs/rfc2445.html
144. http://www.faqs.org/rfcs/rfc2376.html
145. http://www.faqs.org/rfcs/rfc2376.html
146. http://www.faqs.org/rfcs/rfc2781.html
147. http://www.faqs.org/rfcs/rfc2048.html
148. mailto:ietf-xml-mime@imc.org
149. http://www.faqs.org/rfcs/rfc3022.html
150. http://www.faqs.org/rfcs/rfc3024.html
151. http://www.faqs.org/rfcs/
152. http://www.faqs.org/faqs/
153. http://www.faqs.org/contrib/
154. http://www.faqs.org/docs/
155. http://www.city-data.com/
156. http://www.city-data.com/restaurant-inspections.html
Usage: http://www.kk-software.de/kklynxview/get/URL
e.g. http://www.kk-software.de/kklynxview/get/http://www.kk-software.de
Errormessages are in German, sorry ;-)