idnits 2.17.1 draft-ietf-atompub-protocol-08.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 1326. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1298. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1305. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1311. ** 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 == Line 677 has weird spacing: '...taining more ...' -- 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: Atom Protocol servers MUST provide representations of collections as Atom feed documents whose entries represent the collection's members. 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 (February 01, 2006) is 6659 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 592, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO88591' ** 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) ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) Summary: 8 errors (**), 0 flaws (~~), 5 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: August 5, 2006 B. de hOra, Ed. 5 Propylon Ltd. 6 February 01, 2006 8 The Atom Publishing Protocol 9 draft-ietf-atompub-protocol-08.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 August 5, 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:member-type" Element . . . . . . . . . . . . 16 78 8. Collections . . . . . . . . . . . . . . . . . . . . . . . . 17 79 8.1 Creating resources with POST . . . . . . . . . . . . . . . 17 80 8.1.1 Example . . . . . . . . . . . . . . . . . . . . . . . 17 81 8.1.2 Title: Header . . . . . . . . . . . . . . . . . . . . 17 82 8.2 Entry Collections . . . . . . . . . . . . . . . . . . . . 18 83 8.2.1 Editing entries with foreign markup . . . . . . . . . 18 84 8.3 Media Collections . . . . . . . . . . . . . . . . . . . . 18 85 8.3.1 Editing Media Resources . . . . . . . . . . . . . . . 18 86 8.3.2 Editing Media Metadata . . . . . . . . . . . . . . . . 19 87 9. Listing Collections . . . . . . . . . . . . . . . . . . . . 20 88 9.1 Collection Paging . . . . . . . . . . . . . . . . . . . . 20 89 10. Atom Format Link Relation Extensions . . . . . . . . . . . . 22 90 10.1 The "edit" Link Relation . . . . . . . . . . . . . . . . 22 91 11. Atom Publishing Control Extensions . . . . . . . . . . . . . 23 92 11.1 The Atom Publishing Control Namespace . . . . . . . . . 23 93 11.2 The "pub:control" Element . . . . . . . . . . . . . . . 23 94 11.2.1 The "pub:draft" Element . . . . . . . . . . . . . . 23 95 12. Atom Publishing Protocol Example . . . . . . . . . . . . . . 24 96 13. Securing the Atom Protocol . . . . . . . . . . . . . . . . . 26 97 14. Security Considerations . . . . . . . . . . . . . . . . . . 27 98 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 28 99 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 100 16.1 Normative References . . . . . . . . . . . . . . . . . . 30 101 16.2 Informative References . . . . . . . . . . . . . . . . . 31 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 32 103 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 33 104 B. RELAX NG Compact Schema . . . . . . . . . . . . . . . . . . 34 105 C. Revision History . . . . . . . . . . . . . . . . . . . . . . 37 106 Intellectual Property and Copyright Statements . . . . . . . 40 108 1. Introduction 110 The Atom Publishing Protocol is an application-level protocol for 111 publishing and editing Web resources using HTTP [RFC2616] and XML 1.0 112 [W3C.REC-xml-20040204]. The protocol supports the creation of 113 arbitrary web resources and provides facilities for: 115 o Collections: Sets of resources, which may be retrieved in whole or 116 in part. 118 o Introspection: Discovering and describing collections. 120 o Editing: Creating, updating and deleting resources. 122 2. Notational Conventions 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [RFC2119]. 128 Note: The Introspection Document allows the use of IRIs [RFC3987], as 129 well as URIs [RFC3986]. Every URI is an IRI, so any URI can be used 130 where an IRI is needed. How to map an IRI to a URI is specified in 131 Section 3.1 of Internationalized Resource Identifiers (IRIs) 132 [RFC3987]. 134 3. Terminology 136 For convenience, this protocol may be referred to as the "Atom 137 Protocol" or "APP". 139 URI/IRI - A Uniform Resource Identifier and Internationalized 140 Resource Identifier. These terms and the distinction between them 141 are defined in [RFC3986] and [RFC3987]. Note that IRIs are mapped to 142 URIs before dereferencing takes place. 144 Resource - A network-accessible data object or service identified by 145 an IRI, as defined in [RFC2616]. See [W3C.REC-webarch-20041215] for 146 further discussion on resources. 148 The phrase "the URI of a document" in this specification is shorthand 149 for "an URI which, when dereferenced, is expected to produce that 150 document as a representation". 152 Representation - An entity included with a request or response as 153 defined in [RFC2616]. 155 Collection - A resource that contains a set of member IRIs. See 156 Section 8. 158 Member - A resource whose IRI is listed in a Collection. 160 Introspection Document - A document that describes the location and 161 capabilities of one or more Collections. See Section 7. 163 4. Protocol Model 165 The Atom Publishing Protocol uses HTTP to edit and author web 166 resources. The Atom Protocol uses the following HTTP methods: 168 o GET is used to retrieve a representation of a resource or perform 169 a query. 171 o POST is used to create a new, dynamically-named resource. 173 o PUT is used to update a known resource. 175 o DELETE is used to remove a resource. 177 Along with operations on resources, the Atom Protocol provides list- 178 based structures, called Collections, for managing and organising 179 resources, called Members. Collections contain the IRIs of, and 180 metadata about, their Member resources. For authoring and editing of 181 resources to commence, an Atom Protocol client can examine 182 Introspection Documents which represent server-defined groups of 183 Collections. 185 Note that when an IRI is used for resource retrieval over HTTP, the 186 IRI is first converted to a URI according the procedure defined in 187 [RFC3987] section 3.1. The resource that the IRI locates is the same 188 as the one located by the URI obtained after converting the IRI. 190 5. Protocol Operations 192 5.1 Retrieving an Introspection Document 194 Client Server 195 | | 196 | 1.) GET to URI of Introspection Document | 197 |------------------------------------------>| 198 | | 199 | 2.) Introspection Document | 200 |<------------------------------------------| 201 | | 203 1. The client sends a GET request to the URI of the Introspection 204 Document. 206 2. The server responds with the document enumerating the IRIs of a 207 set of Collections and the capabilities of those Collections 208 supported by the server. The content of this document can vary 209 based on aspects of the client request, including, but not 210 limited to, authentication credentials. 212 5.2 Creating a Resource 214 Client Server 215 | | 216 | 1.) POST to URI of Collection | 217 |------------------------------------------>| 218 | | 219 | 2.) 201 Created | 220 |<------------------------------------------| 221 | | 223 1. The client POSTs a representation of the Member to the URI of the 224 collection. 226 2. If the Member resource was created successfully, the server 227 responds with a status code of 201 and a Location: header that 228 contains the URI of the newly created resource. 230 5.3 Editing a Resource 232 Once a resource has been created and its URI is known, that URI may 233 be used to retrieve, update, and delete the resource. 235 5.3.1 Retrieving a Resource 237 Client Server 238 | | 239 | 1.) GET to Member URI | 240 |------------------------------------------>| 241 | | 242 | 2.) Member Representation | 243 |<------------------------------------------| 244 | | 246 1. The client sends a GET request to the Member's URI to retrieve 247 its representation. 249 2. The server responds with the representation of the resource. 251 5.3.2 Updating a Resource 253 Client Server 254 | | 255 | 1.) PUT to Member URI | 256 |------------------------------------------>| 257 | | 258 | 2.) 200 OK | 259 |<------------------------------------------| 261 1. The client PUTs an updated representation to the Member's URI. 263 2. Upon a successful update of the resource the server responds with 264 a status code of 200. 266 5.3.3 Deleting a Resource 268 Client Server 269 | | 270 | 1.) DELETE to Member URI | 271 |------------------------------------------>| 272 | | 273 | 2.) 200 Ok | 274 |<------------------------------------------| 275 | | 277 1. The client sends a DELETE request to the Member's URI. 279 2. Upon the successful deletion of the resource the server responds 280 with a status code of 200. 282 5.4 Listing Collection Members 284 To list the members of a Collection the client sends a GET request to 285 the Collection's URI. An Atom Feed Document is returned containing 286 one Atom Entry for each member resource. See Section 9 and 287 Section 10 for a description of the feed contents. 289 Client Server 290 | | 291 | 1.) GET to Collection URI | 292 |------------------------------->| 293 | | 294 | 2.) 200 OK, Atom Feed Doc | 295 |<-------------------------------| 296 | | 298 1. The client sends a GET request to the Collection's URI. 300 2. The server responds with an Atom Feed Document containing the 301 IRIs of the collection members. 303 5.5 Use of HTTP Response codes 305 The Atom Protocol uses the response status codes defined in HTTP to 306 indicate the success or failure of an operation. Consult the HTTP 307 specification [RFC2616] for detailed definitions of each status code. 308 It is RECOMMENDED that entities contained within HTTP 4xx and 5xx 309 responses include an explanation of the error using natural language. 311 6. XML-related Conventions 313 The Atom Protocol Introspection format is specified in terms of the 314 XML Information Set [W3C.REC-xml-infoset-20040204], serialised as XML 315 1.0 [W3C.REC-xml-20040204]. Atom Publishing Protocol Documents MUST 316 be well-formed XML. This specification does not define any DTDs for 317 Atom Protocol, and hence does not require them to be "valid" in the 318 sense used by XML. 320 6.1 Referring to Information Items 322 This specification uses a shorthand for two common terms: the phrase 323 "Information Item" is omitted when discussing Element Information 324 Items and Attribute Information Items. Therefore, when this 325 specification uses the term "element," it is referring to an Element 326 Information Item in Infoset terms. Likewise, when it uses the term 327 "attribute," it is referring to an Attribute Information Item. 329 6.2 XML Namespace Usage 331 The namespace name [W3C.REC-xml-names-19990114] for the XML format 332 described in this specification is: 334 http://purl.org/atom/app# 336 This specification uses the prefix "app:" for the namespace name. 337 The choice of namespace prefix is not semantically significant. 339 This specification also uses the prefix "atom:" for 340 "http://www.w3.org/2005/Atom", the namespace name of the Atom 341 Publishing Format [RFC4287]. 343 6.3 Use of xml:base and xml:lang 345 XML elements defined by this specification MAY have an xml:base 346 attribute [W3C.REC-xmlbase-20010627]. When xml:base is used, it 347 serves the function described in section 5.1.1 of URI Generic Syntax 348 [RFC3986], establishing the base URI (or IRI) for resolving any 349 relative references found within the effective scope of the xml:base 350 attribute. 352 Any element defined by this specification MAY have an xml:lang 353 attribute, whose content indicates the natural language for the 354 element and its descendents. The language context is only 355 significant for elements and attributes declared to be "Language- 356 Sensitive" by this specification. Requirements regarding the content 357 and interpretation of xml:lang are specified in Section 2.12 of XML 358 1.0 [W3C.REC-xml-20040204]. 360 appCommonAttributes = 361 attribute xml:base { atomUri }?, 362 attribute xml:lang { atomLanguageTag }?, 363 undefinedAttribute* 365 6.4 RELAX NG Schema 367 Some sections of this specification are illustrated with fragments of 368 a non-normative RELAX NG Compact schema [RNC]. A complete schema 369 appears in Appendix B. However, the text of this specification 370 provides the definition of conformance. 372 7. Introspection Documents 374 For authoring to commence, a client needs to first discover the 375 capabilities and locations of collections offered. This is done 376 using Introspection Documents. An Introspection Document describes 377 workspaces, which are server-defined groupings of collections. 379 Introspection documents are identified with the "application/ 380 atomserv+xml" media type (see Section 15). 382 While an introspection document allows multiple workspaces, there is 383 no requirement that a service support multiple workspaces. In 384 addition, a collection MAY appear in more than one workspace. 386 7.1 Example 388 389 390 391 394 entry 395 396 399 media 400 401 402 403 405 entry 406 407 408 410 This Introspection Document describes two workspaces. The first, 411 called "Main Site", has two collections called "My Blog Entries" and 412 "Pictures" whose URIs are "http://example.org/reilly/main" and 413 "http://example.org/reilly/pic" respectively. "My Blog Entries" is 414 an Entry collection and "Pictures" is a Media collection. Entry and 415 Media collections are discussed in Section 7.2.4. 417 The second workspace is called "Side Bar Blog" and has a single 418 collection called "Remaindered Links" whose collection URI is 419 "http://example.org/reilly/list". "Remaindered Links" is an Entry 420 collection. 422 7.2 Element Definitions 424 7.2.1 The "app:service" Element 426 The root of an introspection document is the "app:service" element. 428 The "app:service" element is the container for introspection 429 information associated with one or more workspaces. An app:service 430 element MUST contain one or more app:workspace elements. 432 namespace app = "http://purl.org/atom/app#" 433 start = appService 435 appService = 436 element app:service { 437 appCommonAttributes, 438 ( appWorkspace+ 439 & extensionElement* ) 440 } 442 7.2.2 The "app:workspace" Element 444 The "app:workspace" element contains information elements about the 445 collections of resources available for editing. The app:workspace 446 element MUST contain one or more app:collection elements. 448 appWorkspace = 449 element app:workspace { 450 appCommonAttributes, 451 attribute title { text }, 452 ( appCollection+ 453 & extensionElement* ) 454 } 456 In an app:workspace element, the first app:collection element of each 457 type MUST refer to the preferred or primary collection. In the 458 following example, the "Entries" collection would be considered the 459 preferred (or primary) entries collection of the workspace and the 460 "Photos" collection would be considered the primary media collection: 462 463 464 466 entry 467 468 470 media 471 472 473 475 7.2.2.1 The "title" Attribute 477 The app:workspace element MUST contain a "title" attribute, which 478 gives a human-readable name for the workspace. This attribute is 479 Language-Sensitive. 481 7.2.3 The "app:collection" Element 483 The "app:collection" describes an Atom Protocol collection. One 484 child element is defined here for app:collection: "app:member-type". 486 appCollection = 487 element app:collection { 488 appCommonAttributes, 489 attribute title { text }, 490 attribute href { text }, 491 ( appMemberType 492 & appListTemplate 493 & extensionElement* ) 494 } 496 7.2.3.1 The "title" Attribute 498 The app:collection element MUST contain a "title" attribute, whose 499 value gives a human-readable name for the collection. This attribute 500 is Language-Sensitive. 502 7.2.3.2 The "href" Attribute 504 The app:collection element MUST contain a "href" attribute, whose 505 value gives the IRI of the collection. 507 7.2.4 The "app:member-type" Element 509 The app:collection element MUST contain one "app:member-type" 510 element. The app:member-type element value specifies the types of 511 members that can appear in the collection. 513 appMemberType = 514 element app:member-type { 515 appCommonAttributes, 516 ( appTypeValue ) 517 } 519 appTypeValue = "entry" | "media" 521 This specification defines two values for the app:member-type 522 element: 524 o "entry" - Indicates the collection contains only member resources 525 whose representation MUST be an Atom Entry. Further constraints 526 on the representations of members in a collection of type "entry" 527 are listed in Section 8.2. 529 o "media" - Indicates the collection contains member resources whose 530 representation can be of any media type. Additional constraints 531 are listed in Section 8.3. 533 8. Collections 535 8.1 Creating resources with POST 537 To add members to a collection, clients send POST requests to the 538 collection's URI. Collections MAY impose constraints on the media- 539 types that are created in a collection and MAY generate a response 540 with a status code of 415 ("Unsupported Media Type"). On successful 541 creation, the response to the POST request MUST return a Location: 542 header with the URI of the newly created resource. 544 8.1.1 Example 546 Below, the client sends a POST request containing an Atom Entry 547 representation to the URI of the Collection: 549 POST /myblog/entries HTTP/1.1 550 Host: example.org 551 User-Agent: Thingio/1.0 552 Content-Type: application/atom+xml 553 Content-Length: nnn 555 556 Atom-Powered Robots Run Amok 557 urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a 558 2003-12-13T18:30:02Z 559 Some text. 560 562 The server signals a successful creation with a status code of 201 563 and the response includes a 'Location' header indicating the URI of 564 the Atom Entry. 566 HTTP/1.1 201 Created 567 Date: Fri, 7 Oct 2005 17:17:11 GMT 568 Content-Length: 0 569 Location: http://example.org/edit/first-post.atom 571 8.1.2 Title: Header 573 A POST to a Media Collection creating a resource SHOULD contain a 574 Title: header that indicates the client's suggested title for the 575 resource: 577 POST /myblog/fotes HTTP/1.1 578 Host: example.org 579 User-Agent: Thingio/1.0 580 Content-Type: image/png 581 Content-Length: nnnn 582 Title: An Atom-Powered Robot 584 ...binary data... 586 The server MAY ignore the content of the Title: header or modify the 587 suggested title. 589 Title = "Title" ":" [TEXT] 591 The syntax of this header MUST conform to the augmented BNF grammar 592 in section 2.1 of the HTTP/1.1 specification [RFC2616]. The [TEXT] 593 rule is described in section 2.2 of the same document. Words of 594 *TEXT MAY contain characters from character sets other than 595 [ISO88591] only when encoded according to the rules of 596 [RFC2047]. 598 8.2 Entry Collections 600 Entry Collections are collections that restrict their membership to 601 Atom Entries. They are identified by having an app:member-type of 602 "entry". Every member representation MAY contain an atom:link 603 element with a link relation of "edit" that contains the IRI of the 604 member resource. Member representations MAY contain a pub:control 605 element (Section 11). 607 8.2.1 Editing entries with foreign markup 609 To avoid unintentional loss of data when editing entry collection 610 members, Atom Protocol clients SHOULD preserve all metadata, 611 including unknown foreign markup, that has not been intentionally 612 modified. 614 8.3 Media Collections 616 Media Collections are collections whose member representations are 617 not constrained. They are identified by having an app:member-type of 618 "media". 620 8.3.1 Editing Media Resources 622 When listing the contents of a Media Collection, every Entry in the 623 Atom Feed Document MUST have an atom:content element with a "src" 624 attribute containing the IRI of the media resource itself. This 625 value may be used to update and delete resources as described in 626 Section 5.3. When creating a public, read-only reference to the 627 member resource, a client SHOULD use this value. 629 8.3.2 Editing Media Metadata 631 Entries in a Media Collection MAY contain an atom:link element with a 632 link relation of "edit" that contains the IRI of an Atom Entry 633 document representing the metadata of the member resource. A client 634 MAY use this to edit the metadata associated with the resource. 636 9. Listing Collections 638 Collection resources MUST provide representations in the form of Atom 639 Feed documents. Each entry in the Feed Document MUST have an atom: 640 link element with a relation of "edit" (See Section 10.1). 642 The entries in the returned Atom Feed MUST be ordered by their "atom: 643 updated" property, with the most recently updated entries coming 644 first in the document order. Clients SHOULD be constructed in 645 consideration that changes which do not alter the entry's 646 atom:updated value will not affect the position of the entry in a 647 collection. 649 Clients MUST NOT assume that an Atom Entry returned in the Feed is a 650 full representation of a member resource and SHOULD perform a GET on 651 the member resource before editing. 653 Collections can contain large numbers of resources. A naive client 654 such as a web spider or web browser could be overwhelmed if the 655 response to a GET contained every entry in the collection, and the 656 server would waste large amounts of bandwidth and processing time on 657 clients unable to handle the response. For this reason, servers MAY 658 return a partial listing containing the most recently updated member 659 resources. Such partial feed documents MUST have an atom:link with a 660 "next" relation whose "href" value is the URI of the next partial 661 listing of the collection (the least recently updated member 662 resources) where it exists. This is called "collection paging". 664 9.1 Collection Paging 666 Atom Protocol servers MUST provide representations of collections as 667 Atom feed documents whose entries represent the collection's members. 668 The returned Atom feed MAY NOT contain entries for all the 669 collection's members. Instead, the Atom feed document MAY contain 670 link elements with "rel" attribute values of "next", "previous", 671 "first" and "last" that can be used to navigate through the complete 672 set of matching entries. 674 For instance, suppose a client is supplied the URI 675 "http://example.org/entries/go" of a collection of member entries, 676 where the server as a matter of policy avoids generating feed 677 documents containing more than 10 entries. The Atom feed document 678 for the collection will then represent the first 'page' in a set of 679 10 linked feed documents. The "first" relation will reference the 680 initial feed document in the set and the "last" relation references 681 the final feed document in the set. Within each document, the "next" 682 and "previous" link relations reference the preceding and subsequent 683 documents. 685 686 688 690 692 ... 693 695 The "next" and "previous" link elements for the feed 'page' located 696 at "http://example.org/entries/2" would look like this: 698 699 701 703 705 707 ... 708 710 10. Atom Format Link Relation Extensions 712 10.1 The "edit" Link Relation 714 The Atom Protocol adds the value "edit" to the Atom Registry of Link 715 Relations (see section 7.1 of [RFC4287]). The value of "edit" 716 specifies that the IRI in the value of the href attribute is the IRI 717 of an editable Atom Entry Document associated with a resource. In a 718 Media Collection this IRI may be used to update the metadata 719 associated with a Media Resource. In an Entry Collection this IRI 720 may be used to update and delete the member resource itself. The 721 link relation MAY appear in Atom Entry representations as well as 722 Entry and Media Collections. 724 11. Atom Publishing Control Extensions 726 11.1 The Atom Publishing Control Namespace 728 This specification defines an Atom Format extension for publishing 729 control called Atom Publishing Control. The namespace name for the 730 Atom Publishing Control's XML vocabulary is 731 "http://example.net/appns/". This specification uses "pub:" for the 732 namespace prefix. The choice of namespace prefix is not semantically 733 significant. 735 11.2 The "pub:control" Element 737 namespace pub = "http://example.net/appns/" 739 pubControl = 740 element pub:control { 741 atomCommonAttributes, 742 pubDraft? 743 & extensionElement 744 } 746 pubDraft = 747 element pub:draft { "yes" | "no" } 749 The "pub:control" element MAY appear as a child of an "atom:entry" 750 which is being created or updated via the Atom Publishing Protocol. 751 The "pub:control" element, if it does appear in an entry, MUST only 752 appear at most one time. The "pub:control" element is considered 753 foreign markup as defined in Section 6 of [RFC4287]. 755 The "pub:control" element and its child elements MAY be included in 756 Atom Feed or Entry Documents. 758 The "pub:control" element MAY contain exactly one "pub:draft" element 759 as defined here, and MAY contain zero or more extension elements as 760 outlined in Section 6 of [RFC4287]. Both clients and servers MUST 761 ignore foreign markup present in the pub:control element. 763 11.2.1 The "pub:draft" Element 765 The number of "pub:draft" elements in "pub:control" MUST be zero or 766 one. Its value MUST be one of "yes" or "no". A value of "no" means 767 that the entry MAY be made publicly visible. If the "pub:draft" 768 element is missing then the value MUST be understood to be "no". The 769 pub:draft element MAY be ignored. 771 12. Atom Publishing Protocol Example 773 This is an example of a client creating a new entry with an image. 774 The client has an image to publish and an entry that includes an HTML 775 "img" element that uses that image. In this scenario we consider a 776 client that has IRIs of two collections, an entry collection and a 777 media collection, both of which were discovered through an 778 introspection document. The IRI of the entry collection is: 780 http://example.net/blog/edit/ 782 The IRI of the media collection is: 784 http://example.net/binary/edit 786 First the client creates a new image resource by POSTing the image to 787 the IRI of the media collection. 789 POST /binary/edit/ HTTP/1.1 790 Host: example.net 791 User-Agent: Thingio/1.0 792 Content-Type: image/png 793 Content-Length: nnnn 794 Title: A picture of the beach 796 ...binary data... 798 The member resource is created and an HTTP status code of 201 is 799 returned. 801 HTTP/1.1 201 Created 802 Date: Fri, 25 Mar 2005 17:17:11 GMT 803 Content-Length: nnnn 804 Content-Type: application/atom+xml 805 Location: http://example.net/binary/edit/b/129.png 807 808 809 A picture of the beach 810 812 urn:uuid:1225c695-cfb8-4ebb-aaaa-568596895695 813 2005-09-02T10:30:00Z 814 Waves 815 817 818 The client then POSTs the Atom Entry that refers to the newly created 819 image resource. Note that the client takes the URI 820 http://example.net/binary/readonly/129.png and uses it in the 'img' 821 element in the Entry content: 823 POST /blog/edit/ HTTP/1.1 824 Host: example.net 825 User-Agent: Thingio/1.0 826 Content-Type: application/atom+xml 827 Content-Length: nnnn 829 830 831 What I did on my summer vacation 832 833 urn:uuid:1225c695-ffb8-4ebb-aaaa-80da354efa6a 834 2005-09-02T10:30:00Z 835 Beach! 836 837
838

