Re: [rfc-i] No, constraining to a custom SVG profile is not trivial

Phillip Hallam-Baker <phill@hallambaker.com> Mon, 20 January 2020 19:32 UTC

Return-Path: <rfc-interest-bounces@rfc-editor.org>
X-Original-To: ietfarch-rfc-interest-archive@ietfa.amsl.com
Delivered-To: ietfarch-rfc-interest-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D58B5120639 for <ietfarch-rfc-interest-archive@ietfa.amsl.com>; Mon, 20 Jan 2020 11:32:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.951
X-Spam-Level:
X-Spam-Status: No, score=-4.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2SWQVYrnOYE3 for <ietfarch-rfc-interest-archive@ietfa.amsl.com>; Mon, 20 Jan 2020 11:32:57 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4034F12029C for <rfc-interest-archive-eekabaiReiB1@ietf.org>; Mon, 20 Jan 2020 11:32:57 -0800 (PST)
Received: from rfcpa.amsl.com (localhost [IPv6:::1]) by rfc-editor.org (Postfix) with ESMTP id 6A522F406F3; Mon, 20 Jan 2020 11:32:49 -0800 (PST)
X-Original-To: rfc-interest@rfc-editor.org
Delivered-To: rfc-interest@rfc-editor.org
Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id BCC70F406F0 for <rfc-interest@rfc-editor.org>; Mon, 20 Jan 2020 11:32:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at rfc-editor.org
Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qRZ_k8Xu8AW for <rfc-interest@rfc-editor.org>; Mon, 20 Jan 2020 11:32:46 -0800 (PST)
Received: from mail-ot1-f45.google.com (mail-ot1-f45.google.com [209.85.210.45]) by rfc-editor.org (Postfix) with ESMTPS id 88481F406F3 for <rfc-interest@rfc-editor.org>; Mon, 20 Jan 2020 11:32:46 -0800 (PST)
Received: by mail-ot1-f45.google.com with SMTP id i15so811112oto.2 for <rfc-interest@rfc-editor.org>; Mon, 20 Jan 2020 11:32:54 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xjMlnBNNdLpcTduavVocSsz/kGD13n6hBCwp6IS456k=; b=C1PMlZ450+3Ffvl3hiD/AHXj+vM4y1r5jWyKyWcYMH1t6hdoNtvw+otRFAEbmRI8Tp /bdSt8PZW4n6PjNXQEr2/BB7EW+1aGL/2tag3X387rNxegcOpegZdoQGxzMhZR5HR8Qv f4Fvv9Kd9T3FB5NpQs8U5bsoU/7MEABst+u34rcvd0hoSwkzhHckXHCWorssRXBqoV4R eTmjAkJ4ZA5LZHI6wmVoTB31R1OJR1X9TKmoMT4Fpe3jz4wcI7XRVpyRqMLGBfysx2Nj QnsyfXlkWRMT3v2lIav9tRZLGjll13oi6E71w/308EqJofVLhBWncHWxkC3/LgHW1b7Q gEYA==
X-Gm-Message-State: APjAAAU733LeHE6gFNZBnTXgraCZLy9SFi6vZEyNye9VcPcA6suE3cHR q+nCbLqUKWMds6eKG0oWTgRAw1UVWJoi+TzqjrI=
X-Google-Smtp-Source: APXvYqxyDko79i4thmnKihYtDIDmqACMg6jm/3CrGJKhVk6tTJTvtI1ztzPsqVPBT7fkQB9xpqTMOySXvGly40ZXOKE=
X-Received: by 2002:a05:6830:1481:: with SMTP id s1mr826272otq.66.1579548773304; Mon, 20 Jan 2020 11:32:53 -0800 (PST)
MIME-Version: 1.0
References: <CAMm+LwiXhhJO7qYi41+DC4W7uMUVipXqyq75Fq2vagA1ppJNdA@mail.gmail.com> <10cca93f-a8b8-4c42-0653-3b12fa67ad12@gmail.com> <CAMm+LwgA-1UffBfrH-Y3J6pfh7ni9kNrndp=gHNyUyi5j=oLxg@mail.gmail.com> <53607da4-6608-783b-b875-65551e3add19@gmail.com>
In-Reply-To: <53607da4-6608-783b-b875-65551e3add19@gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Mon, 20 Jan 2020 14:32:20 -0500
Message-ID: <CAMm+LwgNU2Dr3bB+A8k+UwbQiRRzgUkoRRh60tc6+bBv6CXwfQ@mail.gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: Re: [rfc-i] No, constraining to a custom SVG profile is not trivial
X-BeenThere: rfc-interest@rfc-editor.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the RFC series and RFC Editor functions." <rfc-interest.rfc-editor.org>
List-Unsubscribe: <https://www.rfc-editor.org/mailman/options/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <http://www.rfc-editor.org/pipermail/rfc-interest/>
List-Post: <mailto:rfc-interest@rfc-editor.org>
List-Help: <mailto:rfc-interest-request@rfc-editor.org?subject=help>
List-Subscribe: <https://www.rfc-editor.org/mailman/listinfo/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=subscribe>
Cc: RFC Interest <rfc-interest@rfc-editor.org>
Content-Type: multipart/mixed; boundary="===============4642902580950025490=="
Errors-To: rfc-interest-bounces@rfc-editor.org
Sender: rfc-interest <rfc-interest-bounces@rfc-editor.org>

It is not just the greyscale that is the issue. There are numerous issues
in the diagrams that result from the chosen profile.

Compare the diagrams in:
https://tools.ietf.org/id/draft-hallambaker-mesh-architecture-12.html

With the originals in:
https://mathmesh.com/Documents/draft-hallambaker-mesh-architecture.html

Getting the diagrams to present properly is at least two weeks work for me
on top of the weeks already spent. And I am probably not going to be the
last person making this set of complaints. I am just the first person who
developed specs that depend on having good diagrams in them.

On Wed, Jan 15, 2020 at 10:21 PM Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> > Attached is a simple XSLT script that I created that simply rips out
> invalid elements.
>
> The problem with colour/greyscale is that this isn't enough. If you have
> very dark blue text on a very pale pink background, what happens? svgcheck
> makes this black on black; my heuristic makes it black on white. What would
> your script do?
>
> But I do agree with Phill, this is a non-trivial issue. Currently I think
> doing new drawings with a simple tool like DIA is the only practical way.
>

It is my opinion that a standards organization should stick to existing
standards rather than inventing its own. Deviation from W3C standards
should only happen with an incredibly good reason. I do not see one.

Telling people to use one particular tool looks like bullying behavior to
me. Forcing people top jump through hoops to produce the old plaintext
format was bullying which was one of the reasons I was so opposed to it.

SVG is ubiquitously supported in current generation browsers. There are
tens, probably hundreds of thousands of person years worth of effort
invested in creating SVG content using today's tools. There is a published
spec that is widely distributed and at least as certain to survive whatever
apocalypses might occur as RFCs.

RFCs are merely tools for making the Internet change. We are not writing
holy scripture here. All RFCs that have the slightest importance are going
to have errors. The question is not how to eliminate the errors but to
minimize them.

Moving to HTML greatly reduces the number of errors in interpretation.


Allowing unrestricted SVG has plenty of issues too.
>

Nobody ever gives a specific issue. That is not how a standards
organization should behave. If there is a need to vary any standard, either
our own or someone else's there should be a clearly articulated reason
given.

Please state specific issues.
_______________________________________________
rfc-interest mailing list
rfc-interest@rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-interest