idnits 2.17.1 draft-snell-atompub-app-blogcontrol-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 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 356. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 333. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 340. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 346. ** 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 (September 24, 2005) is 6781 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: 'I-D.ietf-atompub-format' is defined on line 284, but no explicit reference was found in the text Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Snell 3 Internet-Draft E. Torres 4 Expires: March 28, 2006 September 24, 2005 6 Atom Publishing Protocol - Blog Publishing Controls 7 draft-snell-atompub-app-blogcontrol-00.txt 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. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on March 28, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This document introduces weblog specific publishing control 41 extensions for use with the Atom Publishing Protocol pub:control 42 mechanism. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 48 3. The 'blog:private' element . . . . . . . . . . . . . . . . . . 3 49 4. The 'blog:notify' element . . . . . . . . . . . . . . . . . . 3 50 5. The 'blog:enable' element . . . . . . . . . . . . . . . . . . 4 51 6. The 'blog:scheduled' element . . . . . . . . . . . . . . . . . 7 52 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 53 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 54 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 55 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 57 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 58 Intellectual Property and Copyright Statements . . . . . . . . 10 60 1. Introduction 62 This document introduces weblog specific publishing control 63 extensions for use with the Atom Publishing Protocol pub:control 64 mechanism. 66 2. Notational Conventions 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 70 document are to be interpreted as described in BCP 14, [RFC2119], as 71 scoped to those conformance targets. 73 In this specification, "entry" refers to an atom:entry element. 75 In this specification, "publishing control" refers to the Atom 76 Publishing Protocol pub:control element. 78 This specification uses XML Namespaces [W3C.REC-xml-names-19990114] 79 to uniquely identify XML element names. It uses the following 80 namespace prefix for the indicated namespace URI; 81 "blog": "http://purl.org/atompub/blogcontrols/1.0" 83 This specification uses terms from the XML Infoset [W3C.REC-xml- 84 infoset-20040204]. However, this specification uses a shorthand; the 85 phrase "Information Item" is omitted when naming Element Information 86 Items. Therefore, when this specification uses the term "element," 87 it is referring to an Element Information Item in Infoset terms. 89 3. The 'blog:private' element 91 The 'blog:private' element is used to indicate that a weblog entry 92 should only be made available to a limited audience. It is up to 93 specific implementations to provide the mechanism for determining the 94 audience. If missing, the value is assumed to be indeterminate. 95 blogPrivate = element blog:private { 'yes' | 'no' } 97 4. The 'blog:notify' element 99 The 'blog:notify' element is used to specific a collection of 100 endpoints that should be notified upon the creation or update of the 101 entry. 103 blogNotify = element blog:notify { 104 element blogEndpoint *, 105 undefinedContent 106 } 108 blogEndpoint = element blog:endpoint { 109 attribute type { IRI }, 110 ( IRI ) 111 } 113 The blog:endpoint element specifies an IRI to which a notification 114 should be sent. The type attribute specifies a IRI indicating the 115 type of notification to send. 117 Ed. Note: Should notify be ignored on updates?? 119 5. The 'blog:enable' element 121 The 'blog:enable' element is used to specify whether specific 122 features should be enabled for the entry. Examples of such features 123 include whether or not to enable comments or trackbacks for an entry, 124 or whether or not to enable a given text-encoding mechanism or 125 plugin. 127 blogEnable = element blog:enable { 128 element blogComments ?, 129 element blogTrackbacks ?, 130 element blogPingbacks ?, 131 element blogCommentsNotify ?, 132 element blogTrackbacksNotify ?, 133 element blogPingbacksNotify ?, 134 element blogTextEncoding *, 135 element blogPlugin *, 136 undefinedContent 137 } 139 blogComments = element blog:comments { 140 attribute until { dateTime }?, 141 ('yes','no','moderated','registered') 142 } 144 blogTrackbacks = element blog:trackbacks { 145 attribute until { dateTime }?, 146 ('yes','no','moderated','registered') 147 } 149 blogPingbacks = element blog:pingbacks { 150 attribute until { dateTime }?, 151 ('yes','no','moderated','registered') 152 } 154 blogCommentsNotify = 155 element blog:comments-notify { 'yes' | 'no' } 157 blogTrackbacksNotify = 158 element blog:trackbacks-notify { 'yes' | 'no' } 160 blogPingbacksNotify = 161 element blog:pingbacks-notify { 'yes' | 'no' } 163 blogTextEncoding = element blog:text-encoding { 164 attribute id { IRI }, 165 undefinedContent 166 } 168 blogPlugin = element blog:plugin { 169 attribute id { IRI }, 170 undefinedContent 171 } 173 o The blog:comments element specifies whether to enable comments for 174 the entry. The value of the element is either 'yes', indicating 175 that comments are fully enabled; 'no', indicating that comments 176 are fully disabled; 'moderated', indicating that comments must be 177 reviewed and approved prior to acceptance; and 'registered', 178 indicating that users posting comments must be registered in order 179 to submit comments. The option @until attribute must specify a 180 timestamp conformant with the Atom Date Construct that specifies a 181 moment after which comments will no longer be accepted. 182 o The blog:trackbacks element specifies whether to enable trackbacks 183 for the entry. The value of the element is either 'yes', 184 indicating that trackbacks are fully enabled; 'no', indicating 185 that trackbacks are fully disabled; 'moderated', indicating that 186 trackbacks must be reviewed and approved prior to acceptance; and 187 'registered', indicating that users posting trackbacks must be 188 registered. The option @until attribute must specify a timestamp 189 conformant with the Atom Date Construct that specifies a moment 190 after which trackbacks will no longer be accepted. 191 o The blog:pingbacks element specifies whether to enable pingbacks 192 for the entry. The value of the element is either 'yes', 193 indicating that pingbacks are fully enabled; 'no', indicating that 194 pingbacks are fully disabled; 'moderated', indicating that 195 pingbacks must be reviewed and approved prior to acceptance; and 196 'registered', indicating that users posting pingbacks must be 197 registered. The option @until attribute must specify a timestamp 198 conformant with the Atom Date Construct that specifies a moment 199 after which pingbacks will no longer be accepted. 200 o The blog:comments-notify element specifies whether or not 201 notifications should be sent when new comments are posted. The 202 elements value is either 'yes' or 'no'. 203 o The blog:comments-notify element specifies whether or not 204 notifications should be sent when new comments are posted. The 205 elements value is either 'yes' or 'no'. 206 o The blog:trackbacks-notify element specifies whether or not 207 notifications should be sent when new trackbacks are posted. The 208 elements value is either 'yes' or 'no'. 209 o The blog:pingbacks-notify element specifies whether or not 210 notifications should be sent when new pingbacks are posted. The 211 elements value is either 'yes' or 'no'. 212 o The blog:text-encoding element @id attribute specifies an IRI 213 identifying a text-encoding scheme to apply to the post. The 214 blog:text-encoding element MAY contain any number of namespace- 215 qualified child elements that MAY be considered relevant to the 216 application of the identified text-encoding scheme. 217 o The blog:plugin element @id attribute specifies an IRI identifying 218 a plugin to enable for the post. The blog:plugin element MAY 219 contain any number of namespace-qualified child elements that MAY 220 be considered relevant to the application of the identified 221 plugin. 223 6. The 'blog:scheduled' element 225 The 'blog:scheduled' element is used to specify a date and time 226 conformant to the Atom Date Construct that indicates when the posted 227 entry should be published. If specified, sofware implementations 228 MUST NOT make the element externally available until the moment 229 specified in the element passes. 231 The 'blog:scheduled' element is only effective on new or scheduled 232 entries that have not yet been published and MUST be ignored if 233 included in updates to existing published entries. 234 blogScheduled = element blog:scheduled { atomDateConstruct } 236 7. Example 238 The following Atom Entry illustrates the construction of an Atom 239 Publishing Protocol post in which: 241 o The entry is consider to be public 242 o Trackback and Ping notifications should be sent 243 o Comments and trackbacks are moderated and enabled until midnight, 244 December 12, 2005 245 o The post should not be published until midnight, November 11, 2005 246 249 tag:example.com,2005:/entries/1234 250 A simple blog entry 251 2005-10-10T00:00:00Z 252 This is a simple blog entry 253 254 no 255 256 \ 258 http://www.example.com/entry1.tb 259 \ 261 http://www.technorati.com/ping/ 262 263 264 moderated 266 moderated 268 269 2005-11-11T00:00:00Z 270 271 273 8. Security Considerations 275 There are no security considerations introduced by this 276 specification. 278 9. IANA Considerations 280 There are no IANA considerations introduced by this specification. 282 10. References 284 [I-D.ietf-atompub-format] 285 Sayre, R. and M. Nottingham, "The Atom Syndication 286 Format", draft-ietf-atompub-format-11 (work in progress), 287 August 2005. 289 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 290 Requirement Levels", BCP 14, RFC 2119, March 1997. 292 [W3C.REC-xml-infoset-20040204] 293 Tobin, R. and J. Cowan, "XML Information Set (Second 294 Edition)", W3C REC REC-xml-infoset-20040204, 295 February 2004. 297 [W3C.REC-xml-names-19990114] 298 Hollander, D., Bray, T., and A. Layman, "Namespaces in 299 XML", W3C REC REC-xml-names-19990114, January 1999. 301 [W3C.REC-xmlschema-2-20041028] 302 Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes 303 Second Edition", W3C REC REC-xmlschema-2-20041028, 304 October 2004. 306 Authors' Addresses 308 James M Snell 310 Phone: 311 Email: jasnell@gmail.com 312 URI: http://snellspace.com 314 Elias Torres 316 Phone: 317 Email: elias@torrez.us 318 URI: http://torrez.us 320 Appendix A. Acknowledgements 322 TBD 324 Intellectual Property Statement 326 The IETF takes no position regarding the validity or scope of any 327 Intellectual Property Rights or other rights that might be claimed to 328 pertain to the implementation or use of the technology described in 329 this document or the extent to which any license under such rights 330 might or might not be available; nor does it represent that it has 331 made any independent effort to identify any such rights. Information 332 on the procedures with respect to rights in RFC documents can be 333 found in BCP 78 and BCP 79. 335 Copies of IPR disclosures made to the IETF Secretariat and any 336 assurances of licenses to be made available, or the result of an 337 attempt made to obtain a general license or permission for the use of 338 such proprietary rights by implementers or users of this 339 specification can be obtained from the IETF on-line IPR repository at 340 http://www.ietf.org/ipr. 342 The IETF invites any interested party to bring to its attention any 343 copyrights, patents or patent applications, or other proprietary 344 rights that may cover technology that may be required to implement 345 this standard. Please address the information to the IETF at 346 ietf-ipr@ietf.org. 348 Disclaimer of Validity 350 This document and the information contained herein are provided on an 351 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 352 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 353 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 354 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 355 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 356 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 358 Copyright Statement 360 Copyright (C) The Internet Society (2005). This document is subject 361 to the rights, licenses and restrictions contained in BCP 78, and 362 except as set forth therein, the authors retain all their rights. 364 Acknowledgment 366 Funding for the RFC Editor function is currently provided by the 367 Internet Society.