<?xml version="1.0" encoding="UTF-8"?>
 <rdf:RDF xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://web.resource.org/cc/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://pinboard.in">
    <title>Pinboard (jtyost2)</title>
    <link>https://pinboard.in/u:jtyost2/public/</link>
    <description>recent bookmarks from jtyost2</description>
    <items>
      <rdf:Seq>	<rdf:li rdf:resource="https://arstechnica.com/gadgets/2019/03/microsofts-new-skype-for-web-client-an-early-taste-of-the-browser-monoculture/"/>
	<rdf:li rdf:resource="https://www.theverge.com/2019/3/4/18246182/usb-4-thunderbolt-3-specs-features-release-date"/>
	<rdf:li rdf:resource="https://twitter.com/lorenb/status/644510324784295936"/>
	<rdf:li rdf:resource="https://blog.chromium.org/2015/04/a-quic-update-on-googles-experimental.html"/>
	<rdf:li rdf:resource="http://thenextweb.com/insider/2015/02/18/http2-first-major-update-http-sixteen-years-finalized/"/>
	<rdf:li rdf:resource="http://www.theverge.com/2014/11/4/7154439/diverse-emoji-proposal-for-2015"/>
	<rdf:li rdf:resource="http://www.w3.org/blog/news/archives/4167"/>
	<rdf:li rdf:resource="https://medium.com/medium-eng/122d8a40e480"/>
	<rdf:li rdf:resource="http://news.cnet.com/8301-1023_3-57617840-93/reversing-course-google-rejects-adobe-web-publishing-tech/"/>
	<rdf:li rdf:resource="http://www.bbc.co.uk/news/world-europe-25829604"/>
	<rdf:li rdf:resource="http://boingboing.net/2014/01/14/requirements-for-drm-in-html5.html"/>
	<rdf:li rdf:resource="http://arstechnica.com/security/2014/01/nsa-employee-will-continue-to-co-chair-influential-crypto-standards-group/"/>
	<rdf:li rdf:resource="http://coding.smashingmagazine.com/2013/11/13/laying-the-groundwork-for-extensibility/"/>
	<rdf:li rdf:resource="http://www.washingtonpost.com/blogs/wonkblog/wp/2013/12/30/car-companies-are-picking-sides-between-apple-and-google/"/>
	<rdf:li rdf:resource="https://www.eff.org/deeplinks/2013/10/lowering-your-standards"/>
	<rdf:li rdf:resource="http://arstechnica.com/information-technology/2013/12/500mbps-internet-over-phone-lines-might-solve-fibers-last-mile-problem/"/>
	<rdf:li rdf:resource="http://www.ietf.org/mail-archive/web/ietf/current/msg83857.html"/>
	<rdf:li rdf:resource="http://arstechnica.com/security/2013/11/to-restore-credibility-nist-will-audit-its-standards-development-process/"/>
	<rdf:li rdf:resource="https://blog.mozilla.org/blog/2013/10/30/video-interoperability-on-the-web-gets-a-boost-from-ciscos-h-264-codec/"/>
	<rdf:li rdf:resource="http://www.openh264.org/"/>
	<rdf:li rdf:resource="http://www.networkworld.com/news/2013/091913-ios7-multipath-273995.html"/>
	<rdf:li rdf:resource="http://bits.blogs.nytimes.com/2013/09/10/government-announces-steps-to-restore-confidence-on-encryption-standards/"/>
	<rdf:li rdf:resource="http://arstechnica.com/business/2013/08/crypto-experts-blast-german-e-mail-providers-secure-data-storage-claim/"/>
	<rdf:li rdf:resource="http://www.washingtonpost.com/blogs/wonkblog/wp/2013/08/07/should-legal-codes-be-copyrighted-lets-sue-to-find-out/"/>
	<rdf:li rdf:resource="http://www.guardian.co.uk/books/2012/jun/22/ray-bradbury-internet-error-message-451"/>
	<rdf:li rdf:resource="http://googledevelopers.blogspot.com/2013/06/making-googles-caldav-and-carddav-apis.html"/>
	<rdf:li rdf:resource="https://plus.google.com/116276248303121270590/posts/ggNwh9eLYWu"/>
	<rdf:li rdf:resource="http://nymag.com/daily/intelligencer/2013/05/gif-pronunciation-goff-webby-awards-wilhite.html"/>
	<rdf:li rdf:resource="http://bits.blogs.nytimes.com/2013/05/21/an-honor-for-the-creator-of-the-gif/"/>
	<rdf:li rdf:resource="http://phil.ipal.org/tc.html"/>
	<rdf:li rdf:resource="http://eschnou.com/entry/whats-next-google--dropping-smtp-support--62-24930.html"/>
	<rdf:li rdf:resource="http://techblog.netflix.com/2013/04/html5-video-at-netflix.html"/>
	<rdf:li rdf:resource="http://ejohn.org/blog/webkit-is-the-jquery-of-browser-engines/"/>
	<rdf:li rdf:resource="http://bitsplitting.org/2013/03/13/netnewswire-cloud/"/>
	<rdf:li rdf:resource="http://inessential.com/2013/03/14/why_i_love_rss_and_you_do_too"/>
	<rdf:li rdf:resource="http://css-tricks.com/using-svg/"/>
	<rdf:li rdf:resource="http://paulirish.com/2013/webkit-for-developers/"/>
	<rdf:li rdf:resource="http://www.netmagazine.com/opinions/jeffrey-zeldman-dream-standards-based-web"/>
	<rdf:li rdf:resource="http://modernwebaccessibility.com/blog/stop-fud-a11y"/>
	<rdf:li rdf:resource="http://www.webstandards.org/2013/03/01/our-work-here-is-done/"/>
	<rdf:li rdf:resource="http://xkcd.com/1179/"/>
	<rdf:li rdf:resource="http://www.w3.org/News/2012"/>
	<rdf:li rdf:resource="http://www.brucelawson.co.uk/2012/on-drm-in-html5/"/>
	<rdf:li rdf:resource="http://dickhardt.org/2012/10/oauth-2-0/"/>
	<rdf:li rdf:resource="http://my.opera.com/ODIN/blog/2012/10/08/introducing-device-stock-ua"/>
	<rdf:li rdf:resource="http://www.theregister.co.uk/2012/07/28/oauth_editor_quits/"/>
	<rdf:li rdf:resource="https://mikewest.org/2012/05/content-security-policy-feature-detection"/>
	<rdf:li rdf:resource="http://www.webkitbits.com/post/22222538210/why-o-why"/>
	<rdf:li rdf:resource="http://mir.aculo.us/2012/04/24/5-things-they-told-you-not-to-use-in-javascript/"/>
	<rdf:li rdf:resource="http://www.blog.bt.com/viewpoint/index.php/2012/04/23/ipv6ietf/"/>
	<rdf:li rdf:resource="http://blog.izs.me/post/2353458699/an-open-letter-to-javascript-leaders-regarding"/>
	<rdf:li rdf:resource="http://brendaneich.com/2012/04/the-infernal-semicolon/"/>
	<rdf:li rdf:resource="http://blog.killtheradio.net/technology/email-is-not-broken-its-a-framework-not-an-application/"/>
	<rdf:li rdf:resource="http://meyerweb.com/eric/thoughts/2006/09/25/w3c-change-full-independence/"/>
	<rdf:li rdf:resource="http://blog.jgc.org/2012/04/in-praise-of-text-files-and-protocols.html"/>
	<rdf:li rdf:resource="http://arstechnica.com/business/news/2012/03/fsfe-celebrates-document-freedom-day-by-sending-handcuffs-to-policymakers.ars"/>
	<rdf:li rdf:resource="http://arstechnica.com/business/news/2012/03/mozilla-firefox-needs-h264-support-to-survive-shift-to-mobile.ars"/>
	<rdf:li rdf:resource="http://blog.benstrong.com/2010/11/google-and-microsoft-cheat-on-slow.html?m=1"/>
	<rdf:li rdf:resource="http://arstechnica.com/microsoft/news/2012/02/cisco-begs-eu-make-microsoft-open-up-skypes-users-to-cisco-hardware.ars"/>
	<rdf:li rdf:resource="http://arstechnica.com/apple/news/2012/02/apple-takes-frand-issue-to-etsi-asks-for-common-frand-royalty-standards.ars"/>
	<rdf:li rdf:resource="http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#the-translate-attribute"/>
	<rdf:li rdf:resource="http://dev.w3.org/csswg/css3-hierarchies/"/>
	<rdf:li rdf:resource="http://tantek.com/2011/238/b1/many-ways-slice-url-name-pieces"/>
	<rdf:li rdf:resource="https://hacks.mozilla.org/2011/08/introducing-webapi/"/>
	<rdf:li rdf:resource="http://www.readwriteweb.com/hack/2011/04/internet-explorer-webgl-and-a.php"/>
	<rdf:li rdf:resource="http://arstechnica.com/apple/news/2011/04/adobe-throws-in-towel-adopts-http-live-streaming-for-ios.ars"/>
	<rdf:li rdf:resource="http://news.cnet.com/8301-30685_3-10402642-264.html"/>
	<rdf:li rdf:resource="http://daringfireball.net/linked/2009/11/18/ie9-interop"/>
	<rdf:li rdf:resource="http://radar.oreilly.com/2009/11/the-war-for-the-web.html"/>
	<rdf:li rdf:resource="http://ajaxian.com/archives/ie-9-hardware-rendering-new-js-engine-css-standards-and-more?utm_source=feedburner&amp;utm_medium=feed&amp;utm_campaign=Feed%3A+ajaxian+%28Ajaxian+Blog%29&amp;utm_content=Google+Reader"/>
      </rdf:Seq>
    </items>
  </channel><item rdf:about="https://arstechnica.com/gadgets/2019/03/microsofts-new-skype-for-web-client-an-early-taste-of-the-browser-monoculture/">
    <title>Microsoft’s new Skype for Web client: An early taste of the browser monoculture</title>
    <dc:date>2019-03-12T22:51:38+00:00</dc:date>
    <link>https://arstechnica.com/gadgets/2019/03/microsofts-new-skype-for-web-client-an-early-taste-of-the-browser-monoculture/</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[Rather, it's a being bothered to do the work issue. Microsoft has said that its decision to prioritize Edge and Chrome is based on "customer value." Or, to put it another way, there's not much point in taking the time and effort to support browsers that have a small audience. This creates a negative feedback loop for those browsers, discouraging their use and pushing developers toward a world in which Chrome is the only browser that developers think about and target.

There's perhaps also some irony in that the Skype app is built with a framework designed to foster cross-platform development, between devices, desktop, and the Web. For those who can use the Web app, it looks extremely similar to the desktop apps, which also look very similar to the mobile apps. That's because it's built using ReactXP, Microsoft's layer on top of Facebook's React and React Native frameworks. These let you use Web technology to build applications not just for the Web but also the desktop and smartphone platforms. When targeting the Web, ReactXP supports Firefox, reinforcing once again that this isn't really a technology question.]]></description>
<dc:subject>software webdevelopment webdesign browser googlechrome microsoft firefox internet standards</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:84396d46f4cb/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:webdevelopment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:webdesign"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:browser"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:googlechrome"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:microsoft"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:firefox"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.theverge.com/2019/3/4/18246182/usb-4-thunderbolt-3-specs-features-release-date">
    <title>With USB 4, Thunderbolt 3’s benefits become open to all</title>
    <dc:date>2019-03-04T16:50:30+00:00</dc:date>
    <link>https://www.theverge.com/2019/3/4/18246182/usb-4-thunderbolt-3-specs-features-release-date</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[Photo by Vlad Savov / The Verge Hot on the heels of USB 3.2 receiving a confusing Gen 2x2 suffix , the USB Implementers Forum (USB-IF) has today announced USB…]]></description>
<dc:subject>standards hardware technology usb thunderbolt</dc:subject>
<dc:source>https://instapaper.com/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:e2820e1b6e15/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:hardware"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:technology"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:usb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:thunderbolt"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://twitter.com/lorenb/status/644510324784295936">
    <title>Loren Brichter on Twitter: &quot;The web is like democracy; it's messy and it sucks. But a (currently benevolent) dictatorship adverse to it has damaging implications.&quot;</title>
    <dc:date>2015-09-18T02:56:07+00:00</dc:date>
    <link>https://twitter.com/lorenb/status/644510324784295936</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[The web is like democracy; it's messy and it sucks. But a (currently benevolent) dictatorship adverse to it has damaging implications.]]></description>
<dc:subject>apple software technology opensource standards advertising business</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:0a1a34a16392/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:apple"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:technology"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:opensource"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:advertising"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:business"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blog.chromium.org/2015/04/a-quic-update-on-googles-experimental.html">
    <title>Chromium Blog: A QUIC update on Google’s experimental transport</title>
    <dc:date>2015-04-18T19:21:36+00:00</dc:date>
    <link>https://blog.chromium.org/2015/04/a-quic-update-on-googles-experimental.html</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[Today, roughly half of all requests from Chrome to Google servers are served over QUIC and we’re continuing to ramp up QUIC traffic, eventually making it the default transport from Google clients — both Chrome and mobile apps — to Google servers. We plan to formally propose QUIC to the IETF as an Internet standard but we have some housekeeping to do first, like changing the wire format and updating our reference implementation from SPDY-over-QUIC to HTTP2-over-QUIC. In the coming months, we also plan to work on lowering handshake overhead to allow better server-side scalability, improving forward error correction and congestion control, and adding support for multipath connections.   ]]></description>
<dc:subject>standards protocol http TCP UDP QUIC</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:e0bd5561a4ed/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:protocol"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:TCP"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:UDP"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:QUIC"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://thenextweb.com/insider/2015/02/18/http2-first-major-update-http-sixteen-years-finalized/">
    <title>The Largest Update to HTTP in 16 Years Has Been Finalized</title>
    <dc:date>2015-02-18T04:36:26+00:00</dc:date>
    <link>http://thenextweb.com/insider/2015/02/18/http2-first-major-update-http-sixteen-years-finalized/</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[The new HTTP standard was based on Google’s SPDY protocol, which is used today by some technologies to manipulate traffic which helps improve latency and security, delivering faster page load times. Google announced just a few days ago that it plans to switch fully to HTTP/2 in Chrome.

Developers wishing to test HTTP/2 before it becomes official can already do so now in Firefox and Chrome, along with downloadable test servers to try improvements for themselves. More information is available in the HTTP/2 FAQ.

It should be a relatively short time before the standard is passed through the Request-For-Comments Editor and published for use in its final form.]]></description>
<dc:subject>http technology software standards protocol</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:590d52c4a1c3/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:technology"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:protocol"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.theverge.com/2014/11/4/7154439/diverse-emoji-proposal-for-2015">
    <title>Apple and Google engineers are trying to make emoji more diverse | The Verge</title>
    <dc:date>2014-11-04T23:18:12+00:00</dc:date>
    <link>http://www.theverge.com/2014/11/4/7154439/diverse-emoji-proposal-for-2015</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[The diversity issue with emoji has been fairly obvious for a while now, but it's been a growing issue as emoji have grown in importance for communications. Apple even stated earlier this year that it felt "there needs to be more diversity in the emoji character set," noting that it was working with the consortium to update the standard.

Given that this proposal comes from one Apple engineer and one Google engineer, who also happens to be president of the consortium, it's pretty clear that this is a real issue that tech companies want to address. Though those two companies are the only ones listed with an involvement in this proposal, the overall standard is widely supported — so any modern platform that you're using emoji on right now has a good chance of supporting diverse emoji sometime after the standard is finished.]]></description>
<dc:subject>emoji communication diversity technology standards software</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:79895ef8d9d0/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:emoji"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:communication"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:diversity"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:technology"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:software"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.w3.org/blog/news/archives/4167">
    <title>HTML5 is a W3C Recommendation | W3C News</title>
    <dc:date>2014-10-30T00:43:32+00:00</dc:date>
    <link>http://www.w3.org/blog/news/archives/4167</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[The HTML Working Group today published HTML5 as W3C Recommendation. This specification defines the fifth major revision of the Hypertext Markup Language (HTML), the format used to build Web pages and applications, and the cornerstone of the Open Web Platform.]]></description>
<dc:subject>html5 w3c standards browser webdevelopment</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:35fc76a07eef/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:html5"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:w3c"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:browser"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:webdevelopment"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://medium.com/medium-eng/122d8a40e480">
    <title>Why ContentEditable is Terrible — Medium Engineering — Medium</title>
    <dc:date>2014-05-17T21:33:49+00:00</dc:date>
    <link>https://medium.com/medium-eng/122d8a40e480</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[ContentEditable is the native widget for editing rich text in a web browser. It is…sad.

I’m going to try to prove to you, with some hand-wavey math, that the current approach of ContentEditable is broken. This is not because I think math is a persuasive way to make this argument. It actually makes the argument more alienating.

But I do think that text editors lead to lots of fuzzy, ill-defined questions like “What does What-You-See-Is-What-You-Get (WYSIWYG) even mean?” and “What happens when you select this text and hit Enter?” Axiomatic math is the best toolkit I know to take fuzzy, ill-defined questions and sharpen them.

So what does WYSIWYG mean? A good WYSIWYG editor should satisfy the following 3 axioms:

The mapping between DOM content and Visible content should be well-behaved.
The mapping between DOM selection and Visible selection should be well-behaved.
All visible edits should map onto an algebraically closed and complete set of visible content.
First, I’ll explain what each of these 3 axioms mean, and why a good editor should obey these rules. But let’s be clear: they’re axioms. The weakest part of any proof. We’re assuming they’re OK unless we have evidence otherwise.

Second, I’ll show that ContentEditable fails all 3 axioms.

Third, we’ll talk about how new browser features and libraries try to address these issues, and how we handle them in the Medium editor.]]></description>
<dc:subject>html dom design software usability standards mathematics</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:b5aa41910e72/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:html"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:dom"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:usability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:mathematics"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://news.cnet.com/8301-1023_3-57617840-93/reversing-course-google-rejects-adobe-web-publishing-tech/">
    <title>Reversing course, Google rejects Adobe Web publishing tech | Internet &amp; Media - CNET News</title>
    <dc:date>2014-01-28T17:25:34+00:00</dc:date>
    <link>http://news.cnet.com/8301-1023_3-57617840-93/reversing-course-google-rejects-adobe-web-publishing-tech/</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[It can be hard to say no to an idea with some merit -- especially after already saying yes.
But that's the position Google is in with an Adobe Systems technology for bringing more sophisticated, magazine-style layouts to Web publishing through a technology called CSS Regions. Google changed its mind after deciding that it was too complex and that it would hamper one of Google's top 2014 priorities, making Chrome faster on mobile devices, according to Google Chrome programmer Eric Seidel.
Adobe had been working on CSS Regions for years, developing the idea as part of its effort to reincarnate Flash Player abilities as native Web standards. Adobe made progress working CSS Regions support into Google's Blink browser engine and the Apple WebKit project from which Blink originated. But Seidel proposed working with Adobe to remove CSS Regions code from Blink.
"I believe Blink's focus this year must be on mobile and specifically mobile performance...I have come to understand that Regions both does not play well with existing performance optimizations [and] impedes ongoing simplification and optimization work to our core rendering code," Seidel said about his reversal of opinion on CSS Regions. "Regions addresses some very real deficiencies of the Web platform. But I believe Blink (hopefully with Adobe's help) will need to find other simpler/smaller ways to address these deficiencies."]]></description>
<dc:subject>google googlechrome blink webdesign webdevelopment adobe software technology standards</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:0638b7c11eda/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:googlechrome"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:blink"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:webdesign"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:webdevelopment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:adobe"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:technology"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.bbc.co.uk/news/world-europe-25829604">
    <title>BBC News - Free trade: EU halts investment talks with US</title>
    <dc:date>2014-01-21T17:57:31+00:00</dc:date>
    <link>http://www.bbc.co.uk/news/world-europe-25829604</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[The European Commission has suspended talks on part of a far-reaching EU-US free trade deal amid concern that hard-won social protections in Europe might be undermined.

The trade negotiations began last year but now the Commission has launched a three-month public consultation on the proposed investment rules for firms.

The aim is to close legal loopholes.

Consumer and environmental lobbyists say there is a risk of the EU accepting lower US standards in many areas.

The proposed EU-US Transatlantic Trade and Investment Partnership (TTIP) could bring huge benefits for Europe and America, the Commission says.

An EU study last September estimated it could boost the size of the EU economy by 120bn euros (£99bn; $162bn) - equal to 0.5% of GDP - and the US economy by 95bn euros (or 0.4% of GDP).

But several European non-governmental organisations (NGOs) and MEPs have questioned the investment rules, fearing that they could tie governments' hands in the face of powerful US corporations.]]></description>
<dc:subject>usa business regulation standards trade economics economy EuropeanUnion government</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:3cdce5d8b6ad/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:usa"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:business"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:regulation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:trade"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:economics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:economy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:EuropeanUnion"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:government"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://boingboing.net/2014/01/14/requirements-for-drm-in-html5.html">
    <title>Requirements for DRM in HTML5 are a secret - Boing Boing</title>
    <dc:date>2014-01-16T06:15:44+00:00</dc:date>
    <link>http://boingboing.net/2014/01/14/requirements-for-drm-in-html5.html</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[DRM, by its nature, has secret requirements. That's why attempts to standardize it always end up with unworkable garbage, like the DVB's CPCM. DRM relies on me installing software on your computer that stops you from running other software. For example, you install a browser that plays video in such a way that another program on your computer can't grab the video as the browser shows it on the screen.

This is silly. It's your computer. Whatever steps the browser takes to obscure how it is playing the video back can be unpicked by you, at your leisure, so you can make a tool that gets around it.

Standards are, by their nature, public: they say, "This is what you are expected to do." But if you make DRM's workings public ("here's how we hide the keys from you"), you provide a roadmap for defeating it. Standardized DRM is an oxymoron, like a secret law.

The ensuing Hacker News thread is well worth a read on this]]></description>
<dc:subject>drm privacy legal w3c standards encryption browser webstandards</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:95202b342556/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:drm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:privacy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:legal"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:w3c"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:encryption"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:browser"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:webstandards"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://arstechnica.com/security/2014/01/nsa-employee-will-continue-to-co-chair-influential-crypto-standards-group/">
    <title>NSA employee will continue to co-chair influential crypto standards group</title>
    <dc:date>2014-01-08T02:25:40+00:00</dc:date>
    <link>http://arstechnica.com/security/2014/01/nsa-employee-will-continue-to-co-chair-influential-crypto-standards-group/</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[A National Security Agency employee will continue to co-chair an influential group that helps to develop cryptographic standards designed to protect Internet communications, despite calls he should be removed.]]></description>
<dc:subject>nsa security encryption privacy civilrights standards</dc:subject>
<dc:identifier>https://pinboard.in/u:jtyost2/b:d7974410c461/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:nsa"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:encryption"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:privacy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:civilrights"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://coding.smashingmagazine.com/2013/11/13/laying-the-groundwork-for-extensibility/">
    <title>Laying The Groundwork For Extensibility | Smashing Coding</title>
    <dc:date>2014-01-02T19:24:20+00:00</dc:date>
    <link>http://coding.smashingmagazine.com/2013/11/13/laying-the-groundwork-for-extensibility/</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[In an earlier time, attempting such a sweeping cultural change might have been foolish. Starting at a declarative level was undoubtedly a good idea. However, explaining even a bit of the underlying magic goes a long way: Exposing a DOM tree JavaScript opened new worlds to developers and bolstered the competitiveness of the platform. It also enabled the community to adapt through experimentation and enabled libraries to compete. This allows valuable, popular API ideas to potentially be standardized. The community can do it faster and with less risk than browser vendors and standards organizations can.
The answers aren’t always obvious, but the process of asking “How does that work?” is often more fruitful than it first appears. Details come into focus and missing explanations are uncovered, layer by layer. At each layer, it’s tempting to throw up our collective hands and say “It’s too hard” to explain all the stuff down there. Throw it all out. Start over. At least we won’t make the same mistakes, right?
Perhaps. But we’d also be starting from zero. Zero users, zero developers and zero useful content. The Web is the open, extensible, multi-vendor, universal platform of our lifetime. Small, meaningful changes to the Web can have an outsized impact relative to the effort involved. It’s a straightforward way to do a great deal of good. Encouraging layering, bit by bit, doesn’t mean giving up or “slowing down.” Just the opposite: It’s our only credible hope of making a Web that’s worthy to succeed the Web we have today.]]></description>
<dc:subject>standards html5 html webdevelopment software api w3c</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:de34a823e606/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:html5"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:html"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:webdevelopment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:w3c"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.washingtonpost.com/blogs/wonkblog/wp/2013/12/30/car-companies-are-picking-sides-between-apple-and-google/">
    <title>Car companies are picking sides between Apple and Google</title>
    <dc:date>2013-12-31T18:03:11+00:00</dc:date>
    <link>http://www.washingtonpost.com/blogs/wonkblog/wp/2013/12/30/car-companies-are-picking-sides-between-apple-and-google/</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[It’s probably an asset to have your car integrate with the device that runs the rest of your life. The annoying part comes in when you think about the implications of cars getting enmeshed in the platform wars: If you want an Audi, and you have an iPhone, will you have to switch to an Android in order to get the most out of your driving experience? A couple weeks ago, Google hinted to EE Times that its announcement would include the formation of an industry consortium that will create compatibility standards to ease the process of making apps for cars — but will they just be for those that run Android? Developers already have to make a version for each operating system on regular phones; now the inconvenience could extend  into the auto world as well. (And considering the way internet companies form alliances with phonemakers now, an Amazon car or a Facebook car could be next.)

It would seem logical for a car company to stay platform-agnostic, so as not to repel consumers who are wedded to one operating system or the other. Hyundai, for example, is developing near-field communications technology that turns any kind of phone into a key fob. But big corporate alliances tend not to work that way: It’s very difficult to serve both Coke and Pepsi as a fast food restaurant, for example, because of the marketing and bulk purchasing advantages that come with signing on exclusively with one or the other.

So, let the division of the driving world begin.]]></description>
<dc:subject>standards technology hardware automotive business mobile google googleandroid ios apple</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:6982b3c64476/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:technology"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:hardware"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:automotive"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:business"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:mobile"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:googleandroid"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:ios"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:apple"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.eff.org/deeplinks/2013/10/lowering-your-standards">
    <title>Lowering Your Standards: DRM and the Future of the W3C | Electronic Frontier Foundation</title>
    <dc:date>2013-12-26T21:22:46+00:00</dc:date>
    <link>https://www.eff.org/deeplinks/2013/10/lowering-your-standards</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[Just five years ago, font companies tried to demand DRM-like standards for embedded Web fonts. These Web typography wars fizzled out without the adoption of these restrictions, but now that such technical restrictions are clearly "in scope," why wouldn't typographers come back with an argument for new limits on what browsers can do?

Indeed, within a few weeks of EME hitting the headlines, a community group within W3C formed around the idea of locking away Web code, so that Web applications could only be executed but not examined online. Static image creators such as photographers are eager for the W3C to help lock down embedded images. Shortly after our Tokyo discussions, another group proposed their new W3C use-case: "protecting" content that had been saved locally from a Web page from being accessed without further restrictions. Meanwhile, publishers have advocated that HTML textual content should have DRM features for many years.

In our conversations with the W3C, we argued that the W3C needed to develop a clearly defined line against the wave of DRM systems it will now be encouraged to adopt.

A Web where you cannot cut and paste text; where your browser can't "Save As..." an image; where the "allowed" uses of saved files are monitored beyond the browser; where JavaScript is sealed away in opaque tombs; and maybe even where we can no longer effectively "View Source" on some sites, is a very different Web from the one we have today. It's a Web where user agents—browsers—must navigate a nest of enforced duties every time they visit a page. It's a place where the next Tim Berners-Lee or Mozilla, if they were building a new browser from scratch, couldn't just look up the details of all the "Web" technologies. They'd have to negotiate and sign compliance agreements with a raft of DRM providers just to be fully standards-compliant and interoperable.

To be clear, we don't think all of these proposals will come to fruition. We appreciate that there's no great hunger for DRM at the W3C. Many W3C participants held their nose to accept even the EME draft, which was carefully drafted to position itself as far away from the taint of DRM as was possible for a standard solely intended to be used for DRM systems.

But the W3C has now accepted "content protection". By discarding the principle that users should be in charge of user agents, as well as the principle that all the information needed to interoperate with a standard should be open to all prospective implementers, they've opened the door for the many rightsholders who would like the same control for themselves.

The W3C is now in an unenviable position. It can either limit its "content protection" efforts to the aims of a privileged few, like Hollywood. Or it can let a thousand "content protection systems" bloom, and allow any rightsholder group to chip away at software interoperability and users' control.

EFF is still a W3C member, and we'll do our best to work with other organizations within and without the consortium to help it fight off the worse consequences of accepting DRM. But it's not easy to defend a king who has already invited its attackers across his moat.

Still, even if the W3C has made the wrong decision, that doesn't mean the Web will. The W3C has parted ways with the wider Web before: in the early 2000s, its choice to promote XHTML (an unpopular and restrictive variant of HTML) as the future led to Mozilla, Apple and Opera forming the independent WHATWG. It was WHATWG's vision of a dynamic, application-oriented Web that won—so decisively, in fact, that the W3C later re-adopted it and made it the W3C's own HTML5 deliverable.

Recently, WHATWG has diplomatically parted with the W3C again. Its "HTML Living Standard" continues to be developed in tandem with the W3C's version of the HTML standard, and does not contain EME or any other such DRM-enabling proposals.

By contrast, W3C has now put its weight behind a restrictive future: let's call it "DRM-HTML". Others have certainly bet against open, interoperable standards and user control before. It's just surprising and disappointing to see the W3C and its Director gamble against the precedent of their own success, as well as the fears and consciences of so many of their colleagues.]]></description>
<dc:subject>drm html5 eff privacy legal copyright w3c standards html</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:5686682474f4/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:drm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:html5"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:eff"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:privacy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:legal"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:copyright"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:w3c"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:html"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://arstechnica.com/information-technology/2013/12/500mbps-internet-over-phone-lines-might-solve-fibers-last-mile-problem/">
    <title>500Mbps Internet over phone lines might solve fiber’s “last mile” problem</title>
    <dc:date>2013-12-12T19:25:04+00:00</dc:date>
    <link>http://arstechnica.com/information-technology/2013/12/500mbps-internet-over-phone-lines-might-solve-fibers-last-mile-problem/</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[The International Telecommunication Union (ITU) yesterday gave initial approval to a data transmission standard capable of 500Mbps speeds in both directions over existing telephone wires. The new standard, G.fast, can be used on phone lines within 250 meters of a distribution point, benefiting fiber-to-the-node deployments. With telcos not having to build fiber on the proverbial “last mile,” this could bring fiber-like speeds to many more homes.

The ITU describes G.fast as providing speeds up to 1Gbps over existing phone lines, but telecom equipment vendor Huawei notes that “Reports of G.fast bandwidth exceeding 1 Gbit/s generally refer to the sum of the upstream and downstream bandwidths,” or 500Mbps in each direction. And although G.fast is usable within 250 meters of a node, the highest speeds aren’t likely to be available on the top end of that range.

“G.fast is intended for typical applications of 500 megabits per second (Mbps) speeds at 100 meters or less,” Alcatel-Lucent said in July of this year. “In recent demonstrations and under laboratory conditions, Alcatel-Lucent achieved 1.3 Gbps over 70 meters, making G.fast a promising option for service providers to complement their fiber deployments.”

Alcatel-Lucent’s 1.3Gbps speed was achieved on the downstream path alone, according to Informa telecom analyst Tony Brown. That won’t be typical, but actual speeds should be a big improvement for many people. “[O]ne big advantage of G.Fast is that it allows operators to offer symmetrical speeds—so with 1Gbps of bandwidth an operator could offer 500Mbps downstream AND upstream to achieve—something other copper acceleration technologies cannot do,” Brown wrote.

“G.fast, within the fibre to the distribution point (FTTdp) architecture, combines the best aspects of fibre and ADSL2,” the ITU said. “Consumers will have an over-the-counter solution, self-installed without a technician’s assistance, but equipped to support bandwidth-intensive services such as Ultra-HD ‘4K’ or ‘8K’ streaming and IPTV, advanced cloud-based storage, and communication via HD video.”

To follow on yesterday’s vote, “Chip manufacturers will now scale-up G.fast chip design and testing efforts, feeding results of this work into ITU-T Study Group 15 in the interests of finalizing G.fast as early as April 2014,” the ITU said. The ITU says it will specify methods to prevent interference with FM radio and other broadcast services.

G.fast operates on higher frequencies than DSL. “VDSL2 currently works on 17 MHz or 30 MHz, while G.fast will work on 106 MHz or even 212 MHz,” Huawei says. The company notes that higher frequencies do result in “shorter transmission distances, higher costs, and greater power consumption.” 

Like VDSL2, “G.fast performance is affected by crosstalk between lines.” But because of the higher frequency, crosstalk will cause bigger problems for G.fast than VDSL2. “Without the vectoring noise cancellation process, G.fast rates are severely degraded,” Huawei said. “Therefore, G.fast must use a more advanced vectoring technology to cancel crosstalk between lines.”

G.fast could be a boon to Internet services such as AT&T’s U-verse, which typically brings fiber to the node (except when AT&T builds all the way to homes). AT&T says its nodes are typically 2,000 to 3,000 feet from homes, so more buildout would still be required to reach 500Mbps bandwidth.

The ITU said G.fast “is designed to coexist with VDSL2, enabling service providers to play to the strengths of each standard in different environments; switching customers between G.fast and VDSL2 in line with dynamic business models. The standard will complement FTTH [fiber-to-the-home] strategies, serving the many scenarios where G.fast is more cost-efficient than FTTH.”

Huawei has been working on developing G.fast since 2010 and says it had a prototype delivering gigabit (combined upstream and downstream) speeds over 100 meters of copper by 2011. Huawei announced two months ago that BT is trialing its G.fast technology. Alcatel-Lucent and Telekom Austria Group announced a similar trial in July of this year.

The ITU’s G.fast group has seen participation “from a large number of operators, chipset manufacturers, and equipment suppliers,” Huawei said. D-Link says that it’s “working today with selective Operators to achieve FTTdp deployment and trials” using G.fast.

A new company, called Sckipio, was founded last year to build G.fast chips, on the belief that it will become a booming business because it’s more cost-effective than fiber-to-the-home. “[A]s fiber nodes move closer to the home, it is becoming obvious the cost to deploy fiber for the last 250 meters is prohibitive,” Sckipio says. “According to some accounts, over 80 percent of the cost to deploy fiber is based upon this last segment. This is due to the high cost of trenching and installation for fiber optics. In fact, most fiber to the home deployments will take longer than 10 years to break even.”

Sckipio Marketing VP Michael Weissman told The Register that field trials should be followed by live deployments in late 2014 or 2015. Other estimates have deployments expected for 2016.]]></description>
<dc:subject>internet technology standards telecommunications</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:5bbfa8c7fdcf/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:technology"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:telecommunications"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.ietf.org/mail-archive/web/ietf/current/msg83857.html">
    <title>IETF88 Technical Plenary hums</title>
    <dc:date>2013-11-07T02:28:02+00:00</dc:date>
    <link>http://www.ietf.org/mail-archive/web/ietf/current/msg83857.html</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[At the end of the IETF88 Technical Plenary, there were five hums.  This note is to provide the text of the hums and the community response.  The people in the room were asked to hum for YES if they agreed with the statement and hum for NO if they disagreed with the statement.

1.  The IETF is willing to respond to the pervasive surveillance attack?

    Overwhelming YES.  Silence for NO.

2. Pervasive surveillance is an attack, and the IETF needs to adjust our threat model to consider it when developing standards track specifications.

    Very strong YES.  Silence for NO.

3. The IETF should include encryption, even outside authentication, where practical.

    Strong YES.  Silence for NO.

4.  The IETF should strive for end-to-end encryption, even when there are middleboxes in the path.

    Mixed response, but more YES than NO.

5.  Many insecure protocols are used in the Internet today, and the IETF should create a secure alternative for the popular ones.

    Mostly YES, but some NO.

Russ]]></description>
<dc:subject>internet security privacy legal surveillance usa government regulation standards</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:3d5fea1cdeb4/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:privacy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:legal"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:surveillance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:usa"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:government"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:regulation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://arstechnica.com/security/2013/11/to-restore-credibility-nist-will-audit-its-standards-development-process/">
    <title>To restore credibility, NIST will audit its standards development process</title>
    <dc:date>2013-11-03T02:26:06+00:00</dc:date>
    <link>http://arstechnica.com/security/2013/11/to-restore-credibility-nist-will-audit-its-standards-development-process/</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[On Friday, the National Institute of Standards and Technology (NIST), which sets many of the standards that cryptographers use to create robust security systems, gave notice that it would formally review its standards development process. This comes about two months after a report from the New York Times that the National Security Agency may have included a backdoor in an algorithm called Dual EC_DRBG, which is used to create a widely-adopted, NIST-approved encryption standard.

The fallout from the September New York Times report, which was based on internal memos leaked by former NSA contractor Edward Snowden, made many security experts wary of NIST and its standards. At the time of the report, NIST issued a statement saying that it would reopen its public vetting process for the encryption standard that was in question. “We want to assure the IT cybersecurity community that the transparent, public process used to rigorously vet our standards is still in place,” a memo from the Institute read.

Now, NIST is apparently going a step further. In its latest November 1 statement, the organization promised to do a full audit of its standards development process. “Recent news reports about leaked classified documents have caused concern from the cryptographic community about the security of NIST cryptographic standards and guidelines,” the statement read.

In order to restore that lost confidence, NIST plans to compile its “goals and objectives, principles of operation, processes for identifying cryptographic algorithms for standardization, methods for reviewing and resolving public comments, and other important procedures necessary for a rigorous process.” It will then make its process available for review by both the public and an (as yet unnamed) independent organization.

”Based on the public comments and independent review, we will update our process as necessary to make sure it meets our goals for openness and transparency, and leads to the most secure, trustworthy guidance practicable,” NIST stated. It also promised to reevaluate its current cryptographic standards in light of its audit of the standards development process.]]></description>
<dc:subject>science NIST standards technology encryption nsa government cryptography</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:95fd4e9dd57f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:science"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:NIST"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:technology"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:encryption"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:nsa"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:government"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:cryptography"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blog.mozilla.org/blog/2013/10/30/video-interoperability-on-the-web-gets-a-boost-from-ciscos-h-264-codec/">
    <title>Video Interoperability on the Web Gets a Boost From Cisco’s H.264 Codec</title>
    <dc:date>2013-11-01T06:29:39+00:00</dc:date>
    <link>https://blog.mozilla.org/blog/2013/10/30/video-interoperability-on-the-web-gets-a-boost-from-ciscos-h-264-codec/</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[As I noted last year, one of the biggest challenges to open source software has been the patent status of video codecs. The most popular codec, H.264, is patent-encumbered and licensed by MPEG LA, under terms that prevent distributing it with open source products including Firefox. Cisco has announced today that they are going to release a gratis, high quality, open source H.264 implementation — along with gratis binary modules compiled from that source and hosted by Cisco for download. This move enables any open source project to incorporate Cisco’s H.264 module without paying MPEG LA license fees.

We are grateful for Cisco’s contribution, and we will add support for Cisco’s OpenH.264 binary modules to Firefox soon. These modules will be usable by downstream distributions of Firefox, as well as by any other project. In addition, we will work with Cisco to put the OpenH264 project on a sound footing and to ensure that it is governed well. We have already been collaborating very closely with Cisco on our WebRTC implementation, and we are excited to see Cisco deepening their commitment to the Open Web. Or, as Jonathan Rosenberg, Cisco CTO for Collaboration puts it,

Cisco has a long-standing history of supporting and integrating open standards, open formats and open source technologies as a model for delivering greater flexibility and interoperability to users. We look forward to collaborating with Mozilla to help bring H.264
to the Web and to the Internet.

Here’s a little more detail about how things are going to work: Cisco is going to release, under the BSD license, an H.264 stack, and build it into binary modules compiled for all popular or feasibly supportable platforms, which can be loaded into any application (including Firefox). The binary modules will be available for download from Cisco, and Cisco will pay for the patent license from the MPEG LA. Firefox will automatically download and install the appropriate binary module onto each user’s machine when needed, unless disabled in the user’s preferences.

Interoperability is critical on the Internet, and H.264 is the dominant video codec on the Web. The vast majority of HTML5 streaming video is encoded using H.264, and most softphones and videoconferencing systems use H.264. H.264 chipsets are widely available and can be found in most current smartphones, including many Firefox OS phones. Firefox already supports H.264 for the video element using platform codecs where they are available, but as noted in my last blog post on the topic, not all OSes ship with H.264 included. Provided we can get AAC audio decoders to match, using Cisco’s OpenH264 binary modules allows us to extend support to other platforms and uses of H.264.

While Cisco’s move helps add H.264 support to Firefox on all OSes, we will continue to support VP8, both for the HTML video element and for WebRTC. VP8 and H.264 are both good codecs for WebRTC, and we believe that at this point, users are best served by having both choices.

Of course, this is not a not a complete solution. In a perfect world, codecs, like other basic Internet technologies such as TCP/IP, HTTP, and HTML, would be fully open and free for anyone to modify, recompile, and redistribute without license agreements or fees. Mozilla is fully committed to working towards that better future. To that end, we are developing Daala, a fully open next generation codec. Daala is still under development, but our goal is to leapfrog H.265 and VP9, building a codec that will be both higher-quality and free of encumberances. Mozilla has assembled an engineering dream team to develop Daala, including Jean-Marc Valin, co-inventor of Opus, the new standard for audio encoding; Theora project lead Tim Terriberry; and recently Xiph co-founders Jack Moffitt, author of Icecast; and Monty Montgomery, the author of Ogg Vorbis.

Cullen Jennings, Cisco Fellow, Collaboration Group, says:

Cisco is very excited about the future of royalty free codecs. Daala is one of the most interesting ongoing technical developments in the codec space and we have been contributing to the project.

At Mozilla we always come back to the question of what’s good for the users and in this case that means interoperation of copious H.264 content across OSes and other browsers. We’ve already started looking at how to integrate the Cisco-hosted H.264 binary module, and we hope to have something ready for users in early 2014.

Watch this space for more exciting developments in WebRTC, Daala, and open web video.]]></description>
<dc:subject>cisco internet patent h.264 codec video standards software programming mozillafirefox</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:98f3701ef614/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:cisco"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:patent"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:h.264"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:codec"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:video"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:mozillafirefox"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.openh264.org/">
    <title>OpenH264</title>
    <dc:date>2013-10-30T15:16:21+00:00</dc:date>
    <link>http://www.openh264.org/</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[Cisco is announcing today that we will take our H.264 implementation, and open source it under BSD license terms. Development and maintenance will be overseen by a board from industry and the open source community. Furthermore, we will provide a binary form suitable for inclusion in applications across a number of different operating systems (Windows, MacOS, Linux x86, Linux ARM and Android ARM), and make this binary module available for download from the Internet. We will not pass on our MPEG-LA licensing costs for this module, and based on the current licensing environment, this will effectively make H.264 free for use on supported platforms.]]></description>
<dc:subject>h.264 cisco codec video standards patent legal business mpeg</dc:subject>
<dc:source>https://twitter.com/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:311cf454dc22/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:h.264"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:cisco"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:codec"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:video"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:patent"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:legal"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:business"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:mpeg"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.networkworld.com/news/2013/091913-ios7-multipath-273995.html">
    <title>Apple iOS 7 surprises as first with new multipath TCP connections - Network World</title>
    <dc:date>2013-09-22T22:13:48+00:00</dc:date>
    <link>http://www.networkworld.com/news/2013/091913-ios7-multipath-273995.html</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[Apple's iOS 7 is the first large-scale use of a newly-minted Internet protocol, called multipath TCP. It lets computers send and receive data across different network paths and interfaces at the same time, such as Ethernet, Wi-Fi and 3G.

There is evidence [see screen shot below that Apple is using the new protocol for iOS 7 device links to Siri, Apple’s cloud-based, natural language voice command and navigation service. MPTCP is intended to create more robust connections, resistant to path failures, and to improve performance, especially for delay-sensitive applications such as voice. It’s part of an ambitious, global effort to transform the Internet from a mainly data network today to one that supports far more demanding applications such as telephony and IP TV.]]></description>
<dc:subject>internet telecommunications standards software engineering</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:56050d9d84dd/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:telecommunications"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:engineering"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://bits.blogs.nytimes.com/2013/09/10/government-announces-steps-to-restore-confidence-on-encryption-standards/">
    <title>Government Announces Steps to Restore Confidence on Encryption Standards</title>
    <dc:date>2013-09-11T04:36:35+00:00</dc:date>
    <link>http://bits.blogs.nytimes.com/2013/09/10/government-announces-steps-to-restore-confidence-on-encryption-standards/</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[The federal agency charged with recommending cybersecurity standards said Tuesday that it would reopen the public vetting process for an encryption standard, after reports that the National Security Agency had written the standard and could break it.

“We want to assure the I.T. cybersecurity community that the transparent, public process used to rigorously vet our standards is still in place,” The National Institute of Standards and Technology said in a public statement. “N.I.S.T. would not deliberately weaken a cryptographic standard.”

The announcement followed reports published by The New York Times, The Guardian and ProPublica last Thursday about the N.S.A.’s success in foiling much of the encryption that protects vast amounts of information on the Web. The Times reported that as part of its efforts, the N.S.A. had inserted a back door into a 2006 standard adopted by N.I.S.T. and later by the International Organization for Standardization, which counts 163 countries as members.

For encryption to be secure, the system must generate secret prime numbers randomly. That random number generation process — which is based on mathematical algorithms — makes it practically impossible for an attacker, or intelligence agency, to predict the scrambling protocols that would allow it to unscramble an encrypted message.

But internal memos leaked by a former N.S.A. contractor, Edward Snowden, suggest that the N.S.A. generated one of the random number generators used in a 2006 N.I.S.T. standard — called the Dual EC DRBG standard — which contains a back door for the N.S.A. In publishing the standard, N.I.S.T. acknowledged “contributions” from N.S.A., but not primary authorship.

Internal N.S.A. memos describe how the agency subsequently worked behind the scenes to push the same standard on the International Organization for Standardization. “The road to developing this standard was smooth once the journey began,” one memo noted. “However, beginning the journey was a challenge in finesse.”

At the time, Canada’s Communications Security Establishment ran the standards process for the international organization, but classified documents describe how ultimately the N.S.A. seized control. “After some behind-the-scenes finessing with the head of the Canadian national delegation and with C.S.E., the stage was set for N.S.A. to submit a rewrite of the draft,” the memo notes. “Eventually, N.S.A. became the sole editor.”

Cryptographers have long had mixed feelings about N.I.S.T.’s close relationship with the N.S.A., but many said last week’s revelations had confirmed their worst fears and eroded their confidence in N.I.S.T. standards entirely.

“We’ll have to re-evaluate that relationship,” Matthew D. Green, a cryptography researcher at Johns Hopkins University, wrote in a blog post Thursday. “Trust has been violated.”

(Mr. Green said on Twitter Monday that Johns Hopkins asked him to remove that blog post.  He was allowed to reinstate it hours later after the university realized the content was based on public news reports. The university later apologized.)

On Tuesday, N.I.S.T. attributed the allegations to confusion and noted that it was required, by statute, to consult with the N.S.A.

“There has been some confusion about the standards development process and the role of different organizations in it,” the agency’s statement read. “N.I.S.T. has a long history of extensive collaboration with the world’s cryptography experts to support robust encryption. The National Security Agency (N.S.A.) participates in the N.I.S.T. cryptography process because of its recognized expertise. N.I.S.T. is also required by statute to consult with the N.S.A.”

The agency said that because of cryptographers’ concerns, it would reopen the public comment period for three publications — Special Publication 800-90A and drafts of Special Publications 800-90B and 800-90C — which all use the random number generator in question.

“If vulnerabilities are found in these or any other N.I.S.T. standard, we will work with the cryptographic community to address them as quickly as possible,” the agency’s statement said.

“I know from firsthand communications that a number of people at N.I.S.T. feel betrayed by their colleagues at the N.S.A.,” Mr. Green said in an interview Tuesday. “Reopening the standard is the first step in fixing that betrayal and restoring confidence in N.I.S.T.”]]></description>
<dc:subject>nsa nist cryptography encryption privacy legal standards</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:9662bc747738/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:nsa"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:nist"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:cryptography"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:encryption"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:privacy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:legal"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://arstechnica.com/business/2013/08/crypto-experts-blast-german-e-mail-providers-secure-data-storage-claim/">
    <title>Crypto experts blast German e-mail providers’ “secure data storage” claim</title>
    <dc:date>2013-08-10T22:30:19+00:00</dc:date>
    <link>http://arstechnica.com/business/2013/08/crypto-experts-blast-german-e-mail-providers-secure-data-storage-claim/</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[In the wake of the shutdown of two secure e-mail providers in the United States, three major German e-mail providers have banded together to say that they’re stepping forward to fill the gap. There’s just one problem: the three companies only provide security for e-mail in transit (in the form of SMTP TLS) and not actual secure data storage.

GMX, T-Online (a division of Deutsche Telekom), and Web.de—which serve two-thirds of German e-mail users—announced on Friday that data would be stored in Germany and the intiative would “automatically encrypt data over all transmission paths and offer peace of mind that data are handled in compliance with German data privacy laws.” Starting immediately, users who use these e-mail services in-browser will have SMTP TLS enabled, and starting next year, these three e-mail providers will refuse to send all e-mails that do not have it enabled.

“Germans are deeply unsettled by the latest reports on the potential interception of communication data,” said René Obermann, CEO of Deutsche Telekom, in a statement. “Our initiative is designed to counteract this concern and make e-mail communication throughout Germany more secure in general. Protection of the private sphere is a valuable commodity.”

These companies have dubbed this effort “E-mail made in Germany,” and tout “secure data storage in Germany as a reputable location.” In practice, that appears (Google Translate) to simply mean that starting in 2014, these providers will “only transport SSL-encrypted e-mails to ensure that data traffic over all of their transmission paths is secure.”

Germany has notoriously strong data protection laws—likely the strongest in the world. But those laws do have law enforcement exceptions for security agencies, like the BND, Germany’s equivalent to the National Security Agency. The BND likely can easily access e-mails stored unencrypted on German servers with little legal or technical interference. Clearly, forcing users (particularly less tech-savvy ones) to use SMTP TLS provides a modicum of better protection for data in transit, but it’s hardly anywhere close to improved security for stored data.]]></description>
<dc:subject>cryptography germany email security hacking privacy information ssl smtp technology standards</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:6cfbe86fc4ce/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:cryptography"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:germany"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:email"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:hacking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:privacy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:information"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:ssl"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:smtp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:technology"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.washingtonpost.com/blogs/wonkblog/wp/2013/08/07/should-legal-codes-be-copyrighted-lets-sue-to-find-out/">
    <title>Should legal codes be copyrighted? Let’s sue to find out!</title>
    <dc:date>2013-08-08T05:37:06+00:00</dc:date>
    <link>http://www.washingtonpost.com/blogs/wonkblog/wp/2013/08/07/should-legal-codes-be-copyrighted-lets-sue-to-find-out/</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[Whenever you build a building, most states require you to obey thick books full of standards for all the specs that make it safe and sturdy. Those standards are developed by professional societies and trade associations, like ASTM International, whose members are contractors and equipment manufacturers and other technical experts. State and local governments then incorporate them into building codes, which have the force of law. But the standards aren’t usually replicated in full — you have to buy them from the standards development organizations, which derive most of their operating revenue from sales.

Wait a second: Why should you have to pay to read the laws you have to obey? Usually, they’re not copyrightable. For a couple years now, open government activist Carl Malamud has been posting building codes on his Web site Public.Resource.org, deliberately undermining that revenue stream. In the spring, the Sheet Metal and Air Conditioning Contractors National Association got fed up, and asked him to stop. With the help of the Electronic Frontier Foundation, Malamud sued for relief, and a few months later got a judgment in which SMACNA basically agreed to let him post a few of their older standards online.

Well, the battle just kicked up a notch. Not satisfied with that half-measure, three of the country’s biggest standards development organizations — ASTM International, the air quality group ASHRAE and the National Fire Protection Association — sued Public.Resource.org in U.S. District Court for the District of Columbia for copyright infringement. How the case proceeds could have far-reaching implications for the viability of institutions that write the rules, as well as the rights the public has to read them.

The 51-page complaint is interesting reading, going through the history of the public standards movement over the past century. It’s not just building codes — there are also standards for protective clothing, manufacturing, chemical ingredients, you name it. It’s truly a story of international progress on safety and health, and has been encouraged by governments as an efficient way to channel the knowledge of industry into detailed laws that bureaucrats wouldn’t know how to write. And it takes a long time: Most of ASTM’s standards are on a five-year development timeline, requiring the participation of hundreds of subject-matter experts. The standards development organizations contend that they wouldn’t be able to do all that work without maintaining an exclusive copyright on the end product.

The cost isn’t prohibitive; price tags on digital and printed standards usually fall between $25 and $125. And all three plaintiffs have made copies of their standards available free online in read-only format.  But Malamud argues that’s not enough: Independent developers should be able to make even more user-friendly editions of the standards, and they should be totally free. Besides, he told me during the SMACNA proceedings, many other industries have found different ways of making money in the Internet age. Why shouldn’t the one that writes rules?

There are various pieces of administrative precedent and case law in different courts that support either side. Essentially, though, it’s a question of principle vs. practicality: Code is law, Malamud says, and it’s owned by the public. But good code is also expensive, the standards development groups maintain, and charging for copies is the least bad way to pay for it. The complaint reads:

Depriving Plaintiffs and other SDOs of this important, independent source of revenue would substantially diminish the quality of future standards, including those in the health and safety areas which are most suitable for use by government entities. To the extent that Plaintiffs were able to continue their standards development activities without copyright revenues, they could be forced to rely on funding from interested parties, or to charge fees to participate in the process of developing the standards, which would inhibit the participation of small businesses, consumers, academics, and other important stakeholders in the standards development process.

Most copyright disputes involve some question of whether creators should be compensated for their work, thereby fostering more of it. But this one is unusual in running up against the fundamental right to ownership of the laws you have to obey. The court will have a tricky job in balancing the two.]]></description>
<dc:subject>legal lawsuit copyright politics standards regulation government business</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:706fa5ca42c3/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:legal"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:lawsuit"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:copyright"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:politics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:regulation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:government"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:business"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.guardian.co.uk/books/2012/jun/22/ray-bradbury-internet-error-message-451">
    <title>Call for Ray Bradbury to be honoured with internet error message | Books | guardian.co.uk</title>
    <dc:date>2013-06-22T23:25:35+00:00</dc:date>
    <link>http://www.guardian.co.uk/books/2012/jun/22/ray-bradbury-internet-error-message-451</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[Tim Bray, a fan of Bradbury's writing, is recommending to the Internet Engineering Task Force, which governs such choices, that when access to a website is denied for legal reasons the user is given the status code 451.

There are already a host of HTTP status codes, from the common 404 Not Found to 504 Gateway Timeout. The 451 idea follows a blogpost from Terence Eden, who found that his ISP had been ordered to censor the Pirate Bay when he was given an HTTP 403 Forbidden message, meaning that "the server understood the request, but is refusing to fulfil it". In fact, Eden writes on his blog, it was not Pirate Bay that was preventing access but the government, after Britain's high court issued an order to ISPs to block access to the filesharing site in April, so the response was "factually incorrect", and a new code is needed to indicate "censorship".

451, Bray believes, would work nicely, as it would provide a tribute to Bradbury as well as reminding users of the dystopian future predicted by the science fiction author. Bradbury died earlier this month, leaving behind an oeuvre numbering hundreds of short stories as well as the novels Something Wicked This Way Comes, The Martian Chronicles and Fahrenheit 451, which tells of a world where books are banned and burned and fireman don't put fires out but start them.]]></description>
<dc:subject>legal standards webdevelopment software privacy</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:86eaa5be0c70/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:legal"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:webdevelopment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:privacy"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://googledevelopers.blogspot.com/2013/06/making-googles-caldav-and-carddav-apis.html">
    <title>Making Google’s CalDAV and CardDAV APIs available for everyone - Google Developers Blog</title>
    <dc:date>2013-06-06T00:04:51+00:00</dc:date>
    <link>http://googledevelopers.blogspot.com/2013/06/making-googles-caldav-and-carddav-apis.html</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[In March we announced that CalDAV, an open standard for accessing calendar data across the web, would become a partner-only API because it appeared that almost all the API usage was driven by a few large developers. Since that announcement, we received many requests for access to CalDAV, giving us a better understanding of developers’ use cases and causing us to revisit that decision. In response to those requests, we are keeping the CalDAV API public. And in the spirit of openness, today we’re also making CardDAV – an open standard for accessing contact information across the web – available to everyone for the first time.

Both of these APIs are getting other updates as well:
Integration with the Google APIs Console. To start using CalDAV or CardDAV in your project, just enable it in the Console.
OAuth 2.0 authentication.
In addition, the CalDAV API now has a new endpoint: 
https://apidata.googleusercontent.com/caldav/v2]]></description>
<dc:subject>google api calendar GoogleCalendar software standards</dc:subject>
<dc:source>https://twitter.com/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:f37cdfc83952/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:calendar"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:GoogleCalendar"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://plus.google.com/116276248303121270590/posts/ggNwh9eLYWu">
    <title>Ralph Meijer - Google+ - Google defends dropping chat federation with inaccurate and…</title>
    <dc:date>2013-05-26T22:05:10+00:00</dc:date>
    <link>https://plus.google.com/116276248303121270590/posts/ggNwh9eLYWu</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[Google defends dropping chat federation with inaccurate and misinformed comments on the underlying protocol (XMPP) and blaming others for not joining.

Apparently, all the of the (good) sentiments behind the reasons for choosing XMPP as the protocol for Google Talk (https://developers.google.com/talk/open_communications) are no longer the driving force behind the decision making regarding its replacement Google Hangouts. All that talk about Client Choice, Service Choice and Platform Choice has been replaced with "if the other big players don't play, why should we?". So all those "thousands of other ISPs, universities, corporations and individual users" Google Talk used to federate with are no longer important.

On top of that, XMPP is blamed for not keeping up with the times:

"When XMPP was designed, smartphones and social networks didn't exist. Yet both trends essentially transformed communication but the standard remains unchanged. For example, mobile has several requirements around bandwidth and battery that are simply not part of the standard. And audio and video integration are not well defined," [a Google spokesperson] said.

This glances over the the fact that the X in XMPP stands for eXtensible, which still results in proposals for new protocol extensions every month. The XMPP Council, which I am currently serving on, watches over XMPP extensions in the XEP series (http://xmpp.org/xmpp-protocols/xmpp-extensions/) of the XMPP Standards Foundation. However, as XMPP is built on distributed technologies, everyone can invent their own protocol extensions in private, too. Something that Google should be fully aware of, as they have created a bunch of their own protocol additions, of which some are documented here: https://developers.google.com/talk/jep_extensions/extensions.

To go into even more depth, at various times, battery and bandwidth constraints for mobile use, have been discussed within the XMPP community at several times, since at least in 2008 and possibly before, with protocol proposals like Roster Versioning (XEP-0273, now part of RFC 6121), SIFT (XEP-0273) and background information on XMPP on Mobile Devices (XEP-0286).

Meanwhile, Google never participated in any of these discussions (https://plus.google.com/116276248303121270590/posts/V7LzUzj8R4D). Instead, they invented their own protocol (google:queue) for delayed presence delivery, much like but slightly simpler than what SIFT proposes. Had Google just participated, that protocol had likely been remade into a true XEP, for broader use in the community. This would have prevented, for example, Facebook, from also creating its own protocol for the same thing (https://bugs.freedesktop.org/show_bug.cgi?id=38943).

Of course none of these concerns for mobile are applicable for server federation. As far as I know, the Google Talk client on Android doesn't even use XMPP as the client-to-server protocol.

Google did cooperate with the XMPP community on standardizing Jingle (http://xmpp.org/extensions/xep-0166.html), a suite of protocol extensions for initiating and managing peer-to-peer media sessions between two XMPP entities. Ironically, this includes *audio and video integration", the very thing Google now says is not well defined, where Google was by far the largest driver behind it. And then Google Talk also never fully implemented the standardized protocol, causing other implementations to add custom, non-standard, workarounds.


Likewise, there are several proposals and even IETF drafts (for enhancing network security, including spam prevention, that Google didn't bother to implement. As an example, whereas as many other server operators would have wanted to start verifying X509 certificates on the TLS encrypted connections between servers, Google still doesn't check certificates or serve up properly signed ones themselves, allowing rogue servers to come in play.

The XMPP community even tried to accommodate some of the harder issues with serving up proper certificates for large numbers of hosted domains, explicitly including Google Talk, resulting in this IETF draft: http://tools.ietf.org/html/draft-saintandre-xmpp-dna-02.

From personal experience with building federated social networks on top of XMPP at Mediamatic Lab, I can name several other protocols that would benefit some of the newer features in Google Hangouts, including Publish-Subscribe (XEP-0060) and the related Personal Eventing Protocol (XEP-0163), that Google just ignored.

How didn't the standard (XMPP) change again?

As +Peter Saint-Andre was quoted in the TechHive article, we will just move forward.]]></description>
<dc:subject>google standards XMPP GoogleTalk</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:2aeec59a127e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:XMPP"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:GoogleTalk"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://nymag.com/daily/intelligencer/2013/05/gif-pronunciation-goff-webby-awards-wilhite.html">
    <title>Obama Tech Team on GIFs: Hard G! -- Daily Intelligencer</title>
    <dc:date>2013-05-22T23:57:23+00:00</dc:date>
    <link>http://nymag.com/daily/intelligencer/2013/05/gif-pronunciation-goff-webby-awards-wilhite.html</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[Nevertheless, the guests at the Webbys were decidedly mixed on the subject. David Karp, the suddenly extremely wealthy Tumblr founder, told Daily Intelligencer, "I usually do JIF. I usually try to do it properly. I don't really care; I won't correct anybody, but I usually go with JIF. Both are pretty weird words." But Karp did add that soft J makes no sense. "It's Graphic Interchange Format, and you would think it was a 'Gah' sound, a hard G," he admitted.
Randi Zuckerberg, the former Facebook executive and sister of Mark, told us she's always pronounced it with a hard G. But now that she's aware of Wilhite's soft-J proclamation, her "whole world has been turned upside down."
Nobody felt as strongly about the pronunciation of GIF, though, as the tech team from President Obama's e-campaign.
"Fuck that shit," Harper Reed, Obama's former chief technology officer, told us. "It is GIF."
"It is GIF all the way, and I do not care what the founder thinks," added Teddy Goff, the Obama campaign's digital director.
"If people think it's JIF," Michael Slaby, Obama's former chief integration and innovation officer, chimed in,"they're not very smart."
Goff argued that it really doesn't matter what Wilhite says. "Sometimes you create a monster and that monster takes on a life of its own, and the GIF has taken on a life of its own apart from the founder and his intent." Despite Wilhite's preference, a hard G is now correct.
"The Internet has decided," Slaby declared.]]></description>
<dc:subject>gif language communication standards technology</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:b2946241bbec/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:gif"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:language"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:communication"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:technology"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://bits.blogs.nytimes.com/2013/05/21/an-honor-for-the-creator-of-the-gif/">
    <title>GIF Creator, Steve Wilhite, Receives Lifetime Achievement Webby Award - NYTimes.com</title>
    <dc:date>2013-05-22T03:28:07+00:00</dc:date>
    <link>http://bits.blogs.nytimes.com/2013/05/21/an-honor-for-the-creator-of-the-gif/</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[Since retiring in 2001, Mr. Wilhite has led a quieter existence than his creation. He goes on RV trips. He built a house in the country with a lot of lawn to mow. He dabbles in color photography and Java programming. He uses e-mail and Facebook to keep up with family.

He is proud of the GIF, but remains annoyed that there is still any debate over the pronunciation of the format.

“The Oxford English Dictionary accepts both pronunciations,” Mr. Wilhite said. “They are wrong. It is a soft ‘G,’ pronounced ‘jif.’ End of story.”]]></description>
<dc:subject>gif standards programming</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:6dc85e5ada4f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:gif"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:programming"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://phil.ipal.org/tc.html">
    <title>True-Color GIF Example</title>
    <dc:date>2013-05-21T04:35:44+00:00</dc:date>
    <link>http://phil.ipal.org/tc.html</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[While using more than 256 colors in GIF is in most cases a bad practice, and should be limited to certain technical cases where extreme size can be tolerated, a statement that the GIF image file format is limited to 256 colors is simply false.]]></description>
<dc:subject>gif compression graphics software standards</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:f336ba49f5ea/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:gif"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:compression"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:graphics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://eschnou.com/entry/whats-next-google--dropping-smtp-support--62-24930.html">
    <title>Laurent Eschenauer | What's next Google? Dropping SMTP support?</title>
    <dc:date>2013-05-17T00:45:32+00:00</dc:date>
    <link>http://eschnou.com/entry/whats-next-google--dropping-smtp-support--62-24930.html</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[A company that was the cheerleader of the open web is rapidly turning its back on every single open standard they once championned. Their latest move, announced yesterday at Google I/O, appears to be closing XMPP server-to-server federation. 
 
It is only a natural next step in a process started a while ago. Here is a quick, and probably not exhaustive recap:
Google+ has no open RSS output, hence no PuSH support, no write API, in fact it has absolutely nothing open
Google Reader is scrapped, along with RSS support within Chrome
WebDav for Google Calendar is dropped in favor of their proprietary API
XMPP is dropped, while 3 years ago it was at the core of their Wave efforts
If they continue with this trend, then why not drop support for SMTP (and thus email federation)? When @aaronparecki.com posted the following picture a few months ago, I smiled. Today I wonder if this could actually ever happen.]]></description>
<dc:subject>xmpp standards webdevelopment google server rss email smtp</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:eb7b10c7d510/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:xmpp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:webdevelopment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:server"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:rss"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:email"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:smtp"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://techblog.netflix.com/2013/04/html5-video-at-netflix.html">
    <title>The Netflix Tech Blog: HTML5 Video at Netflix</title>
    <dc:date>2013-04-16T06:56:29+00:00</dc:date>
    <link>http://techblog.netflix.com/2013/04/html5-video-at-netflix.html</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[We've been working with Google to implement support for the HTML5 Premium Video Extensions in the Chrome browser, and we've just started using this technology on the Samsung ARM-Based Chromebook. Our player on this Chromebook device uses the Media Source Extensions and Encrypted Media Extensions to adaptively stream protected content.  WebCrypto hasn't been implemented in Chrome yet, so we're using a Netflix-developed PPAPI (Pepper Plugin API) plugin which provides these cryptographic operations for now.  We will remove this last remaining browser plugin as soon as WebCrypto is available directly in the Chrome browser.  At that point, we can begin testing our new HTML5 video player on Windows and OS X.

 We're excited about the future of premium video playback on the web, and we look forward to the day that these Premium Video Extensions are implemented in all browsers!]]></description>
<dc:subject>netflix html5 html drm video software googlechrome internet browser standards w3c</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:e6d38f72acf4/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:netflix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:html5"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:html"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:drm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:video"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:googlechrome"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:browser"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:w3c"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://ejohn.org/blog/webkit-is-the-jquery-of-browser-engines/">
    <title>John Resig - WebKit is the jQuery of Browser Engines</title>
    <dc:date>2013-03-18T04:15:39+00:00</dc:date>
    <link>http://ejohn.org/blog/webkit-is-the-jquery-of-browser-engines/</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[In the case of JavaScript libraries virtually everyone has standardized upon jQuery at this point. This didn’t result in stagnation, which was a major concern, instead it’s resulted in a number of interesting and hyper-popular second-tier frameworks which build upon jQuery, such as: Twitter Bootstrap, HTML5 Boilerplate, and Backbone.js.]]></description>
<dc:subject>webkit browser standards opera googlechrome mozillafirefox jquery internet software</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:b92c3b298cbe/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:webkit"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:browser"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:opera"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:googlechrome"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:mozillafirefox"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:jquery"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:software"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://bitsplitting.org/2013/03/13/netnewswire-cloud/">
    <title>NetNewsWire Cloud | Bitsplitting.org</title>
    <dc:date>2013-03-15T03:17:08+00:00</dc:date>
    <link>http://bitsplitting.org/2013/03/13/netnewswire-cloud/</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[At this point Black Pixel need to ask themselves one question: are we interested in RSS, or aren’t we? They acquired NetNewsWire because they no doubt loved it and had become reliant on using it themselves. They wanted to see it live on and prosper. But did they expect to be put in a position where they are faced with the challenge/opportunity of becoming the world’s leading RSS services company? Probably not.

My understanding is that the slowness in developing and releasing a successor to NetNewsWire 3 is largely in coming to terms with the challenges of working around Google Reader issues. With Google Reader out of the picture, not just for NetNewsWire, but for everybody, a new future for RSS syncing arises: NetNewsWire Cloud.

By implementing a suitable syncing API for RSS, and implementing a reasonably useful web interface, Black Pixel could establish NetNewsWire Cloud as the de facto replacement for Google Reader. Charging a reasonable fee for this service would likely inoculate it from the risk of sudden termination, and it would doubly serve to provide the very service that NetNewsWire needs to thrive on the desktop and on iOS.

Don’t get me wrong: this is no small order. I would not fault Black Pixel one iota for looking at the challenge and deciding to take a pass. But if they are truly passionate about RSS, this is their moment. This is the time when accepting the impossible challenge will reap the greatest reward.]]></description>
<dc:subject>rss GoogleReader software standards</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:f2c269321436/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:rss"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:GoogleReader"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://inessential.com/2013/03/14/why_i_love_rss_and_you_do_too">
    <title>inessential.com: Why I love RSS and You Do Too</title>
    <dc:date>2013-03-15T03:07:27+00:00</dc:date>
    <link>http://inessential.com/2013/03/14/why_i_love_rss_and_you_do_too</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[RSS is plumbing. It’s used all over the place but you don’t notice it. Which is cool.

But here’s why it’s great plumbing:]]></description>
<dc:subject>rss software internet standards programming</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:c5af5883e309/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:rss"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:programming"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://css-tricks.com/using-svg/">
    <title>Using SVG | CSS-Tricks</title>
    <dc:date>2013-03-06T05:04:04+00:00</dc:date>
    <link>http://css-tricks.com/using-svg/</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[SVG is an image format for vector graphics. It literally means Scalable Vector Graphics. Basically, what you work with in Adobe Illustrator. You can use SVG on the web pretty easily, but there is plenty you should know.


Why use SVG at all?
Small file sizes that compress well
Scales to any size without losing clarity (except very tiny)
Looks great on retina displays
Design control like interactivity and filters]]></description>
<dc:subject>svg webdesign webdevelopment software programming images standards browser</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:d294dff11f5e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:svg"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:webdesign"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:webdevelopment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:images"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:browser"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://paulirish.com/2013/webkit-for-developers/">
    <title>WebKit for Developers - Paul Irish</title>
    <dc:date>2013-03-05T02:07:46+00:00</dc:date>
    <link>http://paulirish.com/2013/webkit-for-developers/</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[First, let’s review the commonalities shared by all WebKit ports.

You know it’s funny. I tried writing this a few times. 
Each time I got corrected by Chrome team members, as you’ll see…
So first, WebKit parses HTML the same way. Well, except Chromium is the only port so far to enable threaded HTML parsing support.
… Okay, but once parsed, the DOM tree is constructed the same. Well, actually Shadow DOM is only turned on for the Chromium port, so DOM construction varies. Same goes for custom elements.
… Okay, well WebKit creates a window object and document object for everyone. True, though the properties and constructors it exposes can be conditional on the feature flags enabled.
… CSS parsing is the same, though. Slurping up your CSS and turning it into CSSOM’s pretty standard. Yeah, though Chrome accepts just the -webkit- prefix whereas Apple and other ports accept legacy prefixes like -khtml- and -apple-.
… Layout.. positioning? Those are the bread and butter. Same, right? Come on! Sub-pixel layout and saturated layout arithmetic is part of WebKit but differs from port to port.
Super.]]></description>
<dc:subject>webkit browser programming software standards css html safari googlechrome opera webdevelopment webdesign</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:73d72b93b7e9/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:webkit"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:browser"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:css"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:html"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:safari"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:googlechrome"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:opera"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:webdevelopment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:webdesign"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.netmagazine.com/opinions/jeffrey-zeldman-dream-standards-based-web">
    <title>Jeffrey Zeldman on the dream of a standards-based web | Opinion | .net magazine</title>
    <dc:date>2013-03-05T00:23:54+00:00</dc:date>
    <link>http://www.netmagazine.com/opinions/jeffrey-zeldman-dream-standards-based-web</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[By my lights, it succeeded around 2003, or maybe 2005. I was surprised that The Web Standards Project kept going as long as it did. From the outside, it sometimes seemed that nothing much was happening at The WaSP. But then again, this coincided with the period where IE6 stayed on the market for five or six years with no real changes, so it may have seemed like standards had been taken as far as they could be. From the outside, the persistence of webstandards.org was like the persistence of Dixieland music — a pleasant but fairly irrelevant reminder of the past!

Toward the end, over the past few years, I know there was some good educational work going on inside WaSP, although it wasn't always wildly apparent to the outside world, and I think many people's attention had moved on to other problems, such as multi-device design, which of course ironically recapitulates the whole standards struggle. (And standards are the answer in multi-device design as well. It's just that the standards that fully address some of the concerns of multi-device design are still evolving, like the devices—again, a perfect echo of the standards struggle during the years of the browser wars and Flash.) Once that educational piece got handed off to the W3C (finally!), it made sense for The WaSP to close up shop. And now they have.

A tip of the blue beanie to each and every person who helped make the dream of a standards-based web come true.]]></description>
<dc:subject>webdevelopment webdesign standards programming software css html</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:ffc4a767cefa/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:webdevelopment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:webdesign"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:css"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:html"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://modernwebaccessibility.com/blog/stop-fud-a11y">
    <title>Modern Web Accessibility - We have to stop FUD accessibility</title>
    <dc:date>2013-03-02T23:35:33+00:00</dc:date>
    <link>http://modernwebaccessibility.com/blog/stop-fud-a11y</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[I think a comment like this clarifies the situation and doesn’t add confusion, which is important. But the discussion goes on, and on, and on until very different use cases are described. Instead of encouragement, we casted doubt. Instead of creating positive vibes about the subject, we decided to tell them they are wrong, we told them to leave accessibility to the experts, please. Additionally we use complicated language that is only understood by insiders. I know that I’m not perfect in this regard, and I don’t want to reproach anyone here.
Accessibility people are enthusiastic about this topic. That’s good. But we’ll get more people to start with thinking about accessibility if we welcome them instead of alienate them. If we stop the FUD that we use to teach people about accessibility, no matter what:
Fear: “You will be sued if your site isn’t accessible.”
Uncertainty: “You will have missed something in the process anyway, see my totally different example here!”
Doubt: “You don’t have enough knowledge anyway.”
We need to be an open, welcoming community, providing solutions, not problems. I didn’t start out as someone who knows everything about web accessibility, and in some regards I’m still learning every day. I wouldn’t be here if I were alienated when I started out. We shouldn’t alienate people that are starting out. If they think about accessibility they should be welcomed, although their conclusions may be wrong or imprecise sometimes. That’s what learning is all about.]]></description>
<dc:subject>accessibility webdesign standards webdevelopment programming software</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:a639694566c3/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:accessibility"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:webdesign"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:webdevelopment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:software"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.webstandards.org/2013/03/01/our-work-here-is-done/">
    <title>Our Work Here is Done - The Web Standards Project</title>
    <dc:date>2013-03-02T23:33:53+00:00</dc:date>
    <link>http://www.webstandards.org/2013/03/01/our-work-here-is-done/</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[When The Web Standards Project (WaSP) formed in 1998, the web was the battleground in an ever-escalating war between two browser makers—Netscape and Microsoft—who were each taking turns “advancing” HTML to the point of collapse. You see, in an effort to one-up each other, the two browsers introduced new elements and new ways of manipulating web documents; this escalated to the point where their respective 4.0 versions were largely incompatible.
