From khaitan at gmail.com Mon Feb 1 22:42:30 2010 From: khaitan at gmail.com (Indus Khaitan) Date: Mon Feb 1 22:51:14 2010 Subject: [uf-new] New proposal: Microformat for email unsubscribe Message-ID: ufrs, I'm researching few extensions to an open source email client. One of the things I'm exploring is standardizing the unsubscribe information which is normally buried in the footer using a new microformat for annotating unsubscribe information. Benefits of the microformat: 1. Standardizing/semanticizing of unsubscribe information will allow automation for handling unsubscribes 2. Further to (1), email clients may extract the unsubscribe and present it in a different view altogether 3. Further to (1), custom unsubscribe workflows can be 'embedded' as the format matures Comparables: 1. There is an optional email header called 'List-unsubscribe' which is already in production use by GMail and other vendors Wanted to get your feedback before putting up an exploratory-discussions page. If you are looking to dig deeper, I have written it up here at http://www.khaitan.org/blog/unsubscribe-microformat/ Thx, Indus Khaitan From danbri at danbri.org Tue Feb 2 00:54:25 2010 From: danbri at danbri.org (Dan Brickley) Date: Tue Feb 2 00:54:32 2010 Subject: [uf-new] New proposal: Microformat for email unsubscribe In-Reply-To: References: Message-ID: On Tue, Feb 2, 2010 at 7:42 AM, Indus Khaitan wrote: > ufrs, > > I'm researching few extensions to an open source email client. One of > the things I'm exploring is standardizing the unsubscribe information > which is normally buried in the footer using a new microformat for > annotating unsubscribe information. > > Benefits of the microformat: > 1. Standardizing/semanticizing of unsubscribe information will allow > automation for handling unsubscribes > 2. Further to (1), email clients may extract the unsubscribe and > present it in a different view altogether > 3. Further to (1), custom unsubscribe workflows can be 'embedded' as > the format matures For clarity, is your expectation that this information would be in the footer of HTML mail messages? Or in the Web site(s) that those messages reference? > Comparables: > 1. There is an optional email header called 'List-unsubscribe' which > is already in production use by GMail and other vendors Most mail processing is centered around headers. Do you see particular benefits to adopting a microformat here? Ease of authoring, of consuming, of extensibility etc? cheers, Dan > Wanted to get your feedback before putting up an > exploratory-discussions page. If you are looking to dig deeper, I have > written it up here at > http://www.khaitan.org/blog/unsubscribe-microformat/ > > Thx, > Indus Khaitan > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > From khaitan at gmail.com Tue Feb 2 22:43:48 2010 From: khaitan at gmail.com (Indus Khaitan) Date: Tue Feb 2 22:44:12 2010 Subject: [uf-new] New proposal: Microformat for email unsubscribe In-Reply-To: References: Message-ID: > > For clarity, is your expectation that this information would be in the > footer of HTML mail messages? Or in the Web site(s) that those > messages reference? > Footer of an email message. > > Most mail processing is centered around headers. Do you see particular > benefits to adopting a microformat here? Ease of authoring, of > consuming, of extensibility etc? > Headers, though, simple, are mere directives as name value pairs. Using microformats would allow extensibility of processing the message. e.g., encoding the unsubscribe/opt-out mechanism (click thru urls/reply-to email/etc) as well as any mandatory fields pertaining to CAN-SPAM compliance. A compliant email client may extract this and convert in action buttons for the end-users. There are other things which could be done once there is a standard way of depicting the unsubscribe like, embedding workflows, auto-unsubscribe handling, aggregation, spam ratings, etc. Indus From tantek at cs.stanford.edu Fri Feb 19 18:30:10 2010 From: tantek at cs.stanford.edu (=?UTF-8?Q?Tantek_=C3=87elik?=) Date: Fri Feb 19 18:30:34 2010 Subject: [uf-new] HTML5 Profile attribute draft in progress Message-ID: <60cb038a1002191830k17aa1012le8aae33138dde1a4@mail.gmail.com> Greetings microformatters, Though this is not a new microformat, it is a new foundational feature that affects processing of microformats and thus I felt it appropriate to use this list for discussion. For a while now I've been playing with the idea of how to scope XMDP so that microformat vocabularies could be locally defined and used in a document without having to access the head of the document. To date the most conservative/compatible approach seemed to be to introduce a "profile" rel value (which I initially proposed ages ago for XHTML2 while in a previous incarnation of the W3C HTML WG) which could be used in a section of content with to link to a specific profile or profiles for that section of content. That work in progress is here: http://microformats.org/wiki/rel-profile However, having played with real world examples of doing so, the rel-profile technique felt clumsy and bit invasive (visible hyperlinks to profiles) and/or encouraging of poor coding (empty hyperlinks), or invalid coding (use of a element in content). The second idea that's been bouncing around in my head for a few years would be to generalize the profile attribute for all elements. Others (Toby Inkster, folks in the RDFa community) have had similar thoughts apparently. Frankly, I've not thought it worthy of pursuing (because it would be invalid HTML4/XHTML1) until now. Recently in the HTML5 world, microdata (syntax & processing) and RDFa have been published (or will soon be published) as extensions to HTML5 - both of which add attributes to HTML5. And Julian Reschke contacted me and Manu Sporny requesting our thoughts on how to proceed regarding the profile attribute (or lack thereof) in HTML5. In that discussion (which was mostly about how to have it on IRC and then having it on IRC #microformats), we explored the possibility of the publication of another extension to HTML5 - that of adding the profile attribute to all elements and describing a processing model for it. http://krijnhoetmer.nl/irc-logs/microformats/20100219#l-90 The result is the following draft in progress: http://microformats.org/wiki/html5-profile Which Julian recently announced on the public-html list: http://lists.w3.org/Archives/Public/public-html/2010Feb/0683.html This has helped resolve an open issue in HTML5 which is now likely to permanently drop the head element's profile attribute from the HTML5 core vocabulary/API. Redefining a more useful/usable profile attribute in an extension seems to me to be the best path forward for the profile attribute. Please take a look at the html5-profile draft in progress if topics like profiles, XMDP, follow-your-nose interest you, and feel free to raise issues on the issues page: http://microformats.org/wiki/html5-profile-issues Thanks, Tantek -- http://tantek.com/