idnits 2.17.1 

draft-ietf-atompub-protocol-11.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

  ** It looks like you're using RFC 3978 boilerplate.  You should update this
     to the boilerplate described in the IETF Trust License Policy document
     (see https://trustee.ietf.org/license-info), which is required now.

  -- Found old boilerplate from RFC 3978, Section 5.1 on line 16.

  -- Found old boilerplate from RFC 3978, Section 5.5 on line 1964.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1936.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1943.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1949.

  ** This document has an original RFC 3978 Section 5.4 Copyright Line,
     instead of the newer IETF Trust Copyright according to RFC 4748.

  ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
     of the newer disclaimer which includes the IETF Trust according to RFC
     4748.


  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  == No 'Intended status' indicated for this document; assuming Proposed
     Standard


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** The abstract seems to contain references ([RFC4287], [1]), which it
     shouldn't.  Please replace those with straight textual mentions of the
     documents in question.


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
     match the current year

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer. 
     (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)

  -- The document date (October 03, 2006) is 6415 days in the past.  Is this
     intentional?

  -- Found something which looks like a code comment -- if you have code
     sections in the document, please surround them with '<CODE BEGINS>' and
     '<CODE ENDS>' lines.


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231,
     RFC 7232, RFC 7233, RFC 7234, RFC 7235)

  ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615,
     RFC 7616, RFC 7617)

  ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110)

  ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303)

  ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246)


     Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

--------------------------------------------------------------------------------


2	Network Working Group                                   J. Gregorio, Ed.
3	Internet-Draft                                                       IBM
4	Expires: April 6, 2007                                   B. de hOra, Ed.
5	                                                           Propylon Ltd.
6	                                                        October 03, 2006

8	                      The Atom Publishing Protocol
9	                   draft-ietf-atompub-protocol-11.txt

11	Status of this Memo

13	   By submitting this Internet-Draft, each author represents that any
14	   applicable patent or other IPR claims of which he or she is aware
15	   have been or will be disclosed, and any of which he or she becomes
16	   aware will be disclosed, in accordance with Section 6 of BCP 79.

18	   Internet-Drafts are working documents of the Internet Engineering
19	   Task Force (IETF), its areas, and its working groups.  Note that
20	   other groups may also distribute working documents as Internet-
21	   Drafts.

23	   Internet-Drafts are draft documents valid for a maximum of six months
24	   and may be updated, replaced, or obsoleted by other documents at any
25	   time.  It is inappropriate to use Internet-Drafts as reference
26	   material or to cite them other than as "work in progress."

28	   The list of current Internet-Drafts can be accessed at
29	   http://www.ietf.org/ietf/1id-abstracts.txt.

31	   The list of Internet-Draft Shadow Directories can be accessed at
32	   http://www.ietf.org/shadow.html.

34	   This Internet-Draft will expire on April 6, 2007.

36	Copyright Notice

38	   Copyright (C) The Internet Society (2006).

40	Abstract

42	   The Atom Publishing Protocol (APP) is an application-level protocol
43	   for publishing and editing Web resources.  The protocol is based on
44	   HTTP transport of Atom-formatted representations.  The Atom format is
45	   documented in the Atom Syndication Format [RFC4287].

47	Editorial Note
48	   To provide feedback on this Internet-Draft, join the atom-protocol
49	   mailing list (http://www.imc.org/atom-protocol/index.html) [1].

51	Table of Contents

53	   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   4
54	   2.   Notational Conventions . . . . . . . . . . . . . . . . . . .   5
55	     2.1  XML-related Conventions  . . . . . . . . . . . . . . . . .   5
56	       2.1.1  Referring to Information Items . . . . . . . . . . . .   5
57	       2.1.2  RELAX NG Schema  . . . . . . . . . . . . . . . . . . .   5
58	       2.1.3  Use of xml:base and xml:lang . . . . . . . . . . . . .   5
59	   3.   Terminology  . . . . . . . . . . . . . . . . . . . . . . . .   6
60	   4.   Protocol Model . . . . . . . . . . . . . . . . . . . . . . .   7
61	   5.   Protocol Operations  . . . . . . . . . . . . . . . . . . . .   9
62	     5.1  Retrieving a Service Document  . . . . . . . . . . . . . .   9
63	     5.2  Listing Collection Members . . . . . . . . . . . . . . . .   9
64	     5.3  Creating a Resource  . . . . . . . . . . . . . . . . . . .  10
65	     5.4  Editing a Resource . . . . . . . . . . . . . . . . . . . .  10
66	       5.4.1  Retrieving a Resource  . . . . . . . . . . . . . . . .  10
67	       5.4.2  Updating a Resource  . . . . . . . . . . . . . . . . .  11
68	       5.4.3  Deleting a Resource  . . . . . . . . . . . . . . . . .  11
69	     5.5  Use of HTTP Response codes . . . . . . . . . . . . . . . .  11
70	   6.   Atom Publishing Protocol Documents . . . . . . . . . . . . .  12
71	     6.1  Document Types . . . . . . . . . . . . . . . . . . . . . .  12
72	     6.2  Document Extensibility . . . . . . . . . . . . . . . . . .  12
73	   7.   Category Documents . . . . . . . . . . . . . . . . . . . . .  13
74	     7.1  Example  . . . . . . . . . . . . . . . . . . . . . . . . .  13
75	     7.2  Element Definitions  . . . . . . . . . . . . . . . . . . .  13
76	       7.2.1  The "app:categories" element . . . . . . . . . . . . .  13
77	   8.   Service Documents  . . . . . . . . . . . . . . . . . . . . .  15
78	     8.1  Example  . . . . . . . . . . . . . . . . . . . . . . . . .  16
79	     8.2  Element Definitions  . . . . . . . . . . . . . . . . . . .  17
80	       8.2.1  The "app:service" Element  . . . . . . . . . . . . . .  17
81	       8.2.2  The "app:workspace" Element  . . . . . . . . . . . . .  17
82	       8.2.3  The "app:collection" Element . . . . . . . . . . . . .  18
83	       8.2.4  The "app:accept" Element . . . . . . . . . . . . . . .  19
84	       8.2.5  The "app:categories" Element . . . . . . . . . . . . .  20
85	   9.   Creating and Editing Resources . . . . . . . . . . . . . . .  22
86	     9.1  Member URIs  . . . . . . . . . . . . . . . . . . . . . . .  22
87	     9.2  Creating resources with POST . . . . . . . . . . . . . . .  22
88	       9.2.1  Example  . . . . . . . . . . . . . . . . . . . . . . .  23
89	     9.3  Updating Resources with PUT  . . . . . . . . . . . . . . .  24
90	     9.4  Deleting Resources with DELETE . . . . . . . . . . . . . .  24
91	     9.5  Media Resources and Media Link Entries . . . . . . . . . .  24
92	     9.6  The Slug: Header . . . . . . . . . . . . . . . . . . . . .  25
93	       9.6.1  Slug: Header syntax  . . . . . . . . . . . . . . . . .  25
94	       9.6.2  Examples . . . . . . . . . . . . . . . . . . . . . . .  26
95	   10.  Listing Collections  . . . . . . . . . . . . . . . . . . . .  28
96	     10.1   Collection Paging  . . . . . . . . . . . . . . . . . . .  28
97	     10.2   The "app:edited" Element . . . . . . . . . . . . . . . .  29
98	   11.  Atom Format Link Relation Extensions . . . . . . . . . . . .  30
99	     11.1   The "edit" Link Relation . . . . . . . . . . . . . . . .  30
100	     11.2   The "edit-media" Link Relation . . . . . . . . . . . . .  30
101	   12.  Atom Publishing Controls . . . . . . . . . . . . . . . . . .  31
102	     12.1   The "app:control" Element  . . . . . . . . . . . . . . .  31
103	       12.1.1   The "app:draft" Element  . . . . . . . . . . . . . .  31
104	   13.  Securing the Atom Publishing Protocol  . . . . . . . . . . .  32
105	   14.  Security Considerations  . . . . . . . . . . . . . . . . . .  33
106	     14.1   Denial of Service  . . . . . . . . . . . . . . . . . . .  33
107	     14.2   Replay Attacks . . . . . . . . . . . . . . . . . . . . .  33
108	     14.3   Spoofing Attacks . . . . . . . . . . . . . . . . . . . .  33
109	     14.4   Linked Resources . . . . . . . . . . . . . . . . . . . .  33
110	     14.5   Digital Signatures and Encryption  . . . . . . . . . . .  33
111	     14.6   URIs and IRIs  . . . . . . . . . . . . . . . . . . . . .  33
112	   15.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  34
113	     15.1   Content-type registration for
114	            'application/atomserv+xml' . . . . . . . . . . . . . . .  34
115	     15.2   Content-type registration for
116	            'application/atomcat+xml'  . . . . . . . . . . . . . . .  35
117	     15.3   Header field registration for 'SLUG' . . . . . . . . . .  36
118	   16.  References . . . . . . . . . . . . . . . . . . . . . . . . .  38
119	     16.1   Normative References . . . . . . . . . . . . . . . . . .  38
120	     16.2   Informative References . . . . . . . . . . . . . . . . .  39
121	        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  40
122	   A.   Contributors . . . . . . . . . . . . . . . . . . . . . . . .  41
123	   B.   RELAX NG Compact Schema  . . . . . . . . . . . . . . . . . .  42
124	   C.   Revision History . . . . . . . . . . . . . . . . . . . . . .  48
125	        Intellectual Property and Copyright Statements . . . . . . .  51

127	1.  Introduction

129	   The Atom Publishing Protocol is an application-level protocol for
130	   publishing and editing Web resources using HTTP [RFC2616] and XML 1.0
131	   [W3C.REC-xml-20060816].  The protocol supports the creation of
132	   arbitrary web resources and provides facilities for:

134	   o  Collections: Sets of resources, which can be retrieved in whole or
135	      in part.

137	   o  Service: Discovering and describing Collections.

139	   o  Editing: Creating, updating and deleting resources.

141	2.  Notational Conventions

143	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
144	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
145	   document are to be interpreted as described in [RFC2119].

147	2.1  XML-related Conventions

149	2.1.1  Referring to Information Items

151	   Atom Protocol Document formats are specified in terms of the XML
152	   Information Set [W3C.REC-xml-infoset-20040204], serialized as XML 1.0
153	   [W3C.REC-xml-20060816].

155	   The Infoset terms "Element Information Item" and "Attribute
156	   Information Item" are shortened to "element" and "attribute"
157	   respectively.  Therefore, when this specification uses the term
158	   "element", it is referring to an Element Information Item, and when
159	   it uses the term "attribute", it is referring to an Attribute
160	   Information Item.

162	2.1.2  RELAX NG Schema

164	   Some sections of this specification are illustrated with fragments of
165	   a non-normative RELAX NG Compact schema [RNC].  However, the text of
166	   this specification provides the definition of conformance.  Complete
167	   schemas appear in Appendix B.

169	2.1.3  Use of xml:base and xml:lang

171	   XML elements defined by this specification MAY have an xml:base
172	   attribute [W3C.REC-xmlbase-20010627].  When xml:base is used, it
173	   serves the function described in Section 5.1.1 of URI Generic Syntax
174	   [RFC3986], by establishing the base URI (or IRI) for resolving
175	   relative references found within the scope of the xml:base attribute.

177	   Any element defined by this specification MAY have an xml:lang
178	   attribute, whose content indicates the natural language for the
179	   element and its descendents.  The language context is only
180	   significant for elements and attributes declared to be "Language-
181	   Sensitive" by this specification.  Requirements regarding the content
182	   and interpretation of xml:lang are specified in Section 2.12 of XML
183	   1.0 [W3C.REC-xml-20060816].

185	3.  Terminology

187	   For convenience, this protocol can be referred to as the "Atom
188	   Protocol" or "APP".

190	   URI/IRI - A Uniform Resource Identifier and Internationalized
191	   Resource Identifier.  These terms and the distinction between them
192	   are defined in [RFC3986] and [RFC3987].  Before an IRI found in a
193	   document is used by HTTP, the IRI is first converted to a URI (see
194	   Section 4

196	   The phrase "the URI of a document" in this specification is shorthand
197	   for "a URI which, when dereferenced, is expected to produce that
198	   document as a representation".

200	   Resource - A network-accessible data object or service identified by
201	   an IRI, as defined in [RFC2616].  See [W3C.REC-webarch-20041215] for
202	   further discussion on resources.

204	   Representation - An entity included with a request or response as
205	   defined in [RFC2616].

207	   Collection - A resource that contains a set of Member Entries.  See
208	   Section 9.

210	   Member - A resource whose IRI is listed in a Collection by a link
211	   element with a relation of "edit" or "edit-media".  See Section 9.1.

213	   Workspace - A group of collections.  See Section 8.

215	   Service Document - A document that describes the location and
216	   capabilities of one or more Collections.  See Section 8.

218	   Category Document - A document that describes the categories allowed
219	   in a Collection.  See Section 7.

221	4.  Protocol Model

223	   The Atom Publishing Protocol uses HTTP methods to author Member
224	   Resources as follows:

226	   o  GET is used to retrieve a representation of a known resource.

228	   o  POST is used to create a new, dynamically-named, resource.

230	   o  PUT is used to update a known resource.

232	   o  DELETE is used to remove a known resource.

234	   Along with operations on Member Resources the Atom Protocol defines
235	   Collection resources for managing and organizing Member Resources.
236	   Collections are represented by Atom Feed documents and contain the
237	   IRIs of, and metadata about, their Member Resources.

239	   Atom Protocol documents allow the use of IRIs [RFC3987], as well as
240	   URIs [RFC3986].  Before an IRI found in a document is used by HTTP,
241	   the IRI is first converted to a URI according the procedure defined
242	   in Section 3.1 of [RFC3987].  The resource identified by the URI
243	   after conversion is the same as the one identified by the IRI.

245	   There are two kinds of Member Resources - Member Entry Resources and
246	   Media Resources.  Member Entry Resources are represented as Atom
247	   Entries [RFC4287].  Media Resources can have representations in any
248	   media type.  A Media Link Entry is a Member Entry that contains
249	   metadata about a Media Resource.  This diagram shows the
250	   classification of the resources:

252	     Member Resource
253	         -> Member Entry Resource
254	              -> Media Link Entry Resource
255	         -> Media Resource

257	   Collections, represented by Atom feeds, contain entries.  Those
258	   entries contain the Member Entry and Media Resources IRIs of the
259	   Collection.  A Collection can contain any number of entries of either
260	   kind.  In the diagram of a Collection below there are two entries.
261	   The first contains the IRI of a Member Entry Resource.  The second
262	   contains the IRIs of both a Media Resource and a Media Link Entry
263	   Resource, which contains the metadata for that Media Resource:

265	     Collection
266	        Entry
267	           Member Entry IRI    ->   Member Entry Resource

269	        Entry
270	           Member Entry IRI    ->   Media Link Entry Resource
271	           Media IRI           ->   Media Resource

273	   Service Documents represent server-defined groups of Collections, and
274	   are used to initialize the process of creating and editing resources.

276	5.  Protocol Operations

278	5.1  Retrieving a Service Document

280	   Client                                     Server
281	     |                                           |
282	     |  1.) GET to Service Document              |
283	     |------------------------------------------>|
284	     |                                           |
285	     |  2.) Service Document                     |
286	     |<------------------------------------------|
287	     |                                           |

