[rfc-i] illustrations & equations rare: extra overhead for creating them acceptable
hallam at gmail.com
Wed Mar 28 09:58:17 PDT 2012
I would prefer to leave restrictions to the IETF areas to make.
One of the reasons the IETF is shriveling in scope so that it only
really influences the routing layer effectively is that they have
pretty much been allowed to bring the rest of the organization down to
their level of abstraction and thinking.
If you are doing routing you will probably not see the need for
Unicode or rich text or color. If you are doing applications those are
We have a set of documents that try to explain I18N domain names that
are not allowed to use the international character set they are
describing the use of. The result is a specification that is garbage.
I am not going to take that seriously as the authoritative source no
matter who jumps up and down to say it is. I implemented those specs
from what I found on Wikipedia, not the RFC. And that is not a comment
on the authors, it is a comment on the format they were required to
So I would suggest that as far as the IETF is concerned there are no
top-down restrictions on format capabilities.
However use of included content types be subject to AD / Area approval
and require an RFC describing the format, giving standards references
etc, canonicalization etc.
This has already happened to a large extent. It is no longer
acceptable to use ad-hoc BNF. The shepherd has to say that content in
ABNF or XML or ASN.1 have to be validated.
If the Open Steganography Format (OSF) wants to use JPG to illustrate
their specification and their AD thinks that is a reasonable approach
and is willing to argue that in the IESG then let them.
Oh and BTW, yes I am thinking that an April fools RFC proposing a
steganographic format that contained an embedded steganographic
message would be funny.
On Wed, Mar 28, 2012 at 12:13 PM, Larry Masinter <masinter at adobe.com> wrote:
> I suggested MathML for math and SVG for diagrams (with text alternatives) because those are part of HTML5 and supported by many modern browsers without conversion, referencing, or resorting to "data:" URLs. They're also resolution independent.
> I do think limiting the complexity of diagrams and illustrations is important, and people are concerned about size, complexity, etc.
> But perhaps the normal review of working group approval, IETF last call, etc., could filter for complexity.
> For example, we might well want to disallow color in diagrams and illustrations.
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
More information about the rfc-interest