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

[Ballot discuss]
Over email we've discussed whether it's a problem that clients might download or display only a fragment of a text document, with the user unaware of this.  This is new in this kind of fragment specifier as far as I know (HTML fragments specify a position, although in theory they could be used to specify a block there's no way to trigger that)

One possible security consideration here is whether the text/plain line range fragment can be used to abet a phishing attack.  Can an attacker host a phishing page, and imbed in that page, several lines extracted from the real site, holding a sitekey for example?  Of course an attacker can already imbed parts of other pages by proxying, but this might shift the page fetching to the client, which would make the real site think the request was legitimate. 

This precise attack can only work if
- clients might use these text fragments on HTML pages, or servers can be induced to present HTML pages as text/plain
- clients are willing to display only the selected fragment, as opposed to (for example) highlighting it.

Other attacks that don't rely on HTML confusion at all include getting clients to download files without important disclaimers, small print, etc. -- again, a matter of whether the fragment is for download, selective display, or only for focus and selection.

I want to make sure we've concluded the discussion and agree whether these are reasonable security considerations or if they're too far-fetched.

[Ballot comment]
It is unclear to me if anything needs to be said about comparison of URI that contain this fragment.

My understanding of 3986 is that it defined a generic syntax for URI that could be imported into the definitions for specific URI schemes and that all URI types would be subsets of so that an application that did not understand a specific scheme could still parse certain semantics of the URI. However, the detailed specification of the URI of a given scheme would still define what was possible for that scheme. I did not realize that prior to 3986, the fragment was not part of the URI while after 3986 redefined it to be part of the URI and no doubt this is a sign I am confused on some of the history and how the details of how this all works. So please educate me. When I look at ldap 4516, or imap in 2182bis they do not seem to allow a fragment in the URI for theses schemes. I'm not even sure where the ftp URI is defined but in 1738 which looks like it is obsolete, it does not allow a fragment. I am really confused by 2616 which does not seem to allow a fragment in the http URI which, ah, seems either like a bit of a problem or I am very confused about where and how this stuff is all defined. Now, this might all seem irrelevant to this document, but it seems like this is the first document defining a fragment (if there are others, particular for the standard http usage, please point me in the right direction). So given this long ramble, my question is: when implementing ftp or http, what RFCs would tell and implementor that they needed to support fragments in the ftp or http URLs?

So in HTTP, I understand how you fetch the resource, check if it is text/plain and then do the fragment processing if it is. How do you check it was text/plain when using FTP?

[Ballot discuss]
I understand that a fragment specification is only defined for a particular  media types, however, I don't think defining a new fragment updates the definition of the media type it can applies to. The fragment has to do with the semantics of the application that dereferences the URI and does not change any of the semantics of the media type. Because of this, I don't think this should update 2046. I'm happy to be convinced I am wrong here - as I have dug into this URI stuff I realized I don't understand how the fragment stuff is standardized. My basic test here is many implementers of things that used text/plain media types would have no interest whatsoever in the fragment stuff and that is a strong sign that it is an extension of URI and not something to do with 2046.

[Ballot discuss]
I understand that a fragment specification is only defined for a particular  media types, however, I don't think defining a new fragment updates the definition of the media type it can applies to. The fragment has to do with the semantics of the application that dereferences the URI and does not change any of the semantics of the media type. Because of this, I don't think this should update 2046. I'm happy to be convinced I am wrong here - as I have dug into this URI stuff I realized I don't understand how the fragment stuff is standardized. My basic test here is many implementers of things that used text/plain media types would have no interest whatsoever in the fragment stuff and that is a strong sign that it is an extension of URI and not something to do with 2046.

[Ballot comment]
It is unclear to me if anything needs to be said about comparison of URI that contain this fragment.

My understanding of 3986 is that it defined a generic syntax for URI that could be imported into the definitions for specific URI schemes and that all URI types would be subsets of so that an application that did not understand a specific scheme could still parse certain semantics of the URI. However, the detailed specification of the URL of a given scheme would still define what was possible for that scheme. I did not realize that prior to 3986, the fragment was not part of the URI while after 3986 redefined it to be part of the URI and no doubt this is a sign I am confused on some of the history and how the details of how this all works. So please educate me. When I look at ldap 4516, or imap in 2182bis they do not seem to allow a fragment in the URI for theses schemes. I'm not even sure where the ftp URI is defined but in 1738 which looks like it is obsolete, it does not allow a fragment. I am really confused by 2616 which does not seem to allow a fragment in the http URI which, ah, seems either like a bit of a problem or I am very confused about where and how this stuff is all defined. Now, this might all seem irrelevant to this document, but it seems like this is the first document defining a fragment (if there are others, particular for the standard http usage, please point me in the right direction). So given this long ramble, my question is: when implementing ftp or http, what RFCs would tell and implementor that they needed to support fragments in the ftp or http URLs?

So in HTTP, I understand how you fetch the resource, check if it is text/plain and then do the fragment processing if it is. How do you check it was text/plain when using FTP?

[Ballot discuss]
This document supports specification of an integrity check to detect changes in the
referenced resource.  The integrity check comes in two flavors: the length of the
resource in characters, or an MD-5 hash.  I do not have a problem with the mechanisms,
but I do have a problem with the terminology used in the document.

Both integrity checks are referred to as "hash sums".  While the latter mechanism is a
cryptographic hash function, I do not believe the length mechanism should be
characterized in this way.  I reviewed literature that pre-dates cryptographic hash
functions, but the types of mechanisms considered as a hash do not include
the size of the resource.

I would suggest replacing "hash-scheme" with" integrity check" or another phrase
that is more consistent with the range of options specified in the document.

[Ballot discuss]
This document supports specification of an integrity check to detect changes in the
referenced resource.  The integrity check comes in two flavors: the length of the
resource in characters, or an MD-5 hash.  I do not have a problem with the mechanisms,
but I do have a problem with the terminology used in the document.

Both integrity checks are referred to as "hash sums".  While the latter mechanism is a
cryptographic hash function, I do not believe the length mechanism should be
characterized in this way.  I reviewed literature that pre-dates cryptographic hash
functions, but the types of mechanisms considered as a hash do not include
the size of the resource.

I would suggest replacing "hash-scheme" with" integrity check" or another phrase
that is more consistent with the range of options specified in the document.

A decision on the issues raised by Tim is needed; note that the authors don't have to take his suggestion, but text to indicate the issue and the reason for the path chosen may be needed.  The discussion will continue with Chris Newman as sponsoring AD.

IANA Last Call Comments:

Upon approval of this document, the IANA will make the
following changes in "Text Media-Types" registry located at

http://www.iana.org/assignments/media-types/text/

OLD:
Value Description Reference
----- ----------------
plain [RFC2046, RFC3676]

NEW:
Value Description
----- ----------------
plain [RFC2046, RFC3676, RFC-wilde-text-fragment-06]

We understand the above to be the only IANA Action for this
document.

Last Call comment from Tim Bray:

The IESG has received a request from an individual submitter to consider
the following document:

- 'URI Fragment Identifiers for the text/plain Media Type '
    as a Proposed Standard

Editorial point:

Section 2.2.1 says "Character position counting starts with 0, so the
character position
  before the first character of a text/plain MIME entity has the
  character position 0"

but the example in section 5 says "http://example.com/text.txt#char=100

  This URI identifies the position after the 100th character of the
  text.txt MIME entity."

If "character counting starts at 0" I take it that the initial
character is the 0th character, thus char=100 is before not after the
100th, right?  In fact the spec is perfectly correct according to the
normal meaning of "100th" but it took me a minute to get that, and I
suspect a little clean-up in the example description would be useful.

Substantive point:

Each of the addressing schemes is easy to understand, but the ways
they combine are hard to explain and understand, and I'm unconvinced
that being able to identify things like

  This URI identifies the first line and all occurrences of the regular
  expression 'searchterm' in the MIME entity.

are worth the effort.  I'd strongly recommend simplifying the spec by
allowing only one scheme, which might turn out to hit a very desirable
80/20 point.

-Tim