Subject: Type for content

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 30 Sep 2004 16:10:10 -0700

Recent discussion around PaceReformedContent3 shows that there are 
multiple opinions about the relative merits of two-attribute 
(node/type, as in the current format-draft) versus one-attribute 
(type, as in PaceReformedContent*) for specifying the encoding and 
content-type of Text Constructs and atom:content.

Tim could re-engineer PaceReformedContent* to split it into two 
pieces: the part about type and the part about accessibility and src= 
and so on.

The purpose of this note is to sound out the WG's opinion about how 
to go forward; a bit of meta-debate.

Some obvious options are:

- Go ahead and roll in ReformedContent3
- The same, but with the understanding that we then argue about type=
- Preserve the current type/mode attribute pair; rewrite 
ReformedContent to do so
- The same, but add the "TEXT", "HTML", and "XHTML" keywords (or 
lower-case equivalents) to type= since these thing aren't really 
text/plain, text/html, or application/xhtml

Other creative suggestions about how to move along are also welcome.

--Paul Hoffman, Director
--Internet Mail Consortium