[rfc-i] Fwd: New Version Notification for draft-flanagan-plaintext-00.txt

Julian Reschke julian.reschke at gmx.de
Tue Jun 24 12:19:49 PDT 2014


On 2014-06-24 20:59, Dave Crocker wrote:
> ...
> If I've read the draft correctly, the changes are:
>
>     *  Characters set changed from ASCII to UTF-8

Character range extended (there's a separate draft for that as it 
applies to all formats), and encoding scheme set to be UTF-8.

>     *  Line length increased to 85 (or is that only for art?)

The debate is going on :-).

>     *  Page boundaries removed; hence Section numbers only.

Right.

>     *  ASCII art essentially deprecated, in favor of external,
>        graphics-based art.

I think "deprecated" is too strong; it continues to be allowed, but 
there'll be more expressive ways as well.

> I suggest that the abstract should summarize these changes, so there is
> some useful information in the Abstract.
>
> Anyhow...
>
> Character set /has/ had extensive discussion and the change is to use a
> superset of the established usage, with the general view that support
> for UTF-8 has become essentially universal. Hence, this seems a
> lower-risk change, notably permitting continuation of current
> ascii-based practice by any author wishing to stay there.

Right.

> It's just plain(text) odd to specify a linelength for art that is
> different from that for text. In addition it appears to be an arbitrary
> number. Worse, it is likely to cause problems, for any display that has
> text tailored so that a maximum text line consumes the screen (as, for
> example, I do on my 7" tablet, to make things comfortably readable for
> my older eyes.) So artwork will wrap and be unreadable.

On the other hand, there's the problem that ASCII artwork is even harder 
to do when you don't have sufficient horizontal space.

> A separate note commented on the problem created by removal of page
> numbers, in truly text-based environments (where URLs cannot be used to
> create a jump-to mechanism.)  This isn't a small point.  The draft needs
> to attend to it.

It follows from the fact that the canonical format isn't paginated. 
Putting page numbers into one output format would likely cause 
confusion, no?

> One part of the attention probably should go do discussion of section
> numbering and size of sections. Another part needs to attend to
> text-based direct access in the absence of page numbers.
>
> The ASCII-Art vs. graphics art situation is the more challenging, but I
> suggest that it needs direct attention.
>
> Having done the combination for RFC 5598 -- including a figure that is
> complex enough to overwhelm the ascii art but look reasonable (IMO) as a
> graphic, here's specific guidance I suggest:
>
>     1. ASCII Art is required for all drafts that have artwork. In other
> words, the base tool remains.
>
>     2. Graphic art is optional and must be a finer-grained version of the
> ascii art. That is, the information in graphic art must be a superset of
> the information in the ascii art.
>
>     3. Where there are two forms of art, the Ascii art must include a
> citation to the external graphic art and include a statement that the
> ascii art is offered as a 'summary' of the artwork (or similar language.)
>
> Problems with #3 have been posted by others.  But I don't have a
> suggestion for resolving it.

AFAIR, this was discussed, but the feeling was that if an ASCII art 
equivalent is required, almost nobody will be bothered to produce 
something better.

Best regards, Julian



More information about the rfc-interest mailing list