Realizing that this fragmentation would inevitably drive up the cost of building websites and ran the risk of denying users access to content and services they needed, Glenn Davis, George Olsen, and Jeffrey Zeldman co-founded WaSP and rallied an amazing group of web designers and developers to help them push back. The WaSP’s primary goal was getting browser makers to support the standards set forth by the World Wide Web Consortium (W3C).
In 2001, with the browser wars largely over, WaSP began to shift its focus. While some members continued to work with browser vendors on improving their standards support, others began working closely with software makers like Macromedia to improve the quality of code being authored in tools such as Dreamweaver. And others began the hard slog of educating web designers and developers about the importance of using web standards, culminating in the creation of WaSP InterAct, a web curriculum framework which is now overseen by the W3C.
Thanks to the hard work of countless WaSP members and supporters (like you), Tim Berners-Lee’s vision of the web as an open, accessible, and universal community is largely the reality. While there is still work to be done, the sting of the WaSP is no longer necessary. And so it is time for us to close down The Web Standards Project.]]></description>
<dc:subject>standards webdesign webdevelopment programming css browser internet</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:fc03efe9105e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:webdesign"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:webdevelopment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:css"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:browser"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:internet"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://xkcd.com/1179/">
    <title>xkcd: ISO 8601</title>
    <dc:date>2013-03-01T05:38:40+00:00</dc:date>
    <link>http://xkcd.com/1179/</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[Everyone trying to defend ISO 8601 using XKCD:  HELLO WHO IS THE AUTHORITY ON DASHES HERE? DASHES DOT COM, PEOPLE.]]></description>
<dc:subject>xkcd humor programming standards date time</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:ab027d8487d1/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:xkcd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:humor"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:date"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:time"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.w3.org/News/2012">
    <title>W3C News Archive: 2012 W3C</title>
    <dc:date>2012-12-18T15:41:41+00:00</dc:date>
    <link>http://www.w3.org/News/2012</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[W3C published today the complete definition of the HTML5 and Canvas 2D specifications. Though not yet W3C standards, these specifications are now feature complete, meaning businesses and developers have a stable target for implementation and planning. "As of today, businesses know what they can rely on for HTML5 in the coming years, and what their customers will demand," said Jeff Jaffe, W3C CEO. HTML5 is the cornerstone of the Open Web Platform, a full programming environment for cross-platform applications with access to device capabilities; video and animations; graphics; style, typography, and other tools for digital publishing; extensive network capabilities; and more. Read the full press release and W3C Member testimonials.
To reduce browser fragmentation and extend implementations to the full range of tools that consume and produce HTML, W3C now embarks on the stage of W3C standardization devoted to interoperability and testing. W3C is on schedule to finalize the HTML5 standard in 2014. In parallel, the W3C community will continue its work on next generation HTML features, including extensions to complement built-in HTML5 accessibility, responsive images, and adaptive streaming.
The HTML Working Group also published first drafts of HTML 5.1, HTML Canvas 2D Context, Level 2, and main element, providing an early view of the next round of standardization. Learn more About HTML.]]></description>
<dc:subject>w3c webdevelopment programming software standards html html5</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:f56208686556/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:w3c"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:webdevelopment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:html"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:html5"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.brucelawson.co.uk/2012/on-drm-in-html5/">
    <title>Bruce Lawson’s personal site  : On DRM in HTML5</title>
    <dc:date>2012-10-29T02:59:32+00:00</dc:date>
    <link>http://www.brucelawson.co.uk/2012/on-drm-in-html5/</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[I don’t want DRM. I dislike DRM. Not particularly because I think everything should be free (I don’t; I like receiving royalties for the best HTML5 book) but because I don’t think it works. The DRM graveyard: A brief history of digital rights management in music demonstrates this excellently.

However, “the suits” believe it does work, and aren’t willing to invest fully in the web stack until there is some attempt at DRM. That’s why Netflix, Google and Microsoft have proposed the Encrypted Media Extensions specification that’s being worked on by the Encrypted Media Task Force of the HTML Working Group at the W3C.]]></description>
<dc:subject>drm html html5 webdevelopment programming standards politics</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:f43fe9f91d96/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:drm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:html"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:html5"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:webdevelopment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:politics"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://dickhardt.org/2012/10/oauth-2-0/">
    <title>OAuth 2.0 :: RFCs 6749 and 6750</title>
    <dc:date>2012-10-14T04:58:41+00:00</dc:date>
    <link>http://dickhardt.org/2012/10/oauth-2-0/</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[OAuth 2.0 brings three important enhancements:

Simplicity: Client developers don’t need to do any cryptography or use a library to call OAuth 2.0 protected resources. The token can be passed on in the HTTP headers or as a URL parameter. While HTTP headers are preferred, a URL parameter is simpler and allows API exploration with a browser.
Token choice: implementers can use existing tokens that they already generate or consume. There are extension points so that the client can sign the token instead of it being a bearer token.
Separation of roles: if the token is self-contained, then the resource can verify the token independently of the authorization server. Resources don’t have to call back to the authorization server to verify the token on each call, enabling higher performance and separation of security  contexts.
Facebook, Google, Microsoft and Salesforce.com deployed early drafts of OAuth 2.0. I was at f8 when Facebook released the graph API which uses an early draft of OAuth 2.0. My colleagues and I were able to explore the API with our browsers sitting in the audience as the API was described.  With this work now complete, many of us can now focus on the next layers in the identity stack.]]></description>
<dc:subject>oauth oauth2 programming webdevelopment standards politics</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:ee362baa73e3/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:oauth"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:oauth2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:webdevelopment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:politics"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://my.opera.com/ODIN/blog/2012/10/08/introducing-device-stock-ua">
    <title>Opera Developer News - Introducing Device-Stock-UA: a new request header and proposal</title>
    <dc:date>2012-10-09T06:04:20+00:00</dc:date>
    <link>http://my.opera.com/ODIN/blog/2012/10/08/introducing-device-stock-ua</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[The goal of Device-Stock-UA is to help mobile site and application developers determine the device on which an HTTP client is running and adapt content accordingly. In mobile-centric web development, there’s a tension between the “One Web” philosophy and the realities of networks, protocols, device hardware, and user agent capabilities. We think that this header will lead to a better experience for Opera Mobile and Opera Mini users. And we think this can be useful for other user agents as well.

By embracing the “One Web” philosophy, developers can choose to build a single, responsive experience for a range of devices. Feature-detection and progressive enhancement ensure that any capable browser — not a single, dominant browser — has access to a given resource. Innovations such as meta viewport / @viewport and media queries allow us to streamline development and maintenance with a single code base. It’s the approach we advocate here at Opera.

But from a pragmatic point-of-view: data plans cost money and time. Serving fewer bytes helps companies contain bandwidth costs. While we’re looking forward to how the <picture> element will solve a number of these problems through declarative markup, we see a lot of developers choosing server-driven content negotiation: serving markup, CSS, JavaScript, and images based on the value of the User-Agent header.

Most widely-used APIs for server-driven content negotiation use the User-Agent header to infer browser and device capabilities. They assume a one-to-one relationship between a User-Agent string and a device. Opera Mobile and Mini use platform-specific user agent strings — as with desktop browsers — that do not include device information. For Opera Mobile in particular, this created site compatibility and content optimization issues. With no way to determine the device, Opera Mobile would be served the same small images and basic markup as feature phones. The X-OperaMini-Phone-UA header prevented Opera Mini from facing similar issues.]]></description>
<dc:subject>http standards webdevelopment webdesign politics</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:38de2c896119/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:webdevelopment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:webdesign"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:politics"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.theregister.co.uk/2012/07/28/oauth_editor_quits/">
    <title>OAuth 2.0 standard editor quits, takes name off spec • The Register</title>
    <dc:date>2012-07-29T01:21:16+00:00</dc:date>
    <link>http://www.theregister.co.uk/2012/07/28/oauth_editor_quits/</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[The lead author and editor of the OAuth 2.0 network authorization standard has stepped down from his role, withdrawn his name from the specification, and quit the working group, describing the current version of the spec as "the biggest professional disappointment of my career."

Eran Hammer, who helped create the OAuth 1.0 spec, has been editing the evolving 2.0 spec for the last three years. He resigned from his role in June but only went public with his reasons in a blog post on Thursday.

"At the end, I reached the conclusion that OAuth 2.0 is a bad protocol," Hammer writes. "WS-* bad. It is bad enough that I no longer want to be associated with it."

OAuth is an authorization protocol that allows users to share private resources stored on one site with applications running on another site, without handing out their usernames and passwords.

Its best-known proponent is Facebook, which has implemented a draft version of the OAuth 2.0 spec as part of its Open Graph set of social APIs. Other high-profile sites that have implemented OAuth to some degree include Google, Microsoft, Twitter, and Yahoo!

But according to Hammer, none of these implementations is likely to be interoperable with any of the others, because the OAuth 2.0 specification has grown too broad and it allows for almost unlimited extensibility.]]></description>
<dc:subject>standards programming software OAuth OAuth2 politics</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:716ee577982e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:OAuth"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:OAuth2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:politics"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://mikewest.org/2012/05/content-security-policy-feature-detection">
    <title>“Content Security Policy: Feature Detection” — Mike West</title>
    <dc:date>2012-05-04T05:41:34+00:00</dc:date>
    <link>https://mikewest.org/2012/05/content-security-policy-feature-detection</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[AngularJS’s latest release candidate is the first framework I’ve seen that cleanly supports a content security policy that restricts usage of eval(), new Function(), and the like. I’m thrilled to see this happening, and it’s a testament to the priority that the Angular developers place on security. CSP is quite simply one the best XSS-protection mechanisms available to developers these days in modern browsers. The more frameworks that hop on board, the faster sites can start adopting CSP, and the safer we’ll all be on the net.

All that said, the implementation isn’t as complete as it could be. Angular requires that the developer manually opt into CSP-friendly mode via the ng-csp directive. This is error-prone at best, and introduces complexity that would be better hidden away inside the framework. The Angular developers recognize this shortfall, and are explicitly requesting some sort of feature detection API that would allow frameworks to query the currently active policy to determine its boundaries, and fork their implementation accordingly.

This does seem like a great addition to the spec; I’d suggest the following implementation:

Add document.[prefix]contentSecurityPolicy as an object that exists in browsers that support CSP. This would enable trivial feature detection of CSP as a whole, which would enable frameworks to make intelligent decisions about how to proceed through the following use cases:]]></description>
<dc:subject>programming security JavaScript framework standards ContentSecurityPolicy browser politics</dc:subject>
<dc:source>https://instapaper.com/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:79b643e99556/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:JavaScript"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:framework"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:ContentSecurityPolicy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:browser"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:politics"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.webkitbits.com/post/22222538210/why-o-why">
    <title>Why O, why? Thoughts on Opera's Implementation of WebKit's Prefixes — WebKitbits</title>
    <dc:date>2012-05-04T05:37:03+00:00</dc:date>
    <link>http://www.webkitbits.com/post/22222538210/why-o-why</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[So there you go. We have real problems, for both the browser vendors and the users.

If it isn’t already clear, I’m not a fan of this solution, and we’ve finally arrived at the crux of why: It is a short-sighted solution, primarily for the benefit of browser vendors, which contradicts an existing standard.]]></description>
<dc:subject>Mozilla webkit opera MozillaFirefox programming software WebDesign WebDevelopment standards browser politics</dc:subject>
<dc:source>https://instapaper.com/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:ff428eb6df64/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:Mozilla"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:webkit"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:opera"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:MozillaFirefox"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:WebDesign"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:WebDevelopment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:browser"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:politics"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://mir.aculo.us/2012/04/24/5-things-they-told-you-not-to-use-in-javascript/">
    <title>mir.aculo.us JavaScript with Thomas Fuchs » Blog Archive » 5 things they told you not to use in JavaScript</title>
    <dc:date>2012-04-28T18:56:01+00:00</dc:date>
    <link>http://mir.aculo.us/2012/04/24/5-things-they-told-you-not-to-use-in-javascript/</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[My recommendation: learn the language, and use it to your liking; and don’t rely or blindly accept what any “wise elders” tell you. Try to do something new and crazy every day. You might not end up using the crazy, but it’s the best way to master JavaScript. Develop your own style that you are comfortable with. Experiment.]]></description>
<dc:subject>javascript programming software standards development politics</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:b1c09d9cb39a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:javascript"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:development"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:politics"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.blog.bt.com/viewpoint/index.php/2012/04/23/ipv6ietf/">
    <title>IPv6 is no longer considered optional (bt.com)</title>
    <dc:date>2012-04-27T05:09:42+00:00</dc:date>
    <link>http://www.blog.bt.com/viewpoint/index.php/2012/04/23/ipv6ietf/</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[Among the best practices recommended, the RFC stipulates that all new “IP implementations” must support IPv6

The Internet Engineering Task Force (IETF), which for all intents and purposes is the standards body of the Internet Protocol, has declared that “IPv6 is no longer considered optional.” In RFC 6540 officially published the other week as an Internet Best Current Practice, the IETF cites the impending depletion of IPv4 address space with the continued growth of the Internet as drivers for widespread IPv6 deployment. While the RFC defines requirements for all developers of IP nodes, the main target seems to be consumer device vendors, many of whom have delayed implementation of IPv6. With consumers just implementing these IPv4-only devices today, they are likely to remain installed for many years, extending the IPv4 support lifecycle. Of course IPv4 will be around for quite some time, but the more of these devices that are IPv4 + IPv6 instead of IPv4-only, the easier co-existence will be to manage.

Among the best practices recommended, the RFC stipulates that all new “IP implementations” must support IPv6, and IPv6 support must be equivalent to or better than corresponding IPv4 feature support and quality, that dual-stack support is required though IPv4 must not be required for operation, and existing hardware and software implementations should be considered for upgrade to IPv6 support.

Another interesting statement from the RFC is that “the term “IP” can now be interpreted to mean IPv4 + IPv6, IPv6-only, or IPv4-only.” While separate standards exist for IPv4 and IPv6, the term “IP” now officially encompasses both protocols. Requirements for features specific to a given version should be so indicated, while general “IP” features will be assumed to apply to both.]]></description>
<dc:subject>Internet ipv6 standards politics</dc:subject>
<dc:source>https://instapaper.com/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:3ceccc224d41/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:Internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:ipv6"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:politics"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.izs.me/post/2353458699/an-open-letter-to-javascript-leaders-regarding">
    <title>blog.izs.me: An Open Letter to JavaScript Leaders Regarding Semicolons</title>
    <dc:date>2012-04-24T05:09:03+00:00</dc:date>
    <link>http://blog.izs.me/post/2353458699/an-open-letter-to-javascript-leaders-regarding</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[In general, n ends a statement unless:

