idnits 2.17.1 

draft-ietf-atompub-protocol-10.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 1813.

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

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

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

  ** 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 ([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 exact meaning of the all-uppercase expression 'MAY NOT' is not
     defined in RFC 2119.  If it is intended as a requirements expression, it
     should be rewritten using one of the combinations defined in RFC 2119;
     otherwise it should not be all-uppercase.

  == The expression 'MAY NOT', while looking like RFC 2119 requirements text,
     is not defined in RFC 2119, and should not be used.  Consider using 'MUST
     NOT' instead (if that is what you mean).
     
     Found 'MAY NOT' in this paragraph:
     
     The returned Atom Feed MAY NOT contain entries for all the Members
     in a Collection.  Instead, the Atom Feed document MAY contain link
     elements with "rel" attribute values of "next", "previous", "first" and
     "last" that can be used to navigate through the complete set of matching
     entries.

  -- 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 (September 05, 2006) is 6444 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 3023 (Obsoleted by RFC 7303)


     Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 9 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: March 9, 2007                                   B. de hOra, Ed.
5	                                                           Propylon Ltd.
6	                                                      September 05, 2006

8	                      The Atom Publishing Protocol
9	                   draft-ietf-atompub-protocol-10.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 March 9, 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  . . . . . . . . . . . . . . . . . . . . . . . .   7
60	   4.   Protocol Model . . . . . . . . . . . . . . . . . . . . . . .   8
61	   5.   Protocol Operations  . . . . . . . . . . . . . . . . . . . .  10
62	     5.1  Retrieving a Service Document  . . . . . . . . . . . . . .  10
63	     5.2  Listing Collection Members . . . . . . . . . . . . . . . .  10
64	     5.3  Creating a Resource  . . . . . . . . . . . . . . . . . . .  11
65	     5.4  Editing a Resource . . . . . . . . . . . . . . . . . . . .  11
66	       5.4.1  Retrieving a Resource  . . . . . . . . . . . . . . . .  11
67	       5.4.2  Updating a Resource  . . . . . . . . . . . . . . . . .  12
68	       5.4.3  Deleting a Resource  . . . . . . . . . . . . . . . . .  12
69	     5.5  Use of HTTP Response codes . . . . . . . . . . . . . . . .  12
70	   6.   Atom Publishing Protocol Documents . . . . . . . . . . . . .  13
71	     6.1  Document Types . . . . . . . . . . . . . . . . . . . . . .  13
72	     6.2  Document Extensibility . . . . . . . . . . . . . . . . . .  13
73	   7.   Category Documents . . . . . . . . . . . . . . . . . . . . .  14
74	     7.1  Example  . . . . . . . . . . . . . . . . . . . . . . . . .  14
75	     7.2  Element Definitions  . . . . . . . . . . . . . . . . . . .  14
76	       7.2.1  The "app:categories" element . . . . . . . . . . . . .  14
77	   8.   Service Documents  . . . . . . . . . . . . . . . . . . . . .  16
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	   11.  Atom Format Link Relation Extensions . . . . . . . . . . . .  30
98	     11.1   The "edit" Link Relation . . . . . . . . . . . . . . . .  30
99	     11.2   The "edit-media" Link Relation . . . . . . . . . . . . .  30
100	   12.  Atom Publishing Controls . . . . . . . . . . . . . . . . . .  31
101	     12.1   The "app:control" Element  . . . . . . . . . . . . . . .  31
102	       12.1.1   The "app:draft" Element  . . . . . . . . . . . . . .  31
103	   13.  Securing the Atom Protocol . . . . . . . . . . . . . . . . .  32
104	   14.  Security Considerations  . . . . . . . . . . . . . . . . . .  33
105	   15.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  34
106	     15.1   Content-type registration for
107	            'application/atomserv+xml' . . . . . . . . . . . . . . .  34
108	     15.2   Content-type registration for
109	            'application/atomcat+xml'  . . . . . . . . . . . . . . .  35
110	   16.  References . . . . . . . . . . . . . . . . . . . . . . . . .  37
111	     16.1   Normative References . . . . . . . . . . . . . . . . . .  37
112	     16.2   Informative References . . . . . . . . . . . . . . . . .  38
113	        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  39
114	   A.   Contributors . . . . . . . . . . . . . . . . . . . . . . . .  40
115	   B.   RELAX NG Compact Schema  . . . . . . . . . . . . . . . . . .  41
116	   C.   Revision History . . . . . . . . . . . . . . . . . . . . . .  47
117	        Intellectual Property and Copyright Statements . . . . . . .  50

119	1.  Introduction

121	   The Atom Publishing Protocol is an application-level protocol for
122	   publishing and editing Web resources using HTTP [RFC2616] and XML 1.0
123	   [W3C.REC-xml-20040204].  The protocol supports the creation of
124	   arbitrary web resources and provides facilities for:

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

129	   o  Service: Discovering and describing Collections.

131	   o  Editing: Creating, updating and deleting resources.

133	2.  Notational Conventions

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

139	   Atom Protocol documents allow the use of IRIs [RFC3987], as well as
140	   URIs [RFC3986].  Before an IRI found in a document is used by HTTP,
141	   the IRI is first converted to a URI according the procedure defined
142	   in [RFC3987] (Section 3.1).  The resource identified by the URI after
143	   conversion is the same as the one identified by the IRI.

145	2.1  XML-related Conventions

147	2.1.1  Referring to Information Items

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

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

160	2.1.2  RELAX NG Schema

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

167	2.1.3  Use of xml:base and xml:lang

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

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

183	3.  Terminology

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

188	   URI/IRI - A Uniform Resource Identifier and Internationalized
189	   Resource Identifier.  These terms and the distinction between them
190	   are defined in [RFC3986] and [RFC3987].  IRIs are mapped to URIs
191	   before dereferencing takes place.

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

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

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

204	   Collection - A resource that contains a set of Member IRIs.  See
205	   Section 9.

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

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

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

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

218	4.  Protocol Model

220	   The Atom Publishing Protocol uses HTTP methods to edit and author
221	   Member Resources as follows:

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

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

227	   o  PUT is used to update a known resource.

229	   o  DELETE is used to remove a known resource.

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

236	   There are two kinds of Member Resources - Member Entry Resources and
237	   Media Resources.  Member Entry Resources are represented as Atom
238	   Entries.  Media Resources MAY have representations in any media type.
239	   A Media Link Entry is a Member Entry that contains metadata about a
240	   Media Resource.  This diagram shows the classification of the
241	   resources:

243	     Member Resource
244	         -> Member Entry Resource
245	              -> Media Link Entry Resource
246	         -> Media Resource

248	   Collections, represented by Atom feeds, contain entries.  Those
249	   entries contain the Member Entry and Media Resources IRIs of the
250	   Collection.  A Collection can contain any number of entries of either
251	   kind.  In the diagram of a Collection below there are two entries.
252	   The first contains the IRI of a Member Entry Resource.  The second
253	   contains the IRIs of both a Media Resource and a Media Link Entry
254	   Resource, which contains the metadata for that Media Resource:

256	     Collection
257	        Entry
258	           Member Entry IRI    ->   Member Entry Resource

260	        Entry
261	           Member Entry IRI    ->   Media Link Entry Resource
262	           Media IRI           ->   Media Resource

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

267	5.  Protocol Operations

269	5.1  Retrieving a Service Document

271	   Client                                     Server
272	     |                                           |
273	     |  1.) GET to URI of Service Document       |
274	     |------------------------------------------>|
275	     |                                           |
276	     |  2.) Service Document                     |
277	     |<------------------------------------------|
278	     |                                           |

