Network Working Group E. Wilde
Internet-Draft Swiss Federal Institute of
Expires: October 3, 2003 Technology
April 4, 2003
URI Fragment Identifiers for the text/plain Media Type
draft-wilde-text-fragment-02
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 3, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This memo defines URI fragment identifiers for text/plain resources.
These fragment identifiers make it possible to refer to parts of a
text resource, identified by character count or range, line count or
range, or a regular expression. These identification methods can be
combined to identify more than one sub-resource of a text/plain
resource.
Wilde Expires October 3, 2003 [Page 1]
Internet-Draft text/plain Fragment Identifiers April 2003
Table of Contents
1. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 What is text/plain? . . . . . . . . . . . . . . . . . . . . 3
2.1.1 Line Endings in text/plain Resources . . . . . . . . . . . . 4
2.2 What is a URI Fragment Identifier? . . . . . . . . . . . . . 4
2.3 Why text/plain Fragment Identifiers? . . . . . . . . . . . . 5
2.4 Incremental Deployment . . . . . . . . . . . . . . . . . . . 5
3. Fragment Identification Methods . . . . . . . . . . . . . . 6
3.1 Fragment Identification Schemes . . . . . . . . . . . . . . 6
3.1.1 Principles . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.2 Combining the Principles . . . . . . . . . . . . . . . . . . 8
3.1.3 Regular Expressions . . . . . . . . . . . . . . . . . . . . 9
3.1.4 Combining Fragment Identification Scheme Parts . . . . . . . 9
4. Fragment Identification Syntax . . . . . . . . . . . . . . . 9
4.1 Handling of position Values . . . . . . . . . . . . . . . . 10
4.2 Non-ASCII Characters in Regular Expressions . . . . . . . . 10
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . 12
7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1 From -01 to -02 . . . . . . . . . . . . . . . . . . . . . . 12
7.2 From -00 to -01 . . . . . . . . . . . . . . . . . . . . . . 12
Normative References . . . . . . . . . . . . . . . . . . . . 13
Non-Normative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . 14
A. POSIX BRE Syntax . . . . . . . . . . . . . . . . . . . . . . 14
B. Where to send Comments . . . . . . . . . . . . . . . . . . . 14
C. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . 15
Wilde Expires October 3, 2003 [Page 2]
Internet-Draft text/plain Fragment Identifiers April 2003
1. Open Issues
This section will not be part of the final RFC text, it serves as a
place to collect open issues regarding this memo.
o Provide more complex example(s).
o Provide short BRE syntax and description in Appendix A (by
inclusion or by reference).
o Should regex ranges be allowed (ie, a fragment ranging from one
regex match to another regex match)?
o Should a more sophisticated regex mechanism than BREs be used?
o Regexes by themselves may identify disjoint sub-resources. Should
there be a mechanism to say something like "the 5th appearance of
the following regex"? Or are users responsible for composing
regexes which do not need this kind of additional mechanism?
o Is the concatenation of scheme parts (Section 3.1.4) and its
semantics of joining the individual fragments a good thing? Or a
bad thing?
o Should there be more schemes? Or less?
o Is it necessary to mention that applications must be able to
transcode characters, because the text file and the fragment
identifier may use different character encodings? What about
character normalization? Should that be addressed or at least
mentioned as being out of scope?
2. Introduction
Compliant software MUST follow this specification. The capitalized
key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
2.1 What is text/plain?
Internet Media Types as defined in RFC 2045 [2] and RFC 2046 [3] are
used to identify different types and sub-types of media. RFC 2046 [3]
and RFC 2646 [4] specify the text/plain media type, which is used for
simple, unformatted text. Quoting from RFC 2046 [3]: "Plain text does
not provide for or allow formatting commands, font attribute
specifications, processing instructions, interpretation directives,
Wilde Expires October 3, 2003 [Page 3]
Internet-Draft text/plain Fragment Identifiers April 2003
or content markup. Plain text is seen simply as a linear sequence of
characters, possibly interrupted by line breaks or page breaks."
The text/plain media type does not restrict the character encoding,
any character encoding may be used. In the absence of an explicit
character encoding declaration, US-ASCII is assumed as the default
character encoding. This variability of the character encoding makes
it impossible to count characters in a text/plain resource without
taking the character encoding into account, because there are many
character encodings using more than one octet per character.
The biggest advantage of text/plain resources is their portability
among different platforms. As long as they use popular character
encodings (such as US-ASCII), they can be displayed and processed on
virtually every computer system.
2.1.1 Line Endings in text/plain Resources
RFC 2046 [3] and RFC 2646 [4] specify that line endings in text/plain
resources are represented by CR+LF character sequences. In
implementation practice, however, text/plain resources use different
conventions, for example depending on the operating system they have
been created with (in most cases, Unix uses LF, MacOS uses CR, and
Windows uses CR+LF). Because of this diversity of conventions,
implementations interpreting text/plain fragment identifiers MUST
take different line ending conventions into account.
Line endings in text/plain resources MAY be represented by other
character (sequences) than CR+LF, specifically CR, LF, NEL, and
CR+NEL. All these character (sequences) MUST be interpreted as line
endings. This interpretation MUST affect the evaluation of text/plain
fragment identifiers. All representations of line endings (CR+LF, CR,
LF, NEL, and CR+NEL) MUST be treated as a single character in
character counts. For the purpose of regular expression matching, all
representations of line endings must be treated as single LF
characters. The reason for this is that fragment identifiers should
not be broken by converting a file from one line ending convention to
another.
In general, the line ending conventions used in text/plain resources
depends on the character encoding of the resource. Implementations
SHOULD attempt to be as accurate as possible in recognizing line
ending specific to particular character encodings, and MUST treat all
these line endings as one character in character counts, and single
LF characters for regular expression matching.
2.2 What is a URI Fragment Identifier?
Wilde Expires October 3, 2003 [Page 4]
Internet-Draft text/plain Fragment Identifiers April 2003
URIs are the identification mechanism for resources on the Web. The
URI syntax specified in RFC 2396 [5] includes as part of a URI
reference a fragment identifier, which (quoting from RFC 2396 [5])
"consists of additional reference information to be interpreted by
the user agent after the retrieval action has been successfully
completed. As such, it is not part of a URI, but is often used in
conjunction with a URI. The semantics of a fragment identifier is a
property of the data resulting from a retrieval action, regardless of
the type of URI used in the reference. Therefore, the format and
interpretation of fragment identifiers is dependent on the media type
of the retrieval result."
The most popular fragment identifier is defined for text/html
(defined in RFC 2854 [8]), and makes it possible to refer to a
specific element (identified by a 'name' or 'id' attribute) of an
HTML document.
2.3 Why text/plain Fragment Identifiers?
Referring to specific parts of a resource can be very useful, because
it enables users to create more specific references. Rather than
pointing to a whole resource, users can create references to the part
they really are interested in or want to talk about. Even though it
is suggested that fragment identification methods are specified in a
media type's MIME registration, many media types do not have fragment
identification methods associated with them.
Fragment identifiers are only useful if supported by the client,
because they are only interpreted by the client. Therefore, a new
fragment identification method will require some time to be adopted
by clients, and older clients will not support it. However, because
the URI reference still works even if the fragment identifier is not
supported (the resource is retrieved, but the fragment identifier is
not interpreted), rapid adoption is not highly critical to ensure the
success of a new fragment identification method.
Fragment identifiers for text/plain make it possible to refer to
specific parts of a text resource, using concepts of positions and
ranges, which may be applied to characters and lines. The also
support locating a fragment by using a regular expression for
searching for a specific character sequence. Thus, text/plain
fragment identifiers enable users to exchange information more
specifically, thereby reducing time and effort that is necessary to
manually search for the relevant part of a text/plain resource.
2.4 Incremental Deployment
As long as support for text/plain fragment identifiers is not
Wilde Expires October 3, 2003 [Page 5]
Internet-Draft text/plain Fragment Identifiers April 2003
implemented by all programs, it is important to consider the
implications of incremental deployment. Clients (for example, Web
browsers) not supporting the text/plain fragment identifier described
in this memo will work with URI references to text/plain resources,
but they will fail to locate the sub-resource identified by the
fragment identifier. This is a reasonable fallback behavior, and in
general users should take into account the possibility that a program
interpreting a given URI reference will fail to interpret the
fragment identifier part. Since fragment identifier evaluation is
local to the client (and happens after retrieving the resource),
there is no way for a server to determine whether a requesting client
is using a URI reference containing a fragment identifier.
3. Fragment Identification Methods
The identification of resource fragments of text/plain resources can
be based on different foundations. Since it is not possible to insert
explicit, invisible identifiers into a text/plain resource (as for
example used in HTML documents, implemented through special
attributes), fragment identification has to rely on certain inherent
criteria of the resource. This memo specifies fragment identification
using five different methods, character positions and ranges, line
positions and ranges, and regular expression matching.
When interpreting character or line numbers, implementations MUST
take the character encoding of the resource into account, because
character count and octet count may differ for the character encoding
being used. For example, a resource using UTF-16 encoding (as
specified in RFC 2718 [9]) uses two octets per character, and it may
have a leading BOM (Byte-Order Mark), which does not count as a
character and thus also affects the mapping from a simple octet count
to a character count.
3.1 Fragment Identification Schemes
Fragment identification can be done using regular expressions or
combining two orthogonal principles, which are positions and ranges,
and characters and lines. The following section describe the
principles themselves, while Section 3.1.2 describes the combination
of the principles.
3.1.1 Principles
3.1.1.1 Positions and Ranges
A position does not identify an actual fragment of the resource, but
a position inside the resource, which could be regarded as a fragment
of zero length. The usa case for positions is to provide pointers for
Wilde Expires October 3, 2003 [Page 6]
Internet-Draft text/plain Fragment Identifiers April 2003
applications which may use them to implement functionalities such as
"insert some text here", which needs a position rather than a
fragment. Positions are counted from zero (position zero being before
the first character or line of a text/plain resource), so that a
text/plain resource having one character has two positions, one
before the first character (position 0), and one after the first
character (position 1).
Since positions are fragments of length zero, applications SHOULD use
other methods than highlighting to indicate positions, the most
reasonable way being the positions of a cursor (if the application
supports the concept of a cursor).
Ranges, on the other hand, identify fragments of a resource that have
a length that may be greater than zero. As a general principle for
ranges, they specify both a lower and a upper bound. The start or the
end of a range specification may be omitted, defaulting to the first
repectively last position of the resource. The ending position of a
range must have a value greater than or equal to the lower position
(consequently, a range with identical lower and upper positions is
legal, and identifies a range of length 0, which is equivalent to a
position). Counting for ranges uses positions, so that a fragment
containing one entity is specified by using a range with two adjacent
positions.
Since ranges are fragments with a length greater than zero,
applications SHOULD use methods like highlighting to indicate ranges
(if the application supports the concept of highlighting).
For positions and ranges it is implicitly assumed that if a number is
greater than the actual number of entities in the resource, then it
is referring to the last entity of the resource.
3.1.1.2 Characters and Lines
The concept of positions and ranges may be applied to characters and
lines. In both cases, positions indicate points between entities,
while ranges identify zero or more entities by indicating positions.
Character positions are numbered starting with zero (ignoring initial
BOM marks or similar concepts that are not part of the actual textual
content of a text/plain resource), and counting each character
separately, with the exception of line endings, which are always
counted as one character (Section 2.1.1 describes how line endings
MUST be identified).
Line positions are numbered starting with zero (with line position
zero always being identical with character position zero), with
Wilde Expires October 3, 2003 [Page 7]
Internet-Draft text/plain Fragment Identifiers April 2003
Section 2.1.1 describing how line endings must be identified.
Fragments identified by lines include the line endings, so
applications identifying line-based fragments MUST include the line
endings in the fragment identification they are using (eg, the
highlighted selection). If a resource does not contain any line
endings, then it consists of a single (the first) line.
3.1.2 Combining the Principles
In the following sections, the principles described in the preceding
section are combined, resulting in four use cases.
3.1.2.1 Character Position
Using the char scheme followed by a single number, it is possible to
point to a character position (ie, a fragment of length zero between
two characters). Rather than identifying a fragment consisting of a
number of characters, this method identifies a position between two
characters (or before the first or after the last character).
Character position counting starts with 0, so the character position
before the first character of a text/plain resource has the character
position 0, and a resource containing n distinct characters has n+1
distinct character positions.
3.1.2.2 Character Range
If it is necessary to identify a fragment of zero or more characters
using character counting, this can be done by using a character
range, using the char scheme followed by a range specification. A
character range is a consecutive region of the resource that extends
from the starting character position of the range to the ending
character position of the range.
3.1.2.3 Line Position
Using the line scheme followed by a single number, it is possible to
point to a character position (ie, a fragment of length zero between
two lines). Rather than identifying a fragment consisting of a number
of lines, this method identifies a position between two lines (or
before the first or after the last line). Line position counting
starts with 0, so the line position before the first line of a text/
plain resource has the line position 0, and a resource containing n
distinct lines has n+1 distinct line positions.
3.1.2.4 Line Range
If it is necessary to identify a fragment of zero or more lines using
line counting, this can be done by using a line range, using the line
Wilde Expires October 3, 2003 [Page 8]
Internet-Draft text/plain Fragment Identifiers April 2003
scheme followed by a range specification. A line range is a
consecutive region of the resource that extends from the starting
line position of the range to the ending line position of the range.
3.1.3 Regular Expressions
A common problem with fragment identifiers is their robustness (to
changes in the resource), and character and line counts can be broken
very easily. A more robust way of identifying a fragment is by
searching for a specific pattern. Thus, it is possible to use a Basic
Regular Expression (BRE) as defined by ISO 9945-2 [6] (the POSIX
standard) as a fragment identifier (Appendix A contains a short
summary of the POSIX BRE syntax).
3.1.4 Combining Fragment Identification Scheme Parts
While in most cases only one fragment identification scheme part will
be used, it is possible to combine them. By simply concatenating
different fragment identification scheme parts, separated by a
semicolon, the whole fragment identifier refers to the union of all
fragments of the text resource identified by the individual fragment
identification scheme parts. This way, it is possible to identify
disjoint ranges, such as multiple line ranges.
It should be noticed that regular expressions by themselves may
identify disjoint fragments, which is true in any case where the
regular expression matches more than one occurrence in the resource.
Since disjoint fragments can be identified, implementations SHOULD
make sure that these fragments are appropriately marked, for example
by highlighting the fragment (rather than only scrolling to some
line, which only identifies a single location in the resource). If an
implementation can not mark disjoint fragments, it MAY resort to
marking only the first of the disjoint fragments. However, the exact
method of how implementations deal with disjoint fragments depends on
the application and interface, and is beyond the scope of this memo.
4. Fragment Identification Syntax
The syntax for the fragment identifiers is straightforward. The
syntax defines three schemes, 'char', 'line', and 'match'. The 'char'
and 'line' can be used in two different variants, either the position
variant (with a single number), or the range variant (with two
comma-separated positions). The 'match' scheme has a regular
expression as parameter, which must be specified as a string with
escaped semicolons (because the semicolon is used to concatenate
multiple fragment identification schem parts).
Wilde Expires October 3, 2003 [Page 9]
Internet-Draft text/plain Fragment Identifiers April 2003
The following syntax definition uses ABNF as defined in RFC 2234 [7].
text-fragment = text-scheme 0*( ";" text-scheme)
text-scheme = ( char-scheme / line-scheme / match-scheme )
char-scheme = "char=" ( position / range )
line-scheme = "line=" ( position / range )
match-scheme = "match=" regex
position = number
range = (position "," [ position ]) / ("," position )
number = 1*DIGIT
regex = StringWithEscapedSemicolon
The StringWithEscapedSemicolon is a string where all characters may
appear literally (except the characters which are required by the URI
syntax to be escaped), with the exception of a semicolon. A semicolon
that should be part of the regular expression must be escaped with a
leading backslash, and implementations MUST make sure to properly
interpret regular expressions, properly dereferencing all escape
mechanisms that apply (ie, URI encoding, semicolon escaping, and BRE
escaping, as well as any additional escaping that may be present due
to the context of the URI reference).
4.1 Handling of position Values
If any position value (as a position or inside a range) is greater
than the value for the actual resource, then it identifies the last
character or line position of the resource. If the first position
value in a range is not present, then the range extends from the
start of the resource. If the second position value in a range is not
present, then the range extends to the end of the resource. If a
range scheme's positions are not properly ordered (ie, the first
number is less than the second), then this scheme part MUST be
ignored.
4.2 Non-ASCII Characters in Regular Expressions
RFC 2396 [5] does not define how to use non-ASCII characters in URIs.
Consequently, it is not possible to use non-ASCII characters in URIs
in a standardized and reliable way. However, work on
Internationalized Resource Identifiers (IRI) [10] is in progress, and
as soon as this work results in a published RFC, it will be possible
to use non-ASCII characters in regular expressions, using the
encoding defined by IRI.
5. Examples
The following examples show some usages for the fragment identifiers
Wilde Expires October 3, 2003 [Page 10]
Internet-Draft text/plain Fragment Identifiers April 2003
defined in this memo.
http://example.com/text.txt#char=100
This URI reference identifies the position after the 100th character
of the text.txt resource. It should be noted that it is not clear
which octet(s) of the resource this will be without retrieving the
resource and thus knowing which character encoding is it using (in
case of HTTP, this information will be given in the response's
Content-type header). If the resource has fewer than 100 characters,
the URI reference identifies the position after the resource's last
character.
http://example.com/text.txt#line=10,20
This URI reference identifies lines 11 to 20 of the text.txt
resource. If the resource has fewer than 11 lines, it identifies the
position after last line. If the resource has less than 20 but at
least 11 lines, it identifies the lines 11 to the last line of the
resource.
http://example.com/text.txt#match=searchterm
This URI reference identifies all occurrences of the regular
expression 'searchterm' in the resource, ie all occurrences of the
string 'searchterm'. If there is more than one occurrence, then this
URI reference identifies a disjoint fragment, consisting of all of
these occurrences. If there is no occurrence of the search term, the
URI reference does not identify a fragment.
http://example.com/text.txt#line=,1;match=searchterm
This URI reference identifies the first line and all occurrences of
the regular expression 'searchterm' in the resource. If there is an
occurrence of 'searchterm' outside of the first line, then this URI
reference identifies a disjoint fragment.
http://example.com/text.txt#match=hello\;
This URI reference identifies all occurrences of the regular
expression 'hello;' in the resource. The semicolon with the leading
backslash has to be interpreted as a literal semicolon insode of the
BRE, treating the '\;' as an escaped ';', so that the actual regular
Wilde Expires October 3, 2003 [Page 11]
Internet-Draft text/plain Fragment Identifiers April 2003
expression is 'hello;'. If there is more than one occurrence of this
regular expression, then this URI reference identifies a disjoint
fragment, consisting of all of these occurrences.
...
(more complex example...)
6. Security Considerations
Regular expression matching code is notoriously vulnerable to buffer
overflow security holes, so any implementation supporting text/plain
fragment identifiers MUST make sure that the code being used has been
tested against buffer overflow attacks.
7. Change Log
7.1 From -01 to -02
o Fundamental change in semantics: counts turn into positions
(between characters or lines), so in order to identify a character
or line, ranges must be used (which now use positions to specify
the upper and lower bounds of the range).
o Made the first value of a range optional as well, so that line=,5
also is legal, identifying everything from the start of the
resource to the 5th line.
o Changed the syntax from paranthesis-style to a more traditional
style using equals-signs.
7.2 From -00 to -01
o Made the second count value of ranges optional, so that something
like line(10,) is legal and properly defined.
o Added non-normative reference to Internet draft about non-ASCII
characters in search strings.
o Added Section 2.4 about incremental deployement.
o Added more elaborate examples.
o Added text about regex buffer overflow problems in Section 6.
o Added Section 2.1.1 about line endings in text/plain resources.
Wilde Expires October 3, 2003 [Page 12]
Internet-Draft text/plain Fragment Identifiers April 2003
o Added Section 1 to collect open issues regarding this memo (will
be deleted in final RFC text).
Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
[3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
[4] Gellens, R., "The Text/Plain Format Parameter", RFC 2646, August
1999.
[5] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[6] International Organization for Standardization, "Information
technology - Portable Operating System Interface (POSIX) - Part
2: Shell and Utilities", ISO 9945-2, 1993.
[7] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
Non-Normative References
[8] Connolly, D. and L. Masinter, "The 'text/html' Media Type", RFC
2854, June 2000.
[9] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646",
RFC 2781, February 2000.
[10] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRI)", draft-duerst-iri-03 (work in progress),
March 2003.
[11] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June
1999.
Wilde Expires October 3, 2003 [Page 13]
Internet-Draft text/plain Fragment Identifiers April 2003
Author's Address
Erik Wilde
Swiss Federal Institute of Technology
ETH-Zentrum
8092 Zurich
Switzerland
Phone: +41-1-6325132
EMail: net.dret@dret.net
URI: http://dret.net/netdret/
Appendix A. POSIX BRE Syntax
This section contains a short (and non-normative) summary of the
POSIX BRE syntax defined in ISO 9945-2 [6]. The definition of BRE
syntax in ISO 9945-2 [6] is the normative reference, and the
following summary is for informative purposes only.
(tbd - is there some rfc that could be referenced instead?)
Appendix B. Where to send Comments
Please send all comments and questions concerning this document to
Erik Wilde.
Appendix C. Acknowledgements
This document has been prepared using the IETF document DTD described
in RFC 2629 [11].
Thanks for comments and suggestions provided by Dan Kohn, John Cowan,
Benja Fallenstein, and Henrik Levkowetz.
Wilde Expires October 3, 2003 [Page 14]
Internet-Draft text/plain Fragment Identifiers April 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
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
Wilde Expires October 3, 2003 [Page 15]
Internet-Draft text/plain Fragment Identifiers April 2003
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.
Wilde Expires October 3, 2003 [Page 16]