We went to the beach for summer vacation. 839 Here is a picture of the waves rolling in: 840 A picture of the beach 844

845
846 847 849 13. Securing the Atom Protocol 851 All instances of publishing Atom Format entries SHOULD be protected 852 by authentication to prevent posting or editing by unknown sources. 853 Atom Protocol servers and clients MUST support one of the following 854 authentication mechanisms, and SHOULD support both. 856 o HTTP Digest Authentication [RFC2617] 858 o CGI Authentication 860 Atom Protocol servers and clients MAY support encryption of the 861 session using TLS (see [RFC2246]). 863 There are cases where an authentication mechanism might not be 864 required, such as a publicly editable Wiki, or when using POST to 865 send comments to a site that does not require authentication from a 866 commenter. 868 13.1 CGI Authentication 870 [[anchor27: note: this section is incomplete; cgi-authentication is 871 described but is unspecified.]] This authentication method is 872 included as part of the protocol to allow Atom Protocol servers and 873 clients that cannot use HTTP Digest Authentication but where the user 874 can both insert its own HTTP headers and create a CGI program to 875 authenticate entries to the server. This scenario is common in 876 environments where the user cannot control what services the server 877 employs, but the user can write their own HTTP services. 879 14. Security Considerations 881 The security of the Atom Protocol is based on HTTP Digest 882 Authentication and/or CGI Authentication [[anchor29: note: refers to 883 incomplete section]]. Any weaknesses in either of these 884 authentication schemes will affect the security of the Atom 885 Publishing Protocol. 887 Both HTTP Digest Authentication and CGI Authentication [[anchor30: 888 note: refers to incomplete section]] are susceptible to dictionary- 889 based attacks on the shared secret. If the shared secret is a 890 password (instead of a random string with sufficient entropy), an 891 attacker can determine the secret by exhaustively comparing the 892 authenticating string with hashed results of the public string and 893 dictionary entries. 895 See [RFC2617] for the description of the security properties of HTTP 896 Digest Authentication. 898 [[anchor31: expand on HTTP basic and digest authentication, or 899 refer.]] 901 [[anchor32: note: talk here about denial of service attacks using 902 large XML files, or the billion laughs DTD attack.]] 904 15. IANA Considerations 906 An Atom Publishing Protocol Introspection Document, when serialized 907 as XML 1.0, can be identified with the following media type: 909 MIME media type name: application 911 MIME subtype name: atomserv+xml 913 Mandatory parameters: None. 915 Optional parameters: 917 "charset": This parameter has identical semantics to the charset 918 parameter of the "application/xml" media type as specified in 919 [RFC3023]. 921 Encoding considerations: Identical to those of "application/xml" as 922 described in [RFC3023], section 3.2. 924 Security considerations: As defined in this specification. 925 [[anchor33: update upon publication]] 927 In addition, as this media type uses the "+xml" convention, it 928 shares the same security considerations as described in [RFC3023], 929 section 10. 931 Interoperability considerations: There are no known interoperability 932 issues. 934 Published specification: This specification. [[anchor34: update upon 935 publication]] 937 Applications that use this media type: No known applications 938 currently use this media type. 940 Additional information: 942 Magic number(s): As specified for "application/xml" in [RFC3023], 943 section 3.2. 945 File extension: .atomsrv 947 Fragment identifiers: As specified for "application/xml" in 948 [RFC3023], section 5. 950 Base URI: As specified in [RFC3023], section 6. 952 Macintosh File Type code: TEXT 954 Person and email address to contact for further information: Joe 955 Gregorio 957 Intended usage: COMMON 959 Author/Change controller: This specification's author(s). [[anchor35: 960 update upon publication]] 962 16. References 964 16.1 Normative References 966 [ISO88591] 967 ISO, "International Standard -- Information Processing -- 968 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: 969 Latin alphabet No. 1,", January 1987. 971 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 972 Part Three: Message Header Extensions for Non-ASCII Text", 973 RFC 2047, November 1996. 975 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 976 Requirement Levels", BCP 14, RFC 2119, March 1997. 978 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 979 RFC 2246, January 1999. 981 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 982 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 983 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 985 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 986 Leach, P., Luotonen, A., and L. Stewart, "HTTP 987 Authentication: Basic and Digest Access Authentication", 988 RFC 2617, June 1999. 990 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 991 Types", RFC 3023, January 2001. 993 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 994 Resource Identifier (URI): Generic Syntax", STD 66, 995 RFC 3986, January 2005. 997 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 998 Identifiers (IRIs)", RFC 3987, January 2005. 1000 [RFC4287] Nottingham, M. and R. Sayre, "The Atom Syndication 1001 Format", RFC 4287, December 2005. 1003 [W3C.REC-xml-20040204] 1004 Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T., 1005 and E. Maler, "Extensible Markup Language (XML) 1.0 (Third 1006 Edition)", W3C REC REC-xml-20040204, February 2004. 1008 [W3C.REC-xml-infoset-20040204] 1009 Cowan, J., Tobin, R., and A. Layman, "XML Information Set 1010 (Second Edition)", W3C REC W3C.REC-xml-infoset-20040204, 1011 February 2004. 1013 [W3C.REC-xml-names-19990114] 1014 Hollander, D., Bray, T., and A. Layman, "Namespaces in 1015 XML", W3C REC REC-xml-names-19990114, January 1999. 1017 [W3C.REC-xmlbase-20010627] 1018 Marsh, J., "XML Base", W3C REC W3C.REC-xmlbase-20010627, 1019 June 2001. 1021 16.2 Informative References 1023 [RNC] Clark, J., "RELAX NG Compact Syntax", December 2001. 1025 [W3C.REC-webarch-20041215] 1026 Walsh, N. and I. Jacobs, "Architecture of the World Wide 1027 Web, Volume One", W3C REC REC-webarch-20041215, 1028 December 2004. 1030 URIs 1032 [1] 1034 Authors' Addresses 1036 Joe Gregorio (editor) 1037 BitWorking, Inc 1038 1002 Heathwood Dairy Rd. 1039 Apex, NC 27502 1040 US 1042 Phone: +1 919 272 3764 1043 Email: joe@bitworking.com 1044 URI: http://bitworking.com/ 1046 Bill de hOra (editor) 1047 Propylon Ltd. 1048 45 Blackbourne Square, Rathfarnham Gate 1049 Dublin, Dublin D14 1050 IE 1052 Phone: +353-1-4927444 1053 Email: bill.dehora@propylon.com 1054 URI: http://www.propylon.com/ 1056 Appendix A. Contributors 1058 The content and concepts within are a product of the Atom community 1059 and the Atompub Working Group. 1061 Appendix B. RELAX NG Compact Schema 1063 This appendix is informative. 1065 The Relax NG schema explicitly excludes elements in the Atom Protocol 1066 namespace which are not defined in this revision of the 1067 specification. Requirements for Atom Protocol processors 1068 encountering such markup are given in Section 6.2 and Section 6.3 of 1069 [RFC4287]. 1071 # -*- rnc -*- 1072 # RELAX NG Compact Syntax Grammar for the Atom Protocol 1074 namespace app = "http://purl.org/atom/app#" 1075 namespace local = "" 1077 start = appService 1079 # common:attrs 1081 appCommonAttributes = 1082 attribute xml:base { atomUri }?, 1083 attribute xml:lang { atomLanguageTag }?, 1084 undefinedAttribute* 1086 undefinedAttribute = 1087 attribute * - (xml:base | xml:lang | local:*) { text } 1089 atomUri = text 1091 atomLanguageTag = xsd:string { 1092 pattern = "[A-Za-z]{1,8}(-[A-Za-z0-9]{1,8})*" 1093 } 1095 # app:service 1097 appService = 1098 element app:service { 1099 appCommonAttributes, 1100 ( appWorkspace+ 1101 & extensionElement* ) 1102 } 1104 # app:workspace 1106 appWorkspace = 1107 element app:workspace { 1108 appCommonAttributes, 1109 attribute title { text }, 1110 ( appCollection+ 1111 & extensionElement* ) 1112 } 1114 # app:collection 1116 appCollection = 1117 element app:collection { 1118 appCommonAttributes, 1119 attribute title { text }, 1120 attribute href { atomUri }, 1121 ( appMemberType 1122 & extensionElement* ) 1123 } 1125 # app:member 1127 appMemberType = 1128 element app:member-type { 1129 appCommonAttributes, 1130 ( appTypeValue ) 1131 } 1133 appTypeValue = "entry" | "media" 1135 # Simple Extension 1137 simpleExtensionElement = 1138 element * - app:* { 1139 text 1140 } 1142 # Structured Extension 1144 structuredExtensionElement = 1145 element * - app:* { 1146 (attribute * { text }+, 1147 (text|anyElement)*) 1148 | (attribute * { text }*, 1149 (text?, anyElement+, (text|anyElement)*)) 1150 } 1152 # Other Extensibility 1154 extensionElement = 1155 simpleExtensionElement | structuredExtensionElement 1157 # Extensions 1159 anyElement = 1160 element * { 1161 (attribute * { text } 1162 | text 1163 | anyElement)* 1164 } 1166 # EOF 1168 Appendix C. Revision History 1170 draft-ietf-atompub-protocol-08: added infoset ref; added wording re 1171 IRI/URI; fixed URI/IRI ; next/previous fixed as per Atom 1172 LinkRelations Attribute 1173 (http://www.imc.org/atom-protocol/mail-archive/msg04095.html); 1174 incorporated: PaceEditLinkMustToMay; PaceMissingDraftHasNoMeaning, 1175 PaceRemoveMemberTypeMust, PaceRemoveMemberTypePostMust, 1176 PaceTitleHeaderOnlyInMediaCollections, PacePreserveForeignMarkup, 1177 PaceClarifyTitleHeader, PaceClarifyMediaResourceLinks, 1178 PaceTwoPrimaryCollections; 1180 draft-ietf-atompub-protocol-07: updated Atom refs to RFC4287; 1181 incorporated PaceBetterHttpResponseCode; 1182 PaceClarifyCollectionAndDeleteMethodByWritingLessInsteadOfMore; 1183 PaceRemoveAcceptPostText; PaceRemoveListTemplate2; 1184 PaceRemoveRegistry; PaceRemoveWhoWritesWhat; 1185 PaceSimplifyClarifyBetterfyRemoveBogusValidityText; 1186 PaceCollectionOrderSignificance; PaceFixLostIntrospectionText; 1187 PaceListPaging; PaceCollectionControl; element typo in Listing 1188 collections para3 (was app:member-type, not app:list-template); 1189 changed post atom entry example to be valid. Dropped inline use of 1190 'APP'. Removed nested diagram from section 4. Added ed notes in the 1191 security section. 1193 draft-ietf-atompub-protocol-06 - Removed: Robert Sayre from the 1194 contributors section per his request. Added in 1195 PaceCollectionControl. Fixed all the {daterange} verbage and 1196 examples so they all use a dash. Added full rnc schema. Collapsed 1197 Introspection and Collection documents into a single document. 1198 Removed {dateRange} queries. Renamed search to list. Moved 1199 discussion of media and entry collection until later in the document 1200 and tied the discussion to the Introspection element app:member-type. 1202 draft-ietf-atompub-protocol-05 - Added: Contributors section. Added: 1203 de hOra to editors. Fixed: typos. Added diagrams and description to 1204 model section. Incorporates PaceAppDocuments, PaceAppDocuments2, 1205 PaceSimplifyCollections2 (large-sized chunks of it anyhow: the 1206 notions of Entry and Generic resources, the section 4 language on the 1207 Protocol Model, 4.1 through 4.5.2, the notion of a Collection 1208 document, as in Section 5 through 5.3, Section 7 "Collection 1209 resources", Selection resources (modified from pace which talked 1210 about search); results in major mods to Collection Documents, Section 1211 9.2 "Title: Header" and brokeout para to section 9.1 Editing Generic 1212 Resources). Added XML namespace and language section. Some cleanup 1213 of front matter. Added Language Sensitivity to some attributes. 1214 Removed resource descriptions from terminology. Some juggling of 1215 sections. See: 1217 http://www.imc.org/atom-protocol/mail-archive/msg01812.html. 1219 draft-ietf-atompub-protocol-04 - Add ladder diagrams, reorganize, add 1220 SOAP interactions 1222 draft-ietf-atompub-protocol-03 - Incorporates PaceSliceAndDice3 and 1223 PaceIntrospection. 1225 draft-ietf-atompub-protocol-02 - Incorporates Pace409Response, 1226 PacePostLocationMust, and PaceSimpleResourcePosting. 1228 draft-ietf-atompub-protocol-01 - Added in sections on Responses for 1229 the EditURI. Allow 2xx for response to EditURI PUTs. Elided all 1230 mentions of WSSE. Started adding in some normative references. 1231 Added the section "Securing the Atom Protocol". Clarified that it is 1232 possible that the PostURI and FeedURI could be the same URI. Cleaned 1233 up descriptions for Response codes 400 and 500. 1235 Rev draft-ietf-atompub-protocol-00 - 5Jul2004 - Renamed the file and 1236 re-titled the document to conform to IETF submission guidelines. 1237 Changed MIME type to match the one selected for the Atom format. 1238 Numerous typographical fixes. We used to have two 'Introduction' 1239 sections. One of them was moved into the Abstract the other absorbed 1240 the Scope section. IPR and copyright notifications were added. 1242 Rev 09 - 10Dec2003 - Added the section on SOAP enabled clients and 1243 servers. 1245 Rev 08 - 01Dec2003 - Refactored the specification, merging the 1246 Introspection file into the feed format. Also dropped the 1247 distinction between the type of URI used to create new entries and 1248 the kind used to create comments. Dropped user preferences. 1250 Rev 07 - 06Aug2003 - Removed the use of the RSD file for auto- 1251 discovery. Changed copyright until a final standards body is chosen. 1252 Changed query parameters for the search facet to all begin with atom- 1253 to avoid name collisions. Updated all the Entries to follow the 0.2 1254 version. Changed the format of the search results and template file 1255 to a pure element based syntax. 1257 Rev 06 - 24Jul2003 - Moved to PUT for updating Entries. Changed all 1258 the mime-types to application/x.atom+xml. Added template editing. 1259 Changed 'edit-entry' to 'create-entry' in the Introspection file to 1260 more accurately reflect its purpose. 1262 Rev 05 - 17Jul2003 - Renamed everything Echo into Atom. Added 1263 version numbers in the Revision history. Changed all the mime-types 1264 to application/atom+xml. 1266 Rev 04 - 15Jul2003 - Updated the RSD version used from 0.7 to 1.0. 1267 Change the method of deleting an Entry from POSTing to 1268 using the HTTP DELETE verb. Also changed the query interface to GET 1269 instead of POST. Moved Introspection Discovery to be up under 1270 Introspection. Introduced the term 'facet' for the services listed 1271 in the Introspection file. 1273 Rev 03 - 10Jul2003 - Added a link to the Wiki near the front of the 1274 document. Added a section on finding an Entry. Retrieving an Entry 1275 now broken out into its own section. Changed the HTTP status code 1276 for a successful editing of an Entry to 205. 1278 Rev 02 - 7Jul2003 - Entries are no longer returned from POSTs, 1279 instead they are retrieved via GET. Cleaned up figure titles, as 1280 they are rendered poorly in HTML. All content-types have been 1281 changed to application/atom+xml. 1283 Rev 01 - 5Jul2003 - Renamed from EchoAPI.html to follow the more 1284 commonly used format: draft-gregorio-NN.html. Renamed all references 1285 to URL to URI. Broke out introspection into its own section. Added 1286 the Revision History section. Added more to the warning that the 1287 example URIs are not normative. 1289 Intellectual Property Statement 1291 The IETF takes no position regarding the validity or scope of any 1292 Intellectual Property Rights or other rights that might be claimed to 1293 pertain to the implementation or use of the technology described in 1294 this document or the extent to which any license under such rights 1295 might or might not be available; nor does it represent that it has 1296 made any independent effort to identify any such rights. Information 1297 on the procedures with respect to rights in RFC documents can be 1298 found in BCP 78 and BCP 79. 1300 Copies of IPR disclosures made to the IETF Secretariat and any 1301 assurances of licenses to be made available, or the result of an 1302 attempt made to obtain a general license or permission for the use of 1303 such proprietary rights by implementers or users of this 1304 specification can be obtained from the IETF on-line IPR repository at 1305 http://www.ietf.org/ipr. 1307 The IETF invites any interested party to bring to its attention any 1308 copyrights, patents or patent applications, or other proprietary 1309 rights that may cover technology that may be required to implement 1310 this standard. Please address the information to the IETF at 1311 ietf-ipr@ietf.org. 1313 The IETF has been notified of intellectual property rights claimed in 1314 regard to some or all of the specification contained in this 1315 document. For more information consult the online list of claimed 1316 rights. 1318 Disclaimer of Validity 1320 This document and the information contained herein are provided on an 1321 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1322 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1323 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1324 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1325 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1326 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1328 Copyright Statement 1330 Copyright (C) The Internet Society (2006). This document is subject 1331 to the rights, licenses and restrictions contained in BCP 78, and 1332 except as set forth therein, the authors retain all their rights. 1334 Acknowledgment 1336 Funding for the RFC Editor function is currently provided by the 1337 Internet Society.