idnits 2.17.1 draft-ietf-atompub-protocol-09.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 1347. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1319. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1326. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1332. ** 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 collection's members. 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 (June 23, 2006) is 6518 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 '' and '' 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) == Missing Reference: 'TEXT' is mentioned on line 705, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO88591' ** 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 (~~), 4 warnings (==), 10 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 BitWorking, Inc 4 Expires: December 25, 2006 B. de hOra, Ed. 5 Propylon Ltd. 6 June 23, 2006 8 The Atom Publishing Protocol 9 draft-ietf-atompub-protocol-09.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 December 25, 2006. 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 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6 56 4. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 7 57 5. Protocol Operations . . . . . . . . . . . . . . . . . . . . 8 58 5.1 Retrieving an Introspection Document . . . . . . . . . . . 8 59 5.2 Creating a Resource . . . . . . . . . . . . . . . . . . . 8 60 5.3 Editing a Resource . . . . . . . . . . . . . . . . . . . . 8 61 5.3.1 Retrieving a Resource . . . . . . . . . . . . . . . . 9 62 5.3.2 Updating a Resource . . . . . . . . . . . . . . . . . 9 63 5.3.3 Deleting a Resource . . . . . . . . . . . . . . . . . 9 64 5.4 Listing Collection Members . . . . . . . . . . . . . . . . 10 65 5.5 Use of HTTP Response codes . . . . . . . . . . . . . . . . 10 66 6. XML-related Conventions . . . . . . . . . . . . . . . . . . 11 67 6.1 Referring to Information Items . . . . . . . . . . . . . . 11 68 6.2 XML Namespace Usage . . . . . . . . . . . . . . . . . . . 11 69 6.3 Use of xml:base and xml:lang . . . . . . . . . . . . . . . 11 70 6.4 RELAX NG Schema . . . . . . . . . . . . . . . . . . . . . 12 71 7. Introspection Documents . . . . . . . . . . . . . . . . . . 13 72 7.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 7.2 Element Definitions . . . . . . . . . . . . . . . . . . . 14 74 7.2.1 The "app:service" Element . . . . . . . . . . . . . . 14 75 7.2.2 The "app:workspace" Element . . . . . . . . . . . . . 14 76 7.2.3 The "app:collection" Element . . . . . . . . . . . . . 15 77 7.2.4 The "app:accept" Element . . . . . . . . . . . . . . . 16 78 8. Collections . . . . . . . . . . . . . . . . . . . . . . . . 17 79 8.1 Creating resources with POST . . . . . . . . . . . . . . . 17 80 8.2 Example . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 8.3 The 'edit' Link . . . . . . . . . . . . . . . . . . . . . 19 82 8.4 Media Resources and Media Link Entries . . . . . . . . . . 19 83 8.4.1 Title: Header . . . . . . . . . . . . . . . . . . . . 20 84 8.4.2 Example . . . . . . . . . . . . . . . . . . . . . . . 20 85 8.5 Editing Entries with Foreign Markup . . . . . . . . . . . 21 86 9. Listing Collections . . . . . . . . . . . . . . . . . . . . 22 87 9.1 Collection Paging . . . . . . . . . . . . . . . . . . . . 22 88 10. Atom Format Link Relation Extensions . . . . . . . . . . . . 24 89 10.1 The "edit" Link Relation . . . . . . . . . . . . . . . . 24 90 10.2 The "edit-media" Link Relation . . . . . . . . . . . . . 24 91 11. Atom Publishing Control Extensions . . . . . . . . . . . . . 25 92 11.1 The Atom Publishing Control Namespace . . . . . . . . . 25 93 11.2 The "pub:control" Element . . . . . . . . . . . . . . . 25 94 11.2.1 The "pub:draft" Element . . . . . . . . . . . . . . 25 95 12. Securing the Atom Protocol . . . . . . . . . . . . . . . . . 26 96 13. Security Considerations . . . . . . . . . . . . . . . . . . 27 97 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 28 98 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 99 15.1 Normative References . . . . . . . . . . . . . . . . . . 30 100 15.2 Informative References . . . . . . . . . . . . . . . . . 31 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 32 102 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 33 103 B. RELAX NG Compact Schema . . . . . . . . . . . . . . . . . . 34 104 C. Revision History . . . . . . . . . . . . . . . . . . . . . . 37 105 Intellectual Property and Copyright Statements . . . . . . . 40 107 1. Introduction 109 The Atom Publishing Protocol is an application-level protocol for 110 publishing and editing Web resources using HTTP [RFC2616] and XML 1.0 111 [W3C.REC-xml-20040204]. The protocol supports the creation of 112 arbitrary web resources and provides facilities for: 114 o Collections: Sets of resources, which can be retrieved in whole or 115 in part. 117 o Introspection: Discovering and describing collections. 119 o Editing: Creating, updating and deleting resources. 121 2. Notational Conventions 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in [RFC2119]. 127 Note: The Introspection Document allows the use of IRIs [RFC3987], as 128 well as URIs [RFC3986]. Every URI is an IRI, so any URI can be used 129 where an IRI is needed. How to map an IRI to a URI is specified in 130 Section 3.1 of Internationalized Resource Identifiers (IRIs) 131 [RFC3987]. 133 3. Terminology 135 For convenience, this protocol can be referred to as the "Atom 136 Protocol" or "APP". 138 URI/IRI - A Uniform Resource Identifier and Internationalized 139 Resource Identifier. These terms and the distinction between them 140 are defined in [RFC3986] and [RFC3987]. Note that IRIs are mapped to 141 URIs before dereferencing takes place. 143 Resource - A network-accessible data object or service identified by 144 an IRI, as defined in [RFC2616]. See [W3C.REC-webarch-20041215] for 145 further discussion on resources. 147 The phrase "the URI of a document" in this specification is shorthand 148 for "an URI which, when dereferenced, is expected to produce that 149 document as a representation". 151 Representation - An entity included with a request or response as 152 defined in [RFC2616]. 154 Collection - A resource that contains a set of member IRIs. See 155 Section 8. 157 Member - A resource whose IRI is listed in a Collection. 159 Introspection Document - A document that describes the location and 160 capabilities of one or more Collections. See Section 7. 162 4. Protocol Model 164 The Atom Publishing Protocol uses HTTP to edit and author web 165 resources. The Atom Protocol uses the following HTTP methods: 167 o GET is used to retrieve a representation of a resource or perform 168 a query. 170 o POST is used to create a new, dynamically-named resource. 172 o PUT is used to update a known resource. 174 o DELETE is used to remove a resource. 176 Along with operations on resources the Atom Protocol provides 177 structures, called Collections, for managing and organising 178 resources, called Members. Collections contain the IRIs of, and 179 metadata about, their Member resources. Atom Protocol clients can 180 use Introspection documents, which represent server-defined groups of 181 Collections, to initialize the process of creating and editing 182 resources. 184 Note that when an IRI is used for resource retrieval over HTTP, the 185 IRI is first converted to a URI according the procedure defined in 186 [RFC3987] section 3.1. The resource that the IRI locates is the same 187 as the one located by the URI obtained after converting the IRI. 189 5. Protocol Operations 191 5.1 Retrieving an Introspection Document 193 Client Server 194 | | 195 | 1.) GET to URI of Introspection Document | 196 |------------------------------------------>| 197 | | 198 | 2.) Introspection Document | 199 |<------------------------------------------| 200 | | 202 1. The client sends a GET request to the URI of the Introspection 203 Document. 205 2. The server responds with the document enumerating the IRIs of a 206 set of Collections and the capabilities of those Collections 207 supported by the server. The content of this document can vary 208 based on aspects of the client request, including, but not 209 limited to, authentication credentials. 211 5.2 Creating a Resource 213 Client Server 214 | | 215 | 1.) POST to URI of Collection | 216 |------------------------------------------>| 217 | | 218 | 2.) 201 Created | 219 |<------------------------------------------| 220 | | 222 1. The client POSTs a representation of the Member to the URI of the 223 collection. 225 2. If the Member resource was created successfully, the server 226 responds with a status code of 201 and a Location: header that 227 contains the URI of the newly created resource. 229 5.3 Editing a Resource 231 Once a resource has been created and its URI is known, that URI can 232 be used to retrieve, update, and delete the resource. 234 5.3.1 Retrieving a Resource 236 Client Server 237 | | 238 | 1.) GET to Member URI | 239 |------------------------------------------>| 240 | | 241 | 2.) Member Representation | 242 |<------------------------------------------| 243 | | 245 1. The client sends a GET request to the Member's URI to retrieve 246 its representation. 248 2. The server responds with the representation of the resource. 250 5.3.2 Updating a Resource 252 Client Server 253 | | 254 | 1.) PUT to Member URI | 255 |------------------------------------------>| 256 | | 257 | 2.) 200 OK | 258 |<------------------------------------------| 260 1. The client PUTs an updated representation to the Member's URI. 262 2. Upon a successful update of the resource the server responds with 263 a status code of 200. 265 5.3.3 Deleting a Resource 267 Client Server 268 | | 269 | 1.) DELETE to Member URI | 270 |------------------------------------------>| 271 | | 272 | 2.) 200 Ok | 273 |<------------------------------------------| 274 | | 276 1. The client sends a DELETE request to the Member's URI. 278 2. Upon the successful deletion of the resource the server responds 279 with a status code of 200. 281 5.4 Listing Collection Members 283 To list the members of a Collection the client sends a GET request to 284 the Collection's URI. An Atom Feed Document is returned containing 285 one Atom Entry for each member resource. See Section 9 and 286 Section 10 for a description of the feed contents. 288 Client Server 289 | | 290 | 1.) GET to Collection URI | 291 |------------------------------->| 292 | | 293 | 2.) 200 OK, Atom Feed Doc | 294 |<-------------------------------| 295 | | 297 1. The client sends a GET request to the Collection's URI. 299 2. The server responds with an Atom Feed Document containing the 300 IRIs of the collection members. 302 5.5 Use of HTTP Response codes 304 The Atom Protocol uses the response status codes defined in HTTP to 305 indicate the success or failure of an operation. Consult the HTTP 306 specification [RFC2616] for detailed definitions of each status code. 307 It is RECOMMENDED that entities contained within HTTP 4xx and 5xx 308 responses include a human-readable explanation of the error. 310 6. XML-related Conventions 312 The Atom Protocol Introspection format is specified in terms of the 313 XML Information Set [W3C.REC-xml-infoset-20040204], serialised as XML 314 1.0 [W3C.REC-xml-20040204]. Atom Publishing Protocol Documents MUST 315 be well-formed XML. This specification does not define any DTDs for 316 Atom Protocol, and hence does not require them to be "valid" in the 317 sense used by XML. 319 6.1 Referring to Information Items 321 This specification uses a shorthand for two common terms: the phrase 322 "Information Item" is omitted when discussing Element Information 323 Items and Attribute Information Items. Therefore, when this 324 specification uses the term "element," it is referring to an Element 325 Information Item in Infoset terms. Likewise, when it uses the term 326 "attribute," it is referring to an Attribute Information Item. 328 6.2 XML Namespace Usage 330 The namespace name [W3C.REC-xml-names-19990114] for the XML format 331 described in this specification is: 333 http://purl.org/atom/app# 335 This specification uses the prefix "app:" for the namespace name. 336 The choice of namespace prefix is not semantically significant. 338 The "app:" namespace is reserved for future forward-compatible 339 revisions of the Atom Publishing Protocol. Future versions of this 340 specification could add new elements and attributes to the markup 341 vocabulary. Software written to conform to this version of the 342 specification will not be able to process such markup correctly and, 343 in fact, will not be able to distinguish it from markup error. For 344 the purposes of this discussion, unrecognized markup from the Atom 345 Publishing Protocol vocabulary will be considered "foreign markup". 347 This specification also uses the prefix "atom:" for 348 "http://www.w3.org/2005/Atom", the namespace name of the Atom 349 Syndication Format [RFC4287]. 351 6.3 Use of xml:base and xml:lang 353 XML elements defined by this specification MAY have an xml:base 354 attribute [W3C.REC-xmlbase-20010627]. When xml:base is used, it 355 serves the function described in section 5.1.1 of URI Generic Syntax 356 [RFC3986], establishing the base URI (or IRI) for resolving any 357 relative references found within the effective scope of the xml:base 358 attribute. 360 Any element defined by this specification MAY have an xml:lang 361 attribute, whose content indicates the natural language for the 362 element and its descendents. The language context is only 363 significant for elements and attributes declared to be "Language- 364 Sensitive" by this specification. Requirements regarding the content 365 and interpretation of xml:lang are specified in Section 2.12 of XML 366 1.0 [W3C.REC-xml-20040204]. 367 appCommonAttributes = 368 attribute xml:base { atomUri }?, 369 attribute xml:lang { atomLanguageTag }?, 370 undefinedAttribute* 372 6.4 RELAX NG Schema 374 Some sections of this specification are illustrated with fragments of 375 a non-normative RELAX NG Compact schema [RNC]. A complete schema 376 appears in Appendix B. However, the text of this specification 377 provides the definition of conformance. 379 7. Introspection Documents 381 For authoring to commence, a client needs to first discover the 382 capabilities and locations of the available collections. 383 Introspection documents are designed to support this discovery 384 process. An Introspection Document describes workspaces, which are 385 server-defined groupings of collections. 387 Introspection documents are identified with the "application/ 388 atomserv+xml" media type (see Section 14). 390 While an introspection document allows multiple workspaces, there is 391 no requirement that a server support multiple workspaces. In 392 addition, a collection MAY appear in more than one workspace. 394 7.1 Example 396 397 398 399 402 405 image/* 406 407 408 409 411 412 414 This Introspection Document describes two workspaces. The first, 415 called "Main Site", has two collections called "My Blog Entries" and 416 "Pictures" whose IRIs are "http://example.org/reilly/main" and 417 "http://example.org/reilly/pic" respectively. The "Pictures" 418 includes an accept element indicating that client can post image 419 files to the collection to create new entries. Entries with 420 associated media resources are discussed in section 8.3. 422 The second workspace is called "Side Bar Blog" and has a single 423 collection called "Remaindered Links" whose collection IRI is 424 "http://example.org/reilly/list". 426 7.2 Element Definitions 428 7.2.1 The "app:service" Element 430 The root of an introspection document is the "app:service" element. 432 The "app:service" element is the container for introspection 433 information associated with one or more workspaces. An app:service 434 element MUST contain one or more app:workspace elements. 436 namespace app = "http://purl.org/atom/app#" 437 start = appService 439 appService = 440 element app:service { 441 appCommonAttributes, 442 ( appWorkspace+ 443 & extensionElement* ) 444 } 446 7.2.2 The "app:workspace" Element 448 The "app:workspace" element contains information elements about the 449 collections of resources available for editing. The app:workspace 450 element MAY contain zero or more app:collection elements. 452 appWorkspace = 453 element app:workspace { 454 appCommonAttributes, 455 attribute title { text }, 456 ( appCollection+ 457 & extensionElement* ) 458 } 460 In an app:workspace element, the first app:collection element MUST 461 refer to the preferred or primary collection. In the following 462 example, the "Entries" collection would be considered the preferred 463 collection: 465 466 467 469 471 image/* 472 473 474 476 7.2.2.1 The "title" Attribute 478 The app:workspace element MUST contain a "title" attribute, which 479 gives a human-readable name for the workspace. This attribute is 480 Language-Sensitive. 482 7.2.3 The "app:collection" Element 484 The "app:collection" describes an Atom Protocol collection. One 485 child element is defined here for app:collection: "app:accept". 487 appCollection = 488 element app:collection { 489 appCommonAttributes, 490 attribute title { text }, 491 attribute href { atomUri }, 492 ( appAccept? 493 & extensionElement* ) 494 } 496 In an Atom feed, the app:collection element MAY appear as a child of 497 an atom:feed or atom:source element to identify the collection to 498 which new entries can be added to the feed. 500 7.2.3.1 The "title" Attribute 502 The app:collection element MUST contain a "title" attribute, whose 503 value gives a human-readable name for the collection. This attribute 504 is Language-Sensitive. 506 7.2.3.2 The "href" Attribute 508 The app:collection element MUST contain a "href" attribute, whose 509 value gives the IRI of the collection. 511 7.2.4 The "app:accept" Element 513 The app:collection element MAY contain one "app:accept" element. The 514 app:accept element value specifies a comma-separated list of media- 515 ranges [RFC2616] identifying the types of representations that can be 516 POSTed to the Collection's URI. Whitespace separating the media- 517 range values is considered insignificant and MUST be ignored. 519 The app:accept element is similar to the HTTP Accept request-header 520 [RFC2616] with the exception that app:accept has no notion of 521 preference. Accordingly, the value syntax of app:accept does not use 522 accept-params or "q" parameters as specified in [RFC2616], section 523 14.1. The order of media-ranges is not significant. The following 524 lists are all equivalent: 526 image/png, image/* 527 image/*, image/png 528 image/* 530 A value of "entry" indicates that Atom Entry Documents can be posted 531 to the Collection. If the accept element is omitted, or empty, 532 clients SHOULD assume that only Atom Entry documents will be accepted 533 by the collection. 535 appAccept = 536 element app:accept { 537 appCommonAttributes, 538 ( appTypeValue? ) 539 } 541 appTypeValue = ( "entry" | media-type |entry-or-media-type ) 542 media-type = xsd:string { pattern = "entry,(.+/.+,?)*" } 543 entry-or-media-type = xsd:string { pattern = "(.+/.+,?)*" } 545 8. Collections 547 8.1 Creating resources with POST 549 To add members to a collection, clients send POST requests to the 550 collection's URI. Collections MAY impose constraints on the media- 551 types of request entities POSTed to the collection and MAY generate a 552 response with a status code of 415 ("Unsupported Media Type"). 554 If an entry was created in the collection which received the POST, 555 its URI MUST be returned in an HTTP Location header. 557 When the server generates a response with a status code of 201 558 ("Created"), it SHOULD also return a response body, which, if 559 provided, MUST be an Atom Entry Document representing the newly- 560 created resource. Clients MUST NOT assume that an Atom Entry 561 returned is a full representation of the member resource. 563 Since the server is free to alter the posted entry, for example by 564 changing the content of the "id" element. returning the entry as 565 described in the previous paragraph can be useful to the client, 566 enabling it to correlate the client and server views of the new 567 entry. 569 When the POST request contains an Atom Entry Document, the response 570 from the server SHOULD contain a Content-Location header that 571 contains the same character-by-character value as the Location 572 header. 574 Clients MUST NOT assume that the URI provided by the Location header 575 can be used to edit the created entry. 577 The request body of the POST need not be an Atom entry. For example, 578 it might be a picture, or a movie. For a discussion of the issues in 579 posting such content, see Section 8.4. 581 8.2 Example 583 Below, the client sends a POST request containing an Atom Entry 584 representation to the URI of the Collection: 586 POST /myblog/entries HTTP/1.1 587 Host: example.org 588 User- Agent: Thingio/1.0 589 Content- Type: application/atom+xml 590 Content- Length: nnn 592 593 594 Atom-Powered Robots Run Amok 595 urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a 596 2003-12-13T18:30:02Z 597 John Doe 598 Some text. 599 601 The server signals a successful creation with a status code of 201. 602 The response includes a "Location" header indicating the URI of the 603 Atom Entry and a representation of that Entry in the body of the 604 response. 606 HTTP/1.1 201 Created 607 Date: Fri, 7 Oct 2005 17:17:11 GMT 608 Content- Length: nnn 609 Content- Type: application/atom+xml; charset="utf-8" 610 Content- Location: http://example.org/edit/first-post.atom 611 Location: http://example.org/edit/first-post.atom 613 614 615 Atom-Powered Robots Run Amok 616 urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a 617 2003-12-13T18:30:02Z 618 John Doe 619 Some text. 620 622 624 Note that the Entry created by the server might not match exactly the 625 Entry POSTed by the client. In particular, a server MAY change the 626 values of various elements in the Entry such as the atom:id, atom: 627 updated and atom:author values and MAY choose to remove or add other 628 elements and attributes, or change element and attribute values. 630 In particular, the publishing system in this example filled in some 631 values not provided in the original POST. For example, presumably it 632 ascertained the author's name via the authentication protocol used to 633 establish the right to post. 635 8.3 The 'edit' Link 637 Each member Entry within a collection SHOULD contain an atom:link 638 element with a link relation of "edit" that contains the IRI used to 639 retrieve, update or delete the member Entry. 641 8.4 Media Resources and Media Link Entries 643 As discussed above, if the body of a client's POST is an Atom Entry 644 document, this constitutes a request that the server create a new 645 entry in the collection to which the POST is addressed and return its 646 URI. 648 If the body of the client's POST is of a media type other than 649 application/atom+xml, this constitutes a request that the server 650 create a new resource as represented by the body of the post, called 651 a "media resource", and also an entry in the collection to which the 652 POST was addressed, called a "media link entry", and return both 653 URIs. If the server successfully creates a media resource and media 654 link entry pair, the Location header included in the response MUST be 655 that of the media link entry. The media link entry MUST have a 656 "content" element with a "src" attribute which links to the media 657 resource. 659 The intent is that the media link entry be used to store metadata 660 about the (perhaps non-textual) media resource, so that the media and 661 the metadata can be retrieved and updated separately. 663 A media link entry SHOULD contain an atom:link element with a link 664 relation of "edit-media" that contains the IRI used to modify the 665 media resource. Deletion of a media link entry SHOULD result in the 666 deletion of the linked media resource. 668 Implementors will note that per the requirements of [RFC4287], media 669 link entries MUST contain an atom:summary element. Upon successful 670 creation of a media link entry, a server MAY choose to populate the 671 atom:summary element (as well as other required elements such as 672 atom:id, atom:author and atom:title) with content derived from the 673 POSTed media resource or from any other source. A server might not 674 allow a client to modify the server selected values for these 675 elements. 677 Note that this specification covers the cases when the POST body is 678 an Atom Entry, and when it is of a non-Atom media type. It does not 679 specify any request semantics or server behavior in the case where 680 the POST media-type is application/atom+xml but the body is something 681 other than an Atom Entry. 683 8.4.1 Title: Header 685 A POST whose body is not of the Atom media type and which thus 686 requests the creation of a media resource SHOULD contain a Title: 687 header indicating the client's suggested title for the resource. For 688 example: 690 POST /myblog/fotes HTTP/1.1 691 Host: example.org 692 Content- Type: image/png 693 Content- Length: nnnn 694 Title: An Atom-Powered Robot 696 ...binary data... 698 The server MAY use the content of the Title: header, as provided or 699 in a modified form, in constructing a title for the resource, which 700 would presumably appear in the media link entry. 702 Title = "Title" ":" [TEXT] 704 The syntax of this header MUST conform to the augmented BNF grammar 705 in section 2.1 of the HTTP/1.1 specification [RFC2616]. The [TEXT] 706 rule is described in section 2.2 of the same document. Words of 707 *TEXT MAY contain characters from character sets other than 708 [ISO88591] only when encoded according to the rules of [RFC2047]. 710 8.4.2 Example 712 Below, the client sends a POST request containing a PNG image to the 713 URI of the Collection: 715 POST /myblog/entries HTTP/1.1 716 Host: example.org 717 Content- Type: image/png 718 Content- Length: nnn 719 Title: A picture of the beach 721 ...binary data... 723 The server signals a successful creation with a status code of 201. 724 The response includes a "Location" header indicating the URI of the 725 media link entry and a representation of that entry in the body of 726 the response. The media link entry includes a content element with a 727 src attribute referencing the media resource, and a link using the 728 link relation "edit-media" specifying the IRI to be used for 729 modifying the media resource. 731 HTTP/1.1 201 Created 732 Date: Fri, 7 Oct 2005 17:17:11 GMT 733 Content- Length: nnn 734 Content- Type: application/atom+xml; charset="utf-8" 735 Content- Location: http://example.org/edit/first-post.atom 736 Location: http://example.org/edit/first-post.atom 738 739 740 A picture of the beach 741 urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a 742 2003-12-13T18:30:02Z 743 John Doe 744 745 747 749 751 753 8.5 Editing Entries with Foreign Markup 755 To avoid unintentional loss of data when editing entries or media 756 link entries, Atom Protocol clients SHOULD preserve all metadata, 757 including unknown foreign markup as defined in Section 6 of 758 [RFC4287], which has not been intentionally modified. 760 9. Listing Collections 762 Collection resources MUST provide representations in the form of Atom 763 Feed documents whose entries represent the collection's members. 764 Each entry in the Feed Document SHOULD have an atom:link element with 765 a relation of "edit" (See Section 10.1). 767 The entries in the returned Atom Feed MUST be ordered by their "atom: 768 updated" property, with the most recently updated entries coming 769 first in the document order. Clients SHOULD be constructed in 770 consideration of the fact that changes which do not alter the entry's 771 atom:updated value will not affect the position of the entry in a 772 collection. 774 Clients MUST NOT assume that an Atom Entry returned in the Feed is a 775 full representation of a member resource and SHOULD perform a GET on 776 the member resource before editing. 778 Collections can contain large numbers of resources. A naive client 779 such as a web spider or web browser could be overwhelmed if the 780 response to a GET contained every entry in the collection, and the 781 server would waste large amounts of bandwidth and processing time on 782 clients unable to handle the response. For this reason, servers MAY 783 return a partial listing containing the most recently updated member 784 resources. Such partial feed documents MUST have an atom:link with a 785 "next" relation whose "href" value is the URI of the next partial 786 listing of the collection (the least recently updated member 787 resources) where it exists. This is called "collection paging". 789 9.1 Collection Paging 791 The returned Atom feed MAY NOT contain entries for all the 792 collection's members. Instead, the Atom feed document MAY contain 793 link elements with "rel" attribute values of "next", "previous", 794 "first" and "last" that can be used to navigate through the complete 795 set of matching entries. 797 For instance, suppose a client is supplied the URI 798 "http://example.org/entries/go" of a collection of member entries, 799 where the server as a matter of policy avoids generating feed 800 documents containing more than 10 entries. The Atom feed document 801 for the collection will then represent the first 'page' in a set of 802 10 linked feed documents. The "first" relation will reference the 803 initial feed document in the set and the "last" relation references 804 the final feed document in the set. Within each document, the "next" 805 and "previous" link relations reference the preceding and subsequent 806 documents. 808 809 811 813 815 ... 816 818 The "next" and "previous" link elements for the feed 'page' located 819 at "http://example.org/entries/2" would look like this: 821 822 824 826 828 830 ... 831 833 10. Atom Format Link Relation Extensions 835 10.1 The "edit" Link Relation 837 The Atom Protocol adds the value "edit" to the Atom Registry of Link 838 Relations (see section 7.1 of [RFC4287]). The value of "edit" 839 specifies that the value of the href attribute is the IRI of an 840 editable Atom Entry Document. When appearing within an atom:entry, 841 the href IRI MAY be used to update and delete the resource 842 represented by that entry. An atom:entry MUST contain no more than 843 one "edit" link relation. 845 10.2 The "edit-media" Link Relation 847 The Atom Protocol adds the value "edit-media" to the Atom Registry of 848 Link Relations (see section 7.1 of [RFC4287]). When appearing within 849 an atom:entry, the value of the href attribute is an IRI that MAY be 850 used to modify a media resource associated with that entry. 852 An atom:entry MAY contain zero or more "edit-media" link relations. 853 An atom:entry MUST NOT contain more than one atom:link element with a 854 rel attribute value of "edit-media" that has the same type and 855 hreflang attribute values. All "edit-media" link relations in the 856 same entry reference the same resource. If a client encounters 857 multiple "edit-media" link relations in an entry then it SHOULD 858 choose a link based on the client preferences for type and hreflang. 859 If a client encounters multiple "edit-media" link relations in an 860 entry and has no preference based on the type and hreflang attributes 861 then the client SHOULD pick the first "edit-media" link relation in 862 document order. 864 11. Atom Publishing Control Extensions 866 11.1 The Atom Publishing Control Namespace 868 This specification defines an Atom Format extension for publishing 869 control called Atom Publishing Control. The namespace name for the 870 Atom Publishing Control's XML vocabulary is 871 "http://example.net/appns/". This specification uses "pub:" for the 872 namespace prefix. The choice of namespace prefix is not semantically 873 significant. 875 11.2 The "pub:control" Element 877 namespace pub = "http://example.net/appns/" 879 pubControl = 880 element pub:control { 881 atomCommonAttributes, 882 pubDraft? 883 & extensionElement 884 } 886 pubDraft = 887 element pub:draft { "yes" | "no" } 889 The "pub:control" element MAY appear as a child of an "atom:entry" 890 which is being created or updated via the Atom Publishing Protocol. 891 The "pub:control" element, if it does appear in an entry, MUST only 892 appear at most one time. The "pub:control" element is considered 893 foreign markup as defined in Section 6 of [RFC4287]. 895 The "pub:control" element and its child elements MAY be included in 896 Atom Feed or Entry Documents. 898 The "pub:control" element MAY contain exactly one "pub:draft" element 899 as defined here, and MAY contain zero or more extension elements as 900 outlined in Section 6 of [RFC4287]. Both clients and servers MUST 901 ignore foreign markup present in the pub:control element. 903 11.2.1 The "pub:draft" Element 905 The number of "pub:draft" elements in "pub:control" MUST be zero or 906 one. Its value MUST be one of "yes" or "no". A value of "no" means 907 that the entry MAY be made publicly visible. If the "pub:draft" 908 element is missing then the value MUST be understood to be "no". The 909 inclusion of the pub:draft element represents a request by the client 910 to control the visibility of an entry and the pub:draft element MAY 911 be ignored by the server. 913 12. Securing the Atom Protocol 915 All instances of publishing Atom Format entries SHOULD be protected 916 by authentication to prevent posting or editing by unknown sources. 917 [[anchor22: note: this section is currently under discussion.]] 919 13. Security Considerations 921 The security of the Atom Protocol is based on [[anchor24: note: 922 refers to incomplete section]]. 924 [[anchor25: note: talk here about denial of service attacks using 925 large XML files, or the billion laughs DTD attack.]] 927 14. IANA Considerations 929 An Atom Publishing Protocol Introspection Document, when serialized 930 as XML 1.0, can be identified with the following media type: 932 MIME media type name: application 934 MIME subtype name: atomserv+xml 936 Mandatory parameters: None. 938 Optional parameters: 940 "charset": This parameter has identical semantics to the charset 941 parameter of the "application/xml" media type as specified in 942 [RFC3023]. 944 Encoding considerations: Identical to those of "application/xml" as 945 described in [RFC3023], section 3.2. 947 Security considerations: As defined in this specification. 948 [[anchor26: update upon publication]] 950 In addition, as this media type uses the "+xml" convention, it 951 shares the same security considerations as described in [RFC3023], 952 section 10. 954 Interoperability considerations: There are no known interoperability 955 issues. 957 Published specification: This specification. [[anchor27: update upon 958 publication]] 960 Applications that use this media type: No known applications 961 currently use this media type. 963 Additional information: 965 Magic number(s): As specified for "application/xml" in [RFC3023], 966 section 3.2. 968 File extension: .atomsrv 970 Fragment identifiers: As specified for "application/xml" in 971 [RFC3023], section 5. 973 Base URI: As specified in [RFC3023], section 6. 975 Macintosh File Type code: TEXT 977 Person and email address to contact for further information: Joe 978 Gregorio 980 Intended usage: COMMON 982 Author/Change controller: This specification's author(s). [[anchor28: 983 update upon publication]] 985 15. References 987 15.1 Normative References 989 [ISO88591] 990 ISO, "International Standard -- Information Processing -- 991 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: 992 Latin alphabet No. 1,", January 1987. 994 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 995 Part Three: Message Header Extensions for Non-ASCII Text", 996 RFC 2047, November 1996. 998 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 999 Requirement Levels", BCP 14, RFC 2119, March 1997. 1001 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1002 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1003 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1005 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 1006 Types", RFC 3023, January 2001. 1008 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1009 Resource Identifier (URI): Generic Syntax", STD 66, 1010 RFC 3986, January 2005. 1012 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 1013 Identifiers (IRIs)", RFC 3987, January 2005. 1015 [RFC4287] Nottingham, M. and R. Sayre, "The Atom Syndication 1016 Format", RFC 4287, December 2005. 1018 [W3C.REC-xml-20040204] 1019 Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T., 1020 and E. Maler, "Extensible Markup Language (XML) 1.0 (Third 1021 Edition)", W3C REC REC-xml-20040204, February 2004. 1023 [W3C.REC-xml-infoset-20040204] 1024 Cowan, J., Tobin, R., and A. Layman, "XML Information Set 1025 (Second Edition)", W3C REC W3C.REC-xml-infoset-20040204, 1026 February 2004. 1028 [W3C.REC-xml-names-19990114] 1029 Hollander, D., Bray, T., and A. Layman, "Namespaces in 1030 XML", W3C REC REC-xml-names-19990114, January 1999. 1032 [W3C.REC-xmlbase-20010627] 1033 Marsh, J., "XML Base", W3C REC W3C.REC-xmlbase-20010627, 1034 June 2001. 1036 15.2 Informative References 1038 [RNC] Clark, J., "RELAX NG Compact Syntax", December 2001. 1040 [W3C.REC-webarch-20041215] 1041 Walsh, N. and I. Jacobs, "Architecture of the World Wide 1042 Web, Volume One", W3C REC REC-webarch-20041215, 1043 December 2004. 1045 URIs 1047 [1] 1049 Authors' Addresses 1051 Joe Gregorio (editor) 1052 BitWorking, Inc 1053 1002 Heathwood Dairy Rd. 1054 Apex, NC 27502 1055 US 1057 Phone: +1 919 272 3764 1058 Email: joe@bitworking.com 1059 URI: http://bitworking.com/ 1061 Bill de hOra (editor) 1062 Propylon Ltd. 1063 45 Blackbourne Square, Rathfarnham Gate 1064 Dublin, Dublin D14 1065 IE 1067 Phone: +353-1-4927444 1068 Email: bill.dehora@propylon.com 1069 URI: http://www.propylon.com/ 1071 Appendix A. Contributors 1073 The content and concepts within are a product of the Atom community 1074 and the Atompub Working Group. 1076 Appendix B. RELAX NG Compact Schema 1078 This appendix is informative. 1080 The Relax NG schema explicitly excludes elements in the Atom Protocol 1081 namespace which are not defined in this revision of the 1082 specification. Requirements for Atom Protocol processors 1083 encountering such markup are given in Section 6.2 and Section 6.3 of 1084 [RFC4287]. 1086 # -*- rnc -*- 1087 # RELAX NG Compact Syntax Grammar for the Atom Protocol 1089 namespace app = "http://purl.org/atom/app#" 1090 namespace local = "" 1092 start = appService 1094 # common:attrs 1096 appCommonAttributes = 1097 attribute xml:base { atomUri }?, 1098 attribute xml:lang { atomLanguageTag }?, 1099 undefinedAttribute* 1101 undefinedAttribute = 1102 attribute * - (xml:base | xml:lang | local:*) { text } 1104 atomUri = text 1106 atomLanguageTag = xsd:string { 1107 pattern = "[A-Za-z]{1,8}(-[A-Za-z0-9]{1,8})*" 1108 } 1110 # app:service 1112 appService = 1113 element app:service { 1114 appCommonAttributes, 1115 ( appWorkspace+ 1116 & extensionElement* ) 1117 } 1119 # app:workspace 1121 appWorkspace = 1122 element app:workspace { 1123 appCommonAttributes, 1124 attribute title { text }, 1125 ( appCollection+ 1126 & extensionElement* ) 1127 } 1129 # app:collection 1131 appCollection = 1132 element app:collection { 1133 appCommonAttributes, 1134 attribute title { text }, 1135 attribute href { atomUri }, 1136 ( appAccept? 1137 & extensionElement* ) 1138 } 1140 # app:member 1142 appAccept = 1143 element app:accept { 1144 appCommonAttributes, 1145 ( appTypeValue? ) 1146 } 1148 appTypeValue = ( "entry" | media-type |entry-or-media-type ) 1149 media-type = xsd:string { pattern = "entry,(.+/.+,?)*" } 1150 entry-or-media-type = xsd:string { pattern = "(.+/.+,?)*" } 1151 # above is an approximation, rnc doesn't support interleaved text 1153 # Simple Extension 1155 simpleExtensionElement = 1156 element * - app:* { 1157 text 1158 } 1160 # Structured Extension 1162 structuredExtensionElement = 1163 element * - app:* { 1164 (attribute * { text }+, 1165 (text|anyElement)*) 1166 | (attribute * { text }*, 1167 (text?, anyElement+, (text|anyElement)*)) 1168 } 1170 # Other Extensibility 1171 extensionElement = 1172 simpleExtensionElement | structuredExtensionElement 1174 # Extensions 1176 anyElement = 1177 element * { 1178 (attribute * { text } 1179 | text 1180 | anyElement)* 1181 } 1183 # EOF 1185 Appendix C. Revision History 1187 draft-ietf-atompub-protocol-09: PaceWorkspaceMayHaveCollections, 1188 PaceMediaEntries5, 1189 http://www.imc.org/atom-protocol/mail-archive/msg05322.html, and 1190 http://www.imc.org/atom-protocol/mail-archive/msg05272.html 1192 draft-ietf-atompub-protocol-08: added infoset ref; added wording re 1193 IRI/URI; fixed URI/IRI ; next/previous fixed as per Atom 1194 LinkRelations Attribute 1195 (http://www.imc.org/atom-protocol/mail-archive/msg04095.html); 1196 incorporated: PaceEditLinkMustToMay; PaceMissingDraftHasNoMeaning, 1197 PaceRemoveMemberTypeMust, PaceRemoveMemberTypePostMust, 1198 PaceTitleHeaderOnlyInMediaCollections, PacePreserveForeignMarkup, 1199 PaceClarifyTitleHeader, PaceClarifyMediaResourceLinks, 1200 PaceTwoPrimaryCollections; 1202 draft-ietf-atompub-protocol-07: updated Atom refs to RFC4287; 1203 incorporated PaceBetterHttpResponseCode; 1204 PaceClarifyCollectionAndDeleteMethodByWritingLessInsteadOfMore; 1205 PaceRemoveAcceptPostText; PaceRemoveListTemplate2; 1206 PaceRemoveRegistry; PaceRemoveWhoWritesWhat; 1207 PaceSimplifyClarifyBetterfyRemoveBogusValidityText; 1208 PaceCollectionOrderSignificance; PaceFixLostIntrospectionText; 1209 PaceListPaging; PaceCollectionControl; element typo in Listing 1210 collections para3 (was app:member-type, not app:list-template); 1211 changed post atom entry example to be valid. Dropped inline use of 1212 'APP'. Removed nested diagram from section 4. Added ed notes in the 1213 security section. 1215 draft-ietf-atompub-protocol-06 - Removed: Robert Sayre from the 1216 contributors section per his request. Added in 1217 PaceCollectionControl. Fixed all the {daterange} verbage and 1218 examples so they all use a dash. Added full rnc schema. Collapsed 1219 Introspection and Collection documents into a single document. 1220 Removed {dateRange} queries. Renamed search to list. Moved 1221 discussion of media and entry collection until later in the document 1222 and tied the discussion to the Introspection element app:member-type. 1224 draft-ietf-atompub-protocol-05 - Added: Contributors section. Added: 1225 de hOra to editors. Fixed: typos. Added diagrams and description to 1226 model section. Incorporates PaceAppDocuments, PaceAppDocuments2, 1227 PaceSimplifyCollections2 (large-sized chunks of it anyhow: the 1228 notions of Entry and Generic resources, the section 4 language on the 1229 Protocol Model, 4.1 through 4.5.2, the notion of a Collection 1230 document, as in Section 5 through 5.3, Section 7 "Collection 1231 resources", Selection resources (modified from pace which talked 1232 about search); results in major mods to Collection Documents, Section 1233 9.2 "Title: Header" and brokeout para to section 9.1 Editing Generic 1234 Resources). Added XML namespace and language section. Some cleanup 1235 of front matter. Added Language Sensitivity to some attributes. 1236 Removed resource descriptions from terminology. Some juggling of 1237 sections. See: 1238 http://www.imc.org/atom-protocol/mail-archive/msg01812.html. 1240 draft-ietf-atompub-protocol-04 - Add ladder diagrams, reorganize, add 1241 SOAP interactions 1243 draft-ietf-atompub-protocol-03 - Incorporates PaceSliceAndDice3 and 1244 PaceIntrospection. 1246 draft-ietf-atompub-protocol-02 - Incorporates Pace409Response, 1247 PacePostLocationMust, and PaceSimpleResourcePosting. 1249 draft-ietf-atompub-protocol-01 - Added in sections on Responses for 1250 the EditURI. Allow 2xx for response to EditURI PUTs. Elided all 1251 mentions of WSSE. Started adding in some normative references. 1252 Added the section "Securing the Atom Protocol". Clarified that it is 1253 possible that the PostURI and FeedURI could be the same URI. Cleaned 1254 up descriptions for Response codes 400 and 500. 1256 Rev draft-ietf-atompub-protocol-00 - 5Jul2004 - Renamed the file and 1257 re-titled the document to conform to IETF submission guidelines. 1258 Changed MIME type to match the one selected for the Atom format. 1259 Numerous typographical fixes. We used to have two 'Introduction' 1260 sections. One of them was moved into the Abstract the other absorbed 1261 the Scope section. IPR and copyright notifications were added. 1263 Rev 09 - 10Dec2003 - Added the section on SOAP enabled clients and 1264 servers. 1266 Rev 08 - 01Dec2003 - Refactored the specification, merging the 1267 Introspection file into the feed format. Also dropped the 1268 distinction between the type of URI used to create new entries and 1269 the kind used to create comments. Dropped user preferences. 1271 Rev 07 - 06Aug2003 - Removed the use of the RSD file for auto- 1272 discovery. Changed copyright until a final standards body is chosen. 1273 Changed query parameters for the search facet to all begin with atom- 1274 to avoid name collisions. Updated all the Entries to follow the 0.2 1275 version. Changed the format of the search results and template file 1276 to a pure element based syntax. 1278 Rev 06 - 24Jul2003 - Moved to PUT for updating Entries. Changed all 1279 the mime-types to application/x.atom+xml. Added template editing. 1280 Changed 'edit-entry' to 'create-entry' in the Introspection file to 1281 more accurately reflect its purpose. 1283 Rev 05 - 17Jul2003 - Renamed everything Echo into Atom. Added 1284 version numbers in the Revision history. Changed all the mime-types 1285 to application/atom+xml. 1287 Rev 04 - 15Jul2003 - Updated the RSD version used from 0.7 to 1.0. 1288 Change the method of deleting an Entry from POSTing to 1289 using the HTTP DELETE verb. Also changed the query interface to GET 1290 instead of POST. Moved Introspection Discovery to be up under 1291 Introspection. Introduced the term 'facet' for the services listed 1292 in the Introspection file. 1294 Rev 03 - 10Jul2003 - Added a link to the Wiki near the front of the 1295 document. Added a section on finding an Entry. Retrieving an Entry 1296 now broken out into its own section. Changed the HTTP status code 1297 for a successful editing of an Entry to 205. 1299 Rev 02 - 7Jul2003 - Entries are no longer returned from POSTs, 1300 instead they are retrieved via GET. Cleaned up figure titles, as 1301 they are rendered poorly in HTML. All content-types have been 1302 changed to application/atom+xml. 1304 Rev 01 - 5Jul2003 - Renamed from EchoAPI.html to follow the more 1305 commonly used format: draft-gregorio-NN.html. Renamed all references 1306 to URL to URI. Broke out introspection into its own section. Added 1307 the Revision History section. Added more to the warning that the 1308 example URIs are not normative. 1310 Intellectual Property Statement 1312 The IETF takes no position regarding the validity or scope of any 1313 Intellectual Property Rights or other rights that might be claimed to 1314 pertain to the implementation or use of the technology described in 1315 this document or the extent to which any license under such rights 1316 might or might not be available; nor does it represent that it has 1317 made any independent effort to identify any such rights. Information 1318 on the procedures with respect to rights in RFC documents can be 1319 found in BCP 78 and BCP 79. 1321 Copies of IPR disclosures made to the IETF Secretariat and any 1322 assurances of licenses to be made available, or the result of an 1323 attempt made to obtain a general license or permission for the use of 1324 such proprietary rights by implementers or users of this 1325 specification can be obtained from the IETF on-line IPR repository at 1326 http://www.ietf.org/ipr. 1328 The IETF invites any interested party to bring to its attention any 1329 copyrights, patents or patent applications, or other proprietary 1330 rights that may cover technology that may be required to implement 1331 this standard. Please address the information to the IETF at 1332 ietf-ipr@ietf.org. 1334 The IETF has been notified of intellectual property rights claimed in 1335 regard to some or all of the specification contained in this 1336 document. For more information consult the online list of claimed 1337 rights. 1339 Disclaimer of Validity 1341 This document and the information contained herein are provided on an 1342 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1343 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1344 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1345 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1346 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1347 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1349 Copyright Statement 1351 Copyright (C) The Internet Society (2006). This document is subject 1352 to the rights, licenses and restrictions contained in BCP 78, and 1353 except as set forth therein, the authors retain all their rights. 1355 Acknowledgment 1357 Funding for the RFC Editor function is currently provided by the 1358 Internet Society.