idnits 2.17.00 (12 Aug 2021) /tmp/idnits30554/draft-sayre-atompub-protocol-outline-01.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 333. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 305. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 312. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 318. ** 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 6051 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. 'APP' -- 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 (==), 9 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 Service Description Format 7 draft-sayre-atompub-protocol-outline-01.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 format used to describe Atom Publishing 41 Protocol services. These services typically expose one or more 42 groupings of resources. On a blogging service, for example, each 43 grouping might represent a distinct blog and associated resources. 45 Editorial Note 47 To provide feedback on this Internet-Draft, join the atom-protocol 48 mailing list . 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 54 3. APP Service Description Documents . . . . . . . . . . . . . . 3 55 4. User Agent Conformance . . . . . . . . . . . . . . . . . . . . 4 56 5. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 5 57 6. Sample APP Service Description Documents . . . . . . . . . . . 6 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 59 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 60 9. Normative References . . . . . . . . . . . . . . . . . . . . . 7 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 62 Intellectual Property and Copyright Statements . . . . . . . . 9 64 1. Introduction 66 Many Atom Publishing Protocol [APP] applications require a basic 67 resource layout in order to ease configuration requirements. XML 68 [W3C.REC-xml-20040204] documents are organized hierarchically, but 69 XML does not differentiate between elements serving as structural 70 divisions and elements serving as structural properties. This 71 specification defines two elements which outline the structure of APP 72 services, and defines minimal user agent conformance rules. 74 Example APP Service Description Document: 76 77 79 81 83 84 85 86 87 88 90 2. Notational Conventions 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in BCP 14, [RFC2119], as 95 scoped to those conformance targets. 97 This specification includes a normative RELAX NG Compact schema 98 [RELAX-NG]. 100 The terms 'URI' and 'IRI' are shorthand for the identifiers specified 101 in [RFC3986] and [RFC3987]. 103 3. APP Service Description Documents 105 APP Service Description Documents MUST be well-formed XML [W3C.REC- 106 xml-20040204]. 108 The root element of an APP Service Description Document is "". 109 This specification does not define any attributes of the 110 element, but the element MAY have any number of attributes. 112 Zero or more elements MAY appear as child elements of 113 . Also, elements MAY contain zero or more 114 elements. This specification defines three attributes of the 115 element. elements MUST contain at least one of 116 those attributes. 118 Service properties that are too large to efficiently include in 119 attribute values MAY appear as child elements of the service element. 120 elements MAY contain any number of elements that are not 121 elements, and elements MAY contain any number of 122 elements that are not elements. 124 3.1 The 'name' Attribute 126 The 'name' attribute contains a short string describing the service 127 element. Entities such as "&" and "<" represent their 128 corresponding characters ("&" and "<" respectively), not markup. 130 3.2 The 'href' Attribute 132 The 'href' attribute contains an IRI reference interpreted relative 133 to the in-scope base IRI [RFC3987]. Most protocols require URIs 134 [RFC3986], so IRIs usually need to be converted to URIs before being 135 dereferenced. 137 3.3 The 'class' Attribute 139 The 'class' attribute contains a space-separated list of strings used 140 to classify the service element. This specification defines two 141 values for the 'class' attribute: 143 o feed 144 o media feed 146 These values correspond to standard feeds and media feeds, 147 respectively [APP]. 149 4. User Agent Conformance 151 Foreign markup is markup not defined by this specification. 153 Software consuming APP Service Description Documents MUST NOT not 154 halt processing when any foreign markup is encountered. Software MAY 155 ignore the markup and process any content of foreign elements as 156 though the surrounding markup were not present. For example, 157 software may process 158 159 160 161 162 163 164 ... 165 166 167 168 170 as though the and elements were not present. 172 Software conforming to this specification MAY halt processing when 173 documents that do not conform to the schema below are encountered. 175 5. Relax NG Schema 177 This schema is normative. 179 start = app 181 app = element app { 182 anyAttribute*, 183 (service* & anyElement*) 184 } 186 service = element service { 187 (nameAtt | classAtt | hrefAtt), anyAttribute*, 188 (service* & anyElement*) 189 } 191 nameAtt = attribute name { text } 192 hrefAtt = attribute href { text } 193 classAtt = attribute class { text } 195 anyElement = element * { (anyAttribute | text | anyElement)* } 196 anyAttribute = attribute * { text } 198 6. Sample APP Service Description Documents 200 Simple APP Service Description Document: 202 203 204 205 206 207 209 Valid APP Service Description Document with extensions: 211 212 hmm 213 214 215 216 hmm 217 218 220 7. Security Considerations 222 TBD. 224 8. IANA Considerations 226 An APP Service Description Document can be identified with the 227 following media type: 229 MIME media type name: application 230 MIME subtype name: sdf+xml 231 Mandatory parameters: None. 232 Optional parameters: 233 "charset": This parameter has identical semantics to the charset 234 parameter of the "application/xml" media type as specified in 235 [RFC3023]. 236 Encoding considerations: Identical to those of "application/xml" as 237 described in [RFC3023], section 3.2. 238 Security considerations: As defined in this specification. 239 In addition, as this media type uses the "+xml" convention, it 240 shares the same security considerations as described in [RFC3023], 241 section 10. 243 Interoperability considerations: There are no known interoperability 244 issues. 245 Published specification: This specification. 246 Applications that use this media type: No known applications 247 currently use this media type. 249 Additional information: 251 Magic number(s): As specified for "application/xml" in [RFC3023], 252 section 3.2. 253 File extension: .ao 254 Fragment identifiers: As specified for "application/xml" in 255 [RFC3023], section 5. 256 Base URI: As specified in [RFC3023], section 6. 257 Macintosh File Type code: TEXT 258 Person and email address to contact for further information: Robert 259 Sayre 260 Intended usage: COMMON 261 Author/Change controller: IESG 263 9. Normative References 265 [APP] Gregorio, J. and B. de hOra, "The Atom Publishing 266 Protocol", November 2005. 268 [RELAX-NG] 269 Clark, J., "RELAX NG Compact Syntax", December 2001. 271 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 272 Requirement Levels", BCP 14, RFC 2119, March 1997. 274 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 275 Types", RFC 3023, January 2001. 277 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 278 Resource Identifier (URI): Generic Syntax", STD 66, 279 RFC 3986, January 2005. 281 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 282 Identifiers (IRIs)", RFC 3987, January 2005. 284 [W3C.REC-xml-20040204] 285 Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T., 286 and E. Maler, "Extensible Markup Language (XML) 1.0 (Third 287 Edition)", W3C REC REC-xml-20040204, February 2004. 289 Author's Address 291 Robert Sayre 293 Email: rfsayre@boswijck.com 294 URI: http://boswijck.com 296 Intellectual Property Statement 298 The IETF takes no position regarding the validity or scope of any 299 Intellectual Property Rights or other rights that might be claimed to 300 pertain to the implementation or use of the technology described in 301 this document or the extent to which any license under such rights 302 might or might not be available; nor does it represent that it has 303 made any independent effort to identify any such rights. Information 304 on the procedures with respect to rights in RFC documents can be 305 found in BCP 78 and BCP 79. 307 Copies of IPR disclosures made to the IETF Secretariat and any 308 assurances of licenses to be made available, or the result of an 309 attempt made to obtain a general license or permission for the use of 310 such proprietary rights by implementers or users of this 311 specification can be obtained from the IETF on-line IPR repository at 312 http://www.ietf.org/ipr. 314 The IETF invites any interested party to bring to its attention any 315 copyrights, patents or patent applications, or other proprietary 316 rights that may cover technology that may be required to implement 317 this standard. Please address the information to the IETF at 318 ietf-ipr@ietf.org. 320 The IETF has been notified of intellectual property rights claimed in 321 regard to some or all of the specification contained in this 322 document. For more information consult the online list of claimed 323 rights. 325 Disclaimer of Validity 327 This document and the information contained herein are provided on an 328 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 329 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 330 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 331 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 332 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 333 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 335 Copyright Statement 337 Copyright (C) The Internet Society (2005). This document is subject 338 to the rights, licenses and restrictions contained in BCP 78, and 339 except as set forth therein, the authors retain all their rights. 341 Acknowledgment 343 Funding for the RFC Editor function is currently provided by the 344 Internet Society.