erlend@hamnaberg.net http://www.hamnis.org/

General Internet-Draft This memo defines a ‘publish’ link relation and provides a number of examples.

This specification outlines the publish link relation and what it means to publish something. The specification will register the relation according to . No assumptions will be made about which media type the target IRI will accept, but some examples and guidelines will be given.

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in .

Please discuss this draft on the apps-discuss@ietf.org mailing list.

What does it mean to publish something? In effect it can be interpreted as making something available for general consumption. A newspaper can publish an article, then it can be read by ‘everyone’. A publisher can publish a book, so it can be read. A video can be submitted to youtube so it can be watched.

The publish link relation allows a resource to be published using the target IRI. Clients SHOULD use an appropriate write method of the target IRI protocol uniform interface. Servers MAY ignore the request to publish something if the resource URI is already published. Examples can be found in

IANA is asked to register the link relation publish, as per Relation Name: publish Description: Allows resources to be published using the target IRI. Reference: [ this document ]

TBD

Thanks to Jan Algermissen, Peter Rushforth and Darrel Miller for their valuable feedback and comments.

Harvard University

1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 sob@harvard.edu

General keyword In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Note that the force of these words is modified by the requirement level of the document in which they are used. This document specifies relation types for Web links, and defines a registry for them. It also defines the use of such links in HTTP headers with the Link header field. [STANDARDS-TRACK] Los Alamos National Laboratory, Advanced Computing Lab

MS B287 Los Alamos NM 87545 US +1 505 665 0597 +1 505 665 4939 rdaniel@lanl.gov

The Uniform Resource Names Working Group (URN-WG) was formed to specify persistent, location-independent names for network accessible resources, as well as resolution mechanisms to retrieve the resources given such a name. At this time the URN-WG is considering one particular resolution mechanism, the NAPTR proposal. That proposal specifies how a client may find a "resolver" for a URN. A resolver is a database that can provide information about the resource identified by a URN, such as the resource's location, a bibliographic description, or even the resource itself. The protocol used for the client to communicate with the resolver is not specified in the NAPTR proposal. Instead, the NAPTR resource record provides a field that indicates the "resolution protocol" and "resolution service requests" offered by the resolver. This document specifies the "THTTP" resolution protocol - a trivial convention for encoding resolution service requests and responses as HTTP 1.0 or 1.1 requests and responses. The primary goal of THTTP is to be simple to implement so that existing HTTP servers may easily add support for URN resolution. We expect that the databases used by early resolvers will be useful when more sophisticated resolution protocols are developed later. The Atom Publishing Protocol (AtomPub) is an application-level protocol for publishing and editing Web resources. The protocol is based on HTTP transfer of Atom-formatted representations. The Atom format is documented in the Atom Syndication Format. [STANDARDS-TRACK]

Let’s say you have an atom feed like the one below

2005-07-31T12:29:29Z tag:example.org,2003:3 urn:id:1 yes 2012-05-04T12:00:29Z Erlend Hamnaberg Some Content here. urn:id:1 yes 2012-05-04T12:29:29Z Erlend Hamnaberg Some Content here. ]]>

Using Atompub (), a Client would have to GET each entry using it’s edit relation and PUT each back with

no ]]>

being the only change in both entries. This is highly inefficient. So let us find a better way.

To be able to publish many resources at once we need a representation which allows this. Appendix A in defines the text/uri-list media type. Extra linefeeds are for display purposes only.

The problem with this approach is that is is a separate resource, and will not invalidate the caches of the feed. This problem is also apparent in the single item approach. One might mediate this by making the feed resource also accept text/uri-list for publishing. We could then change the request to this: