- From: Dave Crocker <dhc2@dcrocker.net>
- Date: Sun, 15 Apr 2007 13:19:50 -0700
- To: public-html-mail@w3.org
- CC: tavisreddick@adamsmith.ac.uk, daniel.glazman@disruptive-innovations.com, arnt@oryx.com, gregory.woodhouse@sbcglobal.net
(I posted this to the list, last night, but have not seen it appear there. So I decided to re-post and copy you.) Folks, Howdy. Quite a few of the postings have been interesting, but I found these tidbits particularly helpful: Gregory Woodhouse wrote: > Now, that's interesting: Are web-based e-mail applications (which are > increasingly common) really distinguishable from other web-based > applications? gregory.woodhouse@sbcglobal.net wrote: > part of the problem is that the issue has been cast in the wrong > terms. Instead of looking for a subset (focusing on the technical > solution) that will solve the problem, shouldn't we start out by > trying to clearly state what it is we are trying to do? Tavis Reddick wrote: > In these discussions, I'm not sure if I understand the role of the > user, email client and server in choosing settings for personal > preference, accessibility and security. Arnt Gulbrandsen wrote: > First and most important: rendering email in a rectangular part of > the screen isn't enough. It's also necessary to reply (including > quoting) and to display excerpts of the message. > > Second, what good would such security settings have? There isn't any > trusted origin in email, At the start of an effort like this, any good engineer wants to dive into the details. (Well, ok. So do bad ones.) The challenge is to refrain from diving in too quickly. If folks can agree on the particular problems they want to solve (together), and then agree on the responsibilities for different components (e.g., html provider, html rendering engine, ...) then the fine-grained details are likely to follow rather naturally. So perhaps some meta-questions, taking from the above: 1. What is it about email use of HTML that is inherently different from web use? As an example, the asynchrony between the HTML provider and the HTML rendering means that the two cannot interact, to tailor what is provided. 2. What is it about the pragmatic aspects of email use that create pressure for additional differences from the web? The obvious example, here, is the very different security concerns. When talking with a web server, the client can have a fair degree of assurance that they are who they say they are, and SSL/TLS significantly add to that assurance. Email might yet get there, with DKIM, but it is a long way from that safety. And the current state of email abuse is one of chronic red-alert. 3. As noted, the Reply function introduces additional expectations. What are they exactly? (Reply has a long-history of being the litmus test for adequacy in a proposal. To that end, it underscores that email is about two-way dialogue, not just one-way publishing.) 4. Generically, what are the security concerns/threats that are key to safe use of HTML in email? 5. Must HTML in email be compatible with HTML on the web? Would it be acceptable to have valid email HTML not be subject to successful processing as a web page? (I'm trying to imagine the justification for making the answer be yes, and I'm failing...) 6. ...? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Received on Monday, 16 April 2007 11:40:16 UTC