280	   1.  The client sends a GET request to the URI of the Service
281	       Document.

283	   2.  The server responds with the document enumerating the IRIs of a
284	       set of Collections and the capabilities of those Collections
285	       supported by the server.  The content of this document can vary
286	       based on aspects of the client request, including, but not
287	       limited to, authentication credentials.

289	5.2  Listing Collection Members

291	   To list the members of a Collection the client sends a GET request to
292	   the URI of a Collection.  An Atom Feed Document is returned
293	   containing one Atom Entry for each Member Entry Resource.  See
294	   Section 10 and Section 11 for a description of the feed contents.

296	   Client                          Server
297	     |                                |
298	     |  1.) GET to Collection URI     |
299	     |------------------------------->|
300	     |                                |
301	     |  2.) 200 OK, Atom Feed Doc     |
302	     |<-------------------------------|
303	     |                                |

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

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

310	5.3  Creating a Resource

312	   Client                                     Server
313	     |                                           |
314	     |  1.) POST to URI of Collection            |
315	     |------------------------------------------>|
316	     |                                           |
317	     |  2.) 201 Created                          |
318	     |      Location: Member Entry URI           |
319	     |<------------------------------------------|
320	     |                                           |

322	   1.  The client POSTs a representation of the Member to the URI of the
323	       Collection.

325	   2.  If the Member Resource was created successfully, the server
326	       responds with a status code of 201 and a Location: header that
327	       contains the IRI of the newly created Member Entry Resource.
328	       Media Resources may have also been created and their IRIs can be
329	       found through the Member Entry Resource.  See Section 9.5 for
330	       more details.

332	5.4  Editing a Resource

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

337	5.4.1  Retrieving a Resource

339	   Client                                     Server
340	     |                                           |
341	     |  1.) GET to Member URI                    |
342	     |------------------------------------------>|
343	     |                                           |
344	     |  2.) Member Representation                |
345	     |<------------------------------------------|
346	     |                                           |

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

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

353	5.4.2  Updating a Resource

355	   Client                                     Server
356	     |                                           |
357	     |  1.) PUT to Member URI                    |
358	     |------------------------------------------>|
359	     |                                           |
360	     |  2.) 200 OK                               |
361	     |<------------------------------------------|

363	   1.  The client PUTs an updated representation to the URI of a Member
364	       Resource.

366	   2.  Upon a successful update of the resource the server responds with
367	       a status code of 200.

369	5.4.3  Deleting a Resource

371	   Client                                     Server
372	     |                                           |
373	     |  1.) DELETE to Member URI                 |
374	     |------------------------------------------>|
375	     |                                           |
376	     |  2.) 200 Ok                               |
377	     |<------------------------------------------|
378	     |                                           |

380	   1.  The client sends a DELETE request to the URI of a Member
381	       Resource.

383	   2.  Upon the successful deletion of the resource the server responds
384	       with a status code of 200.

386	   A different approach is taken for deleting Media Resources, see
387	   Section 9.5 for details.

389	5.5  Use of HTTP Response codes

391	   The Atom Protocol uses the response status codes defined in HTTP to
392	   indicate the success or failure of an operation.  Consult the HTTP
393	   specification [RFC2616] for detailed definitions of each status code.
394	   It is RECOMMENDED that entities contained within HTTP 4xx and 5xx
395	   responses include a human-readable explanation of the error.

397	6.  Atom Publishing Protocol Documents

399	6.1  Document Types

401	   This specification describes two kinds of Documents - Category
402	   Documents and Service Documents.

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

409	   The namespace name [W3C.REC-xml-names-19990114] for either kind of
410	   document is:
411	       http://purl.org/atom/app#

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

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

422	6.2  Document Extensibility

424	   The namespace name "http://purl.org/atom/app#" is reserved for future
425	   forward-compatible revisions of the document types.  Future versions
426	   of this specification could add new elements and attributes.
427	   Software written to conform to this version of the specification will
428	   not be able to process such markup correctly and in fact will not be
429	   able to distinguish it from markup error.

431	   Unrecognized markup in an Atom Publishing Protocol document is
432	   considered "foreign markup" as defined in [RFC4287].

434	   Markup from other vocabularies ("foreign markup") can be used
435	   anywhere within a Category or Service Document unless it is
436	   explicitly forbidden.  Processors that encounter foreign markup MUST
437	   NOT stop processing or signal an error, and SHOULD preserve foreign
438	   markup when transmitting such documents.

440	7.  Category Documents

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

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

450	7.1  Example

452	       <?xml version="1.0" ?>
453	       <app:categories
454	           xmlns:app="http://purl.org/atom/app#"
455	           xmlns="http://www.w3.org/2005/Atom"
456	           fixed="yes" scheme="http://example.com/cats/big3">
457	         <category term="animal" />
458	         <category term="vegetable" />
459	         <category term="mineral" />
460	       </app:categories>

462	   This Category Document contains three categories with the terms
463	   "animal", "vegetable", and "mineral".  None of the categories has a
464	   label attribute (as defined in [RFC4287]).  They all inherit the
465	   "http://example.com/cats/big3" category 'scheme' (in the [RFC4287]
466	   sense) declared on the app:categories element.  Therefore if the
467	   "mineral" category were to appear in an Atom Entry or Feed Document,
468	   it would appear as:

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

472	7.2  Element Definitions

474	7.2.1  The "app:categories" element

476	   The root of a Category Document is the "app:categories" element.  An
477	   app:categories element MAY contain one or more "atom:category"
478	   elements from the Atom namespace ("http://www.w3.org/2005/Atom").

480	   If an app:category child element has no "scheme" attribute it
481	   inherits the attribute from its app:categories parent.  An app:
482	   category child element with an existing "scheme" attribute does not
483	   inherit the "scheme" value of its "app:categories" parent element.

485	7.2.1.1  Attributes of "app:categories"

487	   The app:categories element MAY contain a "fixed" attribute, with a
488	   value of either "yes" or "no", indicating if the list of categories
489	   is a fixed or an open set.  Collections that indicate the set is
490	   fixed MAY reject members whose categories are not listed in the
491	   Collection Document.  Collections that indicate the set is open
492	   SHOULD NOT reject otherwise acceptable members whose categories are
493	   not listed in the Collection.

495	   Alternatively, the app:categories element MAY contain an "href"
496	   attribute, whose value MUST be an IRI reference identifying a
497	   Category Document.  If the "href" attribute is provided, the app:
498	   categories element MUST be empty and MUST NOT have the "fixed" or
499	   "scheme" attributes.

501	   atomCategory =
502	       element atom:category {
503	          atomCommonAttributes,
504	          attribute term { text },
505	          attribute scheme { atomURI }?,
506	          attribute label { text }?,
507	          undefinedContent
508	       }

510	   appInlineCategories =
511	       element app:categories {
512	           attribute fixed { "yes" | "no" }?,
513	           attribute scheme { atomURI }?,
514	           (atomCategory*)
515	       }

517	   appOutOfLineCategories =
518	       element app:categories {
519	           attribute href { atomURI },
520	           (empty)
521	       }

523	   appCategories = appInlineCategories | appOutOfLineCategories

525	8.  Service Documents

527	   For authoring to commence, a client needs to first discover the
528	   capabilities and locations of the available collections.  Service
529	   Documents are designed to support this discovery process.

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

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

538	8.1  Example

