Skip to content

fix: Allow any SVG - #1335

Open
martinthomson wants to merge 4 commits into
ietf-tools:mainfrom
martinthomson:svg-full
Open

fix: Allow any SVG#1335
martinthomson wants to merge 4 commits into
ietf-tools:mainfrom
martinthomson:svg-full

Conversation

@martinthomson

@martinthomson martinthomson commented Jul 6, 2026

Copy link
Copy Markdown
Contributor

Based on RFC 9896, the SVG that can be included in an RFC is a matter of judgment, not something that can be validated by a tool. Implement that.

I searched for a schema that can be used with this (see notes), but it turns out that SVG doesn't subscribe to that philosophy any more:

Because SVG is extensible, conformant "image/svg+xml" processors must expect that content received is well-formed XML, but it cannot be guaranteed that the content is valid to a particular DTD or Schema or that the processor will recognize all of the elements and attributes in the document.
-- Section J.2 of https://www.w3.org/TR/SVG/

Therefore, this adds a very simple wildcard rule to the schema, which will allow virtually anything. I've tested this with the latest aasvg and it's fine.

Note(1): There is a RelaxNG schema for SVG floating around. It's broken; I tried it and gave up.

Note(2): Several of these files contain trailing whitespace, which is bad mojo. I left it there, but you should consider trimming it out.

Note(3): There is an awful lot of duplication of code in schema files. I left that alone too, copying the change to all the necessary places. Still, that seems like something that could be improved.

Note(4): I'm not very happy with my understanding of the testing infrastructure. I added a test that the <style> element was passed through in the test files, but I don't think that is really testing anything at all. I wanted to add a test XML file to tests/input and have that tested, but nothing I tried worked for that and it doesn't look like it would end up testing anything relevant anyway.

Note(5): On that testing infrastructure piece, I edited source files for what looks to be used to generate ./tests/valid/manpage.txt (and ./tests/valid/docfile.html as well), but I couldn't see how to have it generate a replacement file. It doesn't look like it is being generated from its source files.

Note(6): ./xml2rfc/data/rfc7991.rng comments out the SVG parts, so I left those alone. After all, these are just schema for that RFC, which is defunct now, so maybe it's historical (?). And of course, this is more schema duplication!

Based on RFC 9896, the SVG that can be included in an RFC is a matter of
judgment, not something that can be validated by a tool.  Implement
that.

I searched for a schema that can be used with this, but it turns out
that SVG doesn't subscribe to that philosophy any more:

>  Because SVG is extensible, conformant "image/svg+xml" processors must expect that content received is well-formed XML, but it cannot be guaranteed that the content is valid to a particular DTD or Schema or that the processor will recognize all of the elements and attributes in the document.
-- [Section J.2 of https://www.w3.org/TR/SVG/](https://www.w3.org/TR/SVG2/mimereg.html#mime-registration)

Therefore, this adds a very simple wildcard rule to the schema, which
will allow virtually anything.  I've tested this with the latest aasvg
and it's fine.

Note: There is a RelaxNG schema for SVG floating around.  It's broken.

Note(2): v3.rnc contains trailing whitespace, which is bad mojo.  I left
it there, but you should consider trimming it out.

Note(3): There is an awful lot of duplication of code for these schema.
I left that alone too, copying the change to all the necessary places.
Still, that seems like something that could be improved.
@kesara kesara added the rpat Issues needing attention from RFC Production Advisory Team label Jul 6, 2026
@martinthomson

Copy link
Copy Markdown
Contributor Author

I worked out something for the documentation. That was quite unpleasant.

@ajeanmahoney

Copy link
Copy Markdown
Collaborator

@martinthomson, thanks for your work on this, but this PR can't be merged because it allows for executable scripts. The RPC will be consulting with the community before IETF 127 to create updated SVG guidance, and this guidance will be checked by new code. I have created an issue in the RFCXML repo to track this SVG update: ietf-tools/RFCXML#48

@martinthomson

Copy link
Copy Markdown
Contributor Author

I spoke with @rjsparks about this offline and suggested that basic sanitization might work. I've just implemented a lightweight sanitization for SVG in this branch. Robert mentioned a desire to use something like nh3, but if you want to do that, then I suggest that someone else take this work on. (I have no interest in following an ever-increasing piece of string.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

rpat Issues needing attention from RFC Production Advisory Team

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants