diff options
Diffstat (limited to 'doc/rfc/rfc5147.txt')
| -rw-r--r-- | doc/rfc/rfc5147.txt | 955 |
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc5147.txt b/doc/rfc/rfc5147.txt new file mode 100644 index 0000000..ebe2867 --- /dev/null +++ b/doc/rfc/rfc5147.txt @@ -0,0 +1,955 @@ + + + + + + +Network Working Group E. Wilde +Request for Comments: 5147 UC Berkeley +Updates: 2046 M. Duerst +Category: Standards Track Aoyama Gakuin University + April 2008 + + + URI Fragment Identifiers for the text/plain Media Type + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This memo defines URI fragment identifiers for text/plain MIME + entities. These fragment identifiers make it possible to refer to + parts of a text/plain MIME entity, either identified by character + position or range, or by line position or range. Fragment + identifiers may also contain information for integrity checks to make + them more robust. + + + + + + + + + + + + + + + + + + + + + + + + + + +Wilde & Duerst Standards Track [Page 1] + +RFC 5147 text/plain Fragment Identifiers April 2008 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. What Is text/plain? . . . . . . . . . . . . . . . . . . . 3 + 1.2. What Is a URI Fragment Identifier? . . . . . . . . . . . . 4 + 1.3. Why text/plain Fragment Identifiers? . . . . . . . . . . . 4 + 1.4. Incremental Deployment . . . . . . . . . . . . . . . . . . 5 + 1.5. Notation Used in This Memo . . . . . . . . . . . . . . . . 5 + 2. Fragment Identification Methods . . . . . . . . . . . . . . . 5 + 2.1. Fragment Identification Principles . . . . . . . . . . . . 6 + 2.1.1. Positions and Ranges . . . . . . . . . . . . . . . . . 6 + 2.1.2. Characters and Lines . . . . . . . . . . . . . . . . . 7 + 2.2. Combining the Principles . . . . . . . . . . . . . . . . . 7 + 2.2.1. Character Position . . . . . . . . . . . . . . . . . . 7 + 2.2.2. Character Range . . . . . . . . . . . . . . . . . . . 8 + 2.2.3. Line Position . . . . . . . . . . . . . . . . . . . . 8 + 2.2.4. Line Range . . . . . . . . . . . . . . . . . . . . . . 8 + 2.3. Fragment Identifier Robustness . . . . . . . . . . . . . . 8 + 3. Fragment Identification Syntax . . . . . . . . . . . . . . . . 9 + 3.1. Integrity Checks . . . . . . . . . . . . . . . . . . . . . 9 + 4. Fragment Identifier Processing . . . . . . . . . . . . . . . . 10 + 4.1. Handling of Line Endings in text/plain MIME Entities . . . 10 + 4.2. Handling of Position Values . . . . . . . . . . . . . . . 11 + 4.3. Handling of Integrity Checks . . . . . . . . . . . . . . . 11 + 4.4. Syntax Errors in Fragment Identifiers . . . . . . . . . . 12 + 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 + Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16 + + + + + + + + + + + + + + + + + + + +Wilde & Duerst Standards Track [Page 2] + +RFC 5147 text/plain Fragment Identifiers April 2008 + + +1. Introduction + + This memo updates the text/plain media type defined in RFC 2046 [3] + by defining URI fragment identifiers for text/plain MIME entities. + This makes it possible to refer to parts of a text/plain MIME entity. + Such parts can be identified by either character position or range, + or by line position or range. Integrity checking information can be + added to a fragment identifier to make it more robust, enabling + applications to detect changes of the entity. + + This section gives an introduction to the general concepts of text/ + plain MIME entities and URI fragment identifiers, and it discusses + the need for fragment identifiers for text/plain and deployment + issues. Section 2 discusses the principles and methods on which this + memo is based. Section 3 defines the syntax, and Section 4 discusses + processing of text/plain fragment identifiers. Section 5 shows some + examples. + +1.1. What Is text/plain? + + Internet Media Types (often referred to as "MIME 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 3676 [6] 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, 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 [13] is assumed as the + default character encoding. This variability of the character + encoding makes it impossible to count characters in a text/plain MIME + entity 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 MIME entities is their ease of + use and their portability among different platforms. As long as they + use popular character encodings (such as US-ASCII or UTF-8 [12]), + they can be displayed and processed on virtually every computer + system. The only remaining interoperability issue is the + representation of line endings, which is discussed in Section 4.1. + + + + + + +Wilde & Duerst Standards Track [Page 3] + +RFC 5147 text/plain Fragment Identifiers April 2008 + + +1.2. What Is a URI Fragment Identifier? + + URIs are the identification mechanism for resources on the Web. The + URI syntax specified in RFC 3986 [7] optionally includes a so-called + "fragment identifier", separated by a number sign ('#'). The + fragment identifier consists of additional reference information to + be interpreted by the user agent after the retrieval action has been + successfully completed. The semantics of a fragment identifier are 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 [10]) and makes it possible to refer to a + specific element (identified by the value of a 'name' or 'id' + attribute) of an HTML document. This makes it possible to reference + a specific part of a Web page, rather than a Web page as a whole. + +1.3. Why text/plain Fragment Identifiers? + + Referring to specific parts of a resource can be very useful because + it enables users and applications to create more specific references. + Users can create references to the part they really are interested in + or want to talk about, rather than always pointing to a complete + resource. Even though it is suggested that fragment identification + methods are specified in a media type's MIME registration (see [15]), + 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 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, as defined in this memo, make it + possible to refer to specific parts of a text/plain MIME entity, + using concepts of positions and ranges, which may be applied to + characters and lines. Thus, text/plain fragment identifiers enable + users to exchange information more specifically, thereby reducing the + time and effort that is necessary to manually search for the relevant + part of a text/plain MIME entity. + + + + + +Wilde & Duerst Standards Track [Page 4] + +RFC 5147 text/plain Fragment Identifiers April 2008 + + + The text/plain format does not support the embedding of links, so in + most environments, text/plain resources can only serve as targets for + links, and not as sources. However, when combining the text/plain + fragment identifiers specified in this memo with out-of-line linking + mechanisms such as XLink [14], it becomes possible to "bind" link + resources to text/plain resources and thereby "embed" links into + text/plain resources. Thus, the text/plain fragment identifiers + specified in this memo open a path for text/plain files to become + bidirectionally navigable resources in hypermedia systems such as the + Web. + +1.4. Incremental Deployment + + As long as text/plain fragment identifiers are not supported + universally, 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 MIME entities, 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 will fail to interpret the fragment + identifier part. Since fragment identifier evaluation is local to + the client (and happens after retrieving the MIME entity), there is + no reliable way for a server to determine whether a requesting client + is using a URI containing a fragment identifier. + +1.5. Notation Used in This Memo + + 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 [4]. + +2. Fragment Identification Methods + + The identification of fragments of text/plain MIME entities can be + based on different foundations. Since it is not possible to insert + explicit, invisible identifiers into a text/plain MIME entity (for + example, as used in HTML documents, implemented through dedicated + attributes), fragment identification has to rely on certain inherent + properties of the MIME entity. This memo specifies fragment + identification using four different methods, which are character + positions and ranges, and line positions and ranges, augmented by an + integrity check mechanism for improving the robustness of fragment + identifiers. + + + + + +Wilde & Duerst Standards Track [Page 5] + +RFC 5147 text/plain Fragment Identifiers April 2008 + + + When interpreting character or line numbers, implementations MUST + take the character encoding of the MIME entity into account, because + character count and octet count may differ for the character encoding + being used. For example, a MIME entity using the UTF-16 encoding (as + specified in RFC 2781 [11]) uses two octets per character in most + cases, and sometimes four octets per character. It can also 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. + +2.1. Fragment Identification Principles + + Fragment identification can be done by combining two orthogonal + principles, which are positions and ranges, and characters and lines. + This section describes the principles themselves, while Section 2.2 + describes the combination of the principles. + +2.1.1. Positions and Ranges + + A position does not identify an actual fragment of the MIME entity, + but a position inside the MIME entity, which can be regarded as a + fragment of length zero. The use case for positions is to provide + pointers for applications that 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 MIME entity. Thus, a text/plain MIME entity having one + character has two positions, one before the first character (position + zero), 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 + obvious way being the positioning of a cursor (if the application + supports the concept of a cursor). + + Ranges, on the other hand, identify fragments of a MIME entity that + have a length that may be greater than zero. As a general principle + for ranges, they specify both a lower and an upper bound. The start + or the end of a range specification may be omitted, defaulting to the + first or last position of the MIME entity, respectively. The end of + a range must have a value greater than or equal to the start. A + range with identical start and end is legal and identifies a range of + length zero, which is equivalent to a position. + + Applications that support a concept such as highlighting SHOULD use + such a concept to indicate fragments of lengths greater than zero to + the user. + + + + +Wilde & Duerst Standards Track [Page 6] + +RFC 5147 text/plain Fragment Identifiers April 2008 + + + For positions and ranges, it is implicitly assumed that if a number + is greater than the actual number of elements in the MIME entity, + then it is referring to the last element of the MIME entity (see + Section 4 for details). + +2.1.2. Characters and Lines + + The concept of positions and ranges can be applied to characters or + lines. In both cases, positions indicate points between these + entities, while ranges identify zero or more of these 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 MIME entity), and counting each character + separately, with the exception of line endings, which are always + counted as one character (see Section 4.1 for details). + + Line positions are numbered starting with zero (with line position + zero always being identical with character position zero); + Section 4.1 describes how line endings are 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 (e.g., the highlighted + selection). If a MIME entity does not contain any line endings, then + it consists of a single (the first) line. + +2.2. Combining the Principles + + In the following sections, the principles described in the preceding + section (positions/ranges and characters/lines) are combined, + resulting in four use cases. The schemes mentioned below refer to + the fragment identifier syntax, described in detail in Section 3. + +2.2.1. Character Position + + To identify a character position (i.e., a fragment of length zero + between two characters), the 'char' scheme followed by a single + number is used. This method identifies a position between two + characters (or before the first or after the last character), rather + than identifying a fragment consisting of a number of characters. + Character position counting starts with zero, so the character + position before the first character of a text/plain MIME entity has + the character position zero, and a MIME entity containing n distinct + characters has n+1 distinct character positions, the last one having + the character position n. + + + + + +Wilde & Duerst Standards Track [Page 7] + +RFC 5147 text/plain Fragment Identifiers April 2008 + + +2.2.2. Character Range + + To identify a fragment of one or more characters (a character range), + the 'char' scheme followed by a range specification is used. A + character range is a consecutive region of the MIME entity that + extends from the starting character position of the range to the + ending character position of the range. + +2.2.3. Line Position + + To identify a line position (i.e., a fragment of length zero between + two lines), the 'line' scheme followed by a single number is used. + This method identifies a position between two lines (or before the + first or after the last line), rather than identifying a fragment + consisting of a number of lines. Line position counting starts with + zero, so the line position before the first line of a text/plain MIME + entity has the line position zero, and a MIME entity containing n + distinct lines has n+1 distinct line positions, the last one having + the line position n. + +2.2.4. Line Range + + To identify a fragment of one or more lines (a line range), the + 'line' scheme followed by a range specification is used. A line + range is a consecutive region of the MIME entity that extends from + the starting line position of the range to the ending line position + of the range. + +2.3. Fragment Identifier Robustness + + It is easily possible that a modification of the referenced resource + will break a fragment identifier. If applications want to create + more robust fragment identifiers, they may do so by adding integrity- + check information to fragment identifiers. Such information is used + to detect changes in the resource. Applications can then warn users + about the possibility that a fragment identifier might have been + broken by a modification of the resource. + + Fragment identifiers are interpreted by clients, and therefore + integrity-check information is defined on MIME entities rather than + on the resource itself. This means that the integrity-check + information is specific to a certain entity. Specifically, content + encodings and/or content transfer encodings must be removed before + using integrity-check information. + + Integrity-check information may specify the character encoding that + has been used when creating the information, and if such a + specification is present, clients MUST check whether the character + + + +Wilde & Duerst Standards Track [Page 8] + +RFC 5147 text/plain Fragment Identifiers April 2008 + + + encoding specified and the character encoding of the retrieved MIME + entity are equal, and clients MUST NOT use the integrity check + information if these values differ. However, clients MAY choose to + transcode the retrieved MIME entity in the case of differing + character encodings, and after doing so, apply integrity checks. + Please note that this method is inherently unreliable because certain + characters or character sequences may have been lost or normalized + due to restrictions in one of the character encodings used. + +3. Fragment Identification Syntax + + The syntax for the text/plain fragment identifiers is + straightforward. The syntax defines four schemes, 'char', 'line', + and integrity check (which can either be 'length' or 'md5'). The + 'char' and 'line' schemes can be used in two different variants, + either the position variant (with a single number), or the range + variant (with two comma-separated numbers). An integrity check can + either use the 'length' or the 'md5' scheme to specify a value. + 'length' in this case serves as a very weak but easy to calculate + integrity check. + + The following syntax definition uses ABNF as defined in RFC 5234 [9], + including the rules DIGIT and HEXDIG. The mime-charset rule is + defined in RFC 2978 [5]. + + NOTE: In the descriptions that follow, specified text values MUST be + used exactly as given, using exactly the indicated lower-case + letters. In this respect, the ABNF usage differs from [9]. + + + text-fragment = text-scheme 0*( ";" integrity-check ) + text-scheme = ( char-scheme / line-scheme ) + char-scheme = "char=" ( position / range ) + line-scheme = "line=" ( position / range ) + integrity-check = ( length-scheme / md5-scheme ) + [ "," mime-charset ] + position = number + range = ( position "," [ position ] ) / ( "," position ) + number = 1*( DIGIT ) + length-scheme = "length=" number + md5-scheme = "md5=" md5-value + md5-value = 32HEXDIG + +3.1. Integrity Checks + + An integrity check can either specify a MIME entity's length, or its + MD5 fingerprint. In both cases, it can optionally specify the + character encoding that has been used when calculating the integrity + + + +Wilde & Duerst Standards Track [Page 9] + +RFC 5147 text/plain Fragment Identifiers April 2008 + + + check, so that clients interpreting the fragment identifier may check + whether they are using the same character encoding for their + calculations. For lengths, the character encoding can be necessary + because it can influence the character count. As an example, Unicode + includes precomposed characters for writing Vietnamese, but in the + windows-1258 encoding, also used for writing Vietnamese, some + characters have to be encoded with separate diacritics, which means + that two characters will be counted. Applying Unicode terminology, + this means that the length of a text/plain MIME entity is computed + based on its "code points". For MD5 fingerprints, the character + encoding is necessary because the MD5 algorithm works on the binary + representation of the text/plain resource. + + To allow future changes to this specification to address developments + in cryptography, implementations MUST ignore new types of integrity + checks, with names other than 'length' and 'md5'. If several + integrity checks are present, an application can use whatever + integrity checks it understands, and among these, those integrity + checks that provide an appropriate trade-off between performance and + the need for integrity checking. Please see Section 4.3 for further + details. + + The length of a text/plain MIME entity is calculated by using the + principles defined in Section 2.1.2. The MD5 fingerprint of a text/ + plain MIME entity is calculated by using the algorithm presented in + [1], encoding the result in 32 hexadecimal digits (using uppercase or + lowercase letters) as a representation of the 128 bits that are the + result of the MD5 algorithm. Calculation of integrity checks is done + after stripping any potential content-encodings or content-transfer- + encodings of the transport mechanism. + +4. Fragment Identifier Processing + + Applications implementing support for the mechanism described in this + memo MUST behave as described in the following sections. + +4.1. Handling of Line Endings in text/plain MIME Entities + + In Internet messages, line endings in text/plain MIME entities are + represented by CR+LF character sequences (see RFC 2046 [3] and RFC + 3676 [6]). However, some protocols (such as HTTP) additionally allow + other conventions for line endings. Also, some operating systems + store text/plain entities locally with different line endings (in + most cases, Unix uses LF, MacOS traditionally uses CR, and Windows + uses CR+LF). + + Independent of the number of bytes or characters used to represent a + line ending, each line ending MUST be counted as one single + + + +Wilde & Duerst Standards Track [Page 10] + +RFC 5147 text/plain Fragment Identifiers April 2008 + + + character. Implementations interpreting text/plain fragment + identifiers MUST take into account the line ending conventions of the + protocols and other contexts that they work in. + + As an example, an implementation working in the context of a Web + browser supporting http: URIs has to support the various line ending + conventions permitted by HTTP. As another example, an implementation + used on local files (e.g., with the file: URI scheme) has to support + the conventions used for local storage. All implementations SHOULD + support the Internet-wide CR+LF line ending convention, and MAY + support additional conventions not related to the protocols or + systems they work with. + + Implementers should be aware of the fact that line endings in plain + text entities can be represented by other characters or character + sequences than CR+LF. Besides the abovementioned CR and LF, there + are also NEL and CR+NEL. In general, the encoding of line endings + can also depend on the character encoding of the MIME entity, and + implementations have to take this into account where necessary. + +4.2. Handling of Position Values + + If any position value (as a position or as part of a range) is + greater than the length of the actual MIME entity, then it identifies + the last character position or line position of the MIME entity. If + the first position value in a range is not present, then the range + extends from the start of the MIME entity. If the second position + value in a range is not present, then the range extends to the end of + the MIME entity. If a range scheme's positions are not properly + ordered (i.e., the first number is less than the second), then the + fragment identifier MUST be ignored. + +4.3. Handling of Integrity Checks + + Clients are not required to implement the handling of integrity + checks, so they MAY choose to ignore integrity check information + altogether. However, if they do implement integrity checking, the + following applies: + + If a fragment identifier contains one or more integrity checks, and a + client retrieves a MIME entity and, using some integrity check(s), + detects that the entity has changed (observing the character encoding + specification as described in Section 3.1, if present), then the + client SHOULD NOT interpret the text/plain fragment identifier. A + client MAY signal this situation to the user. + + + + + + +Wilde & Duerst Standards Track [Page 11] + +RFC 5147 text/plain Fragment Identifiers April 2008 + + +4.4. Syntax Errors in Fragment Identifiers + + If a fragment identifier contains a syntax error (i.e., does not + conform to the syntax specified in Section 3), then it MUST be + ignored by clients. Clients MUST NOT make any attempt to correct or + guess fragment identifiers. Syntax errors MAY be reported by + clients. + +5. Examples + + The following examples show some usages for the fragment identifiers + defined in this memo. + + http://example.com/text.txt#char=100 + + This URI identifies the position after the 100th character of the + text.txt MIME entity. It should be noted that it is not clear which + octet(s) of the MIME entity this will be without retrieving the MIME + entity and thus knowing which character encoding it is using (in case + of HTTP, this information will be given in the Content-Type header of + the response). If the MIME entity has fewer than 100 characters, the + URI identifies the position after the MIME entity's last character. + + http://example.com/text.txt#line=10,20 + + This URI identifies lines 11 to 20 of the text.txt MIME entity. If + the MIME entity has fewer than 11 lines, it identifies the position + after the last line. If the MIME entity has less than 20 but at + least 11 lines, it identifies the range from line 11 to the last line + of the MIME entity. + + https://example.com/text.txt#line=,1 + + This URI identifies the first line. Please note that the URI scheme + has been changed to https. + + ftp://example.com/text.txt#line=10,20;length=9876,UTF-8 + + As in the second example, this URI identifies lines 11 to 20 of the + text.txt MIME entity. The additional length integrity check + specifies that the MIME entity has a length of 9876 characters when + encoded in UTF-8. If the client supports the length scheme, it may + test the retrieved MIME entity for its length, but only if the + retrieved MIME entity uses the UTF-8 encoding or has been locally + transcoded into this encoding. + + + + + + +Wilde & Duerst Standards Track [Page 12] + +RFC 5147 text/plain Fragment Identifiers April 2008 + + + Please note that the FTP protocol, as well as some other protocols + underlying some other URI schemes, do not provide explicit + information about the media type of the resource being retrieved. + Using fragment identifiers with such URI schemes is therefore + inherently unreliable. Current user agents use various heuristics to + infer some media type for further processing. Processing of the + fragment identifier according to this memo is only appropriate if the + inferred media type is text/plain. + +6. IANA Considerations + + IANA has added a reference to this specification in the text/plain + Media Type registration. + +7. Security Considerations + + The fact that software implementing fragment identifiers for plain + text and software not implementing them differs in behavior, and the + fact that different software may show documents or fragments to users + in different ways, can lead to misunderstandings on the part of + users. Such misunderstandings might be exploited in a way similar to + spoofing or phishing. + + In particular, care has to be taken if fragment identifiers are used + together with a mechanism that allows showing only the part of a + document identified by a fragment. One scenario may be the use of a + fragment identifier to hide small-print legal text. Another scenario + may be the inclusion of site-key-like material, which may give the + user the impression of using the real site rather than a fake site; + other scenarios may also be possible. Possible countermeasures may + include but are not limited to displaying the included content within + clearly visible boundaries and limiting inclusion to material from + the same security realm or from realms that give explicit permission + to be included in another realm. + + Please note that the above issues all apply to the client side; + fragment identifiers are not used when resolving a URI to retrieve + the representation of a resource, but are only applied on the client + side. + + Implementers and users of fragment identifiers for plain text should + also be aware of the security considerations in RFC 3986 [7] and RFC + 3987 [8]. + + + + + + + + +Wilde & Duerst Standards Track [Page 13] + +RFC 5147 text/plain Fragment Identifiers April 2008 + + +8. References + +8.1. Normative References + + [1] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, + April 1992. + + [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] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [5] Freed, N. and J. Postel, "IANA Charset Registration + Procedures", BCP 19, RFC 2978, October 2000. + + [6] Gellens, R., "The Text/Plain Format and DelSp Parameters", + RFC 3676, February 2004. + + [7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, + January 2005. + + [8] Duerst, M. and M. Suignard, "Internationalized Resource + Identifiers (IRI)", RFC 3987, January 2005. + + [9] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, January 2008. + +8.2. Informative References + + [10] Connolly, D. and L. Masinter, "The 'text/html' Media Type", + RFC 2854, June 2000. + + [11] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", + RFC 2781, February 2000. + + [12] Yergeau, F., "UTF-8, a transformation format of ISO 10646", + STD 63, RFC 3629, November 2003. + + [13] ANSI X3.4-1986, "Coded Character Set - 7-Bit American National + Standard Code for Information Interchange", 1986. + + + + +Wilde & Duerst Standards Track [Page 14] + +RFC 5147 text/plain Fragment Identifiers April 2008 + + + [14] DeRose, S., Maler, E., and D. Orchard, "XML Linking Language + (XLink) Version 1.0", World Wide Web Consortium Recommendation, + June 2001, <http://www.w3.org/TR/xlink/>. + + [15] Freed, N. and J. Klensin, "Media Type Specifications and + Registration Procedures", BCP 13, RFC 4288, December 2005. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Wilde & Duerst Standards Track [Page 15] + +RFC 5147 text/plain Fragment Identifiers April 2008 + + +Appendix A. Acknowledgements + + Thanks for comments and suggestions provided by Marcel Baschnagel, + Stephane Bortzmeyer, Tim Bray, Iain Calder, John Cowan, Spencer + Dawkins, Lisa Dusseault, Benja Fallenstein, Ted Hardie, Sam Hartman, + Sandro Hawke, Jeffrey Hutzelman, Cullen Jennings, Graham Klyne, Dan + Kohn, Henrik Levkowetz, Chris Newman, Mark Nottingham, Conrad Parker, + and Tim Polk. + +Authors' Addresses + + Erik Wilde + UC Berkeley + School of Information, 311 South Hall + Berkeley, CA 94720-4600 + U.S.A. + + Phone: +1-510-6432253 + EMail: dret@berkeley.edu + URI: http://dret.net/netdret/ + + + Martin Duerst (Note: Please write "Duerst" with u-umlaut wherever + possible, for example as "Dürst" in XML and HTML.) + Aoyama Gakuin University + 5-10-1 Fuchinobe + Sagamihara, Kanagawa 229-8558 + Japan + + Phone: +81 42 759 6329 + Fax: +81 42 759 6495 + EMail: duerst@it.aoyama.ac.jp + URI: http://www.sw.it.aoyama.ac.jp/D%C3%BCrst/ + + + + + + + + + + + + + + + + + + +Wilde & Duerst Standards Track [Page 16] + +RFC 5147 text/plain Fragment Identifiers April 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights 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; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +Wilde & Duerst Standards Track [Page 17] + |