Subject: Re: Last Call: draft-wilde-text-fragment (URI Fragment Identifiers for the text/plain Media Type) to Proposed Standard

From: "Tim Bray" <[email-masked]>
Date: Wed, 14 Feb 2007 22:48:49 -0800

On 2/14/07, The IESG <[email-masked]> wrote:
> The IESG has received a request from an individual submitter to consider
> the following document:
>
> - 'URI Fragment Identifiers for the text/plain Media Type '
>    <draft-wilde-text-fragment-06.txt> 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

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 15 Feb 2007 13:16:57 +0100

On Wed, Feb 14, 2007 at 07:40:16PM -0500,
 The IESG <[email-masked]> wrote 

> <draft-wilde-text-fragment-06.txt> as a Proposed Standard

There are a few problems regarding the ABNF of this draft which have
been sent to the author, acknowledged but apparently not fixed in this
copy. I suggest another version before a last call. (That's apparently
what the author intended, froma private conversation.)