289	   1.  The client sends a GET request using the URI of the Service
290	       Document.

292	   2.  The server responds with the document enumerating the IRIs of a
293	       set of Collections and the capabilities of those Collections
294	       supported by the server.  The content of this document can vary
295	       based on aspects of the client request, including, but not
296	       limited to, authentication credentials.

298	5.2  Listing Collection Members

300	   To list the members of a Collection, the client sends a GET request
301	   to the URI of a Collection.  An Atom Feed Document is returned
302	   containing one Atom Entry for each Member Entry Resource.  See
303	   Section 10 and Section 11 for a description of the feed contents.

305	   Client                          Server
306	     |                                |
307	     |  1.) GET to Collection URI     |
308	     |------------------------------->|
309	     |                                |
310	     |  2.) 200 OK, Atom Feed Doc     |
311	     |<-------------------------------|
312	     |                                |

314	   1.  The client sends a GET request to the URI of the Collection.

316	   2.  The server responds with an Atom Feed Document containing the
317	       IRIs of the Collection members.

319	5.3  Creating a Resource

321	   Client                                     Server
322	     |                                           |
323	     |  1.) POST to URI of Collection            |
324	     |------------------------------------------>|
325	     |                                           |
326	     |  2.) 201 Created                          |
327	     |      Location: Member Entry URI           |
328	     |<------------------------------------------|
329	     |                                           |

331	   1.  The client POSTs a representation of the Member to the URI of the
332	       Collection.

334	   2.  If the Member Resource was created successfully, the server
335	       responds with a status code of 201 and a Location: header that
336	       contains the IRI of the newly created Member Entry Resource.
337	       Media Resources may have also been created and their IRIs can be
338	       found through the Member Entry Resource.  See Section 9.5 for
339	       more details.

341	5.4  Editing a Resource

343	   Once a resource has been created and its Member URI is known, that
344	   URI can be used to retrieve, update, and delete the resource.

346	5.4.1  Retrieving a Resource

348	   Client                                     Server
349	     |                                           |
350	     |  1.) GET to Member URI                    |
351	     |------------------------------------------>|
352	     |                                           |
353	     |  2.) Member Representation                |
354	     |<------------------------------------------|
355	     |                                           |

357	   1.  The client sends a GET request to the URI of a Member Resource to
358	       retrieve its representation.

360	   2.  The server responds with the representation of the resource.

362	5.4.2  Updating a Resource

364	   Client                                     Server
365	     |                                           |
366	     |  1.) PUT to Member URI                    |
367	     |------------------------------------------>|
368	     |                                           |
369	     |  2.) 200 OK                               |
370	     |<------------------------------------------|

372	   1.  The client PUTs an updated representation to the URI of a Member
373	       Resource.

375	   2.  Upon a successful update of the resource the server responds with
376	       a status code of 200.

378	5.4.3  Deleting a Resource

380	   Client                                     Server
381	     |                                           |
382	     |  1.) DELETE to Member URI                 |
383	     |------------------------------------------>|
384	     |                                           |
385	     |  2.) 200 Ok                               |
386	     |<------------------------------------------|
387	     |                                           |

389	   1.  The client sends a DELETE request to the URI of a Member
390	       Resource.

392	   2.  Upon the successful deletion of the resource the server responds
393	       with a status code of 200.

395	   A different approach is taken for deleting Media Resources, see
396	   Section 9.5 for details.

398	5.5  Use of HTTP Response codes

400	   The Atom Protocol uses the response status codes defined in HTTP to
401	   indicate the success or failure of an operation.  Consult the HTTP
402	   specification [RFC2616] for detailed definitions of each status code.
403	   Implementers are asked to note that per the HTTP specification, HTTP
404	   4xx and 5xx response entities SHOULD include a human-readable
405	   explanation of the error.

407	6.  Atom Publishing Protocol Documents

409	6.1  Document Types

411	   This specification describes two kinds of Documents - Category
412	   Documents and Service Documents.

414	   A Category Document (Section 7) contain lists of categories specified
415	   using the "atom:category" element from the Atom Syndication Format.
416	   A Service Document (Section 8) describes capabilities of workspaces,
417	   which are server-defined groupings of Collections.

419	   The namespace name [W3C.REC-xml-names-20060816] for either kind of
420	   document is:
421	       http://purl.org/atom/app#

423	   [[anchor8: Needs to be updated with the final URI upon publication]]

