idnits 2.17.1 draft-ietf-atompub-protocol-01.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 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 810. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 782. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 789. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 795. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 816), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 17 longer pages, the longest (page 5) being 71 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 20 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1, 2004) is 7238 days in the past. Is this intentional? 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: 'METHOD' is mentioned on line 654, but not defined ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Gregorio, Ed. 2 Internet-Draft BitWorking, Inc 3 Expires: December 30, 2004 R. Sayre, Ed. 4 Boswijck Memex Consulting 5 July 1, 2004 7 The Atom Publishing Protocol 8 draft-ietf-atompub-protocol-01.txt 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 30, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 This memo presents a protocol for using XML (Extensible Markup 42 Language) and HTTP (HyperText Transport Protocol) to edit content. 44 The Atom Publishing Protocol is an application-level protocol for 45 publishing and editing Web resources belonging to periodically 46 updated websites. The protocol at its core is the HTTP transport of 47 Atom-formatted representations. The Atom format is documented in the 48 Atom Syndication Format (draft-ietf-atompub-format-00.txt). 50 Editorial Note 52 To provide feedback on this Internet-Draft, join the 53 . 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1 Notational Conventions . . . . . . . . . . . . . . . . . . 4 59 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. The Atom Publishing Protocol Model . . . . . . . . . . . . . 4 61 3. Functional Specification . . . . . . . . . . . . . . . . . . 5 62 3.1 PostURI . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.1.1 Locating the PostURI . . . . . . . . . . . . . . . . . 5 64 3.1.2 Request . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1.3 Response . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.2 EditURI . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.2.1 Locating . . . . . . . . . . . . . . . . . . . . . . . 7 68 3.2.2 Request . . . . . . . . . . . . . . . . . . . . . . . 7 69 3.3 FeedURI . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 3.3.1 Locating . . . . . . . . . . . . . . . . . . . . . . . 9 71 3.3.2 Request . . . . . . . . . . . . . . . . . . . . . . . 9 72 3.3.3 Response . . . . . . . . . . . . . . . . . . . . . . . 9 73 3.4 Link Tag . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 3.4.1 rel . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 3.4.2 href . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 3.4.3 title . . . . . . . . . . . . . . . . . . . . . . . . 10 77 3.4.4 type . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 3.5 Atom Request and Response Body Constraints . . . . . . . . 11 79 3.5.1 id . . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 3.5.2 link . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 3.5.3 title . . . . . . . . . . . . . . . . . . . . . . . . 11 82 3.5.4 summary . . . . . . . . . . . . . . . . . . . . . . . 11 83 3.5.5 content . . . . . . . . . . . . . . . . . . . . . . . 12 84 3.5.6 issued . . . . . . . . . . . . . . . . . . . . . . . . 12 85 3.5.7 modified . . . . . . . . . . . . . . . . . . . . . . . 12 86 3.5.8 created . . . . . . . . . . . . . . . . . . . . . . . 12 87 3.5.9 author . . . . . . . . . . . . . . . . . . . . . . . . 13 88 3.5.10 contributor . . . . . . . . . . . . . . . . . . . . 13 89 3.5.11 generator . . . . . . . . . . . . . . . . . . . . . 13 90 3.6 Securing the Atom Protocol . . . . . . . . . . . . . . . . 13 91 3.6.1 [@@TBD@@ CGI Authentication] . . . . . . . . . . . . . 14 92 4. Security Considerations . . . . . . . . . . . . . . . . . . 14 93 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 94 6. Appendix A - SOAP Enabling . . . . . . . . . . . . . . . . . 15 95 6.1 Servers . . . . . . . . . . . . . . . . . . . . . . . . . 15 96 6.2 Clients . . . . . . . . . . . . . . . . . . . . . . . . . 15 97 7. Appendix B - Examples . . . . . . . . . . . . . . . . . . . 15 98 7.1 Example for a weblog . . . . . . . . . . . . . . . . . . . 15 99 7.2 Example for a wiki . . . . . . . . . . . . . . . . . . . . 15 100 8. Revision History . . . . . . . . . . . . . . . . . . . . . . 15 101 9. Normative References . . . . . . . . . . . . . . . . . . . . 17 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17 103 Intellectual Property and Copyright Statements . . . . . . . 19 105 1. Introduction 107 The Atom Publishing Protocol is an application-level protocol for 108 publishing and editing Web resources using HTTP [RFC2616] and XML. 110 1.1 Notational Conventions 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 1.2 Terminology 118 Atom Entry: An Atom Entry is a fragment of a full Atom feed. In this 119 case, the fragment is a single 'entry' element and all its child 120 elements. Each Atom Entry describes a single Web resource, 121 providing metadata and optionally a textual representation of that 122 resource. 123 PostURI: A URI that is used to create new resources. POSTing an Atom 124 Entry to this URI will create a new resource. 125 EditURI: A URI that is used to edit a resource. The editing is done 126 using the HTTP verbs GET, PUT and DELETE. The representation of 127 the resource is always that of an Atom Entry. 128 FeedURI: The URI which identifies an Atom Feed. 130 2. The Atom Publishing Protocol Model 132 The Atom Publishing Protocol is an application-level protocol for 133 publishing and editing Web resources. Using the common HTTP verbs 134 provides a pattern for working with all such Web resources: 135 o GET is used to retrieve a representation of a resource or perform 136 a read-only query. 137 o PUT is used to update a known resource. 138 o POST is used to create a new dynamically-named resource. 139 o DELETE is used to remove a resource. 141 There are three major classes of URIs in this specification: PostURI, 142 FeedURI and EditURI. This specification defines the expected actions 143 for each of the methods listed. A URI MAY support methods not listed 144 here. For example, an EditURI could support a POST or OPTIONS 145 method. However, what those methods do is beyond the scope of this 146 specification. 147 o EditURI: PUT, GET, DELETE 148 o PostURI: POST 149 o FeedURI: GET 151 This document does not specify the form of the URIs that are used. 152 The URI space of each server is controlled, as defined by HTTP, by 153 the server alone. What this document does specify are the formats of 154 the files that are exchanged and the actions that can be performed on 155 the URIs embedded in those files. 157 3. Functional Specification 159 3.1 PostURI 161 The PostURI is used to create entries. These can be either full 162 entries, such as a weblog post, or they can be comments, or even a 163 wiki page. The client POSTs a filled-in Atom Entry to this URI. If 164 the request is successful, one or more Web resources MAY be created. 165 For example, POSTing an Atom entry to a PostURI may create two new 166 Web resources, an HTML representation and an Atom representation. 168 3.1.1 Locating the PostURI 170 The PostURI can be discovered in a link element with an @rel of 171 'service.post'. The link element containing a PostURI used to create 172 a new entry MAY be discovered in three different places. The first 173 place it may be found is in a element in the 'head' element of 174 an HTML document. 176 The second place a PostURI may be found an atom:link element that is 177 a child of the atom:feed element. The third place a PostURI may be 178 found is in the atom:link element of an atom:entry. 180 @@ TBD @@ - Discuss subordinate resources and what a PostURI means 181 based on where the URI was found. 183 188 3.1.2 Request 190 The request contains a filled-in Atom entry, subject to the 191 constraints in section Section 3.5. 193 3.1.3 Response 195 The possible status codes from a POST are 201, 303, 400, 404, 410 and 196 500. 198 3.1.3.1 Response code 201 200 Response includes a Location: header with the URI of the created 201 resource, i.e. the URI used to edit the entry, as opposed to the URI 202 used to display the content. The body of the response will contain 203 the entry "filled-in" with time stamps and any other data the server 204 chooses to reveal. This must contain enough information to enable a 205 client to issue a subsequent PUT to this location. Note that the 206 server may chose to omit the content in the response, particularly if 207 it is large. 209 3.1.3.2 Response code 303 211 The body of this response does not contain the filled-in Entry, but 212 the filled-in Entry can be found under a different URI and can be 213 retrieved using a GET method on that resource. The URI SHOULD be 214 given by the Location field in the response. 216 3.1.3.3 Response code 400 218 Indicates that the server believes that the data sent constitutes an 219 invalid request. As an example, the data posted may not be 220 well-formed XML. The server SHOULD include an entity containing an 221 explanation of the error situation, and whether it is a temporary or 222 permanent condition. 224 3.1.3.4 Response code 500 226 Indicates that the server detected an internal error on the server 227 processing this request (such as an unhandled exception). The server 228 SHOULD include an entity containing an explanation of the error 229 situation, and whether it is a temporary or permanent condition. 231 3.2 EditURI 233 An EditURI is used to edit a single entry. Each entry that is 234 editable MUST have a unique URI. This URI supports both GET and PUT 235 and they are used in tandem for an editing cycle. The client GETs 236 the representation which is formatted as an Atom entry. The client 237 may then update the entry and then PUT it back to the same URI. The 238 PUT will cause all the related resources to be updated, for example, 239 the HTML representation. 241 Note that the value of the content element in the Atom entry does not 242 have to exactly match the content element for the same entry when it 243 is represented in an Atom feed. For example, a server may allow the 244 client to post entries whose content is formatted as WikiML, yet the 245 server may clean up such markup and transform it into well-formed 246 XHTML before placing it in the publicly available Atom feed. Another 247 scenario is summaries--the EditURI is for editing the full content of 248 an entry, but the server may only present excerpts when it produces 249 an Atom feed. 251 A client will send a DELETE to the EditURI to delete an entry. 253 3.2.1 Locating 255 For editing a site Entry, the link tag is used. Note that a link tag 256 is used in both HTML and in the Atom format. A link tag of the 257 following format points to the EditURI for a site. In HTML, the link 258 tags for editing are always found in the head element, while in Atom 259 they may appear as children of the entry elements. 261 266 Note: The critical characteristic of this link tag is the @rel of 267 'service.edit' and the @type of 'application/atom+xml'. 269 3.2.2 Request 271 A PUT request, and a GET response both contain a filled-in Atom 272 entry, subject to the constraints in section Section 3.5. 274 The expected status codes from a GET are 200, 301, 307, and 500. 275 400, 404, and 410 are also possible. 277 The expected status codes from a PUT are 2xx, 301, 307, 500 and 501. 278 400, 404, and 410 are also possible. 280 3.2.2.1 Successful Requests 282 Servers MUST indicate successful GET requests with a 200 response. 284 Servers MUST indicate successful PUT requests with a 2xx response. 285 Servers MAY include additional information in the PUT response. 286 Clients SHOULD NOT expect any additional information in a PUT 287 response. 289 3.2.2.2 Response code 301 291 The entry has moved permanently, the new URI is given in the Location 292 header. The client SHOULD retry the GET using the URI returned in 293 the Location header. When a PUT operation is attempted the user 294 agent should prompt the user before attempting the PUT on the URI 295 returned in the Location header. 297 3.2.2.3 Response code 307 299 The entry has moved temporarily, the new URI is given in the Location 300 header. The client SHOULD retry the GET using the URI returned in 301 the Location header. When a PUT operation is attempted the user 302 agent should prompt the user before attempting the PUT on the URI 303 returned in the Location header. 305 3.2.2.4 Response code 401 307 Indicates that the server believes that the data sent constitutes an 308 invalid request. As an example, the data posted may not be 309 well-formed XML. The server SHOULD include an entity containing an 310 explanation of the error situation, and whether it is a temporary or 311 permanent condition. 313 3.2.2.5 Response code 410 315 Indicates that the requested resource is gone permanently. The 316 client SHOULD NOT repeat the request again. 318 3.2.2.6 Response code 500 320 Indicates that the server detected an internal error on the server 321 processing this request (such as an unhandled exception). The server 322 SHOULD include an entity containing an explanation of the error 323 situation, and whether it is a temporary or permanent condition. 325 3.3 FeedURI 327 The FeedURI is used to retrieve a representation in Atom format. 328 Note that this feed is different from a typical Atom feed in that it 329 contains "link" elements for navigating and manipulating the content 330 of the site. For example there should be a "link" element with 331 rel="next" whose URI points to the next block of entries on the site. 332 Similarly, the feed element can contain a "link" element with 333 rel="service.post", the URI of which is a PostURI. Individual 334 entries should contain "link" elements with rel="service.edit" whose 335 URIs are EditURIs. 337 This document only uses some of the methods available for each type 338 of URI. For example, the only method described by this document for 339 the FeedURI is GET. Any other method may be supported by the URI 340 types described, but defining their behavior is beyond the scope of 341 this document. In this light you may notice that the PostURI only 342 supports the POST method. It is possible, and allowable, that for 343 some implementations the PostURI and the FeedURI are the same URI. 345 @@ Editor's Note: @@ Note that the "service.feed" takes the place of 346 the Introspection File and the Search facet in previous versions of 347 the specification. That is, facet discovery, which was previously 348 done by inspecting the Introspection file is now done by looking for 349 "link" tags with an attribute "rel" set to "service.[something]" in 350 the "service.feed" file. At the same time the same representation 351 replaces the search facet by having "link" tags that point to other 352 feeds using well-known 'rel' attribute values such as 'next' and 353 'prev', or the search can branch in multiple directions by specifying 354 multiple link tags with rel="service.feed" and having differing title 355 attributes that announce the kind of search results in that feed. 357 3.3.1 Locating 359 A link tag of the following format points to the FeedURI. 361 366 3.3.2 Request 368 The request is a simple GET. No other verbs are currently specified 369 for this URI. 371 3.3.3 Response 373 The expected status codes from a GET are 200, 301, 307, and 500. 374 401, 404, and 410 are also possible. 376 3.3.3.1 Response code 301 378 The Feed has moved permanently, the new URI is given in the Location 379 header. The client SHOULD do a GET on the URI returned in the 380 Location header. 382 3.3.3.2 Response code 307 384 The Feed has moved temporarily, the new URI is given in the Location 385 header. The client SHOULD do a GET on the URI returned in the 386 Location header. 388 3.4 Link Tag 390 The link tag is used in both HTML and Atom formats. There are slight 391 differences between the two usages. Here are the commonalities, 392 differences, and a list of well-known values for the rel attribute. 394 appears in 395 the 'head' of the document. The 'head' section only allows a linear 396 list of 'link' tags. The Atom format allows 'link' tags as children 397 of both the 'feed' element and of the 'entry' element. Note that 398 this gives the information present in the link tag more context. For 399 example ... @@ TBD @@ 401 3.4.1 rel 403 This attribute describes the relationship from the current document, 404 be it HTML or Atom, to the anchor specified by the href attribute. 405 The value of this attribute is a space-separated list of link types. 406 Note that these values are case insensitive. When used in concert 407 with type="application/atom+xml", the relations may be interpreted as 408 follows. 409 alternate: The URI in the href attribute points to an alternate 410 representation of the containing resource. 411 start: The Atom feed at the URI supplied in the href attribute 412 contains the first feed in a linear sequence of entries. 413 next: The Atom feed at the URI supplied in the href attribute 414 contains the next N entries in a linear sequence of entries. 415 prev: The Atom feed at the URI supplied in the href attribute 416 contains the previous N entries in a linear sequence of entries. 417 service.edit: The URI given in the href attribute is used to edit a 418 representation of the referred resource. 419 service.post: The URI in the href attribute is used to create new 420 resources. 421 service.feed: The URI given in the href attribute is a starting point 422 for navigating content and services. 424 3.4.2 href 426 URI of the resource being described by this link element. 428 3.4.3 title 430 Offers advisory information about the link. Rendered to the user to 431 help them choose among a set of links with the same rel and type 432 attributes. 434 3.4.4 type 436 The content type of the resource available at the URI given in the 437 href attribute of the link element. Most of the link types in this 438 specification are on type 'application/atom+xml'. 440 3.5 Atom Request and Response Body Constraints 442 The Atom format is used as the representation of all the resources in 443 this specification. As it is used in differing contexts, there are 444 different constraints of which elements may be present, and how their 445 values should be interpreted. 447 3.5.1 id 449 PostURI MUST NOT be present. 450 FeedURI MUST be present. 451 EditURI 452 GET MUST be present. 453 PUT MUST be present. 455 3.5.2 link 457 PostURI MAY be present. Servers MAY use the information to determine 458 the URI of the created resource. Relative URLs are to be 459 interpreted relative to xml:base. 460 FeedURI MUST be present. 461 EditURI 462 GET MUST be present. 463 PUT MUST be present. 465 3.5.3 title 467 PostURI MUST be present. The element may be empty, to explicitly 468 indicate "no title". Servers SHOULD NOT try to generate a title 469 if one is not provided. The type attribute MAY be present, and if 470 not it defaults to "text/plain". If present, it MUST represent a 471 MIME type that the server supports. The mode attribute MAY be 472 present. If not present, it defaults to "xml". If present, it 473 MUST be "xml", "base64", or "escaped". 474 FeedURI MUST be present. 475 EditURI 476 GET MUST be present. 477 PUT MUST be present. The element may be empty, to explicitly 478 indicate "no title". Servers SHOULD NOT try to generate a 479 title if one is not provided. 481 3.5.4 summary 483 PostURI MAY be present. If not present, the server is welcome to 484 produce its own summary. If present but empty, the server SHOULD 485 NOT generate a summary of its own. The type attribute MAY be 486 present. If not, it defaults to "text/plain". If present, it 487 must represent a MIME type that the server supports. The mode 488 attribute MAY be present and defaults to "xml". If present, it 489 must be "xml","base64", or "escaped". 490 FeedURI MAY be present. 491 EditURI 492 GET MAY be present. 493 PUT MAY be present. The element may be empty, to explicitly 494 indicate "no summary". Servers SHOULD NOT try to generate a 495 title if one is not provided. 497 3.5.5 content 499 PostURI MAY be present but may be empty, to explicitly indicate "no 500 content". The type attribute MAY be present, but defaults to 501 "text/plain" if not present. It must represent a MIME type that 502 the server supports. The MODE attribute may be present and 503 defaults to "xml" if not present. It must be "xml","base64", or 504 "escaped". 505 FeedURI MAY be present. 506 EditURI 507 GET MAY be present. 508 PUT MAY be present. The element may be empty, to explicitly 509 indicate "no content". 511 3.5.6 issued 513 PostURI MUST be present, but may be empty, in which case it signifies 514 "now" in the time zone of the server. 515 FeedURI MUST be present. 516 EditURI 517 GET MUST be present. 518 PUT MUST be present. Server policy determines if an updated time 519 is accepted. 521 3.5.7 modified 523 PostURI MUST NOT be present. 524 FeedURI MAY be present. 525 EditURI 526 GET MAY be present. 527 PUT MAY be present. The element may be empty, to explicitly 528 indicate that 'now' on the server time is to be used. 530 3.5.8 created 532 PostURI MAY be present. 534 FeedURI MAY be present. 535 EditURI 536 GET MAY be present. 537 PUT MAY be present. The server may or may not accept an updated 538 value. If the server does not allow updating the issued time 539 then any PUT request with a different issued value MUST be 540 rejected. 542 3.5.9 author 544 PostURI MAY be present. If not present, the server determines the 545 author. If present, and conflicting with valid values as 546 determined by the server, then the server may change the value of 547 author. 548 FeedURI MAY be present. 549 EditURI 550 GET MAY be present. 551 PUT MAY be present. 553 3.5.10 contributor 555 PostURI MAY be present. 556 FeedURI MAY be present. 557 EditURI 558 GET MAY be present. 559 PUT MAY be present. 561 3.5.11 generator 563 PostURI MUST be present and contain a URI. The value of the element 564 indicates the code base used to create this request. MUST also 565 have an attribute 'version' with a version number. 566 FeedURI MUST NOT be present. 567 EditURI 568 GET MUST NOT be present. 569 PUT MUST NOT be present. 571 3.6 Securing the Atom Protocol 573 All instances of publishing Atom entries SHOULD be protected by 574 authentication to prevent posting or editing by unknown sources. 575 Atom servers and clients MUST support one of the following 576 authentication mechanisms, and SHOULD support both. 578 o HTTP Digest Authentication [RFC2617] 579 o [@@TBD@@ CGI Authentication ref] 581 Atom servers and clients MAY support encryption of the Atom session 582 using TLS [RFC2246]. 584 There are cases where an authentication mechanism may not be 585 required, such as a publicly editable Wiki, or when using the PostURI 586 to post comments to a site that does not require authentication to 587 create comments. 589 3.6.1 [@@TBD@@ CGI Authentication] 591 This authentication method is included as part of the protocol to 592 allow Atom servers and clients that cannot use HTTP Digest 593 Authentication but where the user can both insert its own HTTP 594 headers and create a CGI program to authenticate entries to the 595 server. This scenario is common in environments where the user 596 cannot control what services the server employs, but the user can 597 write their own HTTP services. 599 4. Security Considerations 601 Because Atom is a publishing protocol, it is important that only 602 authorized users can create and edit entries. 604 The security of Atom is based on HTTP Digest Authentication and/or 605 [@@TBD@@ CGI Authentication]. Any weaknesses in either of these 606 authentication schemes will obviously affect the security of the Atom 607 Publishing Protocol. 609 Both HTTP Digest Authentication and [@@TBD@@ CGI Authentication] are 610 susceptible to dictionary-based attacks on the shared secret. If the 611 shared secret is a password (instead of a random string with 612 sufficient entropy), an attacker can determine the secret by 613 exhaustively comparing the authenticating string with hashed results 614 of the public string and dictionary entries. 616 See RFC 2617 for more detailed description of the security properties 617 of HTTP Digest Authentication. 619 @@TBD@@ Talk here about using HTTP basic and digest authentication. 621 @@TBD@@ Talk here about denial of service attacks using large XML 622 files, or the billion laughs DTD attack. 624 5. IANA Considerations 626 This document has no actions for IANA. 628 6. Appendix A - SOAP Enabling 630 All servers SHOULD support the following alternate interface 631 mechanisms to enable a wider variety of clients to interact with Atom 632 Publishing Protocol servers. The following requirements are in 633 addition to the ones listed in the Functional Specification Section. 634 If a server supports SOAP Enabling then it MUST support all of the 635 following. 637 6.1 Servers 639 1. All servers MUST support the limited use of the SOAPAction HTTP 640 Header as described below in the Client section. 641 2. All servers MUST be able to process well formed XML. Servers 642 need not be able to handle processing instructions or DTDs. 643 3. Servers MUST accept content in a SOAP Envelope, and if they 644 receive a request that is wrapped in a SOAP Envelope then they 645 MUST wrap their responses in SOAP envelopes or produce a SOAP 646 Fault. 648 6.2 Clients 650 1. Clients SHOULD use the appropriate HTTP Method when possible. 651 When not possible, they should use POST and include a SOAPAction 652 HTTP header which is constrained as follows: 653 2. SOAPAction: "http://schemas.xmlsoap.org/wsdl/http/[METHOD]" 654 3. Where [METHOD] is replaced by the desired HTTP Method. 655 4. Clients MAY wrap their XML payload in a SOAP Envelope. If so, 656 they must also wrap it in an element which exactly matches the 657 HTTP Method. 659 7. Appendix B - Examples 661 7.1 Example for a weblog 663 Fill this in with an example for how all the above is used for a 664 weblog. Start with main HTML page, link tag of type service.feed to 665 the 'introspection' file. 1. Creating a new entry 2. Finding an 666 old entry 3. editing an old entry 4. commenting on a entry (via 667 HTML and Atom) 669 7.2 Example for a wiki 671 Fill this in like above but for a wiki. 673 8. Revision History 675 draft-ietf-atompub-protocol-01 - Added in sections on Responses for 676 the EditURI. Allow 2xx for response to EditURI PUTs. Elided all 677 mentions of WSSE. Started adding in some normative references. 678 Added the section "Securing the Atom Protocol". Clarified that it is 679 possible that the PostURI and FeedURI could be the same URI. Cleaned 680 up descriptions for Response codes 400 and 500. 682 Rev draft-ietf-atompub-protocol-00 - 5Jul2004 - Renamed the file and 683 re-titled the document to conform to IETF submission guidelines. 684 Changed MIME type to match the one selected for the Atom format. 685 Numerous typographical fixes. We used to have two 'Introduction' 686 sections. One of them was moved into the Abstract the other absorbed 687 the Scope section. IPR and copyright notifications were added. 689 Rev 09 - 10Dec2003 - Added the section on SOAP enabled clients and 690 servers. 692 Rev 08 - 01Dec2003 - Refactored the specification, merging the 693 Introspection file into the feed format. Also dropped the 694 distinction between the type of URI used to create new entries and 695 the kind used to create comments. Dropped user preferences. 697 Rev 07 - 06Aug2003 - Removed the use of the RSD file for 698 auto-discovery. Changed copyright until a final standards body is 699 chosen. Changed query parameters for the search facet to all begin 700 with atom- to avoid name collisions. Updated all the Entries to 701 follow the 0.2 version. Changed the format of the search results and 702 template file to a pure element based syntax. 704 Rev 06 - 24Jul2003 - Moved to PUT for updating Entries. Changed all 705 the mime-types to application/x.atom+xml. Added template editing. 706 Changed 'edit-entry' to 'create-entry' in the Introspection file to 707 more accurately reflect it's purpose. 709 Rev 05 - 17Jul2003 - Renamed everything Echo into Atom. Added 710 version numbers in the Revision history. Changed all the mime-types 711 to application/atom+xml. 713 Rev 04 - 15Jul2003 - Updated the RSD version used from 0.7 to 1.0. 714 Change the method of deleting an Entry from POSTing to 715 using the HTTP DELETE verb. Also changed the query interface to GET 716 instead of POST. Moved Introspection Discovery to be up under 717 Introspection. Introduced the term 'facet' for the services listed 718 in the Introspection file. 720 Rev 03 - 10Jul2003 - Added a link to the Wiki near the front of the 721 document. Added a section on finding an Entry. Retrieving an Entry 722 now broken out into it's own section. Changed the HTTP status code 723 for a successful editing of an Entry to 205. 725 Rev 02 - 7Jul2003 - Entries are no longer returned from POSTs, 726 instead they are retrieved via GET. Cleaned up figure titles, as 727 they are rendered poorly in HTML. All content-types have been 728 changed to application/atom+xml. 730 Rev 01 - 5Jul2003 - Renamed from EchoAPI.html to follow the more 731 commonly used format: draft-gregorio-NN.html. Renamed all references 732 to URL to URI. Broke out introspection into it's own section. Added 733 the Revision History section. Added more to the warning that the 734 example URIs are not normative. 736 9 Normative References 738 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 739 Requirement Levels", BCP 14, RFC 2119, March 1997. 741 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 742 RFC 2246, January 1999. 744 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 745 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext 746 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 748 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 749 Leach, P., Luotonen, A. and L. Stewart, "HTTP 750 Authentication: Basic and Digest Access Authentication", 751 RFC 2617, June 1999. 753 Authors' Addresses 755 Joe Gregorio (editor) 756 BitWorking, Inc 757 1002 Heathwood Dairy Rd. 758 Apex, NC 27502 759 US 761 Phone: +1 919 272 3764 762 EMail: joe@bitworking.com 763 URI: http://bitworking.com/ 764 Robert Sayre (editor) 765 Boswijck Memex Consulting 766 148 N 9th St. 4R 767 Brooklyn, NY 11211 768 US 770 EMail: rfsayre@boswijck.com 771 URI: http://boswijck.com 773 Intellectual Property Statement 775 The IETF takes no position regarding the validity or scope of any 776 Intellectual Property Rights or other rights that might be claimed to 777 pertain to the implementation or use of the technology described in 778 this document or the extent to which any license under such rights 779 might or might not be available; nor does it represent that it has 780 made any independent effort to identify any such rights. Information 781 on the procedures with respect to rights in RFC documents can be 782 found in BCP 78 and BCP 79. 784 Copies of IPR disclosures made to the IETF Secretariat and any 785 assurances of licenses to be made available, or the result of an 786 attempt made to obtain a general license or permission for the use of 787 such proprietary rights by implementers or users of this 788 specification can be obtained from the IETF on-line IPR repository at 789 http://www.ietf.org/ipr. 791 The IETF invites any interested party to bring to its attention any 792 copyrights, patents or patent applications, or other proprietary 793 rights that may cover technology that may be required to implement 794 this standard. Please address the information to the IETF at 795 ietf-ipr@ietf.org. 797 The IETF has been notified of intellectual property rights claimed in 798 regard to some or all of the specification contained in this 799 document. For more information consult the online list of claimed 800 rights. 802 Disclaimer of Validity 804 This document and the information contained herein are provided on an 805 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 806 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 807 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 808 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 809 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 810 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 812 Copyright Statement 814 Copyright (C) The Internet Society (2004). This document is subject 815 to the rights, licenses and restrictions contained in BCP 78, and 816 except as set forth therein, the authors retain all their rights. 818 Acknowledgment 820 Funding for the RFC Editor function is currently provided by the 821 Internet Society.