Subject: Re: text-only in atom:title?

From: Dave Pawson <[email-masked]>
Date: Wed, 01 Sep 2004 17:26:40 +0100

On Tue, 2004-08-31 at 23:21, Asbjørn Ulsberg wrote:
> On Tue, 31 Aug 2004 13:55:10 -0400, Jon Meyer <[email-masked]> wrote:
> 
> > Is there any interest in an @alt attribute, so people who produce  
> > rich-text titles can also be responsible for generating the plain-
> > text version?
> 
> I think rich-text titles is a really bad idea, but if the consensus is  
> that those should be enabled, I don't think we should just use HTML's @alt  
> attribute.
> 
> Alternative content is great, but the @alt attribute is so badly designed  
> in HTML that I don't think we should inherit it directly. Let's use an  
> element instead.

I thought Atom was to be an XML based beast. Apparently not.

If its going to run to broken in the same way HTML is abused/busted/
broken, why not let users hack at it in any old way?

Put base64 crap in there; What's the difference?

-- 
Regards DaveP.
XSLT&Docbook  FAQ
http://www.dpawson.co.uk/xsl

---

From: Dave Pawson <[email-masked]>
Date: Wed, 01 Sep 2004 17:40:55 +0100

On Wed, 2004-09-01 at 01:09, Paul Hoffman / IMC wrote:
> At 1:55 PM -0400 8/31/04, Jon Meyer wrote:
> >Is there any interest in an @alt attribute, so people who produce rich-text
> >titles can also be responsible for generating the plain-text version?  e.g.
> >
> ><title alt="Ghost says *boo*!" type="application/xhtml+xml" mode="xml">
> >    <div xmlns="http://www.w3.org/1999/xhtml">
> >       Ghost says <em>boo</em><img src=".../exclamation.gif"/>
> >    </div>
> ></title>
> 
> That seems pretty clean to me. The default type would be text/plain, 
> but if someone wants to go crazy and knows that doing so might cause 
> the title to not appear, have a blast.

How about mixing some SVG and a bit of flash in there via an html
object?
Is that still clean?

I don't think so.

---

From: Antone Roundy <[email-masked]>
Date: Wed, 1 Sep 2004 11:11:29 -0600

On Wednesday, September 1, 2004, at 10:40  AM, Dave Pawson wrote:
>>> rich-text

If we allow any HTML at all, it isn't going to matter a whole lot what 
people actually put in there.  The only way for an application to be 
secure will be to filter out all but a specific set of tags, CSS, 
script handlers, and other attributes that is known to be safe and not 
to degrade the UI unacceptably.  Once a program can do that, filtering 
out all kinds of junk is no harder than filtering out a little bit of 
junk.

Applications are going to need to be able to do this for <content> 
anyway, so patching the same processing in to <title> et al (probably 
with a more restricted set of acceptable stuff) is going to be trivial.

---

From: Dave Pawson <[email-masked]>
Date: Wed, 01 Sep 2004 19:07:10 +0100

On Wed, 2004-09-01 at 18:11, Antone Roundy wrote:

> secure will be to filter out all but a specific set of tags,

Isn't that what XML and Schema's are all about.
  Why not define a specific set of tags?
   We've seen the alternative, its called a browser war,
   or perhaps blogging war would be more appropriate here.

---

From: Antone Roundy <[email-masked]>
Date: Wed, 1 Sep 2004 12:40:25 -0600

>    or perhaps blogging war would be more appropriate here.
I'm not certain we're talking about the same thing.

<content type="escaped-html">
	&lt;script&gt;
	DoMaliciousScriptingStuff();
	&lt;/script&gt;
</content>

Are XML and Schema's going to help us here?

<content type="escaped-html">
	&lt;b style="display:block; position:absolute; top:0; left:0; 
width:2000px; height:2000px; background:#fff;"&gt;
	Where'd everybody go?!
	&lt;/b&gt;
</content>

How about here?

If the spec includes a list of all HTML tags, CSS, etc. that are 
allowed in feeds, we're going to have to track new developments in 
those technologies, and periodically decide which new things to add to 
the allowed list.  We'd also limit the usefulness of Atom in closed 
systems that need things that COULD be use maliciously, but are also 
useful when not used maliciously.  I think we should provide GUIDANCE 
on these issues, and let publishers know that if they use things that 
might be considered potentially harmful, they will sometimes get 
filtered out, but not proscribe anything in particular.  That seems 
like an implementation detail that we shouldn't get into.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 1 Sep 2004 20:51:08 -0700

>How about mixing some SVG and a bit of flash in there via an html

Sure. No recipient of such blarg needs to interpret it. Given the 
statistics that folks who do this stuff for a living have given, it 
is unlikely that many client vendors will even bother with putting in 
HTML renderers for this stuff, or if they do, it will be done 
identically to the enclosed content. Titles will probably not be 
special.

It is clean for the creator to clearly label what it is sending, and 
it is clean for us to allow extensibility that costs nothing to 
people who don't want it.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Dave Pawson <[email-masked]>
Date: Thu, 02 Sep 2004 18:52:19 +0100

> I'm not certain we're talking about the same thing.

I think we are Antone. 
I basically want plain text (properly encoded) within XML
elements.
  The presentational style of that content should be
down to the receiver of that content; let them mess
with it, turn it pink, make it bold and big and brassy if 
they so wish.

I.e. I'm very much against html/sgml (or any other historical
meanderings) within plain old fashioned XML.

> like an implementation detail that we shouldn't get into.

Even more reasons to steer clear of markup within markup.