425	   This specification uses the prefix "app:" for the namespace name.
426	   The prefix "atom:" is used for "http://www.w3.org/2005/Atom", the
427	   namespace name of the Atom Syndication Format [RFC4287].  The
428	   namespace prefixes are not semantically significant.

430	   Atom Publishing Protocol Documents MUST be well-formed XML.  This
431	   specification does not define any DTDs for Atom Protocol formats, and
432	   hence does not require them to be "valid" in the sense used by XML.

434	6.2  Document Extensibility

436	   Unrecognized markup in an Atom Publishing Protocol document is
437	   considered "foreign markup" as defined in [RFC4287].  Such foreign
438	   markup can be used anywhere within a Category or Service Document
439	   unless it is explicitly forbidden.  Processors that encounter foreign
440	   markup MUST NOT stop processing or signal an error, and SHOULD
441	   preserve foreign markup when transmitting such documents.

443	   The namespace name "http://purl.org/atom/app#" is reserved for
444	   forward compatible revisions of the Category and Service Document
445	   types - this does not exclude the addition of elements and attributes
446	   that might not be recognised by processors conformant to this
447	   specification.  Such unrecognised markup from the
448	   "http://purl.org/atom/app#" namespace MUST be treated as foreign
449	   markup.

451	7.  Category Documents

453	   Category Documents contain lists of categories described using the
454	   "atom:category" element from the Atom Syndication Format [RFC4287].
455	   Categories can also appear in Service Documents and describe the
456	   categories allowed in a Collection (see Section 8.2.5).

458	   Category Documents are identified with the "application/atomcat+xml"
459	   media type (see Section 15).

461	7.1  Example

463	       <?xml version="1.0" ?>
464	       <app:categories
465	           xmlns:app="http://purl.org/atom/app#"
466	           xmlns="http://www.w3.org/2005/Atom"
467	           fixed="yes" scheme="http://example.com/cats/big3">
468	         <category term="animal" />
469	         <category term="vegetable" />
470	         <category term="mineral" />
471	       </app:categories>

473	   This Category Document contains three categories, with the terms
474	   "animal", "vegetable", and "mineral".  None of the categories use the
475	   'label' attribute defined in [RFC4287].  They all inherit the
476	   "http://example.com/cats/big3" 'scheme' attribute declared on the
477	   app:categories element.  Therefore if the "mineral" category were to
478	   appear in an Atom Entry or Feed Document, it would appear as:

480	       <category scheme="http://example.com/cats/big3" term="mineral" />

482	7.2  Element Definitions

484	7.2.1  The "app:categories" element

486	   The root of a Category Document is the "app:categories" element.  An
487	   app:categories element can contain zero or more "atom:category"
488	   elements from the Atom namespace ("http://www.w3.org/2005/Atom").

490	   An app:category child element that has no "scheme" attribute inherits
491	   the attribute from its app:categories parent.  An app:category child
492	   element with an existing "scheme" attribute does not inherit the
493	   "scheme" value of its "app:categories" parent element.

495	7.2.1.1  Attributes of "app:categories"

497	   The app:categories element can contain a "fixed" attribute, with a
498	   value of either "yes" or "no", indicating whether the list of
499	   categories is a fixed or an open set.  Newly created or updated
500	   members whose categories are not listed in the Collection Document
501	   MAY be rejected by the server.  Collections that indicate the set is
502	   open SHOULD NOT reject otherwise acceptable members whose categories
503	   are not listed in the Collection.

505	   Alternatively, the app:categories element MAY contain an "href"
506	   attribute, whose value MUST be an IRI reference identifying a
507	   Category Document.  If the "href" attribute is provided the app:
508	   categories element MUST be empty and MUST NOT have the "fixed" or
509	   "scheme" attributes.

511	   atomCategory =
512	       element atom:category {
513	          atomCommonAttributes,
514	          attribute term { text },
515	          attribute scheme { atomURI }?,
516	          attribute label { text }?,
517	          undefinedContent
518	       }

520	   appInlineCategories =
521	       element app:categories {
522	           attribute fixed { "yes" | "no" }?,
523	           attribute scheme { atomURI }?,
524	           (atomCategory*)
525	       }

527	   appOutOfLineCategories =
528	       element app:categories {
529	           attribute href { atomURI },
530	           undefinedContent
531	       }

533	   appCategories = appInlineCategories | appOutOfLineCategories

535	8.  Service Documents

537	   For authoring to commence, a client needs to first discover the
538	   capabilities and locations of the available collections.  Service
539	   Documents are designed to support this discovery process.  How
540	   Service Documents are in turn discovered is not defined in this
541	   specification.

543	   A Service Document describes workspaces, which are server-defined
544	   groupings of Collections.  Service Documents are identified with the
545	   "application/atomserv+xml" media type (see Section 15).

547	   There is no requirement that a server support multiple workspaces.
548	   In addition, a Collection MAY appear in more than one Workspace.

550	8.1  Example

