--- 1/draft-ietf-atompub-protocol-01.txt 2006-02-04 22:42:00.000000000 +0100 +++ 2/draft-ietf-atompub-protocol-02.txt 2006-02-04 22:42:01.000000000 +0100 @@ -1,19 +1,19 @@ Network Working Group J. Gregorio, Ed. Internet-Draft BitWorking, Inc -Expires: December 30, 2004 R. Sayre, Ed. +Expires: March 22, 2005 R. Sayre, Ed. Boswijck Memex Consulting - July 1, 2004 + September 21, 2004 The Atom Publishing Protocol - draft-ietf-atompub-protocol-01.txt + draft-ietf-atompub-protocol-02.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -24,91 +24,95 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on December 30, 2004. + This Internet-Draft will expire on March 22, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This memo presents a protocol for using XML (Extensible Markup Language) and HTTP (HyperText Transport Protocol) to edit content. The Atom Publishing Protocol is an application-level protocol for publishing and editing Web resources belonging to periodically updated websites. The protocol at its core is the HTTP transport of Atom-formatted representations. The Atom format is documented in the - Atom Syndication Format (draft-ietf-atompub-format-00.txt). + Atom Syndication Format (draft-ietf-atompub-format-02.txt). Editorial Note To provide feedback on this Internet-Draft, join the . Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Notational Conventions . . . . . . . . . . . . . . . . . . 4 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. The Atom Publishing Protocol Model . . . . . . . . . . . . . 4 3. Functional Specification . . . . . . . . . . . . . . . . . . 5 3.1 PostURI . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1.1 Locating the PostURI . . . . . . . . . . . . . . . . . 5 3.1.2 Request . . . . . . . . . . . . . . . . . . . . . . . 5 3.1.3 Response . . . . . . . . . . . . . . . . . . . . . . . 5 - 3.2 EditURI . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.2 EditURI . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.1 Locating . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.2 Request . . . . . . . . . . . . . . . . . . . . . . . 7 - 3.3 FeedURI . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 3.3.1 Locating . . . . . . . . . . . . . . . . . . . . . . . 9 - 3.3.2 Request . . . . . . . . . . . . . . . . . . . . . . . 9 - 3.3.3 Response . . . . . . . . . . . . . . . . . . . . . . . 9 - 3.4 Link Tag . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 3.4.1 rel . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 3.4.2 href . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 3.4.3 title . . . . . . . . . . . . . . . . . . . . . . . . 10 - 3.4.4 type . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 3.5 Atom Request and Response Body Constraints . . . . . . . . 11 - 3.5.1 id . . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 3.5.2 link . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 3.5.3 title . . . . . . . . . . . . . . . . . . . . . . . . 11 - 3.5.4 summary . . . . . . . . . . . . . . . . . . . . . . . 11 - 3.5.5 content . . . . . . . . . . . . . . . . . . . . . . . 12 - 3.5.6 issued . . . . . . . . . . . . . . . . . . . . . . . . 12 - 3.5.7 modified . . . . . . . . . . . . . . . . . . . . . . . 12 - 3.5.8 created . . . . . . . . . . . . . . . . . . . . . . . 12 - 3.5.9 author . . . . . . . . . . . . . . . . . . . . . . . . 13 - 3.5.10 contributor . . . . . . . . . . . . . . . . . . . . 13 - 3.5.11 generator . . . . . . . . . . . . . . . . . . . . . 13 - 3.6 Securing the Atom Protocol . . . . . . . . . . . . . . . . 13 - 3.6.1 [@@TBD@@ CGI Authentication] . . . . . . . . . . . . . 14 - 4. Security Considerations . . . . . . . . . . . . . . . . . . 14 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 - 6. Appendix A - SOAP Enabling . . . . . . . . . . . . . . . . . 15 - 6.1 Servers . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 6.2 Clients . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 7. Appendix B - Examples . . . . . . . . . . . . . . . . . . . 15 - 7.1 Example for a weblog . . . . . . . . . . . . . . . . . . . 15 - 7.2 Example for a wiki . . . . . . . . . . . . . . . . . . . . 15 - 8. Revision History . . . . . . . . . . . . . . . . . . . . . . 15 - 9. Normative References . . . . . . . . . . . . . . . . . . . . 17 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17 - Intellectual Property and Copyright Statements . . . . . . . 19 + 3.3 FeedURI . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 3.3.1 Locating . . . . . . . . . . . . . . . . . . . . . . . 10 + 3.3.2 Request . . . . . . . . . . . . . . . . . . . . . . . 10 + 3.3.3 Response . . . . . . . . . . . . . . . . . . . . . . . 10 + 3.4 ResourcePostURI . . . . . . . . . . . . . . . . . . . . . 10 + 3.4.1 Locating . . . . . . . . . . . . . . . . . . . . . . . 10 + 3.4.2 Request . . . . . . . . . . . . . . . . . . . . . . . 11 + 3.4.3 Response . . . . . . . . . . . . . . . . . . . . . . . 11 + 3.5 Link Tag . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 3.5.1 rel . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 3.5.2 href . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 3.5.3 title . . . . . . . . . . . . . . . . . . . . . . . . 13 + 3.5.4 type . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 3.6 Atom Request and Response Body Constraints . . . . . . . . 13 + 3.6.1 id . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 3.6.2 link . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 3.6.3 title . . . . . . . . . . . . . . . . . . . . . . . . 13 + 3.6.4 summary . . . . . . . . . . . . . . . . . . . . . . . 14 + 3.6.5 content . . . . . . . . . . . . . . . . . . . . . . . 14 + 3.6.6 issued . . . . . . . . . . . . . . . . . . . . . . . . 14 + 3.6.7 modified . . . . . . . . . . . . . . . . . . . . . . . 15 + 3.6.8 created . . . . . . . . . . . . . . . . . . . . . . . 15 + 3.6.9 author . . . . . . . . . . . . . . . . . . . . . . . . 15 + 3.6.10 contributor . . . . . . . . . . . . . . . . . . . . 15 + 3.6.11 generator . . . . . . . . . . . . . . . . . . . . . 15 + 3.7 Securing the Atom Protocol . . . . . . . . . . . . . . . . 16 + 3.7.1 [@@TBD@@ CGI Authentication] . . . . . . . . . . . . . 16 + 4. Security Considerations . . . . . . . . . . . . . . . . . . 16 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 17 + 6. Appendix A - SOAP Enabling . . . . . . . . . . . . . . . . . 17 + 6.1 Servers . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 6.2 Clients . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 7. Appendix B - Examples . . . . . . . . . . . . . . . . . . . 17 + 7.1 Example for a weblog . . . . . . . . . . . . . . . . . . . 17 + 7.2 Example for a wiki . . . . . . . . . . . . . . . . . . . . 18 + 8. Revision History . . . . . . . . . . . . . . . . . . . . . . 18 + 9. Normative References . . . . . . . . . . . . . . . . . . . . 19 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20 + Intellectual Property and Copyright Statements . . . . . . . 21 1. Introduction The Atom Publishing Protocol is an application-level protocol for publishing and editing Web resources using HTTP [RFC2616] and XML. 1.1 Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this @@ -132,31 +136,33 @@ The Atom Publishing Protocol is an application-level protocol for publishing and editing Web resources. Using the common HTTP verbs provides a pattern for working with all such Web resources: o GET is used to retrieve a representation of a resource or perform a read-only query. o PUT is used to update a known resource. o POST is used to create a new dynamically-named resource. o DELETE is used to remove a resource. - There are three major classes of URIs in this specification: PostURI, - FeedURI and EditURI. This specification defines the expected actions - for each of the methods listed. A URI MAY support methods not listed - here. For example, an EditURI could support a POST or OPTIONS - method. However, what those methods do is beyond the scope of this - specification. + There are four major classes of URI [RFC2396] in this specification: + PostURI, ResourcePostURI, FeedURI, and EditURI. This specification + defines the expected actions for each of the methods listed. A URI + MAY support methods not listed here. For example, an EditURI could + support a POST or OPTIONS method. However, what those methods do is + beyond the scope of this specification. o EditURI: PUT, GET, DELETE o PostURI: POST o FeedURI: GET + o ResourcePostURI: POST This document does not specify the form of the URIs that are used. + The URI space of each server is controlled, as defined by HTTP, by the server alone. What this document does specify are the formats of the files that are exchanged and the actions that can be performed on the URIs embedded in those files. 3. Functional Specification 3.1 PostURI The PostURI is used to create entries. These can be either full @@ -177,59 +183,80 @@ The second place a PostURI may be found an atom:link element that is a child of the atom:feed element. The third place a PostURI may be found is in the atom:link element of an atom:entry. @@ TBD @@ - Discuss subordinate resources and what a PostURI means based on where the URI was found. + title="The name of the site." /> 3.1.2 Request The request contains a filled-in Atom entry, subject to the - constraints in section Section 3.5. + constraints in section Section 3.6. 3.1.3 Response - The possible status codes from a POST are 201, 303, 400, 404, 410 and - 500. + The possible status codes from a POST are 201, 303, 400, 404, 409, + 410 and 500. 3.1.3.1 Response code 201 - Response includes a Location: header with the URI of the created - resource, i.e. the URI used to edit the entry, as opposed to the URI - used to display the content. The body of the response will contain - the entry "filled-in" with time stamps and any other data the server - chooses to reveal. This must contain enough information to enable a - client to issue a subsequent PUT to this location. Note that the - server may chose to omit the content in the response, particularly if - it is large. + The Response MUST include a Location: header with the URI of the + created resource. The URI returned must be the EditURI of the entry + just created. The body of the response SHOULD contain the newly + created entry. If the entry is present in the response body then it + MUST conform to the same constraints listed for responses to a GET on + an EditURI. User agents MUST NOT depend on the server returning a + response body. If the server does return a response body then the + user agents MUST NOT depend on the response body having a + content-type of 'application/atom+xml". Note that the server may + choose to omit the content in the response, particularly if it is + large. + + A 201 response MAY contain an ETag response header field indicating + the current value of the entity tag for the requested variant just + created. + + If the entry returned is subsequently changed the user agent can + update the entry by submitting it via PUT to the EditURI. If an ETag + was returned with the creation of the entry then the user agent + SHOULD include an If-Match: header in the request that contains that + ETag. 3.1.3.2 Response code 303 The body of this response does not contain the filled-in Entry, but the filled-in Entry can be found under a different URI and can be retrieved using a GET method on that resource. The URI SHOULD be given by the Location field in the response. 3.1.3.3 Response code 400 Indicates that the server believes that the data sent constitutes an invalid request. As an example, the data posted may not be well-formed XML. The server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. -3.1.3.4 Response code 500 +3.1.3.4 Response code 409 + + The request contained a valid Atom Entry, but it conflicts with state + on the server. The response SHOULD contain enough for information + for the user to resolve the conflict. + + [[@@TBD@@ more about response body format]] + +3.1.3.5 Response code 500 Indicates that the server detected an internal error on the server processing this request (such as an unhandled exception). The server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. 3.2 EditURI An EditURI is used to edit a single entry. Each entry that is editable MUST have a unique URI. This URI supports both GET and PUT @@ -255,35 +282,35 @@ For editing a site Entry, the link tag is used. Note that a link tag is used in both HTML and in the Atom format. A link tag of the following format points to the EditURI for a site. In HTML, the link tags for editing are always found in the head element, while in Atom they may appear as children of the entry elements. + title="Readable desc of the entry." /> Note: The critical characteristic of this link tag is the @rel of 'service.edit' and the @type of 'application/atom+xml'. 3.2.2 Request A PUT request, and a GET response both contain a filled-in Atom - entry, subject to the constraints in section Section 3.5. + entry, subject to the constraints in section Section 3.6. The expected status codes from a GET are 200, 301, 307, and 500. 400, 404, and 410 are also possible. The expected status codes from a PUT are 2xx, 301, 307, 500 and 501. - 400, 404, and 410 are also possible. + 400, 404, 409, and 410 are also possible. 3.2.2.1 Successful Requests Servers MUST indicate successful GET requests with a 200 response. Servers MUST indicate successful PUT requests with a 2xx response. Servers MAY include additional information in the PUT response. Clients SHOULD NOT expect any additional information in a PUT response. @@ -304,26 +331,40 @@ returned in the Location header. 3.2.2.4 Response code 401 Indicates that the server believes that the data sent constitutes an invalid request. As an example, the data posted may not be well-formed XML. The server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. -3.2.2.5 Response code 410 +3.2.2.5 Response code 409 + + The request contained a valid Atom Entry, but it conflicts with the + state of the resource, or other state on the server. + + For example, a server could signal that the client has erred in this + manner if it receives a request containing an atom:id element whose + value differs from that of the resource found at the requested URI. + + The response SHOULD contain enough for information for the user to + resolve the conflict. + + [[@@TBD@@ more about response body format ]] + +3.2.2.6 Response code 410 Indicates that the requested resource is gone permanently. The - client SHOULD NOT repeat the request again. + client SHOULD NOT repeat the request. -3.2.2.6 Response code 500 +3.2.2.7 Response code 500 Indicates that the server detected an internal error on the server processing this request (such as an unhandled exception). The server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. 3.3 FeedURI The FeedURI is used to retrieve a representation in Atom format. Note that this feed is different from a typical Atom feed in that it @@ -355,21 +396,21 @@ multiple link tags with rel="service.feed" and having differing title attributes that announce the kind of search results in that feed. 3.3.1 Locating A link tag of the following format points to the FeedURI. + title="The name of the site." /> 3.3.2 Request The request is a simple GET. No other verbs are currently specified for this URI. 3.3.3 Response The expected status codes from a GET are 200, 301, 307, and 500. 401, 404, and 410 are also possible. @@ -379,34 +420,105 @@ The Feed has moved permanently, the new URI is given in the Location header. The client SHOULD do a GET on the URI returned in the Location header. 3.3.3.2 Response code 307 The Feed has moved temporarily, the new URI is given in the Location header. The client SHOULD do a GET on the URI returned in the Location header. -3.4 Link Tag +3.4 ResourcePostURI + + The ResourcePostURI is used to create new non-entry resources. The + client POSTs a resource of the desired MIME type directly to this + URI. + +3.4.1 Locating + + For creating a new non-entry resource, the link tag is used. Note + that a link tag is used in both HTML and in the Atom format. A link + tag of the following format points to the ResourcePostURI for a site. + In HTML the link tags are always found in the head element, while in + Atom they may appear as children of the Feed and entry elements. + + + +3.4.2 Request + + The request contains a resource, sent through a standard HTTP POST, + e.g.: + + POST /_do/exampleblog/post_resource HTTP/1.1 + Host: www.example.com + Content-Type: image/jpeg + Content-Length: nnn + + ...raw bytes of image go here... + +3.4.3 Response + + The expected status codes from a POST are 201, 303, 400, 415, and + 500. 401, 404, 409, and 410 are also possible. + +3.4.3.1 Response code 201 + + The response MUST include a Location: header with the URI of the + created resource, i.e. the URI used to retrieve the resource + representation in a subsequent HTTP GET. The server SHOULD omit the + content of the resource in the response, since it would be redundant + to return it to the client. + +3.4.3.2 Response code 303 + + Similar to 201 but no caching is allowed. The response MUST include + a Location: header. + +3.4.3.3 Response code 400 + + Indicates that the server believes that the data sent constitutes an + invalid request. The server SHOULD include an entity containing an + explanation of the error situation, and whether it is a temporary or + permanent condition. + +3.4.3.4 Response code 415 + + The MIME type of the request entity is not supported by the server + for this resource. + + The response SHOULD contain enough for information for the user to + resolve the conflict. + + [[@@TBD@@ more about response body format ]] + +3.4.3.5 Response code 500 + + Indicates that the server detected an internal error on the server + processing this request (such as an unhandled exception). A short + description of the error will appear on the status line itself. A + longer description will appear in the body. + +3.5 Link Tag The link tag is used in both HTML and Atom formats. There are slight differences between the two usages. Here are the commonalities, differences, and a list of well-known values for the rel attribute. appears in the 'head' of the document. The 'head' section only allows a linear list of 'link' tags. The Atom format allows 'link' tags as children of both the 'feed' element and of the 'entry' element. Note that this gives the information present in the link tag more context. For example ... @@ TBD @@ -3.4.1 rel +3.5.1 rel This attribute describes the relationship from the current document, be it HTML or Atom, to the anchor specified by the href attribute. The value of this attribute is a space-separated list of link types. Note that these values are case insensitive. When used in concert with type="application/atom+xml", the relations may be interpreted as follows. alternate: The URI in the href attribute points to an alternate representation of the containing resource. start: The Atom feed at the URI supplied in the href attribute @@ -415,186 +527,187 @@ contains the next N entries in a linear sequence of entries. prev: The Atom feed at the URI supplied in the href attribute contains the previous N entries in a linear sequence of entries. service.edit: The URI given in the href attribute is used to edit a representation of the referred resource. service.post: The URI in the href attribute is used to create new resources. service.feed: The URI given in the href attribute is a starting point for navigating content and services. -3.4.2 href +3.5.2 href URI of the resource being described by this link element. -3.4.3 title +3.5.3 title Offers advisory information about the link. Rendered to the user to help them choose among a set of links with the same rel and type attributes. -3.4.4 type +3.5.4 type The content type of the resource available at the URI given in the href attribute of the link element. Most of the link types in this specification are on type 'application/atom+xml'. -3.5 Atom Request and Response Body Constraints +3.6 Atom Request and Response Body Constraints The Atom format is used as the representation of all the resources in this specification. As it is used in differing contexts, there are different constraints of which elements may be present, and how their values should be interpreted. -3.5.1 id +3.6.1 id PostURI MUST NOT be present. FeedURI MUST be present. EditURI GET MUST be present. PUT MUST be present. -3.5.2 link +3.6.2 link PostURI MAY be present. Servers MAY use the information to determine the URI of the created resource. Relative URLs are to be interpreted relative to xml:base. FeedURI MUST be present. EditURI GET MUST be present. PUT MUST be present. -3.5.3 title +3.6.3 title PostURI MUST be present. The element may be empty, to explicitly indicate "no title". Servers SHOULD NOT try to generate a title if one is not provided. The type attribute MAY be present, and if not it defaults to "text/plain". If present, it MUST represent a MIME type that the server supports. The mode attribute MAY be present. If not present, it defaults to "xml". If present, it MUST be "xml", "base64", or "escaped". + FeedURI MUST be present. EditURI GET MUST be present. PUT MUST be present. The element may be empty, to explicitly indicate "no title". Servers SHOULD NOT try to generate a title if one is not provided. -3.5.4 summary +3.6.4 summary PostURI MAY be present. If not present, the server is welcome to produce its own summary. If present but empty, the server SHOULD NOT generate a summary of its own. The type attribute MAY be present. If not, it defaults to "text/plain". If present, it must represent a MIME type that the server supports. The mode attribute MAY be present and defaults to "xml". If present, it must be "xml","base64", or "escaped". FeedURI MAY be present. EditURI GET MAY be present. PUT MAY be present. The element may be empty, to explicitly indicate "no summary". Servers SHOULD NOT try to generate a title if one is not provided. -3.5.5 content +3.6.5 content PostURI MAY be present but may be empty, to explicitly indicate "no content". The type attribute MAY be present, but defaults to "text/plain" if not present. It must represent a MIME type that the server supports. The MODE attribute may be present and defaults to "xml" if not present. It must be "xml","base64", or "escaped". FeedURI MAY be present. EditURI GET MAY be present. PUT MAY be present. The element may be empty, to explicitly indicate "no content". -3.5.6 issued +3.6.6 issued PostURI MUST be present, but may be empty, in which case it signifies "now" in the time zone of the server. FeedURI MUST be present. EditURI GET MUST be present. PUT MUST be present. Server policy determines if an updated time is accepted. -3.5.7 modified +3.6.7 modified PostURI MUST NOT be present. FeedURI MAY be present. EditURI GET MAY be present. PUT MAY be present. The element may be empty, to explicitly indicate that 'now' on the server time is to be used. -3.5.8 created +3.6.8 created PostURI MAY be present. - FeedURI MAY be present. EditURI GET MAY be present. PUT MAY be present. The server may or may not accept an updated value. If the server does not allow updating the issued time then any PUT request with a different issued value MUST be rejected. -3.5.9 author +3.6.9 author PostURI MAY be present. If not present, the server determines the author. If present, and conflicting with valid values as determined by the server, then the server may change the value of author. FeedURI MAY be present. EditURI GET MAY be present. PUT MAY be present. -3.5.10 contributor +3.6.10 contributor PostURI MAY be present. FeedURI MAY be present. EditURI GET MAY be present. PUT MAY be present. -3.5.11 generator +3.6.11 generator PostURI MUST be present and contain a URI. The value of the element indicates the code base used to create this request. MUST also have an attribute 'version' with a version number. FeedURI MUST NOT be present. + EditURI GET MUST NOT be present. PUT MUST NOT be present. -3.6 Securing the Atom Protocol +3.7 Securing the Atom Protocol All instances of publishing Atom entries SHOULD be protected by authentication to prevent posting or editing by unknown sources. Atom servers and clients MUST support one of the following authentication mechanisms, and SHOULD support both. o HTTP Digest Authentication [RFC2617] o [@@TBD@@ CGI Authentication ref] Atom servers and clients MAY support encryption of the Atom session using TLS [RFC2246]. There are cases where an authentication mechanism may not be required, such as a publicly editable Wiki, or when using the PostURI to post comments to a site that does not require authentication to create comments. -3.6.1 [@@TBD@@ CGI Authentication] +3.7.1 [@@TBD@@ CGI Authentication] This authentication method is included as part of the protocol to allow Atom servers and clients that cannot use HTTP Digest Authentication but where the user can both insert its own HTTP headers and create a CGI program to authenticate entries to the server. This scenario is common in environments where the user cannot control what services the server employs, but the user can write their own HTTP services. 4. Security Considerations @@ -666,20 +779,23 @@ the 'introspection' file. 1. Creating a new entry 2. Finding an old entry 3. editing an old entry 4. commenting on a entry (via HTML and Atom) 7.2 Example for a wiki Fill this in like above but for a wiki. 8. Revision History + draft-ietf-atompub-protocol-02 - Incorporates Pace409Response, + PacePostLocationMust, and PaceSimpleResourcePosting. + draft-ietf-atompub-protocol-01 - Added in sections on Responses for the EditURI. Allow 2xx for response to EditURI PUTs. Elided all mentions of WSSE. Started adding in some normative references. Added the section "Securing the Atom Protocol". Clarified that it is possible that the PostURI and FeedURI could be the same URI. Cleaned up descriptions for Response codes 400 and 500. Rev draft-ietf-atompub-protocol-00 - 5Jul2004 - Renamed the file and re-titled the document to conform to IETF submission guidelines. Changed MIME type to match the one selected for the Atom format. @@ -735,20 +851,24 @@ example URIs are not normative. 9 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. + [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform + Resource Identifiers (URI): Generic Syntax", RFC 2396, + August 1998. + [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. Authors' Addresses