540	   <?xml version="1.0" encoding='utf-8'?>
541	   <service xmlns="http://purl.org/atom/app#"
542	            xmlns:atom="http://www.w3.org/2005/Atom">
543	     <workspace>
544	       <atom:title>Main Site</atom:title>
545	       <collection
546	           href="http://example.org/reilly/main" >
547	         <atom:title>My Blog Entries</atom:title>
548	         <categories
549	            href="http://example.com/cats/forMain.cats" />
550	       </collection>
551	       <collection
552	           href="http://example.org/reilly/pic" >
553	         <atom:title>Pictures</atom:title>
554	         <accept>image/*</accept>
555	       </collection>
556	     </workspace>
557	     <workspace>
558	       <atom:title>Side Bar Blog</atom:title>
559	       <collection
560	           href="http://example.org/reilly/list" >
561	         <atom:title>Remaindered Links</atom:title>
562	         <accept>entry</accept>
563	         <categories fixed="yes">
564	           <atom:category
565	             scheme="http://example.org/extra-cats/"
566	             term="joke" />
567	           <atom:category
568	             scheme="http://example.org/extra-cats/"
569	             term="serious" />
570	         </categories>
571	       </collection>
572	     </workspace>

574	   </service>

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

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

588	   Within each of the two entry collections, the categories element
589	   provides a list of available categories for member entries.  In the
590	   "My Blog Entries" Collection, the list of available categories is
591	   obtainable through the "href" attribute.  The "Side Bar Blog"
592	   Collection provides a category list within the Service Document, but
593	   states the list is fixed, signaling a request from the server that
594	   entries be posted using only those two categories.

596	8.2  Element Definitions

598	8.2.1  The "app:service" Element

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

602	   The "app:service" element is the container for service information
603	   associated with one or more workspaces.  An app:service element MUST
604	   contain one or more app:workspace elements.

606	   namespace app = "http://purl.org/atom/app#"
607	   start = appService

609	   appService =
610	      element app:service {
611	         appCommonAttributes,
612	         ( appWorkspace+
613	           & extensionElement* )
614	      }

616	8.2.2  The "app:workspace" Element

618	   The "app:workspace" element contains information elements about the
619	   collections of resources available for editing.  The app:workspace
620	   element contains zero or more app:collection elements.

622	   appWorkspace =
623	      element app:workspace {
624	         appCommonAttributes,
625	         ( appCollection*
626	           & extensionElement* )
627	      }

629	   atomTitle = element atom:title { atomTextConstruct }

631	   In an app:workspace element, the first app:collection element MUST
632	   refer to the preferred or primary Collection.  In the following
633	   example, the "Entries" collection would be considered the preferred
634	   Collection:

636	       <service xmlns="http://purl.org/atom/app#"
637	        xmlns:atom="http://www.w3.org/2005/Atom">
638	         <workspace>
639	           <atom:title>My Blog</atom:title>
640	           <collection
641	                href="http://example.org/myblog/entries" >
642	             <atom:title>Entries</atom:title>
643	          </collection>
644	           <collection
645	                href="http://example.org/myblog/fotes">
646	              <atom:title>Photos</atom:title>
647	              <accept>image/*</accept>
648	           </collection>
649	         </workspace>
650	       </service>

652	8.2.2.1  The "atom:title" Element

654	   The app:workspace element MUST contain one "atom:title" element,
655	   giving a human-readable title for the workspace.

657	8.2.3  The "app:collection" Element

659	   The "app:collection" element describes a Collection.  The app:
660	   collection element MAY contain one app:accept element and MAY contain
661	   any number of app:categories elements.  The app:collection element
662	   MUST NOT contain more that one app:accept element.

664	   appCollection =
665	      element app:collection {
666	         appCommonAttributes,
667	         attribute href { atomURI  },
668	         ( appAccept?

670	           & appCategories*
671	           & extensionElement* )
672	      }

674	8.2.3.1  Usage in Atom Feed Documents

676	   The app:collection element MAY appear as a child of an atom:feed or
677	   atom:source element in an Atom Feed Document.  Its value identifies a
678	   Collection by which new entries can be added to appear in the feed.

680	8.2.3.2  The "href" Attribute

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

685	8.2.3.3  The "atom:title" Element

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

690	8.2.4  The "app:accept" Element

692	   The "app:accept" element value specifies a comma-separated list of
693	   media-ranges (see [RFC2616]) identifying the types of representations
694	   that can be POSTed to the URI of a Collection.  Whitespace separation
695	   of the media-range values is considered insignificant and MUST be
696	   ignored.

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

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

707	     <app:accept>image/png, image/*</app:accept>
708	     <app:accept>image/*, image/png</app:accept>
709	     <app:accept>image/*</app:accept>

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

717	   appAccept =
718	      element app:accept {
719	            appCommonAttributes,
720	            ( appTypeValue? )
721	      }

723	   appTypeValue = ( "entry" | media-type |entry-or-media-type  )
724	   media-type = xsd:string { pattern = "entry,(.+/.+,?)*" }
725	   entry-or-media-type = xsd:string { pattern = "(.+/.+,?)*" }

727	8.2.5  The "app:categories" Element

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

732	   atomCategory =
733	       element atom:category {
734	          atomCommonAttributes,
735	          attribute term { text },
736	          attribute scheme { atomURI }?,
737	          attribute label { text }?,
738	          undefinedContent
739	       }

741	   appInlineCategories =
742	       element app:categories {
743	           attribute fixed { "yes" | "no" }?,
744	           attribute scheme { atomURI }?,
745	           (atomCategory*)
746	       }

748	   appOutOfLineCategories =
749	       element app:categories {
750	           attribute href { atomURI },
751	           (empty)
752	       }

754	   appCategories = appInlineCategories | appOutOfLineCategories
755	   The app:categories element MAY contain a "fixed" attribute, with a
756	   value of either "yes" or "no", indicating whether or not the listing
757	   of categories is considered to be a fixed, or closed set.  The
758	   absence of the "fixed" attribute is equivalent to the presence of a
759	   "fixed" attribute with a value of "no".  Collections that indicate a
760	   fixed set MAY reject members that include categories not specified in
761	   the provided listing.  Collections that indicate an open set SHOULD
762	   NOT reject otherwise acceptable members whose categories are not
763	   present in the provided list.

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

770	9.  Creating and Editing Resources

772	9.1  Member URIs

774	   The Member URI supports retrieving, updating and deleting the
775	   resource using HTTP GET, PUT and DELETE as described in this section.
776	   Retrieval and updating of Member Entry Resources are done via Atom
777	   Entry representations.

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

784	   Each Member Entry SHOULD contain such an atom:link element providing
785	   its Member Entry URI.

787	9.2  Creating resources with POST

789	   To add members to a Collection, clients send POST requests to the URI
790	   of a Collection.  Collections MAY impose constraints on the media-
791	   types of request entities POSTed to the Collection and MAY generate a
792	   response with a status code of 415 ("Unsupported Media Type").

794	   If a Member Resource was created in the Collection which received the
795	   POST, its Member Entry URI MUST be returned in an HTTP Location
796	   header.

798	   When the server generates a response with a status code of 201
799	   ("Created"), it SHOULD also return a response body, which if
800	   provided, MUST be an Atom Entry Document representing the newly-
801	   created resource, and SHOULD include its Member Entry URI in an atom:
802	   link element that has a relation of "edit".

804	   Since the server is free to alter the posted entry, for example by
805	   changing the content of the "id" element, returning the Entry as
806	   described in the previous paragraph can be useful to the client,
807	   enabling it to correlate the client and server views of the new
808	   Entry.

810	   When the POST request contains an Atom Entry Document, the response
811	   from the server SHOULD contain a Content-Location header that
812	   contains the same character-by-character value as the Location
813	   header.

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

819	9.2.1  Example

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

824	       POST /myblog/entries HTTP/1.1
825	       Host: example.org
826	       User-Agent: Thingio/1.0
827	       Authorization: Basic ZGFmZnk6c2VjZXJldA==
828	       Content-Type: application/atom+xml
829	       Content-Length: nnn
830	       Slug: First Post

832	       <?xml version="1.0" ?>
833	       <entry xmlns="http://www.w3.org/2005/Atom"
834	           xmlns:app="http://purl.org/atom/app#">
835	         <title>Atom-Powered Robots Run Amok</title>
836	         <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
837	         <updated>2003-12-13T18:30:02Z</updated>
838	         <author><name>John Doe</name></author>
839	         <content>Some text.</content>
840	       </entry>

842	   The server signals a successful creation with a status code of 201.
843	   The response includes a "Location" header indicating the Member Entry
844	   URI of the Atom Entry and a representation of that Entry in the body
845	   of the response.

847	       HTTP/1.1 201 Created
848	       Date: Fri, 7 Oct 2005 17:17:11 GMT
849	       Content-Length: nnn
850	       Content-Type: application/atom+xml; charset="utf-8"
851	       Content-Location: http://example.org/edit/first-post.atom
852	       Location: http://example.org/edit/first-post.atom

854	       <?xml version="1.0"?>
855	       <entry xmlns="http://www.w3.org/2005/Atom"
856	           xmlns:app="http://purl.org/atom/app#">
857	         <title>Atom-Powered Robots Run Amok</title>
858	         <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
859	         <updated>2003-12-13T18:30:02Z</updated>
860	         <author><name>John Doe</name></author>
861	         <content>Some text.</content>
862	         <link rel="edit"
863	             href="http://example.org/edit/first-post.atom"/>
864	       </entry>

866	   The Entry created and returned by the server might not match the
867	   Entry POSTed by the client.  A server MAY change the values of
868	   various elements in the Entry such as the atom:id, atom:updated and
869	   atom:author values and MAY choose to remove or add other elements and
870	   attributes, or change element and attribute values.

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

877	9.3  Updating Resources with PUT

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

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

887	9.4  Deleting Resources with DELETE

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

894	9.5  Media Resources and Media Link Entries

896	   A client can POST a media type other than application/atom+xml to a
897	   Collection.  Such a request creates two new resources - one that
898	   corresponds to the entity sent in the request, called the Media
899	   Resource, and an associated Member Entry, called the Media Link
900	   Entry.  The server can signal the media types it will accept via the
901	   "accept" element in the Service Document (Section 8.2.4).

903	   The Media Link Entry contains the IRI of the Media Resource and makes
904	   metadata about it separately available for retrieval and update.  The
905	   Media Link Entry is used to store metadata about the (perhaps non-
906	   textual) Media Resource.

908	   Successful responses to creation requests MUST include the URI of the
909	   Media Link Entry in the Location header.  The Media Link Entry SHOULD
910	   contain an atom:link element with a link relation of "edit-media"
911	   that contains the Media Resource IRI.  The Media Link Entry MUST have
912	   an "atom:content" element with a non-empty "src" attribute.  The
913	   value of the "src" attribute is an IRI of the newly created Media
914	   Resource.  It is OPTIONAL that the IRI of the "src" attribute on the
915	   atom:content element be the same as the Media Resource IRI.  That is,
916	   the "src" attribute value might instead be a link into a static cache
917	   or content distribution network and not be the Media Resource IRI.

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

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

937	9.6  The Slug: Header

939	   Slug is a HTTP entity-header whose value is a "slug", i.e. a short
940	   name that can be used as part of URI for a Member Resource.

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

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

953	9.6.1  Slug: Header syntax

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

959	       Slug = "Slug" ":" *TEXT

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

966	9.6.2  Examples

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

971	       POST /myblog/entries HTTP/1.1
972	       Host: example.org
973	       Content-Type: image/png
974	       Slug: The Beach
975	       Authorization: Basic ZGFmZnk6c2VjZXJldA==
976	       Content-Length: nnn

978	       ...binary data...

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

987	       HTTP/1.1 201 Created
988	       Date: Fri, 7 Oct 2005 17:17:11 GMT
989	       Content-Length: nnn
990	       Content-Type: application/atom+xml; charset="utf-8"
991	       Content-Location: http://example.org/myblog/edit/the_beach
992	       Location: http://example.org/myblog/edit/the_beach

994	       <?xml version="1.0"?>
995	       <entry xmlns="http://www.w3.org/2005/Atom">
996	         <title>The Beach</title>
997	         <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
998	         <updated>2005-10-07T17:17:08Z</updated>
999	         <author><name>Daffy</name></author>
1000	         <summary type="text" />
1001	         <content type="image/png"
1002	            src="http://example.org/media/the_beach.png"/>
1003	         <link rel="edit-media"
1004	            href="http://example.org/media/edit/the_beach.png" />
1005	         <link rel="edit"
1006	            href="http://example.org/myblog/edit/the_beach />
1007	       </entry>

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

1012	       POST /myblog/entries HTTP/1.1
1013	       Host: example.org
1014	       Content-Type: image/png
1015	       Slug: =?iso-8859-1?q?The_Beach?=
1016	       Authorization: Basic ZGFmZnk6c2VjZXJldA==
1017	       Content-Length: nnn

1019	       ...binary data...

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

1024	10.  Listing Collections

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

1031	   The entries in the returned Atom Feed MUST be ordered by their "atom:
1032	   updated" property, with the most recently updated entries coming
1033	   first in the document order.  Clients SHOULD be constructed in
1034	   consideration of the fact that changes which do not alter the atom:
1035	   updated value of an entry will not affect the position of the entry
1036	   in a Collection.

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

1042	10.1  Collection Paging

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

1055	   The returned Atom Feed MAY NOT contain entries for all the Members in
1056	   a Collection.  Instead, the Atom Feed document MAY contain link
1057	   elements with "rel" attribute values of "next", "previous", "first"
1058	   and "last" that can be used to navigate through the complete set of
1059	   matching entries.

1061	   For instance, suppose a client is supplied the URI
1062	   "http://example.org/entries/go" of a Collection of Member entries,
1063	   where the server as a matter of policy avoids generating feed
1064	   documents containing more than 10 entries.  The Atom Feed document
1065	   for the Collection will then represent the first 'page' in a set of
1066	   10 linked feed documents.  The "first" relation will reference the
1067	   initial feed document in the set and the "last" relation references
1068	   the final Atom Feed Document in the set.  Within each document, the
1069	   "next" and "previous" link relations reference the preceding and
1070	   subsequent documents.

1072	     <feed xmlns="http://www.w3.org/2005/Atom">
1073	       <link rel="first"
1074	             href="http://example.org/entries/go" />
1075	       <link rel="next"
1076	             href="http://example.org/entries/2" />
1077	       <link rel="last"
1078	             href="http://example.org/entries/10" />
1079	       ...
1080	     </feed>

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

1085	     <feed xmlns="http://www.w3.org/2005/Atom">
1086	       <link rel="first"
1087	             href="http://example.org/entries/go" />
1088	       <link rel="previous"
1089	             href="http://example.org/entries/go" />
1090	       <link rel="next"
1091	             href="http://example.org/entries/3" />
1092	       <link rel="last"
1093	             href="http://example.org/entries/10" />
1094	       ...
1095	     </feed>

1097	11.  Atom Format Link Relation Extensions

1099	11.1  The "edit" Link Relation

1101	   This specification adds the value "edit" to the Atom Registry of Link
1102	   Relations (see section 7.1 of [RFC4287]).  The value of "edit"
1103	   specifies that the value of the href attribute is the IRI of an
1104	   editable Member Entry.  When appearing within an atom:entry, the href
1105	   IRI MAY be used to retrieve, update and delete the resource
1106	   represented by that entry.  An atom:entry MUST contain no more than
1107	   one "edit" link relation.

1109	11.2  The "edit-media" Link Relation

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

1116	   An atom:entry element MAY contain zero or more "edit-media" link
1117	   relations.  An atom:entry MUST NOT contain more than one atom:link
1118	   element with a rel attribute value of "edit-media" that has the same
1119	   type and hreflang attribute values.  All "edit-media" link relations
1120	   in the same entry reference the same resource.  If a client
1121	   encounters multiple "edit-media" link relations in an entry then it
1122	   SHOULD choose a link based on the client preferences for type and
1123	   hreflang.  If a client encounters multiple "edit-media" link
1124	   relations in an entry and has no preference based on the type and
1125	   hreflang attributes then the client SHOULD pick the first "edit-
1126	   media" link relation in document order.

1128	12.  Atom Publishing Controls

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

1134	12.1  The "app:control" Element

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

1138	    pubControl =
1139	       element app:control {
1140	       atomCommonAttributes,
1141	       pubDraft?
1142	       & extensionElement
1143	    }

1145	    pubDraft =
1146	      element app:draft { "yes" | "no" }

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

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

1157	   The app:control element MAY contain exactly one "app:draft" element
1158	   as defined below, and MAY contain zero or more extension elements as
1159	   defined in Section 6 of [RFC4287].

1161	12.1.1  The "app:draft" Element

1163	   The number of app:draft elements in app:control MUST be zero or one.
1164	   Its value MUST be one of "yes" or "no".  A value of "no" indicates a
1165	   client request that the Member Resource be made publicly visible.  If
1166	   the app:draft element is missing then the value MUST be understood to
1167	   be "no".  The inclusion of the app:draft element represents a request
1168	   by the client to control the visibility of a Member Resource and the
1169	   app:draft element MAY be ignored by the server.

1171	13.  Securing the Atom Protocol

1173	   All instances of publishing Atom Format entries SHOULD be protected
1174	   by authentication to prevent posting or editing by unknown sources.
1175	   [[anchor23: note: this section is currently under discussion.]]

1177	14.  Security Considerations

1179	   The security of the Atom Protocol is based on [[anchor25: note:
1180	   refers to incomplete section]].

1182	   [[anchor26: note: talk here about denial of service attacks using
1183	   large XML files, or the billion laughs DTD attack.]]

1185	15.  IANA Considerations

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

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

1192	   MIME media type name: application

1194	   MIME subtype name: atomserv+xml

1196	   Mandatory parameters: None.

1198	   Optional parameters:

1200	      "charset": This parameter has identical semantics to the charset
1201	         parameter of the "application/xml" media type as specified in
1202	         [RFC3023].

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

1207	   Security considerations: As defined in this specification.
1208	      [[anchor27: update upon publication]]

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

1214	   Interoperability considerations: There are no known interoperability
1215	      issues.

1217	   Published specification: This specification. [[anchor28: update upon
1218	      publication]]

1220	   Applications that use this media type: No known applications
1221	      currently use this media type.

1223	   Additional information:

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

1228	   File extension: .atomsrv
1229	   Fragment identifiers: As specified for "application/xml" in
1230	      [RFC3023], section 5.

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

1234	   Macintosh File Type code: TEXT

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

1239	   Intended usage: COMMON

1241	   Author/Change controller: This specification's author(s). [[anchor29:
1242	      update upon publication]]

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

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

1249	   MIME media type name: application

1251	   MIME subtype name: atomcat+xml

1253	   Mandatory parameters: None.

1255	   Optional parameters:

1257	      "charset": This parameter has identical semantics to the charset
1258	         parameter of the "application/xml" media type as specified in
1259	         [RFC3023].

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

1264	   Security considerations: As defined in this specification.
1265	      [[anchor30: update upon publication]]

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

1271	   Interoperability considerations: There are no known interoperability
1272	      issues.

1274	   Published specification: This specification. [[anchor31: update upon
1275	      publication]]

1277	   Applications that use this media type: No known applications
1278	      currently use this media type.

1280	   Additional information:

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

1285	   File extension: .atomcat

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

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

1292	   Macintosh File Type code: TEXT

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

1297	   Intended usage: COMMON

1299	   Author/Change controller: This specification's author(s). [[anchor32:
1300	      update upon publication]]

1302	16.  References

1304	16.1  Normative References

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

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

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

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

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

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

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

1330	   [W3C.REC-xml-20040204]
1331	              Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T.,
1332	              and E. Maler, "Extensible Markup Language (XML) 1.0 (Third
1333	              Edition)", W3C REC REC-xml-20040204, February 2004.

1335	   [W3C.REC-xml-infoset-20040204]
1336	              Cowan, J., Tobin, R., and A. Layman, "XML Information Set
1337	              (Second Edition)", W3C REC W3C.REC-xml-infoset-20040204,
1338	              February 2004.

1340	   [W3C.REC-xml-names-19990114]
1341	              Hollander, D., Bray, T., and A. Layman, "Namespaces in
1342	              XML", W3C REC REC-xml-names-19990114, January 1999.

1344	   [W3C.REC-xmlbase-20010627]
1345	              Marsh, J., "XML Base", W3C REC W3C.REC-xmlbase-20010627,
1346	              June 2001.

1348	16.2  Informative References

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

1352	   [W3C.REC-webarch-20041215]
1353	              Walsh, N. and I. Jacobs, "Architecture of the World Wide
1354	              Web, Volume One", W3C REC REC-webarch-20041215,
1355	              December 2004.

1357	URIs

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

1361	Authors' Addresses

1363	   Joe Gregorio (editor)
1364	   IBM
1365	   4205 South Miama Blvd.
1366	   Research Triangle Park, NC  27709
1367	   US

1369	   Phone: +1 919 272 3764
1370	   Email: joe@bitworking.org
1371	   URI:   http://ibm.com/

1373	   Bill de hOra (editor)
1374	   Propylon Ltd.
1375	   45 Blackbourne Square, Rathfarnham Gate
1376	   Dublin, Dublin  D14
1377	   IE

1379	   Phone: +353-1-4927444
1380	   Email: bill.dehora@propylon.com
1381	   URI:   http://www.propylon.com/

1383	Appendix A.  Contributors

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

1388	Appendix B.  RELAX NG Compact Schema

1390	   This appendix is informative.

1392	   The Relax NG schema explicitly excludes elements in the Atom Protocol
1393	   namespace which are not defined in this revision of the
1394	   specification.  Requirements for Atom Protocol processors
1395	   encountering such markup are given in Section 6.2 and Section 6.3 of
1396	   [RFC4287].

1398	   The Schema for Service Documents:

1400	   # -*- rnc -*-
1401	   # RELAX NG Compact Syntax Grammar for the Atom Protocol

1403	   namespace app = "http://purl.org/atom/app#"
1404	   namespace atom = "http://www.w3.org/2005/Atom"
1405	   namespace xsd = "http://www.w3.org/2001/XMLSchema"
1406	   namespace xhtml = "http://www.w3.org/1999/xhtml"
1407	   namespace local = ""

1409	   start = appService

1411	   # common:attrs

1413	   atomURI = text

1415	   appCommonAttributes =
1416	      attribute xml:base { atomURI }?,
1417	      attribute xml:lang { atomLanguageTag }?,
1418	      undefinedAttribute*

1420	   atomCommonAttributes = appCommonAttributes

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

1425	   atomLanguageTag = xsd:string {
1426	      pattern = "[A-Za-z]{1,8}(-[A-Za-z0-9]{1,8})*"
1427	   }

1429	   atomDateConstruct =
1430	       appCommonAttributes,
1431	       xsd:dateTime

1433	   # app:service

1435	   appService =
1436	      element app:service {
1437	         appCommonAttributes,
1438	         ( appWorkspace+
1439	           & extensionElement* )
1440	      }

1442	   # app:workspace

1444	   appWorkspace =
1445	      element app:workspace {
1446	         appCommonAttributes,
1447	         ( appCollection*
1448	           & extensionElement* )
1449	      }

1451	   atomTitle = element atom:title { atomTextConstruct }

1453	   # app:collection

1455	   appCollection =
1456	      element app:collection {
1457	         appCommonAttributes,
1458	         attribute href { atomURI  },
1459	         ( appAccept?

1461	           & appCategories*
1462	           & extensionElement* )
1463	      }

1465	   # app:categories

1467	   atomCategory =
1468	       element atom:category {
1469	          atomCommonAttributes,
1470	          attribute term { text },
1471	          attribute scheme { atomURI }?,
1472	          attribute label { text }?,
1473	          undefinedContent
1474	       }

1476	   appInlineCategories =
1477	       element app:categories {
1478	           attribute fixed { "yes" | "no" }?,
1479	           attribute scheme { atomURI }?,
1480	           (atomCategory*)

1482	       }

1484	   appOutOfLineCategories =
1485	       element app:categories {
1486	           attribute href { atomURI },
1487	           (empty)
1488	       }

1490	   appCategories = appInlineCategories | appOutOfLineCategories

1492	   # app:accept

1494	   appAccept =
1495	      element app:accept {
1496	            appCommonAttributes,
1497	            ( appTypeValue? )
1498	      }

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

1505	   # Simple Extension

1507	   simpleExtensionElement =
1508	      element * - app:* {
1509	         text
1510	      }

1512	   # Structured Extension

1514	   structuredExtensionElement =
1515	      element * - app:* {
1516	         (attribute * { text }+,
1517	            (text|anyElement)*)
1518	       | (attribute * { text }*,
1519	          (text?, anyElement+, (text|anyElement)*))
1520	      }

1522	   # Other Extensibility

1524	   extensionElement =
1525	      simpleExtensionElement | structuredExtensionElement

1527	   undefinedContent = (text|anyForeignElement)*

1529	   # Extensions

1531	   anyElement =
1532	      element * {
1533	         (attribute * { text }
1534	          | text
1535	          | anyElement)*
1536	      }

1538	   anyForeignElement =
1539	       element * - atom:* {
1540	          (attribute * { text }
1541	           | text
1542	           | anyElement)*
1543	       }

1545	   atomPlainTextConstruct =
1546	       atomCommonAttributes,
1547	       attribute type { "text" | "html" }?,
1548	       text

1550	   atomXHTMLTextConstruct =
1551	       atomCommonAttributes,
1552	       attribute type { "xhtml" },
1553	       xhtmlDiv

1555	   atomTextConstruct = atomPlainTextConstruct | atomXHTMLTextConstruct

1557	   anyXHTML = element xhtml:* {
1558	       (attribute * { text }
1559	        | text
1560	        | anyXHTML)*
1561	   }

1563	   xhtmlDiv = element xhtml:div {
1564	     (attribute * { text }
1565	      | text
1566	      | anyXHTML)*
1567	   }

1569	   # EOF

1571	   The Schema for Category Documents:

1573	   # -*- rnc -*-
1574	   # RELAX NG Compact Syntax Grammar for the Atom Protocol
1575	   namespace app = "http://purl.org/atom/app#"
1576	   namespace atom = "http://www.w3.org/2005/Atom"
1577	   namespace xsd = "http://www.w3.org/2001/XMLSchema"
1578	   namespace local = ""

1580	   start = appCategories

1582	   # common:attrs

1584	   atomCommonAttributes =
1585	      attribute xml:base { atomUri }?,
1586	      attribute xml:lang { atomLanguageTag }?,
1587	      undefinedAttribute*

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

1592	   atomUri = text

1594	   atomLanguageTag = xsd:string {
1595	      pattern = "[A-Za-z]{1,8}(-[A-Za-z0-9]{1,8})*"
1596	   }

1598	   atomCategory =
1599	       element atom:category {
1600	          atomCommonAttributes,
1601	          attribute term { text },
1602	          attribute scheme { atomUri }?,
1603	          attribute label { text }?,
1604	          undefinedContent
1605	       }

1607	   appInlineCategories =
1608	       element app:categories {
1609	           attribute fixed { "yes" | "no" }?,
1610	           attribute scheme { atomUri }?,
1611	           (atomCategory*)
1612	       }

1614	   appOutOfLineCategories =
1615	       element app:categories {
1616	           attribute href { atomURI },
1617	           (empty)
1618	       }

1620	   appCategories = appInlineCategories | appOutOfLineCategories
1621	   # Extensibility

1623	   undefinedContent = (text|anyForeignElement)*

1625	   anyElement =
1626	      element * {
1627	         (attribute * { text }
1628	          | text
1629	          | anyElement)*
1630	      }

1632	   anyForeignElement =
1633	       element * - atom:* {
1634	          (attribute * { text }
1635	           | text
1636	           | anyElement)*
1637	       }

1639	   # EOF

1641	Appendix C.  Revision History

1643	   draft-ietf-atompub-protocol-10: PaceRemoveTitleHeader2,
1644	   PaceSlugHeader4, PaceOnlyMemberURI,PaceOneAppNamespaceOnly,
1645	   PaceAppCategories, PaceExtendIntrospection,
1646	   UseElementsForAppCollectionTitles3, renamed Introspection to Service,
1647	   lots of good editorials suggestions, updated media example with slug,
1648	   moved xml conventions to convention sections, renamed XMl related
1649	   Conventions to Atom Publishing Protocol Documents, added auth header
1650	   to examples, consolidated definition of all resource types into the
1651	   model section, added IANA reg info for application/atomcat+xml.

1653	   draft-ietf-atompub-protocol-09: PaceWorkspaceMayHaveCollections,
1654	   PaceMediaEntries5,
1655	   http://www.imc.org/atom-protocol/mail-archive/msg05322.html, and
1656	   http://www.imc.org/atom-protocol/mail-archive/msg05272.html

1658	   draft-ietf-atompub-protocol-08: added infoset ref; added wording re
1659	   IRI/URI; fixed URI/IRI ; next/previous fixed as per Atom
1660	   LinkRelations Attribute
1661	   (http://www.imc.org/atom-protocol/mail-archive/msg04095.html);
1662	   incorporated: PaceEditLinkMustToMay; PaceMissingDraftHasNoMeaning,
1663	   PaceRemoveMemberTypeMust, PaceRemoveMemberTypePostMust,
1664	   PaceTitleHeaderOnlyInMediaCollections, PacePreserveForeignMarkup,
1665	   PaceClarifyTitleHeader, PaceClarifyMediaResourceLinks,
1666	   PaceTwoPrimaryCollections;

1668	   draft-ietf-atompub-protocol-07: updated Atom refs to RFC4287;
1669	   incorporated PaceBetterHttpResponseCode;
1670	   PaceClarifyCollectionAndDeleteMethodByWritingLessInsteadOfMore;
1671	   PaceRemoveAcceptPostText; PaceRemoveListTemplate2;
1672	   PaceRemoveRegistry; PaceRemoveWhoWritesWhat;
1673	   PaceSimplifyClarifyBetterfyRemoveBogusValidityText;
1674	   PaceCollectionOrderSignificance; PaceFixLostIntrospectionText;
1675	   PaceListPaging; PaceCollectionControl; element typo in Listing
1676	   collections para3 (was app:member-type, not app:list-template);
1677	   changed post atom entry example to be valid.  Dropped inline use of
1678	   'APP'.  Removed nested diagram from section 4.  Added ed notes in the
1679	   security section.

1681	   draft-ietf-atompub-protocol-06 - Removed: Robert Sayre from the
1682	   contributors section per his request.  Added in
1683	   PaceCollectionControl.  Fixed all the {daterange} verbage and
1684	   examples so they all use a dash.  Added full rnc schema.  Collapsed
1685	   Introspection and Collection documents into a single document.
1686	   Removed {dateRange} queries.  Renamed search to list.  Moved
1687	   discussion of media and entry collection until later in the document
1688	   and tied the discussion to the Introspection element app:member-type.

1690	   draft-ietf-atompub-protocol-05 - Added: Contributors section.  Added:
1691	   de hOra to editors.  Fixed: typos.  Added diagrams and description to
1692	   model section.  Incorporates PaceAppDocuments, PaceAppDocuments2,
1693	   PaceSimplifyCollections2 (large-sized chunks of it anyhow: the
1694	   notions of Entry and Generic resources, the section 4 language on the
1695	   Protocol Model, 4.1 through 4.5.2, the notion of a Collection
1696	   document, as in Section 5 through 5.3, Section 7 "Collection
1697	   resources", Selection resources (modified from pace which talked
1698	   about search); results in major mods to Collection Documents, Section
1699	   9.2 "Title: Header" and brokeout para to section 9.1 Editing Generic
1700	   Resources).  Added XML namespace and language section.  Some cleanup
1701	   of front matter.  Added Language Sensitivity to some attributes.
1702	   Removed resource descriptions from terminology.  Some juggling of
1703	   sections.  See:
1704	   http://www.imc.org/atom-protocol/mail-archive/msg01812.html.

1706	   draft-ietf-atompub-protocol-04 - Add ladder diagrams, reorganize, add
1707	   SOAP interactions

1709	   draft-ietf-atompub-protocol-03 - Incorporates PaceSliceAndDice3 and
1710	   PaceIntrospection.

1712	   draft-ietf-atompub-protocol-02 - Incorporates Pace409Response,
1713	   PacePostLocationMust, and PaceSimpleResourcePosting.

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

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

1729	   Rev 09 - 10Dec2003 - Added the section on SOAP enabled clients and
1730	   servers.

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

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

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

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

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

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

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

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

1776	Intellectual Property Statement

1778	   The IETF takes no position regarding the validity or scope of any
1779	   Intellectual Property Rights or other rights that might be claimed to
1780	   pertain to the implementation or use of the technology described in
1781	   this document or the extent to which any license under such rights
1782	   might or might not be available; nor does it represent that it has
1783	   made any independent effort to identify any such rights.  Information
1784	   on the procedures with respect to rights in RFC documents can be
1785	   found in BCP 78 and BCP 79.

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

1794	   The IETF invites any interested party to bring to its attention any
1795	   copyrights, patents or patent applications, or other proprietary
1796	   rights that may cover technology that may be required to implement
1797	   this standard.  Please address the information to the IETF at
1798	   ietf-ipr@ietf.org.

1800	   The IETF has been notified of intellectual property rights claimed in
1801	   regard to some or all of the specification contained in this
1802	   document.  For more information consult the online list of claimed
1803	   rights.

1805	Disclaimer of Validity

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

1815	Copyright Statement

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

1821	Acknowledgment

1823	   Funding for the RFC Editor function is currently provided by the
1824	   Internet Society.