URI Fragment Identifiers for the text/plain Media Type
draft-wilde-text-fragment-09

',
      because the result of dereferencing a URI is not the resource
      itself, but some MIME entity (in our case of type text/plain)
      representing it.  Thanks to Sandro Hawke for pointing this out.

   o  Moved "Open Issues" to the very back of the document.

   o  Added Section 4 to define the processing model for fragment
      identifiers (moved Section 4.2 from Section 3 to Section 4).

   o  Added hash scheme to make fragment identifiers more robust
      (Section 2.3).

   o  Changed IPR clause from RFC 2026 to RFC 3667 (updated version of
      RFC 2026).

8.8.  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 MIME
      entity to the 5th line.

Wilde & Duerst             Expires May 4, 2008                 [Page 17]
Internet-Draft       text/plain Fragment Identifiers       November 2007

   o  Changed the syntax from parenthesis-style to a more traditional
      style using equals-signs.

8.9.  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 1.4 about incremental deployment.

   o  Added more elaborate examples.

   o  Added text about regex buffer overflow problems in Section 7.

   o  Added Section 4.1 about line endings in text/plain resources.

   o  Added "Open Issues" to collect open issues regarding this memo
      (will be deleted in final RFC text).

9.  References

9.1.  Normative References

   [1]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
         Extensions (MIME) Part Two: Media Types", RFC 2046,
         November 1996.

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

   [3]   Gellens, R., "The Text/Plain Format and DelSp Parameters",
         RFC 3676, February 2004.

   [4]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
         Resource Identifier (URI): Generic Syntax", RFC 3986,
         January 2005.

   [5]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", RFC 2119, March 1997.

   [6]   Crocker, D. and P. Overell, "Augmented BNF for Syntax
         Specifications: ABNF", RFC 4234, October 2005.

Wilde & Duerst             Expires May 4, 2008                 [Page 18]
Internet-Draft       text/plain Fragment Identifiers       November 2007

   [7]   Freed, N. and J. Postel, "IANA Charset Registration
         Procedures", BCP 19, October 2000.

   [8]   Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
         April 1992.

   [9]   Duerst, M. and M. Suignard, "Internationalized Resource
         Identifiers (IRI)", RFC 3987, January 2005.

9.2.  Non-Normative References

   [10]  ANSI X3.4-1986, "Coded Character Set - 7-Bit American National
         Standard Code for Information Interchange", STD 63, RFC 3629,
         1992.

   [11]  Yergeau, F., "UTF-8, a transformation format of ISO 10646",
         STD 63, RFC 3629, November 2003.

   [12]  Connolly, D. and L. Masinter, "The 'text/html' Media Type",
         RFC 2854, June 2000.

   [13]  Freed, N. and J. Klensin, "Media Type Specifications and
         Registration Procedures", RFC 4288, December 2005.

   [14]  DeRose, S., Maler, E., and D. Orchard, "XML Linking Language
         (XLink) Version 1.0", W3C Recommendation REC-xlink-20010627,
         June 2001.

   [15]  Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646",
         RFC 2781, February 2000.

Appendix A.  Acknowledgements

   Thanks for comments and suggestions provided by Marcel Baschnagel,
   Stephane Bortzmeyer, Tim Bray, 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.

Wilde & Duerst             Expires May 4, 2008                 [Page 19]
Internet-Draft       text/plain Fragment Identifiers       November 2007

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: mailto:duerst@it.aoyama.ac.jp
   URI:   http://www.sw.it.aoyama.ac.jp/D%C3%BCrst/

Wilde & Duerst             Expires May 4, 2008                 [Page 20]
Internet-Draft       text/plain Fragment Identifiers       November 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Wilde & Duerst             Expires May 4, 2008                 [Page 21]