The document proposes an open protocol called OExchange to provide a standardized way for users to send URL-based content from any website to online services. The key aspects are: 1) Allow users to discover and personalize their preferred services for sharing, saving, translating content through a common protocol. 2) Define a basic solution where services have a standard "Offer" endpoint to receive URLs plus metadata, and an XRD file describing the service. 3) Specify an HTTP GET flow where the user's browser sends the URL and optional extras to the service's endpoint, then the service handles the content.

1. OExchange An Open Protocol Stack for URL-Based Content Sharing on the Web(Quick Geek Remix) May 2010

2. What are we trying to do here? The Web includes an unbounded number of services for sharing, posting, translating, printing, saving for later, and more Goal #1: Provide a simple, default way for users to send any URL-based content to any service on the web Goal #2: Allow users to personalize their choices, across tools, publishers, and machines

4. The Basic Solution A standard endpoint, and a defined HTTP GET flow to send URLs to that endpoint An “Offer” endpoint takes standard arguments (always including URL); has browser control for the transaction An XRD-based resource that describes the service A “Target XRD” document includes the endpoint and related information about the service Host-Meta and page-level Link tags make the service discoverable I accept URLs at my Offer endpoint: http://<me>/<whatever>?url=<url>&<etc> That and some info for humans is in my XRD doc: http://<me>/<whatever>/target.xrd You can discover it from my host-meta or in-page Link tags: rel=“http://oexchange.org/…/related-target”

5. The Offer Flow Build on a deployed browser-based paradigm (add “headless” modes once discovery is adopted) Enforce URLs as primary content indicators (supporting any tagging schemes) Plan for extensibility of verbs (“offer” is the most generic) Content source, in a user’s browser Receiving service (social network, translator, whatever) HTTP GET, usually target=“_blank” http://<service>/<whatever>?url=<url>&<etc> Service-specific UI; browser session up to service Browser session continued

6. About Typing We’re ALWAYS sending URLs URLs which are viewable in a browser URLs which may use any embedded tags (OGP, microformats, etc.) We’re optionally sending extra stuff Iframe URLs, images, rich media objects This gives us guaranteed compatibility, without ANY negotiation an ability to offer a richer experience for services that support it

7. Personalizing Choices If you can send content to any service, and discover new services automatically… Let a user store their preferences Let all tools, including browsers, access it http://<service> http://<service> http://<service> WebFinger lookup Personal XRD with OExchange links http://<service>/target.xrd http://<service>/target.xrd http://<service>/target.xrd http://<service>/target.xrd mary@example.com Optional local cache

8. So What? For Services Receive more content, from a greater variety of tools and content providers For Users Get the right option at the right time for sharing, saving, blogging, whatever Engage with longer-tail communities of interest For Publishers Get more of your content out, through more efficient share-through Don’t have to decide between options

9. Taking it Forward Our strategy Codify the existing model for basic content exchange on the web, while adding a new discovery capability Add new exchange models once this foundation is deployed Additional exchange models With discovery in place, its easy to standardize more optimized exchange flows Headless and return-to-source are primary examples User addressing; mutual service negotiation in “Send to Mom” type use-cases Learn more at www.oexchange.org