Subject: PaceFeedState to be updated?

From: Tim Bray <[email-masked]>
Date: Tue, 01 Feb 2005 22:31:17 -0800

There was a huge amount of discussion around PaceFeedState, with input 
from our AD, and what smelled like converging language on the list.  Is 
someone going to update the Pace to take that into account? -Tim

---

From: Robert Sayre <[email-masked]>
Date: Wed, 02 Feb 2005 03:31:18 -0500

Tim Bray wrote:

>
>  There was a huge amount of discussion around PaceFormatSecurity, with
>  input from our AD, and what smelled like converging language on the
>  list. Is someone going to update the Pace to take that into account?
>  -Tim
>

---------------------------

10.1 HTML and XHTML Content

Text Constructs and atom:content allow the delivery of HTML and XHTML 
into a client application. Many elements are considered 'unsafe' in that 
they open clients to one or more types of attack. Every Atom Processor 
should carefully consider their handling of every type of element when 
processing incoming (X)HTML in Atom documents. See the security sections 
of RFC 2854 and HTML 4.01 for some guidance on many types of attack.

Atom Processors should pay particular attention to the security of the 
IMG, SCRIPT, EMBED, OBJECT, FRAME, FRAMESET, IFRAME, META, and LINK 
elements, but other elements may also have negative security properties.

(X)HTML can either directly contain or indirectly reference executable 
content.

10.1.1 URIs

Atom Processors handle URIs. See Section 7 of RFC 3986.

10.1.2 IRIs

Atom Processors handle IRIs. See Section 8 of RFC 3987.

---------------------------

Robert Sayre

---

From: Antone Roundy <[email-masked]>
Date: Wed, 2 Feb 2005 08:18:41 -0700

On Wednesday, February 2, 2005, at 01:31  AM, Robert Sayre wrote:
> Every Atom Processor should carefully consider their handling of every 
> type of element when processing incoming (X)HTML in Atom documents.
...and might wish to remove all unrecognized elements.

---

From: Tim Bray <[email-masked]>
Date: Wed, 02 Feb 2005 07:46:27 -0800

> 10.1 HTML and XHTML Content

I've dressed this up as PaceSecuritySection: 
http://www.intertwingly.net/wiki/pie/PaceSecuritySection

---

From: Joe Gregorio <[email-masked]>
Date: Wed, 2 Feb 2005 11:07:15 -0500

I had updated PaceFormatSecuruty based on feedback, removing all 
the proscriptive prose about removing elements and just pointing out 
potential security problems.

    -joe

-- 
Joe Gregorio        http://bitworking.org

---

From: Joe Gregorio <[email-masked]>
Date: Wed, 2 Feb 2005 11:38:48 -0500

> of RFC 2854 and HTML 4.01 for some guidance on many types of attack.

As I've stated before, referencing the security sections of these two 
documents will not be helpful to an implementer.

Also, you have dropped all references to CSS. 

   -joe

---

From: Robert Sayre <[email-masked]>
Date: Wed, 02 Feb 2005 11:53:33 -0500

> documents will not be helpful to an implementer.

Yes, you've stated that before. Two paragraphs on HTML security is still 
laughably inadequate, only they're in the wrong document, where they 
won't receive adequate review. What implementors *would* find helpful is 
a document covering these subjects authored by experts in HTML layout 
engines, JavaScript interpreters, and CSS.

Anyway, the Paces don't have opposing requirements, and our AD has told 
us what to write. I'm not sure why we're wasting WG time on this.

Robert Sayre