[rfc-i] artwork, bitmap, SVG...

[rse at rfc-editor.org (Heather Flanagan (RFC Series Editor))]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/11/14 11:07 AM, Julian Reschke wrote:
> On 2014-11-10 19:42, Heather Flanagan (RFC Series Editor) wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>
>> On 11/8/14 5:06 PM, Paul Hoffman wrote:
>>>> The text appears to imply that bitmaps are reasonable artwork.
>>>> I thought that it was going to be restricted to ascii art and
>>>> svg at this time.  (Yes I realize that one can put a bitmap
>>>> into an svg object.)  it might be better to remove some of the
>>>> "such as a bitmap" type text.
>>> Nothing yet has prohibited bitmap graphics on their own. If you
>>> want to do so, please start a thread about saying this in
>>> draft-flanagan-rfc-framework. If the RSE agrees, I'll fix this
>>> document.
>>>
>>
>> The intent is that in the new format world, artwork may be ASCII
>> or SVG.  Support for other formats (e.g., jpg, png) are not on the
>> roadmap for the project at this point.
>>
>> - -Heather
>
> V2 supports bitmap graphics; support for it has been implemented in
> at least two formatter (dunno about the Python one), and it has been
> used for an RFC at least once. So this is a V2 feature; we can
> deprecate it in V3, but let's not pretend it's not there.
>
> For *RFCs*, we can of course state what kinds of media types that are
> accepted, but IMHO that's not a vocabulary question. After all, the
> V3 spec also doesn't say that the prose needs to be in English.
>
>

I have no problem with the vocabulary being flexible enough to allow for
more than we will allow in the final RFC; I believe that helps us with
the future-proofing of the vocabulary.  Someone will certainly correct
me if that's not an accurate expectation.

However, just to make sure we're all clear, artwork within RFCs will be
ASCII art and/or SVG.  Where we had previously allowed other media types
in the PDF because of the limitations of the ASCII-only RFCs, the new
PDFs are going to be generated in an entirely different fashion. 
Today's PDFs are either submitted by the author with whatever diagrams
or special features the authors required (these are reviewed but not
edited by the RFC Editor), OR they are automatically generated as an
image of the plain text.  We're moving to something more consistent and
following the current best practices for archivable digital objects.

Hope that helps,
Heather
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJUZRrXAAoJEER/xjINbZoGSAIIAL4SwrOJbqGmrNBbW2pdeZt2
qsWD3SAiBQF29zqGaChZWKEzQBy+IxPJEBCG63W+tqd+b4zIWGBMC+7REcRtUaLB
MGurKLW2yC+gKshfRrExLFCkND8yFVu/cEfolbFWuz8Z84hMBOM3Us/CKnOCEWII
NKl7b6LjZNTvTrD0O/NiwgjG2hg2/tNVcLO+boC5jq4bXosleSCY+GooewK+vzFZ
H6O31NNRh4YttlH/H3TXayKC9gHT8EuIaW7sD2Is/wCZQaWovY9SePZ8Him8FsE7
li4dJEcEaQxNBagA3C1e/YUzhMON2fRZSHOAZpXZYQb6xqh/BPbu1Qx6UHABKio=
=UIwa
-----END PGP SIGNATURE-----

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20141113/aa167813/attachment.html>