idnits 2.17.1 draft-snell-atompub-app-introspection-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 352. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 329. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 336. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 342. ** 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 (November 13, 2005) is 6740 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: 'RFC3023' is mentioned on line 258, but not defined ** Obsolete undefined reference: RFC 3023 (Obsoleted by RFC 7303) == Unused Reference: 'I-D.ietf-atompub-protocol' is defined on line 283, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-atompub-protocol-06 Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Snell 3 Internet-Draft November 13, 2005 4 Expires: May 17, 2006 6 Atom Publishing Protocol - Introspection 7 draft-snell-atompub-app-introspection-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 May 17, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This specification defines an introspection format for the Atom 41 Publishing Protocol. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 47 3. APP Introspection Documents . . . . . . . . . . . . . . . . . 3 48 3.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 4. Element Definitions . . . . . . . . . . . . . . . . . . . . . 4 50 4.1. The 'app:introspection' Element . . . . . . . . . . . . . 4 51 4.2. The 'app:workspace' Element . . . . . . . . . . . . . . . 5 52 4.3. The 'app:collection' Element . . . . . . . . . . . . . . . 5 53 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 54 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 55 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 56 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 57 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 58 Intellectual Property and Copyright Statements . . . . . . . . . . 10 60 1. Introduction 62 This specification defines an XML format for describing Atom 63 Publishing Protocol [I-D.ietf-atompub-protocol]Collection resources. 65 2. Notational Conventions 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in BCP 14, [RFC2119], as 70 scoped to those conformance targets. 72 This specification uses XML Namespaces [W3C.REC-xml-names-19990114] 73 to uniquely identify XML element names. 75 "app": "http://www.w3.org/2005/Atom-Introspection" 77 This specification uses terms from the XML Infoset [W3C.REC-xml- 78 infoset-20040204]. However, this specification uses a shorthand; the 79 phrase "Information Item" is omitted when naming Element Information 80 Items. Therefore, when this specification uses the term "element," 81 it is referring to an Element Information Item in Infoset terms. 83 3. APP Introspection Documents 85 This specification describes the format for Atom Publishing Protocol 86 Introspection Documents. 88 An Introspection Document represents zero or more APP Collections and 89 Workspaces. A Workspace is a logical collections of related APP 90 Collections. The root of the Introspection document is the app: 91 introspection element. 93 namespace app = "http://www.w3.org/2005/Atom-Introspection" 94 start = appIntrospection 96 Introspection Documents are specified in terms of the XML Information 97 Set, serialised as XML 1.0 [W3C.REC-xml-20040204] and identified with 98 the "application/app-introspection+xml" media type. Introspection 99 Documents MUST be well-formed XML. This specification does not 100 define a DTD for Introspection Documents, and hence does not require 101 them to be valid (in the sense used by XML). 103 APP Introspection allows for the use of IRI's [RFC3987], xml:base 104 [W3C.REC-xmlbase-20010627] and xml:lang in the same fashion described 105 in Section 2 of the Atom Syndication Format specification [I-D.ietf- 106 atompub-format]. 108 3.1. Example 110 Simple Example 112 113 115 119 122 124 Workspace Example 126 127 129 130 134 138 141 142 144 4. Element Definitions 146 4.1. The 'app:introspection' Element 148 The 'app:introspection' Element is the root of APP Introspection 149 Documents. 151 appIntrospection = 152 element app:introspection { 153 atomCommonAttributes, 154 ( appWorkspace*, 155 & appCollection*, 156 & extensionElement* ) 157 } 159 This specification assigns no significance to the order of the child 160 elements of 'app:introspection'. 162 4.2. The 'app:workspace' Element 164 The 'app:workspace' Element represents a logical collection of 165 related APP Collections. 167 appWorkspace = 168 element app:workspace { 169 atomCommonAttributes, 170 & attribute title (text), 171 ( appCollection*, 172 & extensionElement ) 173 } 175 The 'title' attribute specifies a human-readable, language-sensitive 176 label for the workspace. 178 This specification assigns no significance to the order of the child 179 elements of 'app:workspace'. 181 4.3. The 'app:collection' Element 183 The 'app:collection' Element represents a collection resource as 184 specified by the Atom Publishing Protocol. 186 appCollection = 187 element app:collection { 188 atomCommonAttributes, 189 & attribute title (text), 190 & attribute href (IRI), 191 & attribute type ( 'entry' | extensionType )?, 192 ( extensionElement ) 193 } 195 extensionType = ( NMTOKEN | mediaType | mediaRange ) 197 The 'title' attribute specifies a human-readable, language-sensitive 198 label for the collection. 200 The 'href' attribute specifies the IRI of an APP collection resource. 202 The 'type' attribute MAY be used to specify the types of resources 203 contained by the collection. A value of 'entry' indicates that the 204 collection membership consists entirely of Atom Entry Documents. If 205 the collection element does not contain a 'type' attribute, the 206 membership of the collection SHOULD be considered to be 207 unconstrained. If the value specified is a media type or media 208 range, the membership of the collection SHOULD be considered to be 209 constrained to resources of the specified type or covered by the 210 specified range. If the 'type' attribute specifies a value that is 211 not understood by the an application, the application MUST ignore the 212 attribute as if the attribute were not present. 214 5. Security Considerations 216 TBD 218 6. IANA Considerations 220 An Introspection Document can be identified by the following media 221 type. 223 MIME media type name: 224 application 225 MIME subtype name: 226 app-introspection+xml 227 Mandatory parameters: 228 None 229 Optional parameters: 230 "charset": 231 This parameter has identical semantics to the charset 232 parameter of the "application/xml" media type as 233 specified in [RFC3023]. 234 Encoding considerations: 235 Identical to those of "application/xml" as described 236 in [RFC3023], section 3.2. 237 Security considerations: 238 As defined in this specification. 239 In addition, as this media type uses the "+xml" convention, 240 it shares the same security considerations as described in 241 [RFC3023], section 10. 242 Interoperability considerations: 243 There are no known interoperability issues. 244 Published specification: 245 This specification. 246 Applications that use this media type: 247 No known applications currently use this media type. 249 Additional information: 251 Magic number(s): 252 As specified for "application/xml" in [RFC3023], section 3.2. 253 File extension: 254 .appx 255 Fragment identifiers: 256 As specified for "application/xml" in [RFC3023], section 5. 257 Base URI: 258 As specified in [RFC3023], section 6. 259 Macintosh File Type code: 260 TEXT 261 Person and email address to contact for further information: 262 James Snell 263 Intended usage: 264 COMMON 265 Author/Change controller: 266 IESG 268 7. Acknowledgements 270 This draft incorporates ideas discussed by the members of the Atom 271 Publishing Format and Protocol working group. This draft also adapts 272 some of the language and text from the Atom Syndication Format 273 [I-D.ietf-atompub-format] in order to achieve a stylistic similarity 274 between the drafts. 276 8. References 278 [I-D.ietf-atompub-format] 279 Sayre, R. and M. Nottingham, "The Atom Syndication 280 Format", draft-ietf-atompub-format-11 (work in progress), 281 August 2005. 283 [I-D.ietf-atompub-protocol] 284 Hora, B. and J. Gregorio, "The Atom Publishing Protocol", 285 draft-ietf-atompub-protocol-06 (work in progress), 286 November 2005. 288 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 289 Requirement Levels", BCP 14, RFC 2119, March 1997. 291 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 292 Identifiers (IRIs)", RFC 3987, January 2005. 294 [W3C.REC-xml-20040204] 295 Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T., 296 and E. Maler, "Extensible Markup Language (XML) 1.0 (Third 297 Edition)", W3C REC REC-xml-20040204, February 2004. 299 [W3C.REC-xml-infoset-20040204] 300 Tobin, R. and J. Cowan, "XML Information Set (Second 301 Edition)", W3C REC REC-xml-infoset-20040204, 302 February 2004. 304 [W3C.REC-xml-names-19990114] 305 Hollander, D., Bray, T., and A. Layman, "Namespaces in 306 XML", W3C REC REC-xml-names-19990114, January 1999. 308 [W3C.REC-xmlbase-20010627] 309 Marsh, J., "XML Base", W3C REC REC-xmlbase-20010627, 310 June 2001. 312 Author's Address 314 James M Snell 316 Phone: 317 Email: jasnell@gmail.com 318 URI: http://snellspace.com 320 Intellectual Property Statement 322 The IETF takes no position regarding the validity or scope of any 323 Intellectual Property Rights or other rights that might be claimed to 324 pertain to the implementation or use of the technology described in 325 this document or the extent to which any license under such rights 326 might or might not be available; nor does it represent that it has 327 made any independent effort to identify any such rights. Information 328 on the procedures with respect to rights in RFC documents can be 329 found in BCP 78 and BCP 79. 331 Copies of IPR disclosures made to the IETF Secretariat and any 332 assurances of licenses to be made available, or the result of an 333 attempt made to obtain a general license or permission for the use of 334 such proprietary rights by implementers or users of this 335 specification can be obtained from the IETF on-line IPR repository at 336 http://www.ietf.org/ipr. 338 The IETF invites any interested party to bring to its attention any 339 copyrights, patents or patent applications, or other proprietary 340 rights that may cover technology that may be required to implement 341 this standard. Please address the information to the IETF at 342 ietf-ipr@ietf.org. 344 Disclaimer of Validity 346 This document and the information contained herein are provided on an 347 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 348 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 349 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 350 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 351 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 352 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 354 Copyright Statement 356 Copyright (C) The Internet Society (2005). This document is subject 357 to the rights, licenses and restrictions contained in BCP 78, and 358 except as set forth therein, the authors retain all their rights. 360 Acknowledgment 362 Funding for the RFC Editor function is currently provided by the 363 Internet Society.