Media types for RDF languages N3 and Turtle

Sean B. Palmer sean at
Mon Dec 17 18:38:13 CET 2007

On Dec 17, 2007 4:15 PM, Garret Wilson <garret at> wrote:

> My literal reading of RFC 2046 (which may not be correct) led
> me to believe that this only applied to text/plain.

Aha, I understand your reading now. I took it as having used
text/plain merely as an example, and to be talking about the whole
text branch: these quotes are from 4.1. Text Media Type -> 4.1.2.
Charset Parameter, whereas text/plain is defined later on in 4.1.3.
Plain Subtype.

The "pay close attention to the implications of multioctet character
sets" part goes the other way, however, and for me speaks most
strongly in defence of your reading; but either way:

"Semanticists should be obstetricians, not coroners of programming languages."
- John Reynolds, via James Clark [1]

> In fact, I could easily be persuaded just to ignore the US-ASCII
> and CRLF parts if everyone else were to do the same.

I'd be happy with that too. The only issue for me is whether
interpreting utf-8 as US-ASCII would cause any security issues or
serious damage anywhere, because as you say, people have taken RFC
2046 as mandating US-ASCII for non-charset-parametered text/*.

> The problem with the computer standards process is that it has
> gotten so bureaucratic and slow [...] I applaud anyone that would
> push for a new RFC to update RFC 2046

Yes, and yes.

> I'd prefer that either application/* were used, or the RFC 2046
> default character set were ignored.

I'd prefer that text/* were used as intended, not that we continue to
be coroners of RFC 2046. RFC 2046 was looking forward to a time where
there would be a universal character encoding, and utf-8 is what it
wished for. It seems wrong that RFC 2046 should then prevent utf-8
from being deployed!

And as for CRLF, it doesn't seem like anybody cares about that at all.

Perhaps, as Dan Connolly suggested on IRC, some civil disobedience of
RFC 2046 is called for here--as long as we're sure that this won't
cause any security or interoperability problems that would make it not
worth the effort.


Sean B. Palmer,

More information about the Ietf-types mailing list