idnits 2.17.1 draft-sayre-atompub-protocol-outline-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 315. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 287. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 294. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 300. ** 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 : ---------------------------------------------------------------------------- No issues found here. 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 (October 25, 2005) is 6756 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'RELAX-NG' ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Sayre 3 Internet-Draft October 25, 2005 4 Expires: April 28, 2006 6 APP Outline Format 7 draft-sayre-atompub-protocol-outline-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 April 28, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This memo presents an XML outline format. The format is geared 41 towards describing resource layout on Atom Publishing Protocol 42 servers. 44 Editorial Note 46 To provide feedback on this Internet-Draft, join the atom-protocol 47 mailing list . 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 53 3. APP Outline Documents . . . . . . . . . . . . . . . . . . . . 3 54 4. User Agent Conformance . . . . . . . . . . . . . . . . . . . . 4 55 5. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 5 56 6. Sample APP Outline Documents . . . . . . . . . . . . . . . . . 5 57 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 58 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 59 9. Normative References . . . . . . . . . . . . . . . . . . . . . 6 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7 61 Intellectual Property and Copyright Statements . . . . . . . . 8 63 1. Introduction 65 Many applications require an outline of resources. XML [W3C.REC-xml- 66 20040204] documents are organized hierarchically, but XML does not 67 differentiate between elements serving as structural divisions and 68 elements serving as structural properties. This specification 69 defines two elements which serve as structural divisions, provides an 70 associated XML document structure, and defines minimal user agent 71 conformance rules. 73 Example APP Outline Document: 75 76 77 78 79 80 81 82 83 84 86 2. Notational Conventions 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in BCP 14, [RFC2119], as 91 scoped to those conformance targets. 93 This specification includes a normative RELAX NG Compact schema 94 [RELAX-NG]. 96 The terms 'URI' and 'IRI' are shorthand for the identifiers specified 97 in [RFC3986] and [RFC3987]. 99 3. APP Outline Documents 101 APP Outline Documents MUST be well-formed XML [W3C.REC-xml-20040204]. 103 The root element of an APP Outline Document is "". This 104 specification does not define any attributes of the element, 105 but the element MAY have any number of attributes. 107 Zero or more elements MAY appear as child elements of 108 . Also, elements MAY contain zero or more 109 elements. This specification defines three attributes of the 110 element. elements MUST contain at least one of 111 those attributes. Outline properties that are too large to 112 efficiently include in attribute values MAY appear as child elements 113 of the outline element. 115 3.1 The 'text' Attribute 117 The 'text' attribute contains a short string describing the outline 118 element. Entities such as "&" and "<" represent their 119 corresponding characters ("&" and "<" respectively), not markup. 121 3.2 The 'href' Attribute 123 The 'href' attribute contains an IRI reference interpreted relative 124 to the in-scope base IRI [RFC3987]. Most protocols require URIs 125 [RFC3986], so IRIs usually need to be converted to URIs before being 126 dereferenced. 128 3.3 The 'class' Attribute 130 The 'class' attribute contains a space-separated list of strings used 131 to classify the outline element. 133 elements MAY contain any number of elements that are not 134 elements, and elements MAY contain any number of 135 elements that are not elements. 137 4. User Agent Conformance 139 Foreign markup is markup not defined by this specification. 141 Software consuming APP Outline Documents MUST NOT not halt processing 142 when any foreign markup is encountered. Software MAY ignore the 143 markup and process any content of foreign elements as though the 144 surrounding markup were not present. For example, software may 145 process 147 148 149 150 151 153 as though the element was not present. 155 Software conforming to this specification MAY halt processing when 156 documents that do not conform to the schema below are encountered. 158 5. Relax NG Schema 160 This schema is normative. 162 start = app 164 app = element app { 165 anyAttribute*, 166 (outline* & anyElement*) 167 } 169 outline = element outline { 170 (textAtt | classAtt | hrefAtt), anyAttribute*, 171 (outline* & anyElement*) 172 } 174 textAtt = attribute text { text } 176 hrefAtt = attribute href { text } 178 classAtt = attribute class { text } 180 anyElement = element * { (anyAttribute | text | anyElement)* } 182 anyAttribute = attribute * { text } 184 6. Sample APP Outline Documents 186 Simple APP Outline Document: 188 189 190 191 192 193 195 Valid APP Outline Document with extensions: 197 198 hmm 199 200 201 202 hmm 203 204 206 7. Security Considerations 208 TBD. 210 8. IANA Considerations 212 An APP Outline Document can be identified with the following media 213 type: 215 MIME media type name: application 216 MIME subtype name: outline+xml 217 Mandatory parameters: None. 218 Optional parameters: 219 "charset": This parameter has identical semantics to the charset 220 parameter of the "application/xml" media type as specified in 221 [RFC3023]. 222 Encoding considerations: Identical to those of "application/xml" as 223 described in [RFC3023], section 3.2. 224 Security considerations: As defined in this specification. 225 In addition, as this media type uses the "+xml" convention, it 226 shares the same security considerations as described in [RFC3023], 227 section 10. 228 Interoperability considerations: There are no known interoperability 229 issues. 230 Published specification: This specification. 231 Applications that use this media type: No known applications 232 currently use this media type. 234 Additional information: 236 Magic number(s): As specified for "application/xml" in [RFC3023], 237 section 3.2. 238 File extension: .ao 239 Fragment identifiers: As specified for "application/xml" in 240 [RFC3023], section 5. 241 Base URI: As specified in [RFC3023], section 6. 242 Macintosh File Type code: TEXT 243 Person and email address to contact for further information: Robert 244 Sayre 245 Intended usage: COMMON 246 Author/Change controller: IESG 248 9. Normative References 250 [RELAX-NG] 251 Clark, J., "RELAX NG Compact Syntax", December 2001. 253 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 254 Requirement Levels", BCP 14, RFC 2119, March 1997. 256 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 257 Types", RFC 3023, January 2001. 259 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 260 Resource Identifier (URI): Generic Syntax", STD 66, 261 RFC 3986, January 2005. 263 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 264 Identifiers (IRIs)", RFC 3987, January 2005. 266 [W3C.REC-xml-20040204] 267 Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T., 268 and E. Maler, "Extensible Markup Language (XML) 1.0 (Third 269 Edition)", W3C REC REC-xml-20040204, February 2004. 271 Author's Address 273 Robert Sayre 275 Email: rfsayre@boswijck.com 276 URI: http://boswijck.com 278 Intellectual Property Statement 280 The IETF takes no position regarding the validity or scope of any 281 Intellectual Property Rights or other rights that might be claimed to 282 pertain to the implementation or use of the technology described in 283 this document or the extent to which any license under such rights 284 might or might not be available; nor does it represent that it has 285 made any independent effort to identify any such rights. Information 286 on the procedures with respect to rights in RFC documents can be 287 found in BCP 78 and BCP 79. 289 Copies of IPR disclosures made to the IETF Secretariat and any 290 assurances of licenses to be made available, or the result of an 291 attempt made to obtain a general license or permission for the use of 292 such proprietary rights by implementers or users of this 293 specification can be obtained from the IETF on-line IPR repository at 294 http://www.ietf.org/ipr. 296 The IETF invites any interested party to bring to its attention any 297 copyrights, patents or patent applications, or other proprietary 298 rights that may cover technology that may be required to implement 299 this standard. Please address the information to the IETF at 300 ietf-ipr@ietf.org. 302 The IETF has been notified of intellectual property rights claimed in 303 regard to some or all of the specification contained in this 304 document. For more information consult the online list of claimed 305 rights. 307 Disclaimer of Validity 309 This document and the information contained herein are provided on an 310 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 311 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 312 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 313 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 314 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 315 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 317 Copyright Statement 319 Copyright (C) The Internet Society (2005). This document is subject 320 to the rights, licenses and restrictions contained in BCP 78, and 321 except as set forth therein, the authors retain all their rights. 323 Acknowledgment 325 Funding for the RFC Editor function is currently provided by the 326 Internet Society.