[rfc-i] Following up from Atlanta
Heather Flanagan (RFC Series Editor)
rse at rfc-editor.org
Tue Dec 4 15:21:48 PST 2012
On 12/4/12 2:23 PM, Nico Williams wrote:
> On Tue, Dec 4, 2012 at 4:02 PM, Ted Lemon <mellon at fugue.com> wrote:
>> The real question is whether we want the canonical representation to be a particular presentation (of which lpr-style plain text and book-style proportional typeset text are two examples), or whether we want it to be a machine-translatable representation that can be presented in both of those ways, as well as other ways (e.g., hypertext).
>> If the answer is that we prefer a machine readable representation, then the question of which presentation to use falls away, and we can get into the much livelier and more religious discussion of whether nroff or xml2rpc should be the canonical representation. As you have no doubt gathered, I prefer that the canonical representation be explicitly machine-readable, and that there be a few canonical presentation forms that are made available as well, one of which would be the old standby.
> I've *been* saying that I don't care so much what the canonical
> representation is as that there be a text representation for us
> tty-lovers. I'd rather that the text representation be natively
> supported rather than being generated by applying a text-based browser
> to an HTML rendering.
Third requirement in section 3.1 of draft-rfc-format-flanagan-02 states:
* While several Publication formats must be allowed, the
Publication formats must include support for plain-text
Does this meet the need of tty-lovers?
> We currently have a tool that supports text rendering: xml2rfc. If
> we're talking about making such radical changes to the I-D/RFC source
> format(s) and/or renderings that xml2rfc is rendered obsolete, then it
> begins to make sense to say "hey, use elinks for now for text
> rendering until we get around to fully supporting that". But it's not
> clear [to me] that we're talking about abandoning xml2rfc.
> PS: I'm not terribly fond of browsers for many reasons, and, playing
> with elinks just now, some of those reasons apply to text-based
> browsers too:
> - reverse video, or lack thereof (lynx/elinks work fine, of course)
> - lack of regular expression for searches (you can get plugins for
> this, but the text-based ones don't seem to support this)
> - lack of keyboard navigation the Unix way (more, less, vi keybindings, ...)
> - having to use a mouse sucks; I want to minimize my usage of mice
> (again, not applicable to text-based browsers)
> When I want to follow links to non-RFCs I pop into a browser. To
> follow links to RFCs I have shell functions/scripts to manage a cache
> of them that I then read from.
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
More information about the rfc-interest