draft-ietf-atompub-protocol-02.txt		draft-ietf-atompub-protocol-03.txt
	Network Working Group J. Gregorio, Ed.		Network Working Group J. Gregorio, Ed.
	Internet-Draft BitWorking, Inc		Internet-Draft BitWorking, Inc
	Expires: March 22, 2005 R. Sayre, Ed.		Expires: September 19, 2005 R. Sayre, Ed.
	Boswijck Memex Consulting		Boswijck Memex Consulting
	September 21, 2004		March 18, 2005
	The Atom Publishing Protocol		The Atom Publishing Protocol
	draft-ietf-atompub-protocol-02.txt		draft-ietf-atompub-protocol-03.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		This document is an Internet-Draft and is subject to all provisions
	patent or other IPR claims of which I am aware have been disclosed,		of Section 3 of RFC 3667. By submitting this Internet-Draft, each
	and any of which I become aware will be disclosed, in accordance with		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 she become aware will be disclosed, in accordance with
	RFC 3668.		RFC 3668.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as		other groups may also distribute working documents as
	Internet-Drafts.		Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on March 22, 2005.		This Internet-Draft will expire on September 19, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2005).
	Abstract		Abstract
	This memo presents a protocol for using XML (Extensible Markup		This memo presents a protocol for using XML (Extensible Markup
	Language) and HTTP (HyperText Transport Protocol) to edit content.		Language) and HTTP (HyperText Transport Protocol) to edit content.
	The Atom Publishing Protocol is an application-level protocol for		The Atom Publishing Protocol is an application-level protocol for
	publishing and editing Web resources belonging to periodically		publishing and editing Web resources belonging to periodically
	updated websites. The protocol at its core is the HTTP transport of		updated websites. The protocol at its core is the HTTP transport of
	Atom-formatted representations. The Atom format is documented in the		Atom-formatted representations. The Atom format is documented in the
	Atom Syndication Format (draft-ietf-atompub-format-02.txt).		Atom Syndication Format (draft-ietf-atompub-format-06.txt).
	Editorial Note		Editorial Note
	To provide feedback on this Internet-Draft, join the		To provide feedback on this Internet-Draft, join the atom-syntax
	<http://www.imc.org/atom-syntax/index.html>.		mailing list (http://www.imc.org/atom-syntax/index.html) [1].
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1 Notational Conventions . . . . . . . . . . . . . . . . . . 4		1.1 Notational Conventions . . . . . . . . . . . . . . . . . . 4
	1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	2. The Atom Publishing Protocol Model . . . . . . . . . . . . . 4		2. The Atom Publishing Protocol Model . . . . . . . . . . . . . 4
			2.1 Atom Collections . . . . . . . . . . . . . . . . . . . . . 4
			2.1.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . 5
			2.1.2 Client and Server Interaction . . . . . . . . . . . . 5
	3. Functional Specification . . . . . . . . . . . . . . . . . . 5		3. Functional Specification . . . . . . . . . . . . . . . . . . 5
	3.1 PostURI . . . . . . . . . . . . . . . . . . . . . . . . . 5		3.1 Collections . . . . . . . . . . . . . . . . . . . . . . . 6
	3.1.1 Locating the PostURI . . . . . . . . . . . . . . . . . 5		3.1.1 Collection Document . . . . . . . . . . . . . . . . . 6
	3.1.2 Request . . . . . . . . . . . . . . . . . . . . . . . 5		3.1.2 Elements in a Collection Document . . . . . . . . . . 6
	3.1.3 Response . . . . . . . . . . . . . . . . . . . . . . . 5		3.1.3 Collection Requests . . . . . . . . . . . . . . . . . 7
	3.2 EditURI . . . . . . . . . . . . . . . . . . . . . . . . . 7		3.2 Introspection . . . . . . . . . . . . . . . . . . . . . . 8
	3.2.1 Locating . . . . . . . . . . . . . . . . . . . . . . . 7		3.2.1 Service Document . . . . . . . . . . . . . . . . . . . 8
	3.2.2 Request . . . . . . . . . . . . . . . . . . . . . . . 7		3.3 Entry Collection . . . . . . . . . . . . . . . . . . . . . 9
	3.3 FeedURI . . . . . . . . . . . . . . . . . . . . . . . . . 9
	3.3.1 Locating . . . . . . . . . . . . . . . . . . . . . . . 10		3.3.1 Locating . . . . . . . . . . . . . . . . . . . . . . . 10
	3.3.2 Request . . . . . . . . . . . . . . . . . . . . . . . 10		3.4 Simple Resource Collection . . . . . . . . . . . . . . . . 10
	3.3.3 Response . . . . . . . . . . . . . . . . . . . . . . . 10
	3.4 ResourcePostURI . . . . . . . . . . . . . . . . . . . . . 10
	3.4.1 Locating . . . . . . . . . . . . . . . . . . . . . . . 10		3.4.1 Locating . . . . . . . . . . . . . . . . . . . . . . . 10
	3.4.2 Request . . . . . . . . . . . . . . . . . . . . . . . 11		3.4.2 Request . . . . . . . . . . . . . . . . . . . . . . . 10
	3.4.3 Response . . . . . . . . . . . . . . . . . . . . . . . 11		3.5 Atom Request and Response Body Constraints . . . . . . . . 11
	3.5 Link Tag . . . . . . . . . . . . . . . . . . . . . . . . . 12		3.5.1 id . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	3.5.1 rel . . . . . . . . . . . . . . . . . . . . . . . . . 12		3.5.2 link . . . . . . . . . . . . . . . . . . . . . . . . . 11
	3.5.2 href . . . . . . . . . . . . . . . . . . . . . . . . . 12		3.5.3 title . . . . . . . . . . . . . . . . . . . . . . . . 11
	3.5.3 title . . . . . . . . . . . . . . . . . . . . . . . . 13		3.5.4 summary . . . . . . . . . . . . . . . . . . . . . . . 11
	3.5.4 type . . . . . . . . . . . . . . . . . . . . . . . . . 13		3.5.5 content . . . . . . . . . . . . . . . . . . . . . . . 12
	3.6 Atom Request and Response Body Constraints . . . . . . . . 13		3.5.6 issued . . . . . . . . . . . . . . . . . . . . . . . . 12
	3.6.1 id . . . . . . . . . . . . . . . . . . . . . . . . . . 13		3.5.7 modified . . . . . . . . . . . . . . . . . . . . . . . 12
	3.6.2 link . . . . . . . . . . . . . . . . . . . . . . . . . 13		3.5.8 created . . . . . . . . . . . . . . . . . . . . . . . 12
	3.6.3 title . . . . . . . . . . . . . . . . . . . . . . . . 13		3.5.9 author . . . . . . . . . . . . . . . . . . . . . . . . 13
	3.6.4 summary . . . . . . . . . . . . . . . . . . . . . . . 14		3.5.10 contributor . . . . . . . . . . . . . . . . . . . . 13
	3.6.5 content . . . . . . . . . . . . . . . . . . . . . . . 14		3.5.11 generator . . . . . . . . . . . . . . . . . . . . . 13
	3.6.6 issued . . . . . . . . . . . . . . . . . . . . . . . . 14		3.6 Securing the Atom Protocol . . . . . . . . . . . . . . . . 13
	3.6.7 modified . . . . . . . . . . . . . . . . . . . . . . . 15		3.6.1 [@@TBD@@ CGI Authentication] . . . . . . . . . . . . . 14
	3.6.8 created . . . . . . . . . . . . . . . . . . . . . . . 15		4. Security Considerations . . . . . . . . . . . . . . . . . . 14
	3.6.9 author . . . . . . . . . . . . . . . . . . . . . . . . 15		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14
	3.6.10 contributor . . . . . . . . . . . . . . . . . . . . 15		6. Appendix A - SOAP Enabling . . . . . . . . . . . . . . . . . 15
	3.6.11 generator . . . . . . . . . . . . . . . . . . . . . 15		6.1 Servers . . . . . . . . . . . . . . . . . . . . . . . . . 15
	3.7 Securing the Atom Protocol . . . . . . . . . . . . . . . . 16		6.2 Clients . . . . . . . . . . . . . . . . . . . . . . . . . 15
	3.7.1 [@@TBD@@ CGI Authentication] . . . . . . . . . . . . . 16		7. Appendix B - Examples . . . . . . . . . . . . . . . . . . . 15
	4. Security Considerations . . . . . . . . . . . . . . . . . . 16		7.1 Example for a weblog . . . . . . . . . . . . . . . . . . . 15
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 17		7.2 Example for a wiki . . . . . . . . . . . . . . . . . . . . 15
	6. Appendix A - SOAP Enabling . . . . . . . . . . . . . . . . . 17		8. Revision History . . . . . . . . . . . . . . . . . . . . . . 15
	6.1 Servers . . . . . . . . . . . . . . . . . . . . . . . . . 17		9. Normative References . . . . . . . . . . . . . . . . . . . . 17
	6.2 Clients . . . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18
	7. Appendix B - Examples . . . . . . . . . . . . . . . . . . . 17		Intellectual Property and Copyright Statements . . . . . . . 19
	7.1 Example for a weblog . . . . . . . . . . . . . . . . . . . 17
	7.2 Example for a wiki . . . . . . . . . . . . . . . . . . . . 18
	8. Revision History . . . . . . . . . . . . . . . . . . . . . . 18
	9. Normative References . . . . . . . . . . . . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20
	Intellectual Property and Copyright Statements . . . . . . . 21
	1. Introduction		1. Introduction
	The Atom Publishing Protocol is an application-level protocol for		The Atom Publishing Protocol is an application-level protocol for
	publishing and editing Web resources using HTTP [RFC2616] and XML.		publishing and editing Web resources using HTTP [RFC2616] and XML.
	1.1 Notational Conventions		1.1 Notational Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	1.2 Terminology		1.2 Terminology
	Atom Entry: An Atom Entry is a fragment of a full Atom feed. In this		Atom Entry: An Atom Entry is a fragment of a full Atom feed. In this
	case, the fragment is a single 'entry' element and all its child		case, the fragment is a single 'entry' element and all its child
	elements. Each Atom Entry describes a single Web resource,		elements. Each Atom Entry describes a single Web resource,
	providing metadata and optionally a textual representation of that		providing metadata and optionally a textual representation of that
	resource.		resource.
	PostURI: A URI that is used to create new resources. POSTing an Atom
	Entry to this URI will create a new resource.
	EditURI: A URI that is used to edit a resource. The editing is done
	using the HTTP verbs GET, PUT and DELETE. The representation of
	the resource is always that of an Atom Entry.
	FeedURI: The URI which identifies an Atom Feed.
	2. The Atom Publishing Protocol Model		2. The Atom Publishing Protocol Model
	The Atom Publishing Protocol is an application-level protocol for		The Atom Publishing Protocol is an application-level protocol for
	publishing and editing Web resources. Using the common HTTP verbs		publishing and editing Web resources. The primary way of interaction
	provides a pattern for working with all such Web resources:		in the Atom Publishing Protocol is by managing collection of
			resources. All collections support the same basic methods of
			interaction. In addition, the resources belonging to collections
			also share the same interaction patterns. Using the common HTTP
			verbs provides a pattern for working with all such Web resources:
	o GET is used to retrieve a representation of a resource or perform		o GET is used to retrieve a representation of a resource or perform
	a read-only query.		a read-only query.
	o PUT is used to update a known resource.		o PUT is used to update a known resource.
	o POST is used to create a new dynamically-named resource.		o POST is used to create a new dynamically-named resource.
	o DELETE is used to remove a resource.		o DELETE is used to remove a resource.
	There are four major classes of URI [RFC2396] in this specification:		2.1 Atom Collections
	PostURI, ResourcePostURI, FeedURI, and EditURI. This specification
	defines the expected actions for each of the methods listed. A URI
	MAY support methods not listed here. For example, an EditURI could
	support a POST or OPTIONS method. However, what those methods do is
	beyond the scope of this specification.
	o EditURI: PUT, GET, DELETE
	o PostURI: POST
	o FeedURI: GET
	o ResourcePostURI: POST
	This document does not specify the form of the URIs that are used.		An Atom collection is a set of items all of the same type ("members"
			of the collection), where the "type" may be, for example: Atom entry,
			category, template, "simple resource", or any other classification of
			web resource.
			Each collection has a URI which is given in the introspection file.
			A GET on the collection URI MUST produce a collection document as
			defined in "3.X.1 Collection Document." That document describes PART
			OF the state of the collection.
			All the members of a collection have an "updated" property, and the
			collection is considered to be ordered by this property. A single
			collection document may not contain all of the members of a
			collection. If a collection document is the response of a
			non-partial GET request, and does not contain all of the members of a
			collection, then it will contain the URI of the next collection
			document which will contain more of the collection members. By
			traversing this list of collection documents a client can obtain all
			of the members of a collection. The 'next' attribute will not be
			present in the response to a partial GET request.
			2.1.1 Usage
			Below two usages are outlined for Atom Collections. They are here to
			highlight common idioms for interacting with a Collection Resource
			and not a normative interaction pattern.
			The Atom Collection can be used by clients in two ways. In the first
			case the client has attached to a site for the first time and is
			doing an initial syncronization, that is, retrieving a list of all
			the members of the collections and possibly retrieving all the
			members of the collection also. The client can perform a non-partial
			GET on the collection resource and it will receive a collection
			document that either contains all the member of the collection, or
			the collection document root element 'collection' will contain a
			'next' attribute pointing to the next collection document. By
			repeatedly following the 'next' attribute from document to document
			the client can find all the members of the collection.
			In the second case the client has already done an initial sync, and
			now needs to re-sync, because the client was just restarted, or some
			time has passed since a re-sync, etc. The client does a partial GET
			on the collection document, supplying a Range header that begins from
			the last time the client sync'd to the current time. The collection
			document returned will contain only those members of the collection
			that have changed since the last time the client syncronized.
			2.1.2 Client and Server Interaction
			[[anchor5: ...]]
			This document does not specify the form of the URIs that are used.
	The URI space of each server is controlled, as defined by HTTP, by		The URI space of each server is controlled, as defined by HTTP, by
	the server alone. What this document does specify are the formats of		the server alone. What this document does specify are the formats of
	the files that are exchanged and the actions that can be performed on		the files that are exchanged and the actions that can be performed on
	the URIs embedded in those files.		the URIs embedded in those files.
	3. Functional Specification		3. Functional Specification
	3.1 PostURI		3.1 Collections
	The PostURI is used to create entries. These can be either full		3.1.1 Collection Document
	entries, such as a weblog post, or they can be comments, or even a
	wiki page. The client POSTs a filled-in Atom Entry to this URI. If
	the request is successful, one or more Web resources MAY be created.
	For example, POSTing an Atom entry to a PostURI may create two new
	Web resources, an HTML representation and an Atom representation.
	3.1.1 Locating the PostURI		A collection document is rooted by a <collection> element. A
			collection element may have any number of <member> elements as
			children; each such element identifies a member of the collection.
			In some situations, a collection document may not contain every
			member of the collection itself.
	The PostURI can be discovered in a link element with an @rel of		Whether complete or partial, the members in a collection document
	'service.post'. The link element containing a PostURI used to create		MUST constitute a consecutive sequence of the collection's members,
	a new entry MAY be discovered in three different places. The first		ordered by their "updated" properties. That is, a collection
	place it may be found is in a <link> element in the 'head' element of		document MUST contain a contiguous subset of the members of the
	an HTML document.		collection ordered by their 'updated' property.
	The second place a PostURI may be found an atom:link element that is		3.1.2 Elements in a Collection Document
	a child of the atom:feed element. The third place a PostURI may be
	found is in the atom:link element of an atom:entry.
	@@ TBD @@ - Discuss subordinate resources and what a PostURI means		A collection document MAY contain zero or more 'member' elements.
	based on where the URI was found.
	<link rel="service.post"		Each 'member' element MUST include an 'href' attribute identifying a
	type="application/atom+xml"		URL of the member resource. The 'href' URI of a member resource is
	href="URI for Posting goes here"		an "EditURI" under the terms of section 2, and MUST respond to the
	title="The name of the site." />		same HTTP methods as such an EditURI.
	3.1.2 Request		Each 'member' element MAY include an "hrefreadonly" attribute. This
			optional attribute identifies a URI which, on a GET request, responds
			equivalently to how the "href" URI would respond to the same request.
			Clients SHOULD NOT apply to this URI any HTTP methods that would be
			expected to modify the state of the resource (e.g. PUT, POST or
			DELETE). A PUT or POST request to this URI MAY NOT affect the
			underlying resource. If the "hrefreadonly" attribute is not given,
			its value defaults to the "href" value. If the "hrefreadonly"
			attribute is present, and its value is an empty string, then there is
			no URI that can be treated in the way such a value would be treated.
	The request contains a filled-in Atom entry, subject to the		Clients SHOULD use the "href" value to manipulate the resource within
	constraints in section Section 3.6.		the context of the APP itself. Clients SHOULD prefer the
			"hrefreadonly" value in any other context. For example, if the
			resource is an image, a client may replace the image data using a PUT
			on the "href" value, and may even display a preview of the image by
			fetching the "href" URI. But when creating a public, read-only
			reference to the same image resource, the client should use the
			"hrefreadonly" value. If the "hrefreadonly" value is an empty
			string, the client SHOULD NOT make public reference to the "href"
			value.
	3.1.3 Response		Each 'member' element MUST include a 'title' attribute, whose value
			is a human-readable name or description for the item. The values of
			'title' attributes are not required to be unique across all members
			of a collection.
	The possible status codes from a POST are 201, 303, 400, 404, 409,		Each 'member' element MUST include an 'updated' attribute, whose
	410 and 500.		value is the 'updated' property of the collection member whose format
			MUST conform to the date-time BNF rule in [RFC3339].
	3.1.3.1 Response code 201		3.1.3 Collection Requests
	The Response MUST include a Location: header with the URI of the		3.1.3.1 Range: Header
	created resource. The URI returned must be the EditURI of the entry
	just created. The body of the response SHOULD contain the newly
	created entry. If the entry is present in the response body then it
	MUST conform to the same constraints listed for responses to a GET on
	an EditURI. User agents MUST NOT depend on the server returning a
	response body. If the server does return a response body then the
	user agents MUST NOT depend on the response body having a
	content-type of 'application/atom+xml". Note that the server may
	choose to omit the content in the response, particularly if it is
	large.
	A 201 response MAY contain an ETag response header field indicating		HTTP/1.1 allows a client to request that only part (a range of) the
	the current value of the entity tag for the requested variant just		collection to be included within the response. HTTP/1.1 uses range
	created.		units in the Range header field. A collection can be broken down
			into subranges according to the members 'updated' property. If a
			Range: header is present in the request, its value explictly
			identifies the a time interval interval in which all the members
			'updated' property must fall to be included in the response.
	If the entry returned is subsequently changed the user agent can		Range = "Range" ":" ranges-specifier
	update the entry by submitting it via PUT to the EditURI. If an ETag
	was returned with the creation of the entry then the user agent
	SHOULD include an If-Match: header in the request that contains that
	ETag.
	3.1.3.2 Response code 303		The value of the Range: header should be a pair of ISO 8601 dates,
			separated by a slash character; either date may be optionally
			omitted, in which case the range is understood as stretching to
			infinity on that end.
	The body of this response does not contain the filled-in Entry, but		ranges-specifier = updated-ranges-specifier
	the filled-in Entry can be found under a different URI and can be		updated-ranges-specifier = updated-unit "=" updated-range
	retrieved using a GET method on that resource. The URI SHOULD be		updated-unit = "updated"
	given by the Location field in the response.		updated-range = [iso-date] "/" [iso-date]
	3.1.3.3 Response code 400		The response to a collection request MUST be a collection document,
			all of whose 'member' elements fall within the requested range. If
			no members fall in the requested range, the server MUST respond with
			a collection document containing no 'member' elements.
	Indicates that the server believes that the data sent constitutes an		3.1.3.2 Accept-Ranges: Header
	invalid request. As an example, the data posted may not be
	well-formed XML. The server SHOULD include an entity containing an
	explanation of the error situation, and whether it is a temporary or
	permanent condition.
	3.1.3.4 Response code 409		The response to a non-partial GET request MUST include an
			Accept-Ranges header that indicates that the server accepts 'updated'
			range requests.
	The request contained a valid Atom Entry, but it conflicts with state		Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges
	on the server. The response SHOULD contain enough for information		acceptable-ranges = updated-unit ( 1#range-unit )
	for the user to resolve the conflict.
	[[@@TBD@@ more about response body format]]		3.2 Introspection
	3.1.3.5 Response code 500		There are many different kinds of resources that can be managed
			through the APP, for example, entries, templates, users, etc. The
			Service Document is a single document that lists all the facets of
			the APP that a site supports and also contains the URIs of all those
			resources.
	Indicates that the server detected an internal error on the server		3.2.1 Service Document
	processing this request (such as an unhandled exception). The server
	SHOULD include an entity containing an explanation of the error
	situation, and whether it is a temporary or permanent condition.
	3.2 EditURI		The Service Document lists the resources that each site makes
			available. The Service Resource returns an Service Document in
			response to a GET request. Here is an example of an Service
			Document.
	An EditURI is used to edit a single entry. Each entry that is		<?xml version="1.0" encoding='utf-8'?>
			<service version="0.3" xmlns="http://purl.org/atom/ns#">
			<workspace title="Main Site" >
			<collection rel="entries" name="Entries"
			href="http://example.org/reilly/feed" />
			<collection rel="categories" name="Categories"
			href="http://example.org/reilly/cat" />
			<collection rel="templates" name="Templates"
			href="http://example.org/reilly/tmpl" />
			<collection rel="users" name="Users"
			href="http://example.org/reilly/users" />
			<collection rel="resource" name="Pictures"
			href="http://example.org/reilly/pic" />
			</workspace>
			<workspace title="b-links">
			<collection rel="entries" name="Entries"
			href="http://example.org/reilly/feed" />
			<collection rel="http://example.net/booklist" name="Books"
			href="http://example.org/reilly/books" />
			</workspace>
			</service>
			o entries
			o resource
			o categories
			o templates
			o users
			The default for the rel attribute is 'resource'. Extensibility for
			'rel' values is handled in the same manner as PaceFieldingLinks.
			Each 'collection' element in 'workspace' represents a single facet of
			the APP. While a site must fully support each facet they list in
			their Service Document, a site does not need to support all the
			facets in this RFC. Additionally, new facets may be added either
			through vendor extension or follow-on RFCs.
			3.2.1.1 Service Documet Elements
			The "service" element is the document element of a Service Document,
			acting as a container for service data associated with possibly
			multiple workspaces. Its only child elements MUST be one or more
			'workspace' elements. The 'service' element MUST have a single
			attribute 'version' whose content indicates the version of the Atom
			specification that the document conforms to. The content of this
			attribute is unstructured text. The version identifier for this
			specification is "1.0".
			The 'workspace' element element contains information elements about
			the collections of resources available for editing. The only
			children of 'workspace' MUST be one or more "collection" elements.
			The 'workspace' element MUST have a single attribute 'title' whose
			content MUST NOT be empty and which is a human-readable name for the
			workspace.
			The 'collection' element describes various typed groups of resources
			available for editing or adding to.
			3.3 Entry Collection
			Entries are managed through collections and as such entry collection
			and entries that are members of a collection must support all the
			operations enumerated above.
			An Edit Resource is used to edit a single entry. Each entry that is
	editable MUST have a unique URI. This URI supports both GET and PUT		editable MUST have a unique URI. This URI supports both GET and PUT
	and they are used in tandem for an editing cycle. The client GETs		and they are used in tandem for an editing cycle. The client GETs
	the representation which is formatted as an Atom entry. The client		the representation which is formatted as an Atom entry. The client
	may then update the entry and then PUT it back to the same URI. The		may then update the entry and then PUT it back to the same URI. The
	PUT will cause all the related resources to be updated, for example,		PUT will cause all the related resources to be updated, for example,
	the HTML representation.		the HTML representation.
	Note that the value of the content element in the Atom entry does not		Note that the value of the content element in the Atom entry does not
	have to exactly match the content element for the same entry when it		have to exactly match the content element for the same entry when it
	is represented in an Atom feed. For example, a server may allow the		is represented in an Atom feed. For example, a server may allow the
	client to post entries whose content is formatted as WikiML, yet the		client to post entries whose content is formatted as WikiML, yet the
	server may clean up such markup and transform it into well-formed		server may clean up such markup and transform it into well-formed
	XHTML before placing it in the publicly available Atom feed. Another		XHTML before placing it in the publicly available Atom feed. Another
	scenario is summaries--the EditURI is for editing the full content of		scenario is summaries--the EditURI is for editing the full content of
	an entry, but the server may only present excerpts when it produces		an entry, but the server may only present excerpts when it produces
	an Atom feed.		an Atom feed.
	A client will send a DELETE to the EditURI to delete an entry.		A client will send a DELETE to the EditURI to delete an entry.
	3.2.1 Locating		3.3.1 Locating
	For editing a site Entry, the link tag is used. Note that a link tag		For editing a site Entry, the link tag is used. Note that a link tag
	is used in both HTML and in the Atom format. A link tag of the		is used in both HTML and in the Atom format. A link tag of the
	following format points to the EditURI for a site. In HTML, the link		following format points to the EditURI for a site. In HTML, the link
	tags for editing are always found in the head element, while in Atom		tags for editing are always found in the head element, while in Atom
	they may appear as children of the entry elements.		they may appear as children of the entry elements.
	<link rel="service.edit"		<link rel="service.edit"
	type="application/atom+xml"		type="application/atom+xml"
	href="URI for Editing goes here"		href="URI for Editing goes here"
	title="Readable desc of the entry." />		title="Readable desc of the entry." />
	Note: The critical characteristic of this link tag is the @rel of		Note: The critical characteristic of this link tag is the @rel of
	'service.edit' and the @type of 'application/atom+xml'.		'service.edit' and the @type of 'application/atom+xml'.
	3.2.2 Request		3.4 Simple Resource Collection
	A PUT request, and a GET response both contain a filled-in Atom
	entry, subject to the constraints in section Section 3.6.
	The expected status codes from a GET are 200, 301, 307, and 500.
	400, 404, and 410 are also possible.
	The expected status codes from a PUT are 2xx, 301, 307, 500 and 501.
	400, 404, 409, and 410 are also possible.
	3.2.2.1 Successful Requests
	Servers MUST indicate successful GET requests with a 200 response.
	Servers MUST indicate successful PUT requests with a 2xx response.
	Servers MAY include additional information in the PUT response.
	Clients SHOULD NOT expect any additional information in a PUT
	response.
	3.2.2.2 Response code 301
	The entry has moved permanently, the new URI is given in the Location
	header. The client SHOULD retry the GET using the URI returned in
	the Location header. When a PUT operation is attempted the user
	agent should prompt the user before attempting the PUT on the URI
	returned in the Location header.
	3.2.2.3 Response code 307
	The entry has moved temporarily, the new URI is given in the Location
	header. The client SHOULD retry the GET using the URI returned in
	the Location header. When a PUT operation is attempted the user
	agent should prompt the user before attempting the PUT on the URI
	returned in the Location header.
	3.2.2.4 Response code 401
	Indicates that the server believes that the data sent constitutes an
	invalid request. As an example, the data posted may not be
	well-formed XML. The server SHOULD include an entity containing an
	explanation of the error situation, and whether it is a temporary or
	permanent condition.
	3.2.2.5 Response code 409
	The request contained a valid Atom Entry, but it conflicts with the
	state of the resource, or other state on the server.
	For example, a server could signal that the client has erred in this
	manner if it receives a request containing an atom:id element whose
	value differs from that of the resource found at the requested URI.
	The response SHOULD contain enough for information for the user to
	resolve the conflict.
	[[@@TBD@@ more about response body format ]]
	3.2.2.6 Response code 410
	Indicates that the requested resource is gone permanently. The
	client SHOULD NOT repeat the request.
	3.2.2.7 Response code 500
	Indicates that the server detected an internal error on the server
	processing this request (such as an unhandled exception). The server
	SHOULD include an entity containing an explanation of the error
	situation, and whether it is a temporary or permanent condition.
	3.3 FeedURI
				<