idnits 2.17.00 (12 Aug 2021)
/tmp/idnits31081/draft-sayre-2-way-rss-05.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.2b on line 16.
-- Found old boilerplate from RFC 3978, Section 5.5 on line 559.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 536.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 543.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 549.
-- The document has an RFC 3978 Section 5.2(b) Derivative Works Limitation
clause. If this document is intended for submission to the IESG for
publication, this constitutes an error.
** This document has an original RFC 3978 Section 5.4 Copyright Line,
instead of the newer IETF Trust Copyright according to RFC 4748.
** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
of the newer disclaimer which includes the IETF Trust according to RFC
4748.
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 document seems to lack a Security Considerations section.
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
** The document seems to lack separate sections for Informative/Normative
References. All references will be assumed normative when checking for
downward references.
** There is 1 instance of too long lines in the document, the longest one
being 1 character in excess of 72.
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 (May 18, 2006) is 5846 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Unused Reference: 'RSS091' is defined on line 496, but no explicit
reference was found in the text
== Unused Reference: 'RSS092' is defined on line 499, but no explicit
reference was found in the text
== Unused Reference: 'RSS2' is defined on line 502, but no explicit
reference was found in the text
-- Possible downref: Non-RFC (?) normative reference: ref. 'OBJECT'
-- Possible downref: Non-RFC (?) normative reference: ref. 'OPML2'
** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231,
RFC 7232, RFC 7233, RFC 7234, RFC 7235)
** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322)
-- Possible downref: Non-RFC (?) normative reference: ref. 'RSS'
-- Possible downref: Non-RFC (?) normative reference: ref. 'RSS091'
-- Possible downref: Non-RFC (?) normative reference: ref. 'RSS092'
-- Possible downref: Non-RFC (?) normative reference: ref. 'RSS2'
-- Possible downref: Non-RFC (?) normative reference: ref. 'XHTML'
-- Possible downref: Non-RFC (?) normative reference: ref. '1'
Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 17 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group R. Sayre
3 Internet-Draft May 18, 2006
4 Expires: November 19, 2006
6 2-Way RSS
7 draft-sayre-2-way-rss-05
9 Status of this Memo
11 By submitting this Internet-Draft, each author represents that any
12 applicable patent or other IPR claims of which he or she is aware
13 have been or will be disclosed, and any of which he or she becomes
14 aware will be disclosed, in accordance with Section 6 of BCP 79.
15 This document may not be modified, and derivative works of it may not
16 be created.
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 November 19, 2006.
36 Copyright Notice
38 Copyright (C) The Internet Society (2006).
40 Abstract
42 This memo presents a protocol that uses XML and HTTP to publish and
43 edit Web resources.
45 Table of Contents
47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
48 2. The 2-Way RSS Model . . . . . . . . . . . . . . . . . . . . . 3
49 3. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 3
50 4. Listing . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
51 5. Authoring . . . . . . . . . . . . . . . . . . . . . . . . . . 4
52 6. 2-Way RSS Feeds . . . . . . . . . . . . . . . . . . . . . . . 6
53 7. 2-Way Media RSS Feeds . . . . . . . . . . . . . . . . . . . . 7
54 8. Service Outlines . . . . . . . . . . . . . . . . . . . . . . . 9
55 9. The 2-Way RSS Namespace . . . . . . . . . . . . . . . . . . . 11
56 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
57 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13
58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
59 Intellectual Property and Copyright Statements . . . . . . . . . . 15
61 1. Introduction
63 2-Way RSS uses HTTP [RFC2616] and XML [XML 1.0] to publish and edit
64 Web resources.
66 1.1. Editor's Note
68 To discuss this draft, please join the 2-Way RSS mailing list [1].
69 Membership is open to all.
71 2. The 2-Way RSS Model
73 2-Way RSS uses HTTP to operate on collections of Web resources
74 represented by RSS feeds [RSS]. In 2-Way RSS, individual RSS items
75 have URIs [RFC3986]. This section illustrates the editing cycle for
76 RSS items.
77 o GET is used to retrieve an item or perform a read-only query.
78 o POST is used to create a new item.
79 o PUT is used to update an existing item.
80 o DELETE is used to remove an item.
82 3. Discovery
84 To discover the location of the feeds exposed by a 2-way RSS service,
85 the client must locate and request the Service Outline, an OPML 2.0
86 document [OPML2].
88 Client Server
89 | |
90 | 1.) GET Service Outline URI |
91 |------------------------------->|
92 | |
93 | 2.) Service OPML Document |
94 |<-------------------------------|
95 | |
97 1. The client sends a GET request to the Service Outline URI.
98 2. The server responds with an OPML Document containing the
99 locations of feeds provided by the service. The content of this
100 document can vary based on aspects of the client request,
101 including, but not limited to, authentication credentials.
103 4. Listing
104 Once the client has discovered the location of a feed in the outline,
105 it can request a listing of the feed's items. However, a feed might
106 contain an extremely large number of items, so servers are likely to
107 list a small subset of them by default.
109 Client Server
110 | |
111 | 1.) GET to RSS Feed URI |
112 |------------------------------->|
113 | |
114 | 2.) 200 OK, RSS Feed Doc |
115 |<-------------------------------|
116 | |
118 1. The client sends a GET request to the RSS Feed's URI.
119 2. The server responds with an RSS Feed Document containing a full
120 or partial listing of the feed's membership.
122 5. Authoring
124 After locating a feed, a client can add entries by sending a POST
125 request to the feed; other changes are accomplished by sending HTTP
126 requests to each item.
128 5.1. Create
130 Client Server
131 | |
132 | 1.) POST Item to Feed URI |
133 |------------------------------->|
134 | |
135 | 2.) 201 Created @ Location |
136 |<-------------------------------|
137 | |
139 1. The client sends an RSS item to the server via HTTP POST. The
140 Request URI is that of the RSS Feed.
141 2. The server responds with a response of "201 Created" and a
142 "Location" header containing the URI of the newly-created RSS
143 item.
145 5.2. Read
147 Client Server
148 | |
149 | 1.) GET to Item URI |
150 |------------------------------->|
151 | |
152 | 2.) 200 OK RSS Item |
153 |<-------------------------------|
154 | |
156 1. The client sends a GET request to the item's URI.
157 2. The server responds with an RSS item.
159 5.3. Update
161 Client Server
162 | |
163 | 1.) PUT to RSS Item URI |
164 |------------------------------->|
165 | |
166 | 2.) 200 OK |
167 |<-------------------------------|
168 | |
170 1. The client PUTs an updated RSS item to the item's URI.
171 2. The server responds with a successful status code.
173 5.4. Delete
175 Client Server
176 | |
177 | 1.) DELETE to Item URI |
178 |------------------------------->|
179 | |
180 | 2.) 204 No Content |
181 |<-------------------------------|
182 | |
184 1. The client sends a DELETE request to the item's URI.
185 2. The server responds with successful status code.
187 5.5. Success and Failure
189 HTTP defines classes of response. HTTP status codes of the form 2xx
190 signal that a request was successful. HTTP status codes of the form
191 4xx or 5xx signal that an error has occurred, and the request has
192 failed. Consult the HTTP specification for more detailed definitions
193 of each status code.
195 6. 2-Way RSS Feeds
197 6.1. GET
199 RSS feeds can contain extremely large numbers of items. A naive
200 client such as a web spider or web browser would be overwhelmed if
201 the response to a GET contained every item in the feed, and the
202 server would waste large amounts of bandwidth and processing time on
203 clients unable to handle the response. As a result, responses to a
204 simple GET request represent a server-determined subset of the items
205 in the feed.
207 An example 2-Way RSS feed:
209
210
211 The Baron in the Trees
212 http://example.org/trees.html
213 Recent posts.
214
215
216 Chapter One
217 It was on the fifteenth of June, 1767,
218 that Cosimo Piovasco di Rondò, my brother,
219 sat among us for the last time.
220 uuid:941e12b4-6eeb-4753-959d-0cbc51875387
221 http://example.org/chapter1.html
222
223
224
225
227 Each member item is represented by an element, but those items
228 are not an editable representation of the each item. To retrieve the
229 source representation of the item, clients send a GET request to the
230 URI found in each item's edit link, an 'r:link' element Section 9.1
231 with an 'edit' relation.
233 6.2. POST
235 A 2-Way RSS feed also accepts POST requests. The client POSTs a new
236 item to the RSS feed. Some feeds only accept POST requests with
237 certain media-types, so a POST request could result in a response
238 with a status code of 415 ("Unsupported Media Type"). In the case of
239 a successful creation, the status code is 201 ("Created").
241 Example HTTP request creating a new item in a feed:
243 POST /wall HTTP/1.1
244 Host: example.org
245 User-Agent: Cosimo/1.0
246 Content-Type: text/xml
247 Content-Length: nnnn
249
250 Chapter One
251 It started out simple...
252 uuid:941e12b4-6eeb-4753-959d-0cbc51875387
253 http://example.org/chapter1.html
254
255
257 Example response.
259 HTTP/1.1 201 Created
260 Date: Mon, 21 Mar 2005 19:20:19 GMT
261 Server: CountBasic/1.0
262 ETag: "4c083-268-423f1dc6"
263 Location: http://example.org/items/foo13241234.xml
265 7. 2-Way Media RSS Feeds
267 The items within 2-way Media RSS Feeds do not represent uniform types
268 of content. For example, they might contain podcasts, JPEG images,
269 text documents, MPEG movies, or any other type of resource the server
270 allows.
272 7.1. GET
274 2-Way Media RSS Feeds return an RSS feed much like the textual 2-Way
275 RSS feeds described above, but with a few additions. The entries
276 also contain an element with a 'url' attribute pointing
277 to the media object. This URL can be used to edit the uploaded media
278 object, using PUT and DELETE. Such items may contain edit links used
279 to edit the item metadata.
281 An example 2-Way Media RSS Feed:
283
284
285 My Pics
286 http://example.org/pics
287 Recent photos.
288
289
290 beach25
291 http://example.org/beach-pic1.html
292 uuid:941e12b4-6eeb-4753-959d-0cbc51875387
293 This was awesome.
294
297
298
299
301 Implementations require that each such item contain either a
302 or <description> element. The value for the <title> element will
303 likely be provided by the client, as a way for users to associate
304 their local objects with those they have uploaded to the server (see
305 POST below).
307 7.2. POST
309 To add an item to a 2-Way Media RSS feed, clients POST the resource
310 to the Media feed's URL. Clients should provide a 'Title' request
311 header [OBJECT] to provide the server with a short string identifying
312 the object to users.
314 Clients may include a 'Content-Description' header [RFC2045]
315 providing a more complete description of the content. Data gleaned
316 from other entity headers, such as 'Keywords' [RFC2822] and 'From'
317 [RFC2616], may also be exposed in the RSS feed.
319 Servers may inspect the POSTed entity for additional metadata to be
320 exposed in an <item> element when listed in a 2-Way Media RSS feed.
321 For example, the server might inspect a JPEG file for EXIF headers
322 containing creator data.
324 An example request:
326 POST /pics HTTP/1.1
327 Host: example.org
328 User-Agent: Cosimo/1.0
329 Content-Type: image/tiff
330 Content-Length: nnnn
331 Title: A trip to the beach
332 From: Bobby <bobby@example.org>
333 Keywords: beach, digginit, tags, mrpibb, redvines
334 Content-Description: It was so fun.
336 ...binary data...
338 An example response:
340 HTTP/1.1 201 Created
341 Date: Mon, 21 Mar 2005 19:20:19 GMT
342 Server: CountBasic/2.0
343 ETag: "4c083-268-423f1dc6"
344 Location: http://example.org/stuff/beach.tiff
346 <item>
347 <title>A trip to the beach
348 http://example.org/beach.jpg
349 uuid:4019de8a-7d08-4ca7-aee4-1a7cb92f3173
350
353
355 The server's response contains a 'Location' header that gives the URI
356 of the created media resource. The body of the response shows the
357 created item. The enclosure element contains more detailed
358 information about the created media resource.
360 8. Service Outlines
362 Many 2-Way RSS applications require a basic resource layout in order
363 to ease configuration requirements. Servers use Service Outline OPML
364 2.0 documents to convey information about related groups of 2-Way RSS
365 feeds. On a blogging service, for example, each group might
366 represent a distinct blog and associated resources. Normal RSS feeds
367 have a type attribute of 'rss'. 2-Way RSS feeds have a type attribute
368 of '2-way rss'. Read-only media feeds have a type attribute of
369 'media rss', and 2-Way media feeds have a type attribute of '2-way
370 media rss'.
372 Example Service Outline document:
374
375
376 My Blogs
377
378
379
381
383
384
386 Servers are not required to expose a Service Outline OPML document,
387 but experimental deployment experience has shown that a single
388 document which signals some basic information about the server's
389 configuration can greatly simplify client implementations. The
390 simplest useful Service Outline OPML document shows the location of a
391 single feed:
393
394
395 Flickr
396
397
398
400
401
403 If another 2-Way RSS feed is added, another element is added to the
404 Service Outline.
406
407
408 Flickr
409
410
411
413
415
416
418 More extensive services could require some amount of hierarchical
419 grouping.
421
422
423 Flickr
424
425
426
428
429
431
433
434
435
437 Many publishing systems include a categorization system. An outline
438 element with a type attribute value of 'categories' can be used to
439 list the available categories. In this example, the category feeds
440 are read-only.
442
443
444 Flickr
445
446
447
449
450
452
454
455
456
458 9. The 2-Way RSS Namespace
460 The 2-Way RSS namespace URI is 'http://example.org/2006/02/2WayRSS'
461 [@ will update]. The examples in this specifcation use the prefix
462 'r', but any prefix will do in practice.
464 9.1. The 'r:link' Element
466 The syntax and semantics of the 'r:link' element are identical to the
467 XHTML link element [XHTML], except for the namespace, and one other
468 exception: the r:link element allows arbitrary attributes.
470 10. References
472 [OBJECT] Berners-Lee, T., "Object Header lines in HTTP", 1992,
473 .
475 [OPML2] Winer, D., "OPML 2.0 Specification", March 2006,
476 .
478 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
479 Extensions (MIME) Part One: Format of Internet Message
480 Bodies", RFC 2045, November 1996.
482 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
483 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
484 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
486 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
487 April 2001.
489 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
490 Resource Identifier (URI): Generic Syntax", STD 66,
491 RFC 3986, January 2005.
493 [RSS] Cadenhead, et al., "Really Simple Syndication -- RSS
494 Advisory Board Announcements", .
496 [RSS091] Libby, D., "RSS 0.91 Spec, revision 3", June 1997, .
499 [RSS092] Winer, D., "RSS 0.92", December 2005,
500 .
502 [RSS2] Winer, D., "RSS 2.0", July 2003,
503 .
505 [XHTML] Pemberton, S., "XHTML. 1.0 The Extensible HyperText Markup
506 Language (Second Edition)", W3C REC REC-xhtml1-20020801,
507 August 2002,
508 .
510 [XML 1.0] Bray, T., Sperberg-McQueen, C., Paoli, J., Maler, E., and
511 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third
512 Edition)", W3C REC REC-xml-20040204, February 2004,
513 .
515 [1]
517 Appendix A. Acknowledgements
519 [@ will be updated prior to publication]
521 Author's Address
523 Robert Sayre
525 Email: rfsayre@boswijck.com
527 Intellectual Property Statement
529 The IETF takes no position regarding the validity or scope of any
530 Intellectual Property Rights or other rights that might be claimed to
531 pertain to the implementation or use of the technology described in
532 this document or the extent to which any license under such rights
533 might or might not be available; nor does it represent that it has
534 made any independent effort to identify any such rights. Information
535 on the procedures with respect to rights in RFC documents can be
536 found in BCP 78 and BCP 79.
538 Copies of IPR disclosures made to the IETF Secretariat and any
539 assurances of licenses to be made available, or the result of an
540 attempt made to obtain a general license or permission for the use of
541 such proprietary rights by implementers or users of this
542 specification can be obtained from the IETF on-line IPR repository at
543 http://www.ietf.org/ipr.
545 The IETF invites any interested party to bring to its attention any
546 copyrights, patents or patent applications, or other proprietary
547 rights that may cover technology that may be required to implement
548 this standard. Please address the information to the IETF at
549 ietf-ipr@ietf.org.
551 Disclaimer of Validity
553 This document and the information contained herein are provided on an
554 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
555 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
556 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
557 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
558 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
559 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
561 Copyright Statement
563 Copyright (C) The Internet Society (2006). This document is subject
564 to the rights, licenses and restrictions contained in BCP 78, and
565 except as set forth therein, the authors retain all their rights.
567 Acknowledgment
569 Funding for the RFC Editor function is currently provided by the
570 Internet Society.