idnits 2.17.1 draft-sayre-atompub-protocol-basic-00.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.a on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 719. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 691. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 698. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 704. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The 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 (March 25, 2005) is 6970 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) == Unused Reference: 'AtomFormat' is defined on line 639, but no explicit reference was found in the text == Unused Reference: 'RFC2396' is defined on line 646, but no explicit reference was found in the text == Unused Reference: 'RFC2617' is defined on line 654, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AtomFormat' ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. Sayre 2 Internet-Draft Boswijck Memex Consulting 3 Expires: September 26, 2005 March 25, 2005 5 The Atom Publishing Protocol (Basic) 6 draft-sayre-atompub-protocol-basic-00.txt 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 12 author represents that any applicable patent or other IPR claims of 13 which he or she is aware have been or will be disclosed, and any of 14 which he or she 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 September 26, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 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-06.txt). 50 This memo is a variant of the original Atom Publishing Protocol, as 51 authored by Joe Gregorio. 53 Editorial Note 55 To provide feedback on this Internet-Draft, join the atom-protocol 56 mailing list (http://www.imc.org/atom-protocol/index.html) [1]. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1 Notational Conventions . . . . . . . . . . . . . . . . . . 3 62 2. The Atom Publishing Protocol Model . . . . . . . . . . . . . . 3 63 2.1 Collections . . . . . . . . . . . . . . . . . . . . . . . 3 64 2.2 Orientation . . . . . . . . . . . . . . . . . . . . . . . 3 65 2.3 Listing . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2.4 Authoring . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.4.1 Create . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2.4.2 Read . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 2.4.3 Update . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2.4.4 Delete . . . . . . . . . . . . . . . . . . . . . . . . 5 71 2.5 Success and Failure . . . . . . . . . . . . . . . . . . . 6 72 3. Functional Specification . . . . . . . . . . . . . . . . . . . 6 73 3.1 Interacting With Collections . . . . . . . . . . . . . . . 6 74 3.1.1 Request and Response . . . . . . . . . . . . . . . . . 6 75 3.2 Authoring Atom Entries . . . . . . . . . . . . . . . . . . 10 76 3.2.1 Create . . . . . . . . . . . . . . . . . . . . . . . . 10 77 3.2.2 Read . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 3.2.3 Update . . . . . . . . . . . . . . . . . . . . . . . . 10 79 3.2.4 Delete . . . . . . . . . . . . . . . . . . . . . . . . 10 80 3.3 Authoring Generic Resources . . . . . . . . . . . . . . . 10 81 3.3.1 Create . . . . . . . . . . . . . . . . . . . . . . . . 10 82 3.3.2 Read . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 3.3.3 Update . . . . . . . . . . . . . . . . . . . . . . . . 11 84 3.3.4 Delete . . . . . . . . . . . . . . . . . . . . . . . . 11 85 3.4 Service Description . . . . . . . . . . . . . . . . . . . 11 86 3.4.1 Service Description Documents . . . . . . . . . . . . 11 87 3.4.2 Request and Response . . . . . . . . . . . . . . . . . 13 88 4. Extensions to the Atom Syndication Format . . . . . . . . . . 14 89 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 90 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 91 7. Normative References . . . . . . . . . . . . . . . . . . . . . 14 92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15 93 Intellectual Property and Copyright Statements . . . . . . . . 16 95 1. Introduction 97 The Atom Publishing Protocol is an application-level protocol for 98 publishing and editing Web resources using HTTP [RFC2616] and XML 1.0 99 [W3C.REC-xml-20040204]. 101 1.1 Notational Conventions 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [RFC2119]. 107 2. The Atom Publishing Protocol Model 109 The Atom Publishing Protocol operates on collections of Web 110 resources. All collections support the same basic methods of 111 interaction. The member resources of those collections share the 112 same interaction patterns. HTTP methods provide a pattern for 113 working with all such Web resources: 115 o GET is used to retrieve a representation of a resource or perform 116 a read-only query. 117 o POST is used to create a new, dynamically-named resource. 118 o PUT is used to update a known resource. 119 o DELETE is used to remove a resource. 121 2.1 Collections 123 The APP groups resources into "Collections", which are analogous to 124 the "folders" or "directories" found in many file systems. 126 2.2 Orientation 128 To discover the location of the collections exposed by an APP 129 service, the client must locate and request a Service Description 130 Document (Section 3.4). 132 Client Server 133 | | 134 | 1.) GET Service Description | 135 |------------------------------->| 136 | | 137 | 2.) Service Description Doc | 138 |<-------------------------------| 139 | | 141 1. The client sends a GET request to the Service Description 142 Resource. 144 2. The server responds with a Service Description Document 145 containing the locations of collections provided by the service. 146 The content of this document can vary based on aspects of the 147 client request, including, but not limited to, authentication 148 credentials. 150 2.3 Listing 152 Once the client has discovered the location of a collection, it can 153 request a listing of the collection's membership. However, 154 collections might be extremely large, so servers are likely to list a 155 small subset of the collection by default. Clients that wish to 156 exercise greater control over the subset returned by the server can 157 include an Atom-Query (Section 3.1.1.1) header in their request. 159 Client Server 160 | | 161 | 1.) GET to Collection URI | 162 |------------------------------->| 163 | | 164 | 2.) 200 OK, Atom Feed Doc | 165 |<-------------------------------| 166 | | 168 1. The client sends a GET request to the Collection's URI. 169 2. The server responds with an Atom Feed Document containing a full 170 or partial listing of the collection's membership. 172 2.4 Authoring 174 After locating a collection, the client can alter its membership by 175 sending HTTP requests to its member resources, rather than the 176 collection itself, except when it desires to add an entry to the 177 collection. In that case, it sends a request to the collection. 179 2.4.1 Create 181 Client Server 182 | | 183 | 1.) POST to Collection URI | 184 |------------------------------->| 185 | | 186 | 2.) 201 Created @ Location | 187 |<-------------------------------| 188 | | 190 1. The client sends a representation of a member to the server via 191 HTTP POST. The Request URI is that of the Collection. 193 2. The server responds with a response of "201 Created" and a 194 "Location" header containing the URI of the newly-created 195 resource. 197 2.4.2 Read 199 Client Server 200 | | 201 | 1.) GET or HEAD to Member URI | 202 |------------------------------->| 203 | | 204 | 2.) 200 OK | 205 |<-------------------------------| 206 | | 208 1. If the client does not know the current state of the resource, it 209 sends a GET (or HEAD) request to the member's URI. 210 2. The server responds with an appropriate representation. 212 2.4.3 Update 214 Client Server 215 | | 216 | 1.) PUT to Member URI | 217 |------------------------------->| 218 | | 219 | 2.) 200 OK | 220 |<-------------------------------| 222 1. The client PUTs an updated representation to the member's URI. 223 2. The server responds with a representation of the member's new 224 state. 226 2.4.4 Delete 228 Client Server 229 | | 230 | 1.) DELETE to Member URI | 231 |------------------------------->| 232 | | 233 | 2.) 204 No Content | 234 |<-------------------------------| 235 | | 237 1. The client sends a DELETE request to the member's URI. 238 2. The server responds with successful status code. 240 2.5 Success and Failure 242 HTTP defines classes of response. HTTP status codes of the form 2xx 243 signal that a request was successful. HTTP status codes of the form 244 4xx or 5xx signal that an error has occurred, and the request has 245 failed. Consult the HTTP specification for more detailed definitions 246 of each status code. 248 3. Functional Specification 250 3.1 Interacting With Collections 252 3.1.1 Request and Response 254 This specification defines two methods for use with collections: GET 255 and POST. This section will cover GET. POST is covered in 256 Section 3.2 and Section 3.3. 258 Collections can contain extremely large numbers of resources. A 259 naive client such as a web spider or web browser would be overwhelmed 260 if the response to a GET reflected the full membership of the 261 collection, and the server would waste large amounts of bandwidth and 262 processing time on clients unable to handle the response. As a 263 result, responses to a simple GET request represent a 264 server-determined subset of the collection's membership. 266 This specifcation defines two serializations for Atom Collections. 267 Servers MUST provide both, but MAY also provide additional 268 serializations. 270 1. Atom Feed Documents (application/atom+xml) 271 2. Atom Feed Documents wrapped by a SOAP envelope 272 (application/soap+xml) 274 Clients use the HTTP 'Accept' request header to indicate their 275 preference. If no 'Accept' header is present in the request, the 276 server is free to choose any serialization. [[anchor11: Send an 277 'Accept' header, or you might get an mp3 in response.]] 279 Example Request 281 GET /collection HTTP/1.1 282 Host: example.org 283 User-Agent: GenericBot/1.0 284 Accept: */* 286 Here, the server could return any subset of the collection using any 287 serialization. 289 Example Request, with Accept header 291 GET /collection HTTP/1.1 292 Host: example.org 293 User-Agent: Cosimo/1.0 294 Accept: application/atom+xml 296 Here, the server could return any subset of the collection as an Atom 297 Feed Document. 299 Example Response, Atom Feed Document 301 HTTP/1.1 200 OK 302 Date: Fri, 25 Mar 2005 17:15:33 GMT 303 Last-Modified: Mon, 04 Oct 2004 18:31:45 GMT 304 ETag: "2b3f6-a4-5b572640" 305 Accept-Ranges: bytes 306 Content-Length: nnnn 307 Content-Type: application/atom+xml; charset="utf-8" 309 311 313 Example Feed 314 315 2003-12-13T18:30:02Z 316 317 John Doe 318 319 ... 320 321 Sample 322 2003-12-13T18:30:02Z 323 urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a 324 325 326 327 328 ... 329 330 Example Request, with SOAP Accept header 332 GET /collection HTTP/1.1 333 Host: example.org 334 User-Agent: Cosimo/1.0 335 Accept: application/soap+xml 337 Here, the server could return any subset of the collection as an Atom 338 Feed Document wrapped by a SOAP envelope. 340 Example Response, Atom Feed Document wrapped by a SOAP envelope 342 HTTP/1.1 200 OK 343 Date: Fri, 25 Mar 2005 17:15:33 GMT 344 Last-Modified: Mon, 04 Oct 2004 18:31:45 GMT 345 ETag: "2b3f6-a4-5b572640-89" 346 Accept-Ranges: bytes 347 Content-Length: nnnn 348 Content-Type: application/soap+xml; charset="utf-8" 350 351 352 353 354 357 Example Feed 358 359 2003-12-13T18:30:02Z 360 361 John Doe 362 363 ... 364 365 Sample 366 2003-12-13T18:30:02Z 367 urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a 368 369 370 371 372 ... 373 374 375 377 Each Atom Entry in the server's response represents a member 378 resource. The client edits member resources by sending HTTP requests 379 to the URI given in the 'href' attribute of the 'pub:edit' element. 381 [[anchor12: cover next/previous feed-level elements]] 383 3.1.1.1 Atom-Query 385 Clients may require more precise control over the server's response. 386 For example, the client might wish to construct a record of the 387 collection's complete membership. 389 [[anchor13: draft-ietf-atompub-protocol-03 attempts to accomplish 390 many of the same goals with a custom ranges-specifier. This editor 391 now believes that's too close to the metal, loses byte ranges, 392 doesn't jive well with intermediaries (because concatenating two XML 393 documents does not result in a well-formed XML document), and is 394 likely to cause interoperability problems for no good reason.]] 396 The Atom-Query request header field is used to specify a subset of a 397 collection's member resources. It provides four fields: 399 o 'count': the maximum number of Atom Entries to be included in the 400 response. 401 o 'offset': the offset at which to begin the sequence of entries 402 that match a given request. 403 o 'begin': Atom entries in the returned feed MUST have an 404 atom:updated date later in time than the 'begin' date. 405 o 'end': Atom entries in the returned feed MUST have an atom:updated 406 date equal or earlier in time than the 'end' date. 408 None of the fields are required. This specification does not define 409 its meaning when used with request methods other than GET. 411 Example Atom-Query Header 413 Atom-Query: begin=2003-12-13T18:30:02Z; end=2003-12-25T18:30:02Z; 414 offset=2; count=4; 416 If no 'end' field is present: The 'end' date is considered to be the 417 updated date of the collection's most recently updated member 418 resource. 419 If no 'begin' field is present: The 'begin' date is considered to be 420 the update date of the collection least recently updated member 421 resource. 422 If no 'offset' field is present: The 'offset' integer is considered 423 to be 0. 425 If no 'count' field is present: The 'count' integer is determined by 426 the server. 428 [[anchor14: ABNF...]] 430 3.1.1.2 Atom-Result 432 The Atom-Result response header indicates the range of results 433 returned in a query. It MUST include 'offset','count', and 'total' 434 fields. 436 Example Atom-Result Header 438 Atom-Result: offset=10; count=10; total=35000; 440 [[anchor15: ABNF...]] 442 3.1.1.3 Example Query Requests and Responses 444 [[anchor17: Examples...]] 446 3.2 Authoring Atom Entries 448 3.2.1 Create 450 [[anchor19: POSTing to entry collection]] 452 3.2.2 Read 454 [[anchor21: GET to an entry's URI]] 456 3.2.3 Update 458 [[anchor23: PUT to an entry's URI]] 460 3.2.4 Delete 462 [[anchor25: DELETE to an entry's URI]] 464 3.3 Authoring Generic Resources 466 3.3.1 Create 468 [[anchor27: POSTing to generic collection]] 469 POST /_do/exampleblog/generic_collection HTTP/1.1 470 Host: www.example.com 471 Content-Type: image/jpeg 472 Content-Length: nnn 474 ...raw bytes of image go here... 476 3.3.2 Read 478 [[anchor29: GET to a resource's URI]] 480 3.3.3 Update 482 [[anchor31: PUT to a resource's URI]] 484 3.3.4 Delete 486 [[anchor33: DELETE to a resource's URI]] 488 3.4 Service Description 490 In order for authoring to commence, a client must first discover the 491 capabilities and locations of collections offered by an APP service. 493 3.4.1 Service Description Documents 495 The Service Description Document describes "workspaces", which are 496 server-defined groupings of collections. There is no requirement 497 that servers support multiple workspaces, and a collection may appear 498 in more than one workspace. 500 501 502 503 505 507 508 509 511 513 514 516 3.4.1.1 Element Definitions 518 3.4.1.1.1 The 'app:service' Element 520 The "service" element is the document element of a Service Document, 521 acting as a container for service data associated with one or more 522 workspaces. 524 appService = 525 element app:service { 526 ( appWorkspace* 527 & anyElement* ) 528 } 530 The following child elements are defined by this specification: 532 o app:service elements MAY contain any number of app:workspace 533 elements. 535 3.4.1.1.2 The 'app:workspace' Element 537 The 'workspace' element element contains information elements about 538 the collections of resources available for editing. 540 appWorkspace = 541 element app:workspace { 542 attribute title { text }, 543 ( appCollection* 544 & anyElement* ) 545 } 547 The following attributes and child elements are defined by this 548 specification: 550 o app:workspace elements MUST contain a 'title' attribute, which 551 conveys a human-readable name for the workspace 552 o app:workspace elements MAY contain any number of app:collection 553 elements. 555 3.4.1.1.3 The 'app:collection' Element 557 The 'app:collection' element describes collections and their member 558 resources. 560 appCollection = 561 element app:collection { 562 attribute title { text }, 563 attribute contents { text }, 564 attribute href { text }, 565 anyElement* 566 } 568 The following attributes are defined by this specification: 570 o app:collection elements MUST contain a 'title' attribute, whose 571 value conveys a human-readable name for the workspace 572 o app:collection elements MAY contain a 'contents' attribute 573 (Section 3.4.1.1.3.1). If it is not present, it's value is 574 considered to be 'generic'. 575 o app:collection elements MUST contain an 'href' attribute, whose 576 value conveys the URI of the collection. 578 3.4.1.1.3.1 The 'contents' Attribute 580 The 'contents' attribute conveys the nature of a collection's member 581 resources. This specification defines two initial values for the 582 'contents' attribute: 584 o entries 585 o generic 587 Extensibility for 'content' values is handled [[anchor37: Same as 588 atom:link]]. 590 [[anchor38: Define each 'contents' value...]] 592 3.4.2 Request and Response 594 To retrieve a Service Description document, the client sends a GET 595 request to its URI. 597 GET /service-desc HTTP/1.1 598 Host: example.org 599 User-Agent: Cosimo/1.0 600 Accept: application/atom+xml 601 Accept-Encoding: gzip, *;q=0 603 In the example, the client has included an 'Accept' header, ensuring 604 the response will be of the correct media type. Otherwise, the 605 server might return another type of document, such as an HTML or text 606 file. 608 The server responds to a GET request by returning a Service 609 Description document in the message body. 611 HTTP/1.1 200 OK 612 Date: Mon, 21 Mar 2005 19:20:19 GMT 613 Server: CountBasic/2.0 614 Last-Modified: Mon, 21 Mar 2005 19:17:26 GMT 615 ETag: "4c083-268-423f1dc6" 616 Accept-Ranges: bytes 617 Content-Length: 616 618 Content-Type: application/atom+xml 620 ... Service Description bytes ... 622 4. Extensions to the Atom Syndication Format 624 [[anchor41: Document pub: elements]] 626 5. Security Considerations 628 [[anchor43: 2617, TLS, etc]] 630 [[anchor44: Talk here about denial of service attacks using large XML 631 files, or the billion laughs DTD attack.]] 633 6. IANA Considerations 635 This document has no actions for IANA. 637 7. Normative References 639 [AtomFormat] 640 Nottingham, M. and R. Sayre, "The Atom Syndication 641 Format", work-in-progress, March 2005. 643 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 644 Requirement Levels", BCP 14, RFC 2119, March 1997. 646 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 647 Resource Identifiers (URI): Generic Syntax", RFC 2396, 648 August 1998. 650 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 651 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext 652 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 654 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 655 Leach, P., Luotonen, A. and L. Stewart, "HTTP 656 Authentication: Basic and Digest Access Authentication", 657 RFC 2617, June 1999. 659 [W3C.REC-soap12-part1-20030624] 660 Nielsen, H., Mendelsohn, N., Gudgin, M., Hadley, M. and J. 661 Moreau, "SOAP Version 1.2 Part 1: Messaging Framework", 662 W3C REC REC-soap12-part1-20030624, June 2003. 664 [W3C.REC-xml-20040204] 665 Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T. and 666 E. Maler, "Extensible Markup Language (XML) 1.0 (Third 667 Edition)", W3C REC REC-xml-20040204, February 2004. 669 [1] 671 Author's Address 673 Robert Sayre 674 Boswijck Memex Consulting 675 148 N 9th St. 4R 676 Brooklyn, NY 11211 677 US 679 Email: rfsayre@boswijck.com 680 URI: http://boswijck.com 682 Intellectual Property Statement 684 The IETF takes no position regarding the validity or scope of any 685 Intellectual Property Rights or other rights that might be claimed to 686 pertain to the implementation or use of the technology described in 687 this document or the extent to which any license under such rights 688 might or might not be available; nor does it represent that it has 689 made any independent effort to identify any such rights. Information 690 on the procedures with respect to rights in RFC documents can be 691 found in BCP 78 and BCP 79. 693 Copies of IPR disclosures made to the IETF Secretariat and any 694 assurances of licenses to be made available, or the result of an 695 attempt made to obtain a general license or permission for the use of 696 such proprietary rights by implementers or users of this 697 specification can be obtained from the IETF on-line IPR repository at 698 http://www.ietf.org/ipr. 700 The IETF invites any interested party to bring to its attention any 701 copyrights, patents or patent applications, or other proprietary 702 rights that may cover technology that may be required to implement 703 this standard. Please address the information to the IETF at 704 ietf-ipr@ietf.org. 706 The IETF has been notified of intellectual property rights claimed in 707 regard to some or all of the specification contained in this 708 document. For more information consult the online list of claimed 709 rights. 711 Disclaimer of Validity 713 This document and the information contained herein are provided on an 714 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 715 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 716 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 717 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 718 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 719 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 721 Copyright Statement 723 Copyright (C) The Internet Society (2005). This document is subject 724 to the rights, licenses and restrictions contained in BCP 78, and 725 except as set forth therein, the authors retain all their rights. 727 Acknowledgment 729 Funding for the RFC Editor function is currently provided by the 730 Internet Society.