view Side-By-Side changes
Network Working Group R. Sayre Internet-DraftBoswijck Memex Consulting Expires: September 26, 2005 March 25,October 3, 2005 Expires: April 6, 2006 The Atom Publishing Protocol (Basic)draft-sayre-atompub-protocol-basic-00.txtdraft-sayre-atompub-protocol-basic-01.txt Status of this MemoThis document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667.By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or shebecomebecomes aware will be disclosed, in accordance withRFC 3668.Section 6 of BCP 79. This document may not be modified, and derivative works of it may not be created. This document may only be posted in an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents asInternet-Drafts.Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire onSeptember 26, 2005.April 6, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo presents a protocol for using XML (Extensible Markup Language) and HTTP (HyperText Transport Protocol) to edit content. The Atom Publishing Protocol is an application-level protocol for publishing and editing Web resources belonging to periodically updated websites. Theprotocol at its core is the HTTP transport of Atom-formatted representations. TheAtom format is documented in the Atom Syndication Format (draft-ietf-atompub-format-11.txt). Sayre ExpiresSeptember 26, 2005April 6, 2006 [Page 1] Internet-Draft The Atom Publishing Protocol (Basic)MarchOctober 2005Atom Syndication Format (draft-ietf-atompub-format-06.txt). This memo is a variant of the original Atom Publishing Protocol, as authored by Joe Gregorio.Editorial Note To provide feedback on this Internet-Draft, join the atom-protocol mailing list(http://www.imc.org/atom-protocol/index.html) [1].<http://www.imc.org/atom-protocol/index.html>. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . ..31.12. Notational Conventions . . . . . . . . . . . . . . . . . .3 2.. 4 3. The Atom Publishing Protocol Model . . . . . . . . . . . . .. 3 2.15 4. Collections . . . . . . . . . . . . . . . . . . . . . . .3 2.2 Orientation . . . . . . . . . . . . . . . . . . . . . . . 3 2.3 Listing . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.4 Authoring . . . . . . . . . . . . . . . . . . . . . . . . 4 2.4.1 Create . . . . . . . . . . . . . . . . . . . . . .. 9 5. Media Collections .4 2.4.2 Read. . . . . . . . . . . . . . . . . . . . 12 6. Service Outlines . . . . .5 2.4.3 Update. . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . .5 2.4.4 Delete. . . . . . . . . . . 16 8. Normative References . . . . . . . . . . . . .5 2.5 Success and Failure. . . . . . . 16 Author's Address . . . . . . . . . . . .6 3. Functional Specification. . . . . . . . . . 17 A. Contributors . . . . . . . . .6 3.1 Interacting With Collections. . . . . . . . . . . . . . .6 3.1.1 Request18 Intellectual Property andResponse . . . . . . . . . .Copyright Statements . . . . . . .6 3.2 Authoring Atom Entries . . . . . . . . . . . . . . . . . . 10 3.2.1 Create . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.2 Read . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.3 Update . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.4 Delete . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3 Authoring Generic Resources . . . . . . . . . . . . . . . 10 3.3.1 Create . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3.2 Read . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3.3 Update . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3.4 Delete . . . . . . . . . . . . . . . . . . . . . . . . 11 3.4 Service Description . . . . . . . . . . . . . . . . . . . 11 3.4.1 Service Description Documents . . . . . . . . . . . . 11 3.4.2 Request and Response . . . . . . . . . . . . . . . . . 13 4. Extensions to the Atom Syndication Format . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. Normative References . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . 16 Sayre Expires September 26, 2005 [Page 2] Internet-Draft The19 Sayre Expires April 6, 2006 [Page 2] Internet-Draft The Atom Publishing Protocol (Basic)MarchOctober 2005 1. Introduction The Atom Publishing Protocol (APP) is an application-level protocol for publishing and editing Web resources using HTTP [RFC2616] and XML1.0[W3C.REC-xml-20040204].1.1Sayre Expires April 6, 2006 [Page 3] Internet-Draft The Atom Publishing Protocol (Basic) October 2005 2. Notational Conventions 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 [RFC2119].2.The APP namespace is "http://purl.org/atom/app#". This specification refers to it by using the prefix "pub", but that prefix is arbitrary. The terms 'URI' and 'IRI' are shorthand for the identifiers specified in [RFC3986] and [RFC3987]. Sayre Expires April 6, 2006 [Page 4] Internet-Draft The Atom Publishing Protocol (Basic) October 2005 3. The Atom Publishing Protocol Model The Atom Publishing Protocol operates on collections of Web resources. All collections support the same basicmethods of interaction. The memberinteractions, as do the resourcesof those collections sharewithin thesamecollections. The patterns of interactionpatterns.are based on the common HTTPmethods provide a patternverbs. This section illustrates the editing cycle forworking with all such Web resources:Atom entries. o GET is used to retrieve a representation of a resource or perform a read-only query. o POST is used to create a new, dynamically-named resource. o PUT is used to update a known resource. o DELETE is used to remove a resource.2.13.1 Collections The APP groups resources into "Collections", which are analogous to the "folders" or "directories" found in many file systems.2.2 Orientation3.2 Discovery To discover the location of the collections exposed by an APP service, the client must locate and request a ServiceDescription DocumentOutline (Section3.4).6). Service Outlines describe the layout of an APP service. Client Server | | | 1.) GETService DescriptionOutline URI | |------------------------------->| | | | 2.) ServiceDescriptionOutline Doc | |<-------------------------------| | | 1. The client sends a GET request to the ServiceDescriptionOutline Resource.Sayre Expires September 26, 2005 [Page 3] Internet-Draft The Atom Publishing Protocol (Basic) March 20052. The server responds with a ServiceDescriptionOutline Document containing the locations of collections provided by the service. The content of this document can vary based on aspects of the client request, including, but not limited to, authentication credentials.2.3Sayre Expires April 6, 2006 [Page 5] Internet-Draft The Atom Publishing Protocol (Basic) October 2005 3.3 Listing Once the client has discovered the location of a collection, it can request a listing of the collection's membership. However, collections might be extremely large, so servers are likely to list a small subset of the collection by default.Clients that wish to exercise greater control over the subset returned by the server can include an Atom-Query (Section 3.1.1.1) header in their request.Client Server | | | 1.) GET to Collection URI | |------------------------------->| | | | 2.) 200 OK, Atom Feed Doc | |<-------------------------------| | | 1. The client sends a GET request to the Collection's URI. 2. The server responds with an Atom Feed Document containing a full or partial listing of the collection's membership.2.43.4 Authoring After locating a collection,thea client canalter its membership by sending HTTP requests to its member resources, rather than the collection itself, except when it desires toaddan entry to the collection. In that case, it sendsentries by sending a request to thecollection. 2.4.1collection; other changes are accomplished by sending HTTP requests to its member resources. 3.4.1 Create Client Server | | | 1.) POST to Collection URI | |------------------------------->| | | | 2.) 201 Created @ Location | |<-------------------------------| | | 1. The client sends a representation of a member to the server via HTTP POST. The Request URI is that of the Collection.Sayre Expires September 26, 2005 [Page 4] Internet-Draft The Atom Publishing Protocol (Basic) March 20052. The server responds with a response of "201 Created" and a "Location" header containing the URI of the newly-created resource.2.4.2Sayre Expires April 6, 2006 [Page 6] Internet-Draft The Atom Publishing Protocol (Basic) October 2005 3.4.2 Read Client Server | | | 1.) GET or HEAD to Member URI | |------------------------------->| | | | 2.) 200 OK Atom Entry | |<-------------------------------| | | 1.If theThe clientdoes not know the current state of the resource, itsends a GET (or HEAD) request to the member's URI. 2. The server responds with anappropriate representation. 2.4.3Atom Entry document. 3.4.3 Update Client Server | | | 1.) PUT to Member URI | |------------------------------->| | | | 2.) 200 OK | |<-------------------------------| 1. The client PUTs an updated representation to the member's URI. 2. The server responds with a representation of the member's new state.2.4.43.4.4 Delete Client Server | | | 1.) DELETE to Member URI | |------------------------------->| | | | 2.) 204 No Content | |<-------------------------------| | | 1. The client sends a DELETE request to the member's URI. 2. The server responds with successful status code. Sayre ExpiresSeptember 26, 2005April 6, 2006 [Page5]7] Internet-Draft The Atom Publishing Protocol (Basic)MarchOctober 20052.53.5 Success and Failure HTTP defines classes of response. HTTP status codes of the form 2xx signal that a request was successful. HTTP status codes of the form 4xx or 5xx signal that an error has occurred, and the request has failed. Consult the HTTP specification for more detailed definitions of each status code.3. Functional Specification 3.1 Interacting WithSayre Expires April 6, 2006 [Page 8] Internet-Draft The Atom Publishing Protocol (Basic) October 2005 4. Collections3.1.1 Request and Response This specification defines two methods for useAn Atom Collection is a set of related resources represented by one or more Atom Feed documents [AtomFormat]. Atom Collections are ordered the date their members were updated, withcollections:the most recently updated member appearing first. 4.1 GETand POST. This section will cover GET. POST is covered in Section 3.2 and Section 3.3.Collections can contain extremely large numbers of resources. A naive client such as a web spider or web browser would be overwhelmed if the response to a GET reflected the full membership of the collection, and the server would waste large amounts of bandwidth and processing time on clients unable to handle the response. As a result, responses to a simple GET request represent aserver-determinedserver- determined subset of the collection's membership.This specifcation defines two serializations forAn example collection feed: <feed xmlns="http://www.w3.org/2005/Atom" xmlns:pub="http://purl.org/atom/app#"> <title>My Posts1</title> <id>urn:uuid:ce61592c-14e2-4557-978e-dfbd444aefa6</id> <updated>2005-12-21T04:11:00-08:00</updated> <!-- 0 or more atom:entry elements follow --> <entry> <title type="text">title 25</title> <updated>2005-12-21T04:11:00-08:00</updated> <author> <name>Foo</name> </author> <id>urn:uuid:941e12b4-6eeb-4753-959d-0cbc51875387</id> <pub:edit href="./entry7.atom"/> <link href="/permalink7.html" /> </entry> ... </feed> Each member is represented by an AtomCollections. Servers MUST provide both,Entry, butMAY also provide additional serializations. 1. Atom Feed Documents (application/atom+xml) 2. Atom Feed Documents wrapped by a SOAP envelope (application/soap+xml) Clients usethose entries are not an editable representation of theHTTP 'Accept' request header to indicate their preference. If no 'Accept' header is present inentry. To retrieve therequest,source representation of theserver is free to choose any serialization. [[anchor11: Send an 'Accept' header, or you might get an mp3 in response.]] Example Requestentry, clients send a GET/collection HTTP/1.1 Host: example.org User-Agent: GenericBot/1.0 Accept: */* Here, the server could return any subset ofrequest to thecollection using any serialization.URI found in each entry's pub:edit element (see Section 4.3.1). Derived resources are located by examining an entry's atom:link elements. Sayre ExpiresSeptember 26, 2005April 6, 2006 [Page6]9] Internet-Draft The Atom Publishing Protocol (Basic)MarchOctober 2005Example Request,4.2 POST In addition to GET, a Collection Resource also accepts POST requests. The client POSTs a representation of the desired resource to the Collection Resource. Note that some collections only allow members of a specific media-type and a POST MAY generate a response withAccept header GETa status code of 415 ("Unsupported Media Type"). In the case of a successful creation, the status code MUST be 201 ("Created"). Example request creating a resource in a collection. POST /collection HTTP/1.1 Host: example.org User-Agent: Cosimo/1.0Accept:Content-Type: application/atom+xmlHere, the server could return any subset of the collection as an Atom Feed Document.Content-Length: nnnn ...data... ExampleResponse, Atom Feed Documentresponse. HTTP/1.1200 OK201 Created Date:Fri, 25Mon, 21 Mar 200517:15:33 GMT Last-Modified: Mon, 04 Oct 2004 18:31:4519:20:19 GMT Server: CountBasic/2.0 ETag:"2b3f6-a4-5b572640" Accept-Ranges: bytes Content-Length: nnnn Content-Type: application/atom+xml; charset="utf-8" <?xml version="1.0" encoding="UTF-8"?> <feed xmlns="..." xmlns:pub="..."> <title>Example Feed</title> <link href="http://example.org/login"/> <updated>2003-12-13T18:30:02Z</updated> <author> <name>John Doe</name> </author> ... <entry> <title>Sample</title> <updated>2003-12-13T18:30:02Z</updated> <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id> <link rel="alternate" href="http://example.org/sample.html"/> <pub:edit href="http://example.org/app/sample.atom" /> <content /> </entry> ... </feed>"4c083-268-423f1dc6" Location: http://example.org/stuff/foo13241234.atom 4.3 Entry Collection Entry Collections are Collections that restrict their membership to Atom entries. The entries are edited by sending HTTP requests to the URI found in an individual entry's pub:edit element. Servers can determine the processing necessary to interpret a request by examining the request's HTTP method. 4.3.1 The 'pub:edit' Element The pub:edit element has one attribute, 'href'. The value of this attribute is an IRI reference interpreted relative to xml:base. 4.3.2 Role of Atom Entry Elements During Editing The elements of an Atom Entry Document are either a 'Writable Element' or a 'Round Trip Element'. Sayre ExpiresSeptember 26, 2005April 6, 2006 [Page7]10] Internet-Draft The Atom Publishing Protocol (Basic)MarchOctober 2005Example Request, with SOAP Accept header GET /collection HTTP/1.1 Host: example.org User-Agent: Cosimo/1.0 Accept: application/soap+xml Here, the server could return any subsetWritable Element - An element ofthe collection asan AtomFeed Document wrappedEntry whose value is editable bya SOAP envelope. Example Response, Atom Feed Document wrappedthe client and not enforced bya SOAP envelope HTTP/1.1 200 OK Date: Fri, 25 Mar 2005 17:15:33 GMT Last-Modified: Mon, 04 Oct 2004 18:31:45 GMT ETag: "2b3f6-a4-5b572640-89" Accept-Ranges: bytes Content-Length: nnnn Content-Type: application/soap+xml; charset="utf-8" <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Header /> <env:Body> <feed xmlns="..." xmlns:pub="..."> <title>Example Feed</title> <link href="http://example.org/login"/> <updated>2003-12-13T18:30:02Z</updated> <author> <name>John Doe</name> </author> ... <entry> <title>Sample</title> <updated>2003-12-13T18:30:02Z</updated> <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id> <link rel="alternate" href="http://example.org/sample.html"/> <pub:edit href="http://example.org/app/sample.atom" /> <content /> </entry> ... </feed> </env:Body> </env:Envelope> Eachthe server. Round Trip Element - An element of an Atom Entryinwhose value is enforced by theserver's response represents a memberserver and not editable by the client. That categorization determines the elements' disposition during editing. +--------------------+------------+ | Atom Entry Element | Property | +--------------------+------------+ | atom:author | Writable | | | | | atom:category | Writable | | | | | atom:content | Writable | | | | | atom:contributor | Writable | | | | | atom:id | Round Trip | | | | | atom:link | Writable | | | | | atom:published | Writable | | | | | atom:source | Writable | | | | | atom:summary | Writable | | | | | atom:title | Writable | | | | | atom:updated | Round Trip | +--------------------+------------+ Table 1 Sayre ExpiresSeptember 26, 2005April 6, 2006 [Page8]11] Internet-Draft The Atom Publishing Protocol (Basic)MarchOctober 2005resource. The client edits member resources by sending HTTP requests to the URI given in5. Media Collections Media Collections are Collections that do not have uniform restrictions on the'href' attributerepresentations of the'pub:edit' element. [[anchor12: cover next/previous feed-level elements]] 3.1.1.1 Atom-Query Clients may require more precise control over the server's response.member resources. For example,the clientthey mightwish to construct a record of the collection's complete membership. [[anchor13: draft-ietf-atompub-protocol-03 attempts to accomplish many of the same goals with a custom ranges-specifier. This editor now believes that's too close to the metal, loses byte ranges, doesn't jive well with intermediaries (because concatenating two XML documents does not result in a well-formed XML document),contain JPEG images, text documents, MPEG movies, andis likely to cause interoperability problems for no good reason.]] The Atom-Query request header field is used to specify a subset of a collection's member resources. It provides four fields: o 'count': the maximum number of Atom Entries to be included in the response. o 'offset': the offset at which to begin the sequenceany other type ofentries that match a given request. o 'begin': Atom entries inresource thereturned feed MUST haveserver allows. 5.1 GET Media Collections return anatom:updated date later in time than the 'begin' date. o 'end':Atomentries in the returnedfeed much like Entry Collections, but with a few additions. The listing MUSThavealso contain anatom:updated date equal or earlier in time than the 'end' date. None of the fields are required. This specification does not define its meaning when usedatom: content element withrequest methods other than GET. Example Atom-Query Header Atom-Query: begin=2003-12-13T18:30:02Z; end=2003-12-25T18:30:02Z; offset=2; count=4; If no 'end' field is present: The 'end' date is considereda 'src' attribute pointing tobe the updated date ofthecollection's most recently updated membermedia resource.If no 'begin' field is present: The 'begin' date is considered toThis URI can be used to edit theupdate date ofuploaded media resource, using PUT and DELETE. Such entries MAY contain pub:edit elements used to edit the entry metadata. As with other collectionleast recently updated member resource. If no 'offset' field is present:members, derived resources can be located by inspecting an entry's atom:link elements. An example Media Collection feed: <feed xmlns="http://www.w3.org/2005/Atom" xmlns:pub="http://purl.org/atom/app#"> <title>My Posts1</title> <author> <name>Foo</name> </author> <id>urn:uuid:ce61592c-14e2-4557-978e-dfbd444aefa6</id> <updated>2005-12-21T04:11:00-08:00</updated> <!-- 0 or more atom:entry elements follow --> <entry> <title type="text">title 25</title> <updated>2005-12-21T04:11:00-08:00</updated> <id>urn:uuid:941e12b4-6eeb-4753-959d-0cbc51875387</id> <link href="/permalink7.html" type="text/html" /> <link href="/stuff/public/beach.jpg" type="image/jpg" title="Low res public version" /> <summary>this was awesome</summary> <content src="http://example.org/asdf.jpg" /> </entry> ... </feed> The'offset' integer is considered toAtom Syndication Format requires that each such entry contain an atom:title and atom:summary element. This requirement can be0.challenging to meet without requiring users to enter tedious Sayre ExpiresSeptember 26, 2005April 6, 2006 [Page9]12] Internet-Draft The Atom Publishing Protocol (Basic)MarchOctober 2005If no 'count' field is present:metadata, but servers SHOULD attempt to provide textual data about the resource in the interests of accessibility. The'count' integer is determinedatom:title element will likely be provided by theserver. [[anchor14: ABNF...]] 3.1.1.2 Atom-Result The Atom-Result response header indicatesclient, as way for users to associate their local resources with those they have uploaded to therange of results returned in a query. It MUST include 'offset','count', and 'total' fields. Example Atom-Result Header Atom-Result: offset=10; count=10; total=35000; [[anchor15: ABNF...]] 3.1.1.3 Example Query Requests and Responses [[anchor17: Examples...]] 3.2 Authoring Atom Entries 3.2.1 Create [[anchor19: POSTingserver (see POST below). 5.2 POST To create media resources, clients POST the resource toentry collection]] 3.2.2 Read [[anchor21: GETthe Media Collection's URI. Clients SHOULD provide a 'Title' request header toan entry's URI]] 3.2.3 Update [[anchor23: PUTprovide the server with a short string identifying the resource toan entry's URI]] 3.2.4 Delete [[anchor25: DELETEusers. Clients MAY include a 'Content-Description' header [RFC2045] providing a more complete description of the content. In addition, servers MAY inspect the POSTed entity for additional metadata to be exposed in anentry's URI]] 3.3 Authoring Generic Resources 3.3.1 Create [[anchor27: POSTingatom:entry when listed in a Media Collection. For example, the server might inspect a JPEG file for EXIF headers containing creator data. An example request. POST /collection HTTP/1.1 Host: example.org User-Agent: Cosimo/1.0 Content-Type: image/jpg Content-Length: nnnn Title: A Trip togeneric collection]]the beach Content-Description: It was so fun. ...binary data... An example request. HTTP/1.1 201 Created Date: Mon, 21 Mar 2005 19:20:19 GMT Server: CountBasic/2.0 ETag: "4c083-268-423f1dc6" Location: http://example.org/stuff/beach.jpg Sayre ExpiresSeptember 26, 2005April 6, 2006 [Page10]13] Internet-Draft The Atom Publishing Protocol (Basic)MarchOctober 2005POST /_do/exampleblog/generic_collection HTTP/1.1 Host: www.example.com Content-Type: image/jpeg Content-Length: nnn ...raw bytes of image go here... 3.3.2 Read [[anchor29: GET to a resource's URI]] 3.3.3 Update [[anchor31: PUT to a resource's URI]] 3.3.4 Delete [[anchor33: DELETE to a resource's URI]] 3.46. ServiceDescriptionOutlines In order for authoring to commence, a client must first discover the capabilities and locations of collections offered. The Service Outline Document is a XOXO outline [XOXO]. The top level list items describe distinct groups of resources offered by the service. For example, a user with anAPP service. 3.4.1 Service Description Documents The Service Description Document describes "workspaces", which are server-defined groupingsaccount containing three blogs would have 3 items at the top ofcollections.the outline. There is no requirement that servers support multipleworkspaces,top-level items, and a collection may appear in more than oneworkspace. <?xml version="1.0" encoding='utf-8'?> <service xmlns="http://purl.org/atom/ns#"> <workspace title="Main Site" > <collection contents="entries" title="My Blog Entries" href="http://example.org/reilly/feed" /> <collection contents="generic" title="Documents" href="http://example.org/reilly/pic" /> </workspace> <workspace title="Side Bar Blog"> <collection contents="entries" title="Entries" href="http://example.org/reilly/feed" /> <collection contents="http://example.net/booklist" title="Books" href="http://example.org/reilly/books" /> </workspace> </service> Sayre Expires September 26, 2005 [Page 11] Internet-Draft The Atom Publishing Protocol (Basic) March 2005 3.4.1.1 Element Definitions 3.4.1.1.1 The 'app:service' Element The "service" element is the document element of a Service Document, acting as a container for service data associated with one or more workspaces. appService = element app:service { ( appWorkspace* & anyElement* ) } The following child elements are defined by this specification: o app:service elements MAY contain any number of app:workspace elements. 3.4.1.1.2 The 'app:workspace' Element The 'workspace' element element contains information elements aboutlocation in thecollections of resources available for editing. appWorkspace = element app:workspace { attribute title { text }, ( appCollection* & anyElement* ) } The following attributes and child elements are defined by this specification: o app:workspace elements MUST contain a 'title' attribute, which conveysdocument. Clients can read entries contained in ahuman-readable name for the workspace o app:workspace elements MAY contain any number of app:collection elements. 3.4.1.1.3 The 'app:collection' Element The 'app:collection' element describes collections and their member resources. Sayre Expires September 26, 2005 [Page 12] Internet-Draft The Atom Publishing Protocol (Basic) March 2005 appCollection = element app:collection { attribute title { text }, attribute contents { text }, attribute href { text }, anyElement* } The following attributes are definedcollection bythis specification: o app:collection elements MUST contain a 'title' attribute, whose value conveys a human-readable name for the workspace o app:collection elements MAY contain a 'contents' attribute (Section 3.4.1.1.3.1). If it is not present, it's value is considered to be 'generic'. o app:collection elements MUST containvisiting an'href' attribute, whose value conveysthe URIoflocated in thecollection. 3.4.1.1.3.1 The 'contents' Attribute The 'contents''href' attributeconveys the natureof acollection's member resources.XOXO outline item. Thisspecification defines two initial values for the 'contents' attribute: o entries o generic Extensibility for 'content' values is handled [[anchor37: SameURI also serves asatom:link]]. [[anchor38: Define each 'contents' value...]] 3.4.2 Request and Response To retrieve a Service Description document,theclient sendslocation aGET request to its URI. GET /service-desc HTTP/1.1 Host: example.org User-Agent: Cosimo/1.0 Accept: application/atom+xml Accept-Encoding: gzip, *;q=0 In the example, theclienthas included an 'Accept' header, ensuringPOSTs new entries to. The 'rel' attribute of theresponse will beXHTML anchor element conveys the nature of a collection's member resources. This specification defines two initial values for thecorrect'rel' attribute: o entry o mediatype. Otherwise,These values correspond to theserver might return another typetwo types ofdocument, such as an HTML or text file.collection defined by this specification. Extensibility for 'rel' values is specified in XHTML Modularization [W3C.REC-xhtml-modularization-20010410]. Sayre ExpiresSeptember 26, 2005April 6, 2006 [Page13]14] Internet-Draft The Atom Publishing Protocol (Basic)March 2005 The server responds to a GET request by returning a Service Description document in the message body. HTTP/1.1 200 OK Date: Mon, 21 Mar 2005 19:20:19 GMT Server: CountBasic/2.0 Last-Modified: Mon, 21 MarOctober 200519:17:26 GMT ETag: "4c083-268-423f1dc6" Accept-Ranges: bytes Content-Length: 616 Content-Type: application/atom+xml ...An example ServiceDescription bytes ... 4. Extensions to theOutline: <ul class="xoxo"> <li> <a href="/app/collection.py?id=1&type=entries" rel="entry" type="application/atom+xml">Main Blog</a> <ul> <li><a href="/app/collection.py?id=2&type=media" rel="media" type="application/atom+xml">My Stuff2</a> </li> </ul> </li> <li> <a href="/app/collection.py?id=3&type=entries" rel="entry" type="application/atom+xml">Side Bar Blog</a> <ul> <li><a href="/app/collection.py?id=4&type=media" rel="media" type="application/atom+xml">My Stuff4</a> </li> </ul> </li> <li> <a href="/app/collection.py?id=5&type=entries" rel="entry" type="application/atom+xml">A Third Blog</a> <ul> <li> <a href="/app/collection.py?id=6&type=media" rel="media" type="application/atom+xml">My Stuff6</a> </li> </ul> </li> </ul> Sayre Expires April 6, 2006 [Page 15] Internet-Draft The AtomSyndication Format [[anchor41: Document pub: elements]] 5.Publishing Protocol (Basic) October 2005 7. Security Considerations[[anchor43: 2617, TLS, etc]] [[anchor44: Talk here about denialBecause APP is a publishing protocol, it is important that only authorized users can create and edit entries. APP relies on HTTP Authentication. See [RFC2617] for more detailed description ofservice attacks using large XML files, orthebillion laughs DTD attack.]] 6. IANA Considerations This document has no actions for IANA. 7.security properties of HTTP Authentication. 8. Normative References [AtomFormat] Nottingham, M. and R. Sayre, "The Atom Syndication Format", work-in-progress,MarchAugust 2005. [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach,P.P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,Sayre Expires September 26, 2005 [Page 14] Internet-Draft The Atom Publishing Protocol (Basic) March 2005Leach, P., Luotonen,A.A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.[W3C.REC-soap12-part1-20030624] Nielsen, H., Mendelsohn, N., Gudgin, M., Hadley,[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC3987] Duerst, M. andJ. Moreau, "SOAP Version 1.2 Part 1: Messaging Framework",M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005. [W3C.REC-xhtml-modularization-20010410] Altheim, M., Boumphrey, F., McCarron, S., Dooley, S., Schnitzenbaumer, S., and T. Wugofski, "Modularization of XHTML", W3C RECREC-soap12-part1-20030624, June 2003.REC-xhtml-modularization-20010410, April 2001. [W3C.REC-xml-20040204] Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray,T.T., and E. Maler, "Extensible Markup Language (XML) 1.0 (Third Edition)", W3C REC REC-xml-20040204, February 2004.[1] <http://www.imc.org/atom-protocol/index.html>Sayre Expires April 6, 2006 [Page 16] Internet-Draft The Atom Publishing Protocol (Basic) October 2005 [XOXO] Marks, K., Celik, T., Pilgrim, M., and M. Peterson, "XOXO 1.0: Extensible Open XHTML Outlines", October 2004. Author's Address Robert SayreBoswijck Memex Consulting 148 N 9th St. 4R Brooklyn, NY 11211 USEmail: rfsayre@boswijck.com URI: http://boswijck.com Sayre ExpiresSeptember 26,April 6, 2006 [Page 17] Internet-Draft The Atom Publishing Protocol (Basic) October 2005 Appendix A. Contributors This draft is a variant of the in-progress Atom Publishing Protocol specification from the IETF Atompub WG, and owes a debt to the WG's members. Sayre Expires April 6, 2006 [Page15]18] Internet-Draft The Atom Publishing Protocol (Basic)MarchOctober 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Sayre ExpiresSeptember 26, 2005April 6, 2006 [Page16]19] Internet-Draft The Atom Publishing Protocol (Basic)MarchOctober 2005 Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Sayre ExpiresSeptember 26, 2005April 6, 2006 [Page17]20] ----