The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with . or , .)
The line is -- or    (in which case it will decrement/increment the next token.)
It is a for() , while() , do , if() , or else , and there is no {
The next line starts with [ , ( ,   , * , / , - , , , . , or some other binary operator that can only be found between two tokens in a single expression.
The first is pretty obvious. Even JSLint is ok with n chars in JSON and parenthesized constructs, and with var statements that span multiple lines ending in , .

The second is super weird. I’ve never seen a case (outside of these sorts of conversations) where you’d want to do write in  nj , but, point of fact, that’s parsed as i;   j , not i  ; j .

The third is well understood, if generally despised. if (x)ny() is equivalent to if (x) { y() } . The construct doesn’t end until it reaches either a block, or a statement.

; is a valid JavaScript statement, so if(x); is equivalent to if(x){} or, “If x, do nothing.” This is more commonly applied to loops where the loop check also is the update function. Unusual, but not unheard of.

The fourth is generally the fud-inducing “oh noes, you need semicolons!” case. But, as it turns out, it’s quite easy to prefix those lines with semicolons if you don’t mean them to be continuations of the previous line.]]></description>
<dc:subject>javascript programming software standards politics</dc:subject>
<dc:identifier>https://pinboard.in/u:jtyost2/b:98c6332bd14b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:javascript"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:politics"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://brendaneich.com/2012/04/the-infernal-semicolon/">
    <title>The infernal semicolon | Brendan Eich</title>
    <dc:date>2012-04-24T04:48:58+00:00</dc:date>
    <link>http://brendaneich.com/2012/04/the-infernal-semicolon/</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[Similar hazards arise with [ , / , and unary   and - . Remember, if there wasn’t an error, ASI does not apply.

This problem may seem minor, but JS file concatenation ups the ante. For this reason some style guides (Dojo, IIRC) advocate starting your reusable JS file with ; , but people don’t know and it’s easy to forget.

I wish I had made newlines more significant in JS back in those ten days in May, 1995. Then instead of ASI, we would be cursing the need to use infix operators at the ends of continued lines, or perhaps  or brute-force parentheses, to force continuation onto a successive line. But that ship sailed almost 17 years ago.

The way systematic newline significance could come to JS is via an evolution of paren-free that makes it to Harmony status. I intend to work on this in the strawman , but not for ES6.

Some of the github issue comments are naive or idealistic to the point of being silly. Since when does any programming language not have syntax arguments? All living, practical languages that I know of, even those with indentation-based block structure and similar restrictions, have degrees of freedom of expression that allow abusage as well as good usage. Language designers can try to reduce degrees of freedom , but not eliminate them completely.

My two cents: be careful not to use ASI as if it gave JS significant newlines. And please don’t abuse && and || where the mighty if statement serves better.

I’ll also say that if it were up to me, in view of JS’s subtle and long history, I’d fix JSMin. But I would still log a grumpy comment or two first!]]></description>
<dc:subject>javascript standards programming politics</dc:subject>
<dc:identifier>https://pinboard.in/u:jtyost2/b:988e03afadfb/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:javascript"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:politics"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.killtheradio.net/technology/email-is-not-broken-its-a-framework-not-an-application/">
    <title>Email is not broken: It’s a framework, not an application (killtheradio.net)</title>
    <dc:date>2012-04-15T21:19:57+00:00</dc:date>
    <link>http://blog.killtheradio.net/technology/email-is-not-broken-its-a-framework-not-an-application/</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[Repeat after me: “There’s nothing to fix!” If you have a problem with email, fork a client or build your own! Nobody’s stopping you from “fixing” email. Many people have made a lot of cash by “fixing” email.

We don’t have to sit in fluorescent-lit, university buildings deliberating for hours on end about how to change the spec to fit everyone’s new needs. We don’t need 100 stupid startups “disrupting” the “broken” email system with their new protocols, that will inevitably end up being  a proprietary, non-distributed, “ad hoc, informally-specified, bug-ridden, slow implementation of half of” the current email system.

Please don’t try to fix email, you’re just going to fuck it up!! Trust me, you can’t do any better. Instead, let’s build all of our awesome new features on top of an already beautifully-working system by making smarter clients.]]></description>
<dc:subject>email technology standards programming software politics</dc:subject>
<dc:source>https://instapaper.com/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:69e857eb23a5/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:email"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:technology"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:politics"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://meyerweb.com/eric/thoughts/2006/09/25/w3c-change-full-independence/">
    <title>Eric’s Archived Thoughts: W3C Change: Full Independence</title>
    <dc:date>2012-04-05T04:54:07+00:00</dc:date>
    <link>http://meyerweb.com/eric/thoughts/2006/09/25/w3c-change-full-independence/</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[As many of you have noticed, I’m effectively proposing that the W3C become a foundation instead of a consortium, albeit a foundation whose primary mission is to act as a consortium would. I’ve avoided using terms like “non-profit” and “not-for-profit” because they might imply specific things which I don’t fully intend in terms of tax law, or whatever, but I do think of it as a generically non-profit institution; that is, one that does not strive to create a profit, except as can be invested into the endowment.

I’ve tried to explain why I believe this is a good idea, but in the end, I think the most fundamental reason is that one I can’t explain: it just feels like the right thing to do. It’s like I can perceive a shape without grasping all its details, but the overall shape looks right, looks better.

I fully expect that some will recoil from this idea, convinced that a foundation is a poor substitute for a consortium. Obviously, I disagree. I think the W3C’s future could be made much more stable with this approach, especially in financial terms. I also believe, as I said before, that it would be no less of a force for the advancement of the web. In fact, I think it would be a much stronger force, and have a greater positive effect, over the long term.

It is not a small undertaking, but it is an important and worthwhile effort, and I hope it is one the W3C considers seriously.]]></description>
<dc:subject>standards W3C technology politics</dc:subject>
<dc:source>https://instapaper.com/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:5505659d69d6/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:W3C"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:technology"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:politics"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.jgc.org/2012/04/in-praise-of-text-files-and-protocols.html">
    <title>In praise of... text files and protocols (jgc.org)</title>
    <dc:date>2012-04-03T23:44:05+00:00</dc:date>
    <link>http://blog.jgc.org/2012/04/in-praise-of-text-files-and-protocols.html</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[Similarly text based protocols (such as HTTP, IMAP, SMTP, FTP and POP3) make it easy for humans to write, read and debug. One of the things that made POPFile easy to implement was that all the mail protocols are text based (the entire POP3 proxying module is able to use simple string matching and regular expressions to handle POP3). And they are also line oriented (a command is read by reading to the line ending). That makes programs to handle them very easy to implement. Of course, the downside is that text takes up extra space and for low-level protocols (such as IP) it makes sense to use binary. But for almost everything else it’s best to use text. Only use binary protocols where the performance is so sensitive that it’s worth the implementation and debugging downside. The upside is that no special tools are needed. I wonder how much of the success of the Internet can be put down to the decision to use text-based protocols for almost everything that people will need to implement.  And how much we owe the early writes of the RFCs in deciding that text was best.]]></description>
<dc:subject>programming software standards politics</dc:subject>
<dc:source>https://instapaper.com/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:91ce9bf736a3/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:politics"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://arstechnica.com/business/news/2012/03/fsfe-celebrates-document-freedom-day-by-sending-handcuffs-to-policymakers.ars">
    <title>FSFE celebrates Document Freedom Day by sending handcuffs to policymakers</title>
    <dc:date>2012-03-28T23:44:16+00:00</dc:date>
    <link>http://arstechnica.com/business/news/2012/03/fsfe-celebrates-document-freedom-day-by-sending-handcuffs-to-policymakers.ars</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[The Free Software Foundation Europe (FSFE) is celebrating open standards today in an annual event called Document Freedom Day. The event, which was first held in 2008, is observed on the last Wednesday of March. The purpose of the celebration is to raise awareness of the critical role unencumbered interoperability and open standards play in protecting data from vendor lock-in.

According to the FSFE, 34 organizations are hosting 48 events in 17 countries to honor the occasion. The FSFE’s list of Document Freedom Day partners includes The Document Foundation, the KDE eV, the Pirate Party of Baden-Württemberg, and many regional Linux user groups.

Document Freedom Day is also endorsed by Google and Oracle, with both credited as sponsors. Many advocates of free culture and open standards issued statements in support of Document Freedom Day, including actor and humorist Stephen Fry.

“Open standards make sense. What makes no sense is that large companies in the field still do not understand this. It is time once and for all to end the pointless nonsense of one document sent on one platform being incomprehensible to the user of another,” Fry said in a statement.

The FSFE has published a list of activities interested parties can get involved with to help the cause, including promoting open formats in public libraries and creating street art raising awareness of open standards.

In addition to the typical advocacy activities, the FSFE has come up with an unusual means of drawing attention to their cause this year. The organization intends to send policymakers informational packets including a pair of handcuffs, a gesture intended to symbolize the restrictiveness of proprietary formats.]]></description>
<dc:subject>standards OpenSource software politics</dc:subject>
<dc:source>https://instapaper.com/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:ca3f28873643/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:OpenSource"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:politics"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://arstechnica.com/business/news/2012/03/mozilla-firefox-needs-h264-support-to-survive-shift-to-mobile.ars">
    <title>Mozilla: Firefox needs H.264 support to survive shift to mobile</title>
    <dc:date>2012-03-20T06:23:56+00:00</dc:date>
    <link>http://arstechnica.com/business/news/2012/03/mozilla-firefox-needs-h264-support-to-survive-shift-to-mobile.ars</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[Mozilla began an internal discussion last week about whether to implement support for H.264 and other patent-encumbered media formats by relying on hardware decoding and codecs supplied by the underlying operating system. Over the weekend, Mozilla’s Brendan Eich and Mitchell Baker wrote blog entries explaining why they support the plan.

The initial proposal on the mailing list focused on Mozilla’s Boot2Gecko (B2G) mobile platform and the Android port of the Firefox Web browser. As the debate evolved, a path for enabling the same capability in Firefox on the desktop was also discussed. The issue is controversial because royalty-bearing technologies are antithetical to Mozilla’s vision of an inclusive, open Web.

Mozilla has historically argued against the use of H.264 and had previously decided not to support it on principle. The organization argued in favor of Ogg and then backed the VP8 codec when Google made it available under open, royalty-free terms after acquiring On2. Google said that it would encourage adoption of its own VP8-based WebM format by removing H.264 support from the Chrome browser.

One year later, Google still hasn’t followed through with that commitment. Mozilla says that it can no longer afford to wait for Google to do what it has promised. In his blog post, Eich explained that H.264 has become too deeply entrenched in the mobile space to be easily displaced and that browsers that don’t support it are jeopardizing their own future relevance.

“H.264 is absolutely required right now to compete on mobile. I do not believe that we can reject H.264 content in Firefox on Android or in B2G and survive the shift to mobile,” he wrote. “Losing a battle is a bitter experience. I won’t sugar-coat this pill. But we must swallow it if we are to succeed in our mobile initiatives.”

He thinks that Google is in a position where it has to continue supporting H.264 in order to remain competitive itself, which means that the search giant can’t be counted on to champion WebM to the extent that some had hoped. A graph in Eich’s blog post shows that approximately 80 percent of video content on the Web that is available through the HTML5 video element is encoded with H.264.

“Apple sells a lot of H.264-supporting hardware. That hardware in general, and specifically in video playback quality, is the gold standard. Google is in my opinion not going to ship mobile browsers this year or next that fail to play H.264 content that Apple plays perfectly,” he wrote. “Whatever happens in the very long run, Mozilla can’t wait for such an event. Don’t ask Google why they bought On2 but failed to push WebM to the exclusion of H.264 on Android. The question answers itself.”

Although Mozilla is going to have to capitulate on patent-encumbered video in order to stay relevant today, there may be opportunities down the road to address the issue. Patents will eventually expire, Eich pointed out, and can also be invalidated. In the meantime, a pragmatic compromise on H.264 will end the impasse that is currently blocking widespread adoption of standards-based Web video.]]></description>
<dc:subject>Mozilla MozillaFirefox GoogleAndroid Google GoogleChrome browser internet standards H.264 media patent legal WebM html5 politics</dc:subject>
<dc:identifier>https://pinboard.in/u:jtyost2/b:8b411ae744cd/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:Mozilla"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:MozillaFirefox"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:GoogleAndroid"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:Google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:GoogleChrome"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:browser"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:H.264"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:media"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:patent"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:legal"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:WebM"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:html5"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:politics"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.benstrong.com/2010/11/google-and-microsoft-cheat-on-slow.html?m=1">
    <title>Google and Microsoft Cheat on Slow-Start. Should You? (benstrong.com)</title>
    <dc:date>2012-02-25T17:34:26+00:00</dc:date>
    <link>http://blog.benstrong.com/2010/11/google-and-microsoft-cheat-on-slow.html?m=1</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[It’s getting late, so I’ll wrap this up with a few thoughts:
Fast is good. I’m excited to see that sub-100ms page loads are possible, and it’s a shame to not be able to take full advantage of modern networks because of protocol limitations (http being the limiting protocol, btw).
Being non-standards-compliant in a way that privileges their flows relative to others seems more than a little hypocritical from a company that’s making such a fuss about network neutrality.
I’m not really qualified to render judgment on whether IW10 is a net positive, but after reading the discussion (and considering that the internet hasn’t actually melted down), I’m inclined to think that it is.
I’m pretty confident that turning off slow-start entirely, as Microsoft seems to be doing in my trace, is a very bad thing (maybe even a bug).
So, this leaves the question, what should I do in my app (and what should you do in yours)? Join the arms race or sit on the sidelines and let Google have all the page-load glory? I’ll let you know what I decide (and if I do it, I’ll be sure to let you know how it works out).
]]></description>
<dc:subject>Google Microsoft technology HTTP standards webdevelopment sysadmin server TCP politics</dc:subject>
<dc:identifier>https://pinboard.in/u:jtyost2/b:064b2cf953e1/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:Google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:Microsoft"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:technology"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:HTTP"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:webdevelopment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:sysadmin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:server"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:TCP"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:politics"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://arstechnica.com/microsoft/news/2012/02/cisco-begs-eu-make-microsoft-open-up-skypes-users-to-cisco-hardware.ars">
    <title>Cisco begs EU: make Microsoft open up Skype's users to Cisco hardware</title>
    <dc:date>2012-02-17T02:49:14+00:00</dc:date>
    <link>http://arstechnica.com/microsoft/news/2012/02/cisco-begs-eu-make-microsoft-open-up-skypes-users-to-cisco-hardware.ars</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[Cisco has appealed to the European Union’s General Court, asking for the European Commission’s approval of Microsoft’s takeover of Skype to be made conditional. The network infrastructure company wants the EC to ensure “standards-based interoperability in the video calling space.”

Regulatory bodies gave Microsoft’s takeover of Skype the go-ahead last year, with the deal finalized in October . Cisco says that it does not want to block the merger entirely, just restrict it and require Microsoft to make Skype play nicely with other voice and video calling systems.

Skype’s video and voice chat protocol is entirely proprietary and undocumented. Skype also uses a range of different codecs (including the proprietary, Google-owned VP8 and the open H.264). This makes Skype’s network of users almost completely isolated, and unable to communicate directly with any other VoIP or video system.]]></description>
<dc:subject>Cisco EuropeanUnion technology standards legal Microsoft skype politics</dc:subject>
<dc:identifier>https://pinboard.in/u:jtyost2/b:f8dc93bd4779/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:Cisco"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:EuropeanUnion"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:technology"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:legal"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:Microsoft"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:skype"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:politics"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://arstechnica.com/apple/news/2012/02/apple-takes-frand-issue-to-etsi-asks-for-common-frand-royalty-standards.ars">
    <title>Apple hoping to secure standardized royalties for 3G wireless patents</title>
    <dc:date>2012-02-09T03:48:18+00:00</dc:date>
    <link>http://arstechnica.com/apple/news/2012/02/apple-takes-frand-issue-to-etsi-asks-for-common-frand-royalty-standards.ars</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[Apple is attempting to stop the used of “standards essential” patents on 3G technology as legal bludgeons against smartphone competitors . To make its case, the company has gone directly to the standards body behind 3G wireless networking, the European Telecommunications Standards Institute (ETSI). In a letter to ETSI  dated last November (but only recently uncovered by the Wall Street Journal ) Apple suggested that patents offered as part of wireless networking standards should be governed by standardized royalty rates and barred from being used as the basis for legal injunctions.

As the war over smartphone supremacy has spilled over into the courtroom , some players—including Samsung and Motorola—have taken to leveraging patents essential to 3G wireless networking standards in lawsuits largely aimed at Apple. Those patents were offered up to the ETSI to help create 3G standards on the condition that they be licensed on fair, reasonable, and non-discriminatory (FRAND) terms.

In the letter to the ETSI, however, Apple’s chief IP counsel Bruce Watrous asserted, “it is apparent that our industry suffers from a lack of consistence adherence to FRAND principles in the cellular standards arena.”

In particular, Samsung has asked for a 2.4 percent royalty on the full retail price of every iPhone or iPad sold to cover its 3G-related patents, while Motorola has asked for 2.25 percent. Apple has apparently rejected these offers as unfair and unreasonable, leading both Samsung and Motorola to sue Apple for infringement.

So far, courts in the European Union haven’t taken too kindly to using FRAND-encumbered patents to block competitors with injunctions. Samsung lost injunction requests based on 3G patents in France, Germany, Italy, and the Netherlands. Motorola won an injunction in Germany, but was later overturned on appeal.

The European Commission also objects to using FRAND-encumbered patents against competitors. It began a formal investigation in late January “to assess whether Samsung Electronics has abusively, and in contravention of a commitment it gave to the European Telecommunications Standards Institute, used certain of its standard essential patent rights to distort competition in European mobile device markets, in breach of EU antitrust rules.”]]></description>
<dc:subject>Apple technology hardware patent legal lawsuit standards Samsung Motorola EuropeanUnion telecommunications politics</dc:subject>
<dc:identifier>https://pinboard.in/u:jtyost2/b:47325292b6f4/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:Apple"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:technology"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:hardware"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:patent"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:legal"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:lawsuit"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:Samsung"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:Motorola"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:EuropeanUnion"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:telecommunications"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:politics"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#the-translate-attribute">
    <title>3.2 Elements — HTML Standard</title>
    <dc:date>2012-02-08T03:18:39+00:00</dc:date>
    <link>http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#the-translate-attribute</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[The translate attribute is an enumerated attribute that is used to specify whether an element's attribute values and the values of its Text node children are to be translated when the page is localized, or whether to leave them unchanged.

The attribute's keywords are the empty string, yes, and no. The empty string and the yes keyword map to the yes state. The no keyword maps to the no state. In addition, there is a third state, the inherit state, which is the missing value default (and the invalid value default).]]></description>
<dc:subject>html standards webdesign webdevelopment programming politics</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:2cb5df8f17b3/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:html"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:webdesign"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:webdevelopment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:politics"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://dev.w3.org/csswg/css3-hierarchies/">
    <title>CSS Hierarchies Module Level 3</title>
    <dc:date>2012-02-07T05:03:57+00:00</dc:date>
    <link>http://dev.w3.org/csswg/css3-hierarchies/</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[CSS is a language for describing the rendering of structured documents (such as HTML and XML) on screen, on paper, in speech, etc. This module contains the features of CSS level 3 relating to the hierarchical nesting of style rules. It includes and extends the functionality of CSS level 2 [CSS21], which builds on CSS level 1 [CSS1]. The main extension compared to level 2 is the ability to nest a style rule within another rule, allowing greater modularisation and readibility of CSS documents.]]></description>
<dc:subject>css html css3 w3c standards webdesign webdevelopment programming politics</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:463184e0b031/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:css"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:html"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:css3"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:w3c"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:webdesign"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:webdevelopment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:politics"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://tantek.com/2011/238/b1/many-ways-slice-url-name-pieces">
    <title>How many ways can you slice a URL and name the pieces? - Tantek</title>
    <dc:date>2011-08-27T20:57:13+00:00</dc:date>
    <link>http://tantek.com/2011/238/b1/many-ways-slice-url-name-pieces</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[ I was developing a small single purpose microsite and decided to build it using CASSIS not just for application logic, but for the server-side runtime execution and flow as well. I figured the needs of a simple real world site would work well to drive the design of a simple runtime.

No need to invent anything new, just re-use Apache/CGI environment variables (e.g. as used in PHP, like SERVER_NAME). But they look like old C constants, and CASSIS coders will be more familiar with Javascript.

Window.location's properties seem reasonable, until you get to "search" for the "?" query part of a URL. What about the source, the specs for URL and HTTP? And that's when I started to see the problem.

With a little more research I found a half-dozen different ways to slice and dice URLs. Kevin Marks asked me, what about Python? And that made seven. I published my research publicly on the microformats wiki, which is a good place to document existing formats for something (a key step in the microformats process).

Among all the differences (and overloading of the same terms to mean different things) it did seem that there were some patterns. So I made a diagram of a sample URL, chopped into pieces and named according to seven different conventions over the years, in the hopes that doing so might reveal such patterns. ]]></description>
<dc:subject>standards programming url http politics</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:913904de8045/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:url"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:politics"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://hacks.mozilla.org/2011/08/introducing-webapi/">
    <title>Introducing WebAPI ✩ Mozilla Hacks – the Web developer blog</title>
    <dc:date>2011-08-24T08:24:29+00:00</dc:date>
    <link>https://hacks.mozilla.org/2011/08/introducing-webapi/</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[WebAPI is an effort by Mozilla to bridge together the gap, and have consistent APIs that will work in all web browsers, no matter the operating system. Specification drafts and implementation prototypes will be available, and it will be submitted to W3C for standardization. Security is a very important factor here, and it will be a mix of existing security measurements (e.g. asking the user for permission, like Geolocation) or coming up with new alternatives to ensure this.]]></description>
<dc:subject>api programming mozilla w3c standards browser politics</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:b377e9b8db97/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:mozilla"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:w3c"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:browser"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:politics"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.readwriteweb.com/hack/2011/04/internet-explorer-webgl-and-a.php">
    <title>Internet Explorer, WebGL and a Return to the Bad Old Days</title>
    <dc:date>2011-04-17T20:06:03+00:00</dc:date>
    <link>http://www.readwriteweb.com/hack/2011/04/internet-explorer-webgl-and-a.php</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[That, or Microsoft is ignoring an accepted standard in favor of its own technology - and setting the groundwork for the "bad old days" of Web fragmentation all over again. I wrote earlier about the mixed messages Microsoft is sending - on the one hand saying that developers should be able to write markup once and run it anywhere, and on other saying developers should create alternate versions of their sites for non-IE9+ browsers.

It's a shame. IE9 and 10 look to be great browsers. But the harder I look at what Microsoft is doing, the harder it is to believe that its browser strategy developer friendly.

Combine this with Chrome's Native Client and the ongoing war over a video codec standard and think we'll see a return to the bad old days soon.]]></description>
<dc:subject>microsoft html5 ie ie9 marketing webgl technology standards politics</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:2325cb38dd4a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:microsoft"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:html5"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:ie"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:ie9"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:marketing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:webgl"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:technology"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:politics"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://arstechnica.com/apple/news/2011/04/adobe-throws-in-towel-adopts-http-live-streaming-for-ios.ars">
    <title>Adobe throws in towel, adopts HTTP Live Streaming for iOS</title>
    <dc:date>2011-04-16T22:17:48+00:00</dc:date>
    <link>http://arstechnica.com/apple/news/2011/04/adobe-throws-in-towel-adopts-http-live-streaming-for-ios.ars</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA[Adobe previewed some new streaming video capabilities of its Flash Media Server at the 2011 National Association of Broadcasters (NAB) trade show, including new compatibility with iOS devices like the iPad. Instead of getting Steve Jobs to relent on his "thoughts on Flash," however, Adobe is instead adding HTTP Live Streaming support to Flash Media Server.

HTTP Live Streaming is a protocol that Apple developed to stream live and recorded video using standard HTTP connections instead of the more difficult to optimize RTSP. It uses H.264-encoded video and AAC or MP3 audio packaged into discrete chunks of an MPEG-2 transport stream, along with a .m3u playlist to catalog the files that make up the individual chunks of the stream. QuckTime on both Mac OS X and iOS can play back this format, and it is the only streaming format compatible with the iPhone, iPad, and iPod touch.

Apple submitted HTTP Live Streaming to the IETF in 2009 as a proposed standard, though it doesn't appear that the standard ever moved beyond the draft stage. However, Microsoft quickly added support to its IIS Media Services server, which is used to deliver "smooth streaming" video to Silverlight-based clients. When IIS Media Services detects an iOS device, it instead packages and delivers the content using HTTP Live Streaming.

Adobe added its own HTTP-based streaming feature to Flash Media Server last year. Similar to Apple's solution, it breaks up H.264 video into chunks saved as separate files and sends those files to a client over HTTP. The difference is that its HTTP Dynamic Streaming uses an XML-based manifest file (instead of a plain-text playlist file) and the MPEG-4 fragment container format (.f4f). Also, it's only compatible with Flash or AIR.

However, Adobe is "committed to developing technologies that simplify broadcast workflows to make it simpler to reach a fragmented lineup of devices," according to senior product manager for Flash Media Server Kevin Towes. Towes noted in a blog post that Adobe is adding HTTP Live Streaming support to Flash Media Server and Flash Media Live Encoder. "By adding support for HLS within the Flash Media Server, Adobe is reducing the publishing complexity for broadcasters who need to reach browsers supporting HLS through HTML5 (such as Safari) or devices where Adobe Flash is not installed."

In other words, instead of trying in vain to persuade Apple to build Flash into iOS, or losing potential Flash Media Server customers to some other iOS-compatible solution, Adobe seems to be implicitly acknowledging that content publishers need Flash-free video streaming.

It's also worth noting that Flash Media Server will also be served to compatible clients on non-iOS platforms, including Safari on Mac OS X. Apple recently began selling its portable computers without Flash pre-installed, and we discovered that running Safari without Flash seemed to increase battery life of the latest MacBook Air as much as 33 percent. While Adobe has claimed to be working on a MacBook Air-optimized version of Flash, perhaps the company decided it was prudent to cover all bases and serve up content to Mac users who are choosing to not install Flash on their systems (yours truly included).]]></description>
<dc:subject>adobe media video internet http HTTPLiveStreaming standards h.264 MPEG-2 AAC MP3 audio ios politics</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jtyost2/b:d81806f00af4/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:adobe"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:media"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:video"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:HTTPLiveStreaming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:h.264"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:MPEG-2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:AAC"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:MP3"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:audio"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:ios"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:politics"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://news.cnet.com/8301-30685_3-10402642-264.html">
    <title>New standard lets browsers get a grip on files | Deep Tech - CNET News</title>
    <dc:date>2009-11-25T05:52:31+00:00</dc:date>
    <link>http://news.cnet.com/8301-30685_3-10402642-264.html</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA["The World Wide Web Consortium has published a draft of an interface that browsers can use to manipulate files better, one of a series of steps aimed at gradually improving the sophistication and polish of Web site interfaces. The draft File API (application programming interface) defines a number of ways that browsers and Web sites can handle files better. One big part of it: being able to select multiple files for upload, such as on photo-sharing sites or Web-based e-mail, a task that often relies on Adobe Systems' Flash today."]]></description>
<dc:subject>internet standards browser w3c politics</dc:subject>
<dc:identifier>https://pinboard.in/u:jtyost2/b:c87c9fce2f1c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:browser"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:w3c"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:politics"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://daringfireball.net/linked/2009/11/18/ie9-interop">
    <title>Daring Fireball Linked List: I Am Not Making This Up</title>
    <dc:date>2009-11-23T05:32:17+00:00</dc:date>
    <link>http://daringfireball.net/linked/2009/11/18/ie9-interop</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA["To watch this video from Microsoft regarding the upcoming IE 9’s support for standards and interoperability, you are prompted to install Silverlight. (Via Mark Pilgrim.)" So much for open standards.]]></description>
<dc:subject>ie9 standards microsoft internet browser ie politics</dc:subject>
<dc:identifier>https://pinboard.in/u:jtyost2/b:0010907171b1/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:ie9"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:microsoft"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:browser"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:ie"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:politics"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://radar.oreilly.com/2009/11/the-war-for-the-web.html">
    <title>The War For the Web - O'Reilly Radar</title>
    <dc:date>2009-11-23T03:48:00+00:00</dc:date>
    <link>http://radar.oreilly.com/2009/11/the-war-for-the-web.html</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA["One of the points I've made repeatedly about Web 2.0 is that it is the design of systems that get better the more people use them, and that over time, such systems have a natural tendency towards monopoly. And so we've grown used to a world with one dominant search engine, one dominant online encyclopedia, one dominant online retailer, one dominant auction site, one dominant online classified site, and we've been readying ourselves for one dominant social network. But what happens when a company with one of these natural monopolies uses it to gain dominance in other, adjacent areas? I've been watching with a mixture of admiration and alarm as Google has taken their dominance in search and used it to take control of other, adjacent data-driven applications. I noted this first with speech recognition, but it's had the biggest business impact so far in location-based services."]]></description>
<dc:subject>internet google facebook business microsoft mobile iphone web2.0 twitter apple amazon.com monopoly standards interoperability politics</dc:subject>
<dc:identifier>https://pinboard.in/u:jtyost2/b:1ed0f3813043/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:facebook"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:business"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:microsoft"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:mobile"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:iphone"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:web2.0"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:twitter"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:apple"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:amazon.com"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:monopoly"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:interoperability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:politics"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://ajaxian.com/archives/ie-9-hardware-rendering-new-js-engine-css-standards-and-more?utm_source=feedburner&amp;utm_medium=feed&amp;utm_campaign=Feed%3A+ajaxian+%28Ajaxian+Blog%29&amp;utm_content=Google+Reader">
    <title>Ajaxian » IE 9: Hardware rendering, new JS engine, CSS, standards, and more</title>
    <dc:date>2009-11-23T03:34:08+00:00</dc:date>
    <link>http://ajaxian.com/archives/ie-9-hardware-rendering-new-js-engine-css-standards-and-more?utm_source=feedburner&amp;utm_medium=feed&amp;utm_campaign=Feed%3A+ajaxian+%28Ajaxian+Blog%29&amp;utm_content=Google+Reader</link>
    <dc:creator>jtyost2</dc:creator><description><![CDATA["With PDC going on, we get a glimpse at the early stage of IE 9. There is some promise, albeit with omissions!"]]></description>
<dc:subject>ie9 ie browser internet microsoft standards politics</dc:subject>
<dc:identifier>https://pinboard.in/u:jtyost2/b:eb0df14fed2a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:ie9"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:ie"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:browser"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:microsoft"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jtyost2/t:politics"/>
</rdf:Bag></taxo:topics>
</item>
</rdf:RDF>