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

Dave Crocker dhc at dcrocker.net
Tue Jun 24 12:29:31 PDT 2014

On 6/24/2014 12:19 PM, Julian Reschke wrote:
> On 2014-06-24 20:59, Dave Crocker wrote:
>>     *  Line length increased to 85 (or is that only for art?)
> The debate is going on :-).

I haven't noticed messages on this publicly.  In any event, the document
should justify each of the changes.

>>     *  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 should have said "effectively deprecated".  The document essentially
makes ascii art of questionable utility.  My suggestion is to give it a
useful place.

>> 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.

We have a maximum line length.  People have been fitting within it for
45 years.  I'm not saying the constraints are serious or real; I'm
saying we've coped with it.  And repeated citation of the hassles
doesn't alter the history of utility.

Of course, that also does not make the hassles irrelevant.  As I noted,
we do have cases in which the limitations were severe enough to limit
the utility of the graphics.  Hence I've tried to suggest a balanced
relationship between ascii art and graphics-based art.

>> 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?

You did not see me say that page numbers should be retained.  Rather,
I'm noted the concern about 'direct' access that was cited elsewhere and
I've suggest it get attention.  I don't have a clever or useful
suggestion of my own, for resolving it.

>> 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.

So there's an agenda of essentially coercing people to use graphics art,
even when ascii art will suffice?

Yes, I'm using biasing language.  But then, the implication of your
explanation is that there is a goal of bias people towards graphics.

We need to be much more clear about the reason for doing graphics art.
If it is for prettiness, then we shouldn't make the switch.  There is no
evidence that what we've done using ASCII art has not been sufficient,
and we /do/ know it always can be displayed.

If we need graphics for clarity, then we don't need to effectively
deprecate ASCII art.  Simply /permit/ graphics art, which requiring the
base of ascii art remain.

Dave Crocker
Brandenburg InternetWorking

More information about the rfc-interest mailing list