552	   <?xml version="1.0" encoding='utf-8'?>
553	   <service xmlns="http://purl.org/atom/app#"
554	            xmlns:atom="http://www.w3.org/2005/Atom">
555	     <workspace>
556	       <atom:title>Main Site</atom:title>
557	       <collection
558	           href="http://example.org/reilly/main" >
559	         <atom:title>My Blog Entries</atom:title>
560	         <categories
561	            href="http://example.com/cats/forMain.cats" />
562	       </collection>
563	       <collection
564	           href="http://example.org/reilly/pic" >
565	         <atom:title>Pictures</atom:title>
566	         <accept>image/*</accept>
567	       </collection>
568	     </workspace>
569	     <workspace>
570	       <atom:title>Side Bar Blog</atom:title>
571	       <collection
572	           href="http://example.org/reilly/list" >
573	         <atom:title>Remaindered Links</atom:title>
574	         <accept>entry</accept>
575	         <categories fixed="yes">
576	           <atom:category
577	             scheme="http://example.org/extra-cats/"
578	             term="joke" />
579	           <atom:category
580	             scheme="http://example.org/extra-cats/"
581	             term="serious" />
582	         </categories>
583	       </collection>
584	     </workspace>
585	   </service>

587	   This Service Document describes two workspaces.  The first Workspace
588	   is called "Main Site", has two collections called "My Blog Entries"
589	   and "Pictures" whose IRIs are "http://example.org/reilly/main" and
590	   "http://example.org/reilly/pic" respectively.  The "Pictures"
591	   Workspace includes an "accept" element indicating that a client can
592	   post image files to the Collection to create new entries.  Entries
593	   with associated media resources are discussed in Section 9.5.

595	   The second Workspace is called "Side Bar Blog" and has a single
596	   Collection called "Remaindered Links" whose IRI is
597	   "http://example.org/reilly/list".

599	   Within each of the two entry collections, the categories element
600	   provides a list of available categories for member entries.  In the
601	   "My Blog Entries" Collection, the list of available categories is
602	   obtainable through the "href" attribute.  The "Side Bar Blog"
603	   Collection provides a category list within the Service Document, but
604	   states the list is fixed, signaling a request from the server that
605	   entries be posted using only those two categories.

607	8.2  Element Definitions

609	8.2.1  The "app:service" Element

611	   The root of a Service Document is the "app:service" element.

613	   The "app:service" element is the container for service information
614	   associated with one or more workspaces.  An app:service element MUST
615	   contain one or more app:workspace elements.

617	   namespace app = "http://purl.org/atom/app#"
618	   start = appService

620	   appService =
621	      element app:service {
622	         appCommonAttributes,
623	         ( appWorkspace+
624	           & extensionElement* )
625	      }

627	8.2.2  The "app:workspace" Element

629	   The "app:workspace" element contains information elements about the
630	   collections of resources available for editing.  The app:workspace
631	   element contains zero or more app:collection elements.

633	   appWorkspace =
634	      element app:workspace {
635	         appCommonAttributes,
636	         ( atomTitle
637	           & appCollection*
638	           & extensionElement* )
639	      }

641	   atomTitle = element atom:title { atomTextConstruct }
642	   In an app:workspace element, the first app:collection element MUST
643	   refer to the preferred or primary Collection.  This distinction is
644	   considered useful in scenarios where Members and Media Link Entries
645	   are POSTed to different Collections.  In the following example, the
646	   "Eintragungen" collection would be considered the preferred
647	   Collection:

649	       <service xmlns="http://purl.org/atom/app#"
650	        xmlns:atom="http://www.w3.org/2005/Atom">
651	         <workspace xml:lang="de">
652	           <atom:title>Das Blog</atom:title>
653	           <collection
654	                href="http://example.org/blog/eintragungen" >
655	             <atom:title>Eintragungen</atom:title>
656	          </collection>
657	           <collection
658	                href="http://example.org/blog/fotos">
659	              <atom:title>Fotos</atom:title>
660	              <accept>image/*</accept>
661	           </collection>
662	         </workspace>
663	       </service>

665	8.2.2.1  The "atom:title" Element

667	   The app:workspace element MUST contain one "atom:title" element (as
668	   defined in [RFC4287]), giving a human-readable title for the
669	   workspace.

671	8.2.3  The "app:collection" Element

673	   The "app:collection" element describes a Collection.  The app:
674	   collection element MAY contain one app:accept element and MAY contain
675	   any number of app:categories elements.  The app:collection element
676	   MUST NOT contain more than one app:accept element.

678	   appCollection =
679	      element app:collection {
680	         appCommonAttributes,
681	         attribute href { atomURI  },
682	         ( atomTitle
683	           & appAccept?
684	           & appCategories*
685	           & extensionElement* )
686	      }

688	8.2.3.1  Usage in Atom Feed Documents

690	   The app:collection element MAY appear as a child of an atom:feed or
691	   atom:source element in an Atom Feed Document.  Its value identifies a
692	   Collection by which new entries can be added to appear in the feed.
693	   The app:control element is considered foreign markup as defined in
694	   Section 6 of [RFC4287].

696	8.2.3.2  The "href" Attribute

698	   The app:collection element MUST contain an "href" attribute, whose
699	   value gives the IRI of the Collection.

701	8.2.3.3  The "atom:title" Element

703	   The app:collection Element MUST contain one "atom:title" element,
704	   giving a human-readable title for the Workspace.

706	8.2.4  The "app:accept" Element

708	   The "app:accept" element value specifies a comma-separated list of
709	   media-ranges (see [RFC2616]) identifying the types of representations
710	   that can be POSTed to the URI of a Collection.  Whitespace around and
711	   between media-range values is considered insignificant and MUST be
712	   ignored.

714	   The app:accept element is similar to the HTTP Accept request-header
715	   [RFC2616] with the exception that app:accept has no notion of
716	   preference.  As a result, the value syntax of app:accept does not use
717	   "accept-params" or "q" arguments as specified in [RFC2616], section
718	   14.1.

720	   The order of media-ranges is not significant.  The following lists
721	   are all equivalent:

723	     <app:accept>image/png,image/*</app:accept>
724	     <app:accept>image/*, image/png</app:accept>
725	     <app:accept> image/* </app:accept>

727	   A value of "entry" may appear in any list of media-ranges in an
728	   accept element and indicates that Atom Entry Documents can be posted
729	   to the Collection.  If the accept element is omitted or empty,
730	   clients SHOULD assume that only Atom Entry documents will be accepted
731	   by the Collection.

733	   appAccept =
734	      element app:accept {
735	            appCommonAttributes,
736	            ( appTypeValue? )
737	      }

739	   appTypeValue = ( "entry" | media-type |entry-or-media-type  )
740	   media-type = xsd:string { pattern = "entry,(.+/.+,?)*" }
741	   entry-or-media-type = xsd:string { pattern = "(.+/.+,?)*" }

743	8.2.5  The "app:categories" Element

745	   The "app:categories" element provides a listing of the categories
746	   that can be applied to the members of a Collection.

748	   atomCategory =
749	       element atom:category {
750	          atomCommonAttributes,
751	          attribute term { text },
752	          attribute scheme { atomURI }?,
753	          attribute label { text }?,
754	          undefinedContent
755	       }

757	   appInlineCategories =
758	       element app:categories {
759	           attribute fixed { "yes" | "no" }?,
760	           attribute scheme { atomURI }?,
761	           (atomCategory*)
762	       }

764	   appOutOfLineCategories =
765	       element app:categories {
766	           attribute href { atomURI },
767	           undefinedContent
768	       }

770	   appCategories = appInlineCategories | appOutOfLineCategories

772	   The app:categories element MAY contain a "fixed" attribute, with a
773	   value of either "yes" or "no", indicating whether or not the listing
774	   of categories is considered to be a fixed, or closed set.  The
775	   absence of the "fixed" attribute is equivalent to the presence of a
776	   "fixed" attribute with a value of "no".  Collections that indicate a
777	   fixed set MAY reject members that include categories not specified in
778	   the provided listing.  Collections that indicate an open set SHOULD
779	   NOT reject otherwise acceptable members whose categories are not
780	   present in the provided list.

782	   The app:categories element MAY contain an "href" attribute, whose
783	   value MUST be an IRI reference identifying a Category Document.  If
784	   the "href" attribute is provided, the app:categories element MUST be
785	   empty and the "fixed" and "scheme" attributes MUST NOT be present.

787	9.  Creating and Editing Resources

789	9.1  Member URIs

791	   The Member URI supports retrieving, updating and deleting the
792	   resource using HTTP GET, PUT and DELETE as described in this section.
793	   Retrieval and updating of Member Entry Resources are done via Atom
794	   Entry representations.

796	   Member Entry URIs appear in two places.  First, they are returned in
797	   a Location header after successful resource creation using POST, as
798	   described below.  Second, in the entries of a Collection document, by
799	   an atom:link element with a link relation of "edit".

801	   Each Member Entry SHOULD contain such an atom:link element providing
802	   its Member Entry URI.

804	9.2  Creating resources with POST

806	   To add members to a Collection, clients send POST requests to the URI
807	   of a Collection.  Successful member creation is normally indicated
808	   with a 201 ("Created") response code.  Collections MAY generate a
809	   response with a status code of 415 ("Unsupported Media Type") to
810	   indicate media-type of POSTed entity is not allowed or supported by
811	   the Collection.

813	   When a Member Resource is created in the Collection which received
814	   the POST, its Member Entry URI MUST be returned in an HTTP Location
815	   header.

817	   When the server generates a response with a status code of 201
818	   ("Created"), it SHOULD also return a response body, which if
819	   provided, MUST be an Atom Entry Document representing the newly-
820	   created resource.

822	   Since the server is free to alter the posted entry, for example by
823	   changing the content of the "id" element, returning the Entry as
824	   described in the previous paragraph can be useful to the client,
825	   enabling it to correlate the client and server views of the new
826	   Entry.

828	   When the POST request contains an Atom Entry Document, the response
829	   from the server SHOULD contain a Content-Location header that
830	   contains the same character-by-character value as the Location
831	   header.

833	   The request body sent with the POST need not be an Atom Entry.  For
834	   example, it might be a picture, or a movie.  For a discussion of the
835	   issues in posting such content, see Section 9.5.

837	9.2.1  Example

839	   Below, the client sends a POST request containing an Atom Entry
840	   representation to the URI of the Collection:

842	       POST /myblog/entries HTTP/1.1
843	       Host: example.org
844	       User-Agent: Thingio/1.0
845	       Authorization: Basic ZGFmZnk6c2VjZXJldA==
846	       Content-Type: application/atom+xml
847	       Content-Length: nnn
848	       Slug: First Post

850	       <?xml version="1.0" ?>
851	       <entry xmlns="http://www.w3.org/2005/Atom"
852	           xmlns:app="http://purl.org/atom/app#">
853	         <title>Atom-Powered Robots Run Amok</title>
854	         <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
855	         <updated>2003-12-13T18:30:02Z</updated>
856	         <author><name>John Doe</name></author>
857	         <content>Some text.</content>
858	       </entry>

860	   The server signals a successful creation with a status code of 201.
861	   The response includes a "Location" header indicating the Member Entry
862	   URI of the Atom Entry and a representation of that Entry in the body
863	   of the response.

865	       HTTP/1.1 201 Created
866	       Date: Fri, 7 Oct 2005 17:17:11 GMT
867	       Content-Length: nnn
868	       Content-Type: application/atom+xml; charset="utf-8"
869	       Content-Location: http://example.org/edit/first-post.atom
870	       Location: http://example.org/edit/first-post.atom

872	       <?xml version="1.0"?>
873	       <entry xmlns="http://www.w3.org/2005/Atom"
874	           xmlns:app="http://purl.org/atom/app#">
875	         <title>Atom-Powered Robots Run Amok</title>
876	         <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
877	         <updated>2003-12-13T18:30:02Z</updated>
878	         <author><name>John Doe</name></author>
879	         <content>Some text.</content>
880	         <link rel="edit"
881	             href="http://example.org/edit/first-post.atom"/>

883	       </entry>

885	   The Entry created and returned by the server might not match the
886	   Entry POSTed by the client.  A server MAY change the values of
887	   various elements in the Entry such as the atom:id, atom:updated and
888	   atom:author values and MAY choose to remove or add other elements and
889	   attributes, or change element and attribute values.

891	   In particular, the publishing system in this example filled in some
892	   values not provided in the original POST.  For example, it
893	   ascertained the name of the author, presumably via the authentication
894	   protocol used to establish the right to post.

896	9.3  Updating Resources with PUT

898	   To update a resource, clients send PUT requests to its Member URI, as
899	   specified in [RFC2616].

901	   To avoid unintentional loss of data when editing Member Entries or
902	   Media Link Entries, Atom Protocol clients SHOULD preserve all
903	   metadata that has not been intentionally modified, including unknown
904	   foreign markup as defined in Section 6 of [RFC4287].

906	9.4  Deleting Resources with DELETE

908	   To delete a resource, clients send DELETE requests to its Member URI,
909	   as specified in [RFC2616].  For Media Resources, deletion of a Media
910	   Link Entry SHOULD result in the deletion of the associated Media
911	   Resource.

913	9.5  Media Resources and Media Link Entries

915	   A client can POST a media type other than application/atom+xml to a
916	   Collection.  Such a request creates two new resources - one that
917	   corresponds to the entity sent in the request, called the Media
918	   Resource, and an associated Member Entry, called the Media Link
919	   Entry.  Media Link Entries are represented as Atom Entries.  The
920	   server can signal the media types it will accept via the "accept"
921	   element in the Service Document (Section 8.2.4).

923	   The Media Link Entry contains the IRI of the Media Resource and makes
924	   metadata about it separately available for retrieval and update.  The
925	   Media Link Entry is used to store metadata about the (perhaps non-
926	   textual) Media Resource.

928	   Successful responses to creation requests MUST include the URI of the
929	   Media Link Entry in the Location header.  The Media Link Entry SHOULD
930	   contain an atom:link element with a link relation of "edit-media"
931	   that contains the Media Resource IRI.  The Media Link Entry MUST have
932	   an "atom:content" element with a non-empty "src" attribute.  The
933	   value of the "src" attribute is an IRI of the newly created Media
934	   Resource.  It is OPTIONAL that the IRI of the "src" attribute on the
935	   atom:content element be the same as the Media Resource IRI.  That is,
936	   the "src" attribute value might instead be a link into a static cache
937	   or content distribution network and not be the Media Resource IRI.

939	   Implementers are asked to note that according to the requirements of
940	   [RFC4287], entries, and thus Media Link Entries, MUST contain an
941	   atom:summary element.  Upon successful creation of a Media Link
942	   Entry, a server MAY choose to populate the atom:summary element (as
943	   well as other required elements such as atom:id, atom:author and
944	   atom:title) with content derived from the POSTed entity or from any
945	   other source.  A server might not allow a client to modify the server
946	   selected values for these elements.

948	   For resource creation this specification only defines cases where the
949	   POST body has an Atom Entry entity declared as an Atom media type
950	   ("application/atom+xml"), or a non-Atom entity declared as a non-Atom
951	   media type.  It does not specify any request semantics or server
952	   behavior in the case where the POSTed media-type is "application/
953	   atom+xml" but the body is something other than an Atom Entry.  In
954	   particular, what happens on POSTing an Atom Feed Document to a
955	   Collection using the "application/atom+xml" media type is undefined.

957	9.6  The Slug: Header

959	   Slug is a HTTP entity-header whose value is a "slug" - a short name
960	   that can be used as part of the URI for a Member Resource.

962	   When posting an entity to a Collection to add a new Member, the
963	   server MAY use this information when creating the Member URI of the
964	   newly-created resource, for instance by using some or all of the
965	   words in the last URI segment.  It MAY also use it when creating the
966	   atom:id or as the title of a Media Link Entry (see Section 9.5.).

968	   Servers MAY ignore the Slug entity-header and MAY alter its value
969	   before using it.  For example, the server MAY filter out some
970	   characters or replace accented letters with non-accented ones, spaces
971	   with underscores, etc.

973	9.6.1  Slug: Header syntax

975	   The syntax of this header MUST conform to the augmented BNF grammar
976	   in section 2.1 of the HTTP/1.1 specification [RFC2616].  The TEXT
977	   rule is described in section 2.2 of the same document.

979	       Slug = "Slug" ":" *TEXT

981	   Clients MAY send non-ASCII characters in the Slug entity-header,
982	   which they MUST encode using "encoded-words", as defined in
983	   [RFC2047].  Servers SHOULD treat the slug as [RFC2047] encoded if it
984	   matches the "encoded-words" production.

986	9.6.2  Examples

988	   Below, the client sends a POST request containing a PNG image to the
989	   URI of the Collection:

991	       POST /myblog/entries HTTP/1.1
992	       Host: example.org
993	       Content-Type: image/png
994	       Slug: The Beach
995	       Authorization: Basic ZGFmZnk6c2VjZXJldA==
996	       Content-Length: nnn

998	       ...binary data...

1000	   The server signals a successful creation with a status code of 201.
1001	   The response includes a Location header indicating the Member URI of
1002	   the Media Link Entry and a representation of that entry in the body
1003	   of the response.  The Media Link Entry includes a content element
1004	   with a src attribute, and a link using the link relation "edit-media"
1005	   specifying the IRI to be used for modifying the Media Resource.

1007	       HTTP/1.1 201 Created
1008	       Date: Fri, 7 Oct 2005 17:17:11 GMT
1009	       Content-Length: nnn
1010	       Content-Type: application/atom+xml; charset="utf-8"
1011	       Content-Location: http://example.org/myblog/edit/the_beach
1012	       Location: http://example.org/myblog/edit/the_beach

1014	       <?xml version="1.0"?>
1015	       <entry xmlns="http://www.w3.org/2005/Atom">
1016	         <title>The Beach</title>
1017	         <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
1018	         <updated>2005-10-07T17:17:08Z</updated>
1019	         <author><name>Daffy</name></author>
1020	         <summary type="text" />
1021	         <content type="image/png"
1022	            src="http://example.org/media/the_beach.png"/>
1023	         <link rel="edit-media"
1024	            href="http://example.org/media/edit/the_beach.png" />
1025	         <link rel="edit"
1026	            href="http://example.org/myblog/edit/the_beach />
1027	       </entry>

1029	   Here is an example of the Slug: header that uses the encoding rules
1030	   of [RFC2047].

1032	       POST /myblog/entries HTTP/1.1
1033	       Host: example.org
1034	       Content-Type: image/png
1035	       Slug: =?iso-8859-1?q?The_Beach?=
1036	       Authorization: Basic ZGFmZnk6c2VjZXJldA==
1037	       Content-Length: nnn

1039	       ...binary data...

1041	   See Section 9.2.1 for an example of the Slug: header applied to the
1042	   creation of a Member Entry Resource.

1044	10.  Listing Collections

1046	   Collection resources MUST provide representations in the form of Atom
1047	   Feed documents whose entries represent the Members in the Collection.
1048	   Each entry in the Feed Document SHOULD have an atom:link element with
1049	   a relation of "edit" (See Section 11.1).

1051	   The entries in the returned Atom Feed SHOULD be ordered by their
1052	   "atom:updated" property, with the most recently updated entries
1053	   coming first in the document order.  Clients SHOULD be constructed in
1054	   consideration of the fact that changes which do not alter the atom:
1055	   updated value of an entry will not affect the position of the entry
1056	   in a Collection.

1058	   Clients MUST NOT assume that an Atom Entry returned in the Feed is a
1059	   full representation of a Member Entry Resource and SHOULD perform a
1060	   GET on the URI of the Member Entry before editing.

1062	10.1  Collection Paging

1064	   Collections can contain large numbers of resources.  A naive client
1065	   such as a web spider or web browser could be overwhelmed if the
1066	   response to a GET contained every entry in the Collection, and the
1067	   server would waste large amounts of bandwidth and processing time on
1068	   clients unable to handle the response.  For this reason, servers MAY
1069	   return a partial listing of the most recently updated Member
1070	   Resources.  Such partial feed documents MUST have an atom:link with a
1071	   "next" relation whose "href" value is the URI of the next partial
1072	   listing of the Collection (the next most recently updated Member
1073	   Resources) where it exists.  This is called "Collection paging".

1075	   The returned Atom Feed MAY contain a subset the Member Entries for a
1076	   Collection.  In addition, the Atom Feed document MAY contain link
1077	   elements with "rel" attribute values of "next", "previous", "first"
1078	   and "last" that can be used to navigate through the complete set of
1079	   matching entries.

1081	   For instance, suppose a client is supplied the URI
1082	   "http://example.org/entries/go" of a Collection of Member entries,
1083	   where the server as a matter of policy avoids generating feed
1084	   documents containing more than 10 entries.  The Atom Feed document
1085	   for the Collection will then represent the first 'page' in a set of
1086	   10 linked feed documents.  The "first" relation will reference the
1087	   initial feed document in the set and the "last" relation references
1088	   the final Atom Feed Document in the set.  Within each document, the
1089	   "next" and "previous" link relations reference the preceding and
1090	   subsequent documents.

1092	     <feed xmlns="http://www.w3.org/2005/Atom">
1093	       <link rel="first"
1094	             href="http://example.org/entries/go" />
1095	       <link rel="next"
1096	             href="http://example.org/entries/2" />
1097	       <link rel="last"
1098	             href="http://example.org/entries/10" />
1099	       ...
1100	     </feed>

1102	   The "next" and "previous" link elements for the feed 'page' located
1103	   at "http://example.org/entries/2" would look like this:

1105	     <feed xmlns="http://www.w3.org/2005/Atom">
1106	       <link rel="first"
1107	             href="http://example.org/entries/go" />
1108	       <link rel="previous"
1109	             href="http://example.org/entries/go" />
1110	       <link rel="next"
1111	             href="http://example.org/entries/3" />
1112	       <link rel="last"
1113	             href="http://example.org/entries/10" />
1114	       ...
1115	     </feed>

1117	10.2  The "app:edited" Element

1119	   The "app:edited" element is a Date construct as defined by [RFC4287]
1120	   whose value indicates the most recent instant in time when an entry
1121	   was edited, including when created.  Atom entry elements in
1122	   Collection documents SHOULD contain one "app:edited" element, and
1123	   MUST NOT contain more than one.

1125	   appEdited = element app:edited ( atomDateConstruct )

1127	   The server SHOULD change the value of this element every time a
1128	   Collection Member Resource or an associated Media Resource has been
1129	   edited by any means.

1131	11.  Atom Format Link Relation Extensions

1133	11.1  The "edit" Link Relation

1135	   This specification adds the value "edit" to the Atom Registry of Link
1136	   Relations (see section 7.1 of [RFC4287]).  The value of "edit"
1137	   specifies that the value of the href attribute is the IRI of an
1138	   editable Member Entry.  When appearing within an atom:entry, the href
1139	   IRI can be used to retrieve, update and delete the resource
1140	   represented by that entry.  An atom:entry MUST contain no more than
1141	   one "edit" link relation.

1143	11.2  The "edit-media" Link Relation

1145	   This specification adds the value "edit-media" to the Atom Registry
1146	   of Link Relations (see section 7.1 of [RFC4287]).  When appearing
1147	   within an atom:entry, the value of the href attribute is an IRI that
1148	   can be used to modify a Media Resource associated with that entry.

1150	   An atom:entry element MAY contain zero or more "edit-media" link
1151	   relations.  An atom:entry MUST NOT contain more than one atom:link
1152	   element with a rel attribute value of "edit-media" that has the same
1153	   type and hreflang attribute values.  All "edit-media" link relations
1154	   in the same entry reference the same resource.  If a client
1155	   encounters multiple "edit-media" link relations in an entry then it
1156	   SHOULD choose a link based on the client preferences for type and
1157	   hreflang.  If a client encounters multiple "edit-media" link
1158	   relations in an entry and has no preference based on the type and
1159	   hreflang attributes then the client SHOULD pick the first "edit-
1160	   media" link relation in document order.

1162	12.  Atom Publishing Controls

1164	   This specification defines an Atom Format Structured Extension, as
1165	   defined in Section 6 of [RFC4287], for publishing control within the
1166	   http://purl.org/atom/app# namespace.

1168	12.1  The "app:control" Element

1170	   namespace app = "http://purl.org/atom/app#"

1172	    pubControl =
1173	       element app:control {
1174	       atomCommonAttributes,
1175	       pubDraft?
1176	       & extensionElement
1177	    }

1179	    pubDraft =
1180	      element app:draft { "yes" | "no" }

1182	   The "app:control" element MAY appear as a child of an atom:entry
1183	   which is being created or updated via the Atom Publishing Protocol.
1184	   The app:control element MUST appear only once in an Entry.  The app:
1185	   control element is considered foreign markup as defined in Section 6
1186	   of [RFC4287].

1188	   The app:control element and its child elements MAY be included in
1189	   Atom Feed or Entry Documents.

1191	   The app:control element can contain an optional "app:draft" element
1192	   as defined below, and can contain extension elements as defined in
1193	   Section 6 of [RFC4287].

1195	12.1.1  The "app:draft" Element

1197	   The number of app:draft elements in app:control MUST be zero or one.
1198	   Its value MUST be one of "yes" or "no".  A value of "no" indicates a
1199	   client request that the Member Resource be made publicly visible.  If
1200	   the app:draft element is missing then the value MUST be understood to
1201	   be "no".  The inclusion of the app:draft element represents a request
1202	   by the client to control the visibility of a Member Resource and the
1203	   app:draft element MAY be ignored by the server.

1205	13.  Securing the Atom Publishing Protocol

1207	   The Atom Publishing Protocol is based on HTTP.  Authentication
1208	   requirements for HTTP are covered in Section 11 of [RFC2616].

1210	   The use of authentication mechanisms to prevent posting or editing by
1211	   unknown or unauthorized clients is RECOMMENDED but not required.
1212	   When authentication is not used, clients and servers are vulnerable
1213	   to trivial spoofing, denial of service and defacement attacks,
1214	   however, in some contexts, this is an acceptable risk.

1216	   The type of authentication deployed is a local decision made by the
1217	   server operator.  Clients are likely to face authentication schemes
1218	   that vary across server deployments.  At a minimum, client and server
1219	   implementations MUST be capable of being configured to use HTTP Basic
1220	   Authentication [RFC2617] in conjunction with a TLS connection
1221	   [RFC4346] as specified by [RFC2818].

1223	   The choice of authentication mechanism will impact interoperability.
1224	   The minimum level of security referenced above (Basic Auth with TLS)
1225	   is considered good practice for Internet applications at the time of
1226	   publication of this specification and sufficient for establishing a
1227	   baseline for interoperability.  Implementers should, in general,
1228	   investigate and use alternative mechanisms regarded as equivalently
1229	   good or better at the time of deployment.  It is RECOMMENDED that
1230	   clients be implemented in such a way that allows new authentication
1231	   schemes to be deployed.

1233	   Because this protocol uses HTTP response status codes as the primary
1234	   means of reporting the result of a request, servers are advised to
1235	   respond to unauthorized or unauthenticated requests using an
1236	   appropriate 4xx HTTP response code (e.g. 401 "Unauthorized" or 403
1237	   "Forbidden") in accordance with [RFC2617].

1239	14.  Security Considerations

1241	   As an HTTP-based protocol, APP is subject to the security
1242	   considerations found in Section 15 of [RFC2616].

1244	14.1  Denial of Service

1246	   Atom Publishing server implementations need to take adequate
1247	   precautions to ensure malicious clients cannot consume excessive
1248	   server resources (CPU, memory, disk, etc).

1250	14.2  Replay Attacks

1252	   Atom Publishing server implementations are susceptible to replay
1253	   attacks.  Specifically, this specification does not define a means of
1254	   detecting duplicate requests.  Accidentally sent duplicate requests
1255	   are indistinguishable from intentional and malicious replay attacks.

1257	14.3  Spoofing Attacks

1259	   Atom Publishing implementations are susceptible to a variety of
1260	   spoofing attacks.  Malicious clients may send Atom entries containing
1261	   inaccurate information anywhere in the document.

1263	14.4  Linked Resources

1265	   Atom Feed and Entry documents can contain XML External Entities as
1266	   defined in Section 4.2.2 of [W3C.REC-xml-20060816].  Atom
1267	   implementations are not required to load external entities.  External
1268	   entities are subject to the same security concerns as any network
1269	   operation and can alter the semantics of an Atom document.  The same
1270	   issues exist for resources linked to by Atom elements such as atom:
1271	   link and atom:content.

1273	14.5  Digital Signatures and Encryption

1275	   Atom Entry Documents sent to a server might contain XML Digital
1276	   Signatures [W3C.REC-xmldsig-core-20020212] and might be encrypted
1277	   using XML Encryption [W3C.REC-xmlenc-core-20021210] as specified in
1278	   Section 5 of [RFC4287].

1280	   Servers are allowed to modify received resource representations in
1281	   ways that can invalidate signatures covering those representations.

1283	14.6  URIs and IRIs

1285	   Atom Publishing Protocol implementations handle URIs and IRIs.  See
1286	   Section 7 of [RFC3986] and Section 8 of [RFC3987].

1288	15.  IANA Considerations

1290	15.1  Content-type registration for 'application/atomserv+xml'

1292	   An Atom Publishing Protocol Service Document, when serialized as XML
1293	   1.0, can be identified with the following media type:

1295	   MIME media type name: application

1297	   MIME subtype name: atomserv+xml

1299	   Mandatory parameters: None.

1301	   Optional parameters:

1303	      "charset": This parameter has identical semantics to the charset
1304	         parameter of the "application/xml" media type as specified in
1305	         [RFC3023].

1307	   Encoding considerations: Identical to those of "application/xml" as
1308	      described in [RFC3023], section 3.2.

1310	   Security considerations: As defined in this specification.
1311	      [[anchor31: update upon publication]]

1313	      In addition, as this media type uses the "+xml" convention, it
1314	      shares the same security considerations as described in [RFC3023],
1315	      section 10.

1317	   Interoperability considerations: There are no known interoperability
1318	      issues.

1320	   Published specification: This specification. [[anchor32: update upon
1321	      publication]]

1323	   Applications that use this media type: No known applications
1324	      currently use this media type.

1326	   Additional information:

1328	   Magic number(s): As specified for "application/xml" in [RFC3023],
1329	      section 3.2.

1331	   File extension: .atomsrv
1332	   Fragment identifiers: As specified for "application/xml" in
1333	      [RFC3023], section 5.

1335	   Base URI: As specified in [RFC3023], section 6.

1337	   Macintosh File Type code: TEXT

1339	   Person and email address to contact for further information: Joe
1340	      Gregorio <joe@bitworking.org>

1342	   Intended usage: COMMON

1344	   Author/Change controller: This specification's author(s). [[anchor33:
1345	      update upon publication]]

1347	15.2  Content-type registration for 'application/atomcat+xml'

1349	   An Atom Publishing Protocol Category Document, when serialized as XML
1350	   1.0, can be identified with the following media type:

1352	   MIME media type name: application

1354	   MIME subtype name: atomcat+xml

1356	   Mandatory parameters: None.

1358	   Optional parameters:

1360	      "charset": This parameter has identical semantics to the charset
1361	         parameter of the "application/xml" media type as specified in
1362	         [RFC3023].

1364	   Encoding considerations: Identical to those of "application/xml" as
1365	      described in [RFC3023], section 3.2.

1367	   Security considerations: As defined in this specification.
1368	      [[anchor34: update upon publication]]

1370	      In addition, as this media type uses the "+xml" convention, it
1371	      shares the same security considerations as described in [RFC3023],
1372	      section 10.

1374	   Interoperability considerations: There are no known interoperability
1375	      issues.

1377	   Published specification: This specification. [[anchor35: update upon
1378	      publication]]

1380	   Applications that use this media type: No known applications
1381	      currently use this media type.

1383	   Additional information:

1385	   Magic number(s): As specified for "application/xml" in [RFC3023],
1386	      section 3.2.

1388	   File extension: .atomcat

1390	   Fragment identifiers: As specified for "application/xml" in
1391	      [RFC3023], section 5.

1393	   Base URI: As specified in [RFC3023], section 6.

1395	   Macintosh File Type code: TEXT

1397	   Person and email address to contact for further information: Joe
1398	      Gregorio <joe@bitworking.org>

1400	   Intended usage: COMMON

1402	   Author/Change controller: This specification's author(s). [[anchor36:
1403	      update upon publication]]

1405	15.3  Header field registration for 'SLUG'

1407	   [[anchor37: incomplete section --dehora]]

1409	   Header field: SLUG

1411	   Applicable protocol: http [RFC2616]

1413	   Status: standard.

1415	    Author/Change controller: IETF (iesg@ietf.org) Internet Engineering
1416	      Task Force

1418	   Specification document(s): draft-ietf-atompub-protocol-11.txt
1419	      ([[anchor38: update on rfc number assignment --dehora]])

1421	   Related information:

1423	16.  References

1425	16.1  Normative References

1427	   [RFC2047]  Moore, K., "MIME (Multipurpose Internet Mail Extensions)
1428	              Part Three: Message Header Extensions for Non-ASCII Text",
1429	              RFC 2047, November 1996.

1431	   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
1432	              Requirement Levels", BCP 14, RFC 2119, March 1997.

1434	   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1435	              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
1436	              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

1438	   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
1439	              Leach, P., Luotonen, A., and L. Stewart, "HTTP
1440	              Authentication: Basic and Digest Access Authentication",
1441	              RFC 2617, June 1999.

1443	   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

1445	   [RFC3023]  Murata, M., St. Laurent, S., and D. Kohn, "XML Media
1446	              Types", RFC 3023, January 2001.

1448	   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
1449	              Resource Identifier (URI): Generic Syntax", STD 66,
1450	              RFC 3986, January 2005.

1452	   [RFC3987]  Duerst, M. and M. Suignard, "Internationalized Resource
1453	              Identifiers (IRIs)", RFC 3987, January 2005.

1455	   [RFC4287]  Nottingham, M. and R. Sayre, "The Atom Syndication
1456	              Format", RFC 4287, December 2005.

1458	   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
1459	              (TLS) Protocol Version 1.1", RFC 4346, April 2006.

1461	   [W3C.REC-xml-20060816]
1462	              Bray, T., Paoli, J., Maler, E., Sperberg-McQueen, C., and
1463	              F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth
1464	              Edition)", World Wide Web Consortium Recommendation REC-
1465	              xml-20060816, August 2006.

1467	   [W3C.REC-xml-infoset-20040204]
1468	              Cowan, J., Tobin, R., and A. Layman, "XML Information Set
1469	              (Second Edition)", W3C REC W3C.REC-xml-infoset-20040204,
1470	              February 2004.

1472	   [W3C.REC-xml-names-20060816]
1473	              Hollander, D., Bray, T., and A. Layman, "Namespaces in
1474	              XML", World Wide Web Consortium Recommendation REC-xml-
1475	              names-20060816, August 2006.

1477	   [W3C.REC-xmlbase-20010627]
1478	              Marsh, J., "XML Base", W3C REC W3C.REC-xmlbase-20010627,
1479	              June 2001.

1481	   [W3C.REC-xmldsig-core-20020212]
1482	              Solo, D., Reagle, J., and D. Eastlake, "XML-Signature
1483	              Syntax and Processing", World Wide Web Consortium
1484	              Recommendation REC-xmldsig-core-20020212, February 2002,
1485	              <http://www.w3.org/TR/2002/REC-xmldsig-core-20020212>.

1487	   [W3C.REC-xmlenc-core-20021210]
1488	              Eastlake, D. and J. Reagle, "XML Encryption Syntax and
1489	              Processing", World Wide Web Consortium Recommendation REC-
1490	              xmlenc-core-20021210, December 2002,
1491	              <http://www.w3.org/TR/2002/REC-xmlenc-core-20021210>.

1493	16.2  Informative References

1495	   [RNC]      Clark, J., "RELAX NG Compact Syntax", December 2001.

1497	   [W3C.REC-webarch-20041215]
1498	              Walsh, N. and I. Jacobs, "Architecture of the World Wide
1499	              Web, Volume One", W3C REC REC-webarch-20041215,
1500	              December 2004.

1502	URIs

1504	   [1]  <http://www.imc.org/atom-protocol/index.html>

1506	Authors' Addresses

1508	   Joe Gregorio (editor)
1509	   IBM
1510	   4205 South Miama Blvd.
1511	   Research Triangle Park, NC  27709
1512	   US

1514	   Phone: +1 919 272 3764
1515	   Email: joe@bitworking.org
1516	   URI:   http://ibm.com/

1518	   Bill de hOra (editor)
1519	   Propylon Ltd.
1520	   45 Blackbourne Square, Rathfarnham Gate
1521	   Dublin, Dublin  D14
1522	   IE

1524	   Phone: +353-1-4927444
1525	   Email: bill.dehora@propylon.com
1526	   URI:   http://www.propylon.com/

1528	Appendix A.  Contributors

1530	   The content and concepts within are a product of the Atom community
1531	   and the Atompub Working Group.

1533	   [[anchor42: chairs to compile a contribution list for 1.0 --dehora]]

1535	Appendix B.  RELAX NG Compact Schema

1537	   This appendix is informative.

1539	   The Relax NG schema explicitly excludes elements in the Atom Protocol
1540	   namespace which are not defined in this revision of the
1541	   specification.  Requirements for Atom Protocol processors
1542	   encountering such markup are given in Section 6.2 and Section 6.3 of
1543	   [RFC4287].

1545	   The Schema for Service Documents:

1547	   # -*- rnc -*-
1548	   # RELAX NG Compact Syntax Grammar for the Atom Protocol

1550	   namespace app = "http://purl.org/atom/app#"
1551	   namespace atom = "http://www.w3.org/2005/Atom"
1552	   namespace xsd = "http://www.w3.org/2001/XMLSchema"
1553	   namespace xhtml = "http://www.w3.org/1999/xhtml"
1554	   namespace local = ""

1556	   start = appService

1558	   # common:attrs

1560	   atomURI = text

1562	   appCommonAttributes =
1563	      attribute xml:base { atomURI }?,
1564	      attribute xml:lang { atomLanguageTag }?,
1565	      undefinedAttribute*

1567	   atomCommonAttributes = appCommonAttributes

1569	   undefinedAttribute =
1570	     attribute * - (xml:base | xml:lang | local:*) { text }

1572	   atomLanguageTag = xsd:string {
1573	      pattern = "[A-Za-z]{1,8}(-[A-Za-z0-9]{1,8})*"
1574	   }

1576	   atomDateConstruct =
1577	       appCommonAttributes,
1578	       xsd:dateTime

1580	   # app:service

1582	   appService =
1583	      element app:service {
1584	         appCommonAttributes,
1585	         ( appWorkspace+
1586	           & extensionElement* )
1587	      }

1589	   # app:workspace

1591	   appWorkspace =
1592	      element app:workspace {
1593	         appCommonAttributes,
1594	         ( atomTitle
1595	           & appCollection*
1596	           & extensionElement* )
1597	      }

1599	   atomTitle = element atom:title { atomTextConstruct }

1601	   # app:collection

1603	   appCollection =
1604	      element app:collection {
1605	         appCommonAttributes,
1606	         attribute href { atomURI  },
1607	         ( atomTitle
1608	           & appAccept?
1609	           & appCategories*
1610	           & extensionElement* )
1611	      }

1613	   # app:categories

1615	   atomCategory =
1616	       element atom:category {
1617	          atomCommonAttributes,
1618	          attribute term { text },
1619	          attribute scheme { atomURI }?,
1620	          attribute label { text }?,
1621	          undefinedContent
1622	       }

1624	   appInlineCategories =
1625	       element app:categories {
1626	           attribute fixed { "yes" | "no" }?,
1627	           attribute scheme { atomURI }?,
1628	           (atomCategory*)
1629	       }

1631	   appOutOfLineCategories =
1632	       element app:categories {
1633	           attribute href { atomURI },
1634	           undefinedContent
1635	       }

1637	   appCategories = appInlineCategories | appOutOfLineCategories

1639	   # app:accept

1641	   appAccept =
1642	      element app:accept {
1643	            appCommonAttributes,
1644	            ( appTypeValue? )
1645	      }

1647	   appTypeValue = ( "entry" | media-type |entry-or-media-type  )
1648	   media-type = xsd:string { pattern = "entry,(.+/.+,?)*" }
1649	   entry-or-media-type = xsd:string { pattern = "(.+/.+,?)*" }
1650	   # above is an approximation, rnc doesn't support interleaved text

1652	   # Simple Extension

1654	   simpleExtensionElement =
1655	      element * - app:* {
1656	         text
1657	      }

1659	   # Structured Extension

1661	   structuredExtensionElement =
1662	      element * - app:* {
1663	         (attribute * { text }+,
1664	            (text|anyElement)*)
1665	       | (attribute * { text }*,
1666	          (text?, anyElement+, (text|anyElement)*))
1667	      }

1669	   # Other Extensibility

1671	   extensionElement =
1672	      simpleExtensionElement | structuredExtensionElement

1674	   undefinedContent = (text|anyForeignElement)*

1676	   # Extensions

1678	   anyElement =
1679	      element * {
1680	         (attribute * { text }
1681	          | text
1682	          | anyElement)*
1683	      }

1685	   anyForeignElement =
1686	       element * - atom:* {
1687	          (attribute * { text }
1688	           | text
1689	           | anyElement)*
1690	       }

1692	   atomPlainTextConstruct =
1693	       atomCommonAttributes,
1694	       attribute type { "text" | "html" }?,
1695	       text

1697	   atomXHTMLTextConstruct =
1698	       atomCommonAttributes,
1699	       attribute type { "xhtml" },
1700	       xhtmlDiv

1702	   atomTextConstruct = atomPlainTextConstruct | atomXHTMLTextConstruct

1704	   anyXHTML = element xhtml:* {
1705	       (attribute * { text }
1706	        | text
1707	        | anyXHTML)*
1708	   }

1710	   xhtmlDiv = element xhtml:div {
1711	     (attribute * { text }
1712	      | text
1713	      | anyXHTML)*
1714	   }

1716	   # EOF

1718	   The Schema for Category Documents:

1720	   # -*- rnc -*-
1721	   # RELAX NG Compact Syntax Grammar for the Atom Protocol
1722	   namespace app = "http://purl.org/atom/app#"
1723	   namespace atom = "http://www.w3.org/2005/Atom"
1724	   namespace xsd = "http://www.w3.org/2001/XMLSchema"
1725	   namespace local = ""

1727	   start = appCategories

1729	   # common:attrs

1731	   atomCommonAttributes =
1732	      attribute xml:base { atomUri }?,
1733	      attribute xml:lang { atomLanguageTag }?,
1734	      undefinedAttribute*

1736	   undefinedAttribute =
1737	     attribute * - (xml:base | xml:lang | local:*) { text }

1739	   atomUri = text

1741	   atomLanguageTag = xsd:string {
1742	      pattern = "[A-Za-z]{1,8}(-[A-Za-z0-9]{1,8})*"
1743	   }

1745	   atomCategory =
1746	       element atom:category {
1747	          atomCommonAttributes,
1748	          attribute term { text },
1749	          attribute scheme { atomUri }?,
1750	          attribute label { text }?,
1751	          undefinedContent
1752	       }

1754	   appInlineCategories =
1755	       element app:categories {
1756	           attribute fixed { "yes" | "no" }?,
1757	           attribute scheme { atomUri }?,
1758	           (atomCategory*)
1759	       }

1761	   appOutOfLineCategories =
1762	       element app:categories {
1763	           attribute href { atomURI },
1764	           (empty)
1765	       }

1767	   appCategories = appInlineCategories | appOutOfLineCategories
1768	   # Extensibility

1770	   undefinedContent = (text|anyForeignElement)*

1772	   anyElement =
1773	      element * {
1774	         (attribute * { text }
1775	          | text
1776	          | anyElement)*
1777	      }

1779	   anyForeignElement =
1780	       element * - atom:* {
1781	          (attribute * { text }
1782	           | text
1783	           | anyElement)*
1784	       }

1786	   # EOF

1788	Appendix C.  Revision History

1790	   draft-ietf-atompub-protocol-11: Parts of PaceAppEdited.
1791	   PaceSecurityConsiderationsRevised.

1793	   draft-ietf-atompub-protocol-10: PaceRemoveTitleHeader2,
1794	   PaceSlugHeader4, PaceOnlyMemberURI,PaceOneAppNamespaceOnly,
1795	   PaceAppCategories, PaceExtendIntrospection,
1796	   UseElementsForAppCollectionTitles3, renamed Introspection to Service,
1797	   lots of good editorials suggestions, updated media example with slug,
1798	   moved xml conventions to convention sections, renamed XMl related
1799	   Conventions to Atom Publishing Protocol Documents, added auth header
1800	   to examples, consolidated definition of all resource types into the
1801	   model section, added IANA reg info for application/atomcat+xml.

1803	   draft-ietf-atompub-protocol-09: PaceWorkspaceMayHaveCollections,
1804	   PaceMediaEntries5,
1805	   http://www.imc.org/atom-protocol/mail-archive/msg05322.html, and
1806	   http://www.imc.org/atom-protocol/mail-archive/msg05272.html

1808	   draft-ietf-atompub-protocol-08: added infoset ref; added wording re
1809	   IRI/URI; fixed URI/IRI ; next/previous fixed as per Atom
1810	   LinkRelations Attribute
1811	   (http://www.imc.org/atom-protocol/mail-archive/msg04095.html);
1812	   incorporated: PaceEditLinkMustToMay; PaceMissingDraftHasNoMeaning,
1813	   PaceRemoveMemberTypeMust, PaceRemoveMemberTypePostMust,
1814	   PaceTitleHeaderOnlyInMediaCollections, PacePreserveForeignMarkup,
1815	   PaceClarifyTitleHeader, PaceClarifyMediaResourceLinks,
1816	   PaceTwoPrimaryCollections;

1818	   draft-ietf-atompub-protocol-07: updated Atom refs to RFC4287;
1819	   incorporated PaceBetterHttpResponseCode;
1820	   PaceClarifyCollectionAndDeleteMethodByWritingLessInsteadOfMore;
1821	   PaceRemoveAcceptPostText; PaceRemoveListTemplate2;
1822	   PaceRemoveRegistry; PaceRemoveWhoWritesWhat;
1823	   PaceSimplifyClarifyBetterfyRemoveBogusValidityText;
1824	   PaceCollectionOrderSignificance; PaceFixLostIntrospectionText;
1825	   PaceListPaging; PaceCollectionControl; element typo in Listing
1826	   collections para3 (was app:member-type, not app:list-template);
1827	   changed post atom entry example to be valid.  Dropped inline use of
1828	   'APP'.  Removed nested diagram from section 4.  Added ed notes in the
1829	   security section.

1831	   draft-ietf-atompub-protocol-06 - Removed: Robert Sayre from the
1832	   contributors section per his request.  Added in
1833	   PaceCollectionControl.  Fixed all the {daterange} verbage and
1834	   examples so they all use a dash.  Added full rnc schema.  Collapsed
1835	   Introspection and Collection documents into a single document.

1837	   Removed {dateRange} queries.  Renamed search to list.  Moved
1838	   discussion of media and entry collection until later in the document
1839	   and tied the discussion to the Introspection element app:member-type.

1841	   draft-ietf-atompub-protocol-05 - Added: Contributors section.  Added:
1842	   de hOra to editors.  Fixed: typos.  Added diagrams and description to
1843	   model section.  Incorporates PaceAppDocuments, PaceAppDocuments2,
1844	   PaceSimplifyCollections2 (large-sized chunks of it anyhow: the
1845	   notions of Entry and Generic resources, the section 4 language on the
1846	   Protocol Model, 4.1 through 4.5.2, the notion of a Collection
1847	   document, as in Section 5 through 5.3, Section 7 "Collection
1848	   resources", Selection resources (modified from pace which talked
1849	   about search); results in major mods to Collection Documents, Section
1850	   9.2 "Title: Header" and brokeout para to section 9.1 Editing Generic
1851	   Resources).  Added XML namespace and language section.  Some cleanup
1852	   of front matter.  Added Language Sensitivity to some attributes.
1853	   Removed resource descriptions from terminology.  Some juggling of
1854	   sections.  See:
1855	   http://www.imc.org/atom-protocol/mail-archive/msg01812.html.

1857	   draft-ietf-atompub-protocol-04 - Add ladder diagrams, reorganize, add
1858	   SOAP interactions

1860	   draft-ietf-atompub-protocol-03 - Incorporates PaceSliceAndDice3 and
1861	   PaceIntrospection.

1863	   draft-ietf-atompub-protocol-02 - Incorporates Pace409Response,
1864	   PacePostLocationMust, and PaceSimpleResourcePosting.

1866	   draft-ietf-atompub-protocol-01 - Added in sections on Responses for
1867	   the EditURI.  Allow 2xx for response to EditURI PUTs.  Elided all
1868	   mentions of WSSE.  Started adding in some normative references.
1869	   Added the section "Securing the Atom Protocol".  Clarified that it is
1870	   possible that the PostURI and FeedURI could be the same URI.  Cleaned
1871	   up descriptions for Response codes 400 and 500.

1873	   Rev draft-ietf-atompub-protocol-00 - 5Jul2004 - Renamed the file and
1874	   re-titled the document to conform to IETF submission guidelines.
1875	   Changed MIME type to match the one selected for the Atom format.
1876	   Numerous typographical fixes.  We used to have two 'Introduction'
1877	   sections.  One of them was moved into the Abstract the other absorbed
1878	   the Scope section.  IPR and copyright notifications were added.

1880	   Rev 09 - 10Dec2003 - Added the section on SOAP enabled clients and
1881	   servers.

1883	   Rev 08 - 01Dec2003 - Refactored the specification, merging the
1884	   Introspection file into the feed format.  Also dropped the
1885	   distinction between the type of URI used to create new entries and
1886	   the kind used to create comments.  Dropped user preferences.

1888	   Rev 07 - 06Aug2003 - Removed the use of the RSD file for auto-
1889	   discovery.  Changed copyright until a final standards body is chosen.
1890	   Changed query parameters for the search facet to all begin with atom-
1891	   to avoid name collisions.  Updated all the Entries to follow the 0.2
1892	   version.  Changed the format of the search results and template file
1893	   to a pure element based syntax.

1895	   Rev 06 - 24Jul2003 - Moved to PUT for updating Entries.  Changed all
1896	   the mime-types to application/x.atom+xml.  Added template editing.
1897	   Changed 'edit-entry' to 'create-entry' in the Introspection file to
1898	   more accurately reflect its purpose.

1900	   Rev 05 - 17Jul2003 - Renamed everything Echo into Atom.  Added
1901	   version numbers in the Revision history.  Changed all the mime-types
1902	   to application/atom+xml.

1904	   Rev 04 - 15Jul2003 - Updated the RSD version used from 0.7 to 1.0.
1905	   Change the method of deleting an Entry from POSTing <delete/> to
1906	   using the HTTP DELETE verb.  Also changed the query interface to GET
1907	   instead of POST.  Moved Introspection Discovery to be up under
1908	   Introspection.  Introduced the term 'facet' for the services listed
1909	   in the Introspection file.

1911	   Rev 03 - 10Jul2003 - Added a link to the Wiki near the front of the
1912	   document.  Added a section on finding an Entry.  Retrieving an Entry
1913	   now broken out into its own section.  Changed the HTTP status code
1914	   for a successful editing of an Entry to 205.

1916	   Rev 02 - 7Jul2003 - Entries are no longer returned from POSTs,
1917	   instead they are retrieved via GET.  Cleaned up figure titles, as
1918	   they are rendered poorly in HTML.  All content-types have been
1919	   changed to application/atom+xml.

1921	   Rev 01 - 5Jul2003 - Renamed from EchoAPI.html to follow the more
1922	   commonly used format: draft-gregorio-NN.html.  Renamed all references
1923	   to URL to URI.  Broke out introspection into its own section.  Added
1924	   the Revision History section.  Added more to the warning that the
1925	   example URIs are not normative.

1927	Intellectual Property Statement

1929	   The IETF takes no position regarding the validity or scope of any
1930	   Intellectual Property Rights or other rights that might be claimed to
1931	   pertain to the implementation or use of the technology described in
1932	   this document or the extent to which any license under such rights
1933	   might or might not be available; nor does it represent that it has
1934	   made any independent effort to identify any such rights.  Information
1935	   on the procedures with respect to rights in RFC documents can be
1936	   found in BCP 78 and BCP 79.

1938	   Copies of IPR disclosures made to the IETF Secretariat and any
1939	   assurances of licenses to be made available, or the result of an
1940	   attempt made to obtain a general license or permission for the use of
1941	   such proprietary rights by implementers or users of this
1942	   specification can be obtained from the IETF on-line IPR repository at
1943	   http://www.ietf.org/ipr.

1945	   The IETF invites any interested party to bring to its attention any
1946	   copyrights, patents or patent applications, or other proprietary
1947	   rights that may cover technology that may be required to implement
1948	   this standard.  Please address the information to the IETF at
1949	   ietf-ipr@ietf.org.

1951	   The IETF has been notified of intellectual property rights claimed in
1952	   regard to some or all of the specification contained in this
1953	   document.  For more information consult the online list of claimed
1954	   rights.

1956	Disclaimer of Validity

1958	   This document and the information contained herein are provided on an
1959	   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1960	   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1961	   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1962	   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1963	   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1964	   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

1966	Copyright Statement

1968	   Copyright (C) The Internet Society (2006).  This document is subject
1969	   to the rights, licenses and restrictions contained in BCP 78, and
1970	   except as set forth therein, the authors retain all their rights.

1972	Acknowledgment

1974	   Funding for the RFC Editor function is currently provided by the
1975	   Internet Society.