[rfc-i] Fwd: New Version Notification for draft-flanagan-plaintext-00.txt
ietf at thomasclausen.org
Tue Jun 24 06:10:15 PDT 2014
Well yes, it is easy (well, relatively) to come up with an alternative format that satisfies my workflow — or an alternative format that satisfies yours, for that matter. That’s not the point, however.
The point of a specification is interoperability. In this case, the RFC format should be what ensures that you and I can interoperate on “a spec”.
If for me to review (or implement) your spec, I’d have to know and/or adopt your workflow, formats and tools that go with it, then I foresee deep trouble.
As Chris say in another post, not all of us can chose our tools all the time.
I keep going back to this: how can I *precisely* point to what I want?
If in my “alternative format" I spot a bug in “line 17 on page 33”, how do I convey that to you?
Apparently, someone has decided to do away with both page numbers and fixed line lengths……so what, do I count characters (we still have characters, right?) from the beginning of the document?
Do I hope that you have put a section anchor in that’s useful?
Do I need to convince you to either use my “alternative format” (burden on you, who should spend time fixing your protocol - and see the previous comment about “not all of us free to choose our tools all the time") or do I need to use your “alternative format” (burden on me, who kindly reviews your doc - and see “choose our tools all the time” comment, again).
I think that the goals are noble, but I fear that we’re throwing out something that works for some pie-in-the-sky.
On Jun 24, 2014, at 14:54, Paul Kyzivat <pkyzivat at alum.mit.edu> wrote:
> As an alternative to page numbers, some doc formats use line or paragraph numbers, that are positioned in margin. A TOC could reference these. Of course this would be yet another format.
> On 6/24/14 7:41 AM, Thomas Clausen wrote:
>> On Jun 24, 2014, at 13:23, Julian Reschke <julian.reschke at gmx.de> wrote:
>>> On 2014-06-24 13:04, Dearlove, Christopher (UK) wrote:
>>>> This does appear to convert plain text from normative to close to useless. At least as the only text version. An unpaginated text version may have uses as a supplementary form rather than a replacement.
>>>> Is there going to be a numbered page version with a table of contents with page numbers that I can pick up and print? (PDF?) If so, why not text like that as well?
>>> It is possible to get proper printouts from HTML with page numbers (in the TOC and in the index), but not from a desktop browser right now (due to missing CSS paged media support). There will likely be a PDF version as well.
>>> But keep in mind that the page numbers will depend on output formats, so there won't be any unambigious "page 5 of rfc xxxx" anymore. Yes, that's intentional.
>>>> The current RFC Editor process does pagination as a special extra step at the end. It feels like rather than work out how to do that better, it's being thrown out for convenience of the process rather than the users.
>>> It's thrown out because it's in conflict with other goals, namely proper support for other output devices than paper.
>> That does, if you will excuse my violent disagreement, appear like an enormous step backwards in usability: both when writing a specification, when writing an implementation from a specification (especially if actually commenting code), or when reviewing a specification for somebody else, the ability to reference “Page XX line Y” is rather convenient, almost necessary — especially, when collaborating with folks using different output media (of which paper remains an important one, for various reasons….)
>> I haven’t printed an RFC or an I-D in a decade - and yet, find both page numbers and line numbers to be paramount.
>> With my various set of co-authors, while I do *try* to point to “enumerated sections”, we almost always end up “counting lines on a page” at some point in time. I note that other SDOs actually have printed line-numbers in the margin of (at least, their working/intermediate) documents.
>> While I have deep respect for the “other goals” that you cite, and I agree that we should support different output devices, I respectfully submit that that has nothing to do with the argument being made.
>> I also respectfully submit that those “other goals” perhaps are given too high a priority here, and I wonder who set those priorities?
>>> Best regards, Julian
>>> rfc-interest mailing list
>>> rfc-interest at rfc-editor.org
More information about the rfc-interest