idnits 2.17.1
draft-snell-atompub-feature-11.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 15.
-- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on
line 303.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 314.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 321.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 327.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust 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 22, 2007) is 6030 days in the past. Is this
intentional?
Checking references for intended status: Experimental
----------------------------------------------------------------------------
No issues found here.
Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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 October 22, 2007
4 Intended status: Experimental
5 Expires: April 24, 2008
7 Atom Publishing Protocol Feature Discovery
8 draft-snell-atompub-feature-11.txt
10 Status of this Memo
12 By submitting this Internet-Draft, each author represents that any
13 applicable patent or other IPR claims of which he or she is aware
14 have been or will be disclosed, and any of which he or she becomes
15 aware will be disclosed, in accordance with Section 6 of BCP 79.
17 Internet-Drafts are working documents of the Internet Engineering
18 Task Force (IETF), its areas, and its working groups. Note that
19 other groups may also distribute working documents as Internet-
20 Drafts.
22 Internet-Drafts are draft documents valid for a maximum of six months
23 and may be updated, replaced, or obsoleted by other documents at any
24 time. It is inappropriate to use Internet-Drafts as reference
25 material or to cite them other than as "work in progress."
27 The list of current Internet-Drafts can be accessed at
28 http://www.ietf.org/ietf/1id-abstracts.txt.
30 The list of Internet-Draft Shadow Directories can be accessed at
31 http://www.ietf.org/shadow.html.
33 This Internet-Draft will expire on April 24, 2008.
35 Copyright Notice
37 Copyright (C) The IETF Trust (2007).
39 Abstract
41 This document introduces extensions to the Atom Publishing Protocol
42 Service Document format for expressing metadata about the behaviors,
43 functions and capabilities supported by an Atom Publishing Protocol
44 collection.
46 Table of Contents
48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
49 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3
50 3. The f:feature element . . . . . . . . . . . . . . . . . . . . . 4
51 3.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 5
52 4. The "supportsDraft" Feature . . . . . . . . . . . . . . . . . . 6
53 5. The "ignoresDraft" Feature . . . . . . . . . . . . . . . . . . 6
54 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
55 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
56 8. Normative References . . . . . . . . . . . . . . . . . . . . . 6
57 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 7
58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
59 Intellectual Property and Copyright Statements . . . . . . . . . . 8
61 1. Introduction
63 This document introduces an extension to the Atom Publishing Protocol
64 (Atompub) service document [RFC5023] format that allows for the
65 documentation and discovery of behaviors, functions or capabilities
66 supported by an Atompub collection. Examples of such capabilities
67 can include the preservation of certain kinds of content, support for
68 draft entries, support for the scheduled publication of entries, use
69 of a particular set of Atom format extensions, and so on.
71 Describing features using the mechanisms defined in this
72 specification is currently considered to be largely experimental.
73 While there are examples of such mechanisms being put to practical
74 use in deployed applications, there is currently not enough
75 collective implementation experience to determine whether the
76 mechanism defined here is sufficient to fully address the general
77 needs of Atom Publishing Protocol client and server implementations.
78 Implementations and feedback are encouraged.
80 2. Notational Conventions
82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
84 document are to be interpreted as described in BCP 14, [RFC2119].
86 This specification uses XML Namespaces [W3C.REC-xml-names-20060816]
87 to uniquely identify XML element names. It uses the following
88 namespace prefix for the indicated namespace URI;
90 "f": "http://purl.org/atompub/features/1.0"
92 This specification uses terms from the XML Infoset
93 [W3C.REC-xml-infoset-20040204]. However, this specification uses a
94 shorthand; the phrase "Information Item" is omitted when naming
95 Element Information Items. Therefore, when this specification uses
96 the terms "element" and "attribute" it is referring, respectively, to
97 the Element and Attribute Information Items in Infoset terms.
99 This specification uses the terms "atomUri" and
100 "atomCommonAttributes" from the non-normative RELAX NG Compact schema
101 included in [RFC4287]. Where used, these serve the same purpose and
102 have the same meaning as their use in [RFC4287].
104 Atom allows the use of IRIs [RFC3987]. Every URI [RFC3986] is also
105 an IRI, so a URI may be used wherever below an IRI is named. There
106 are two special considerations: (1) when an IRI that is not also a
107 URI is given for dereferencing, it MUST be mapped to a URI using the
108 steps in Section 3.1 of [RFC3987] and (2) when an IRI is serving as
109 an identifier, it MUST NOT be so mapped.
111 Any element defined by this specification MAY have an xml:base
112 attribute [W3C.REC-xmlbase-20010627]. When xml:base is used, it
113 serves the function described in section 5.1.1 of [RFC3986],
114 establishing the base URI (or IRI) for resolving any relative
115 references found within the effective scope of the xml:base
116 attribute.
118 Any element defined by this specification MAY have an xml:lang
119 attribute, whose content indicates the natural language for the
120 element and its descendents. The language context is only
121 significant for elements and attributes declared to be "Language-
122 Sensitive". Requirements regarding the content and interpretation of
123 xml:lang are specified in XML 1.0 [W3C.REC-xml-20060816], Section
124 2.12.
126 3. The f:feature element
128 The f:feature element is used in an app:collection element to declare
129 the collection's support for a feature.
131 namespace f = "http://purl.org/atompub/features/1.0"
133 feature = element f:feature {
134 atomCommonAttributes,
135 attribute ref { atomUri },
136 attribute href { atomUri }?,
137 attribute label { text }?,
138 (anyElement)*
139 }
141 anyElement = element * - f:feature {
142 (attribute * { text }
143 | text
144 | anyElement)*
145 }
147 The ref attribute specifies a globally unique IRI identifying a
148 feature. The value of the ref attribute MUST be compared on a case-
149 sensitive, character-by-character basis. Relative references MUST
150 NOT be used. The IRI is used strictly for identification and cannot
151 be assumed to be dereferenceable.
153 An optional href attribute MAY be used to specify a dereferenceable
154 IRI of a human-readable description of the feature. Relative
155 references MAY be used.
157 The optional label attribute MAY be used to specify a human-readable
158 label for the feature. The value of the label attribute is Language-
159 Sensitive as defined by Section 2 of [RFC4287].
161 The f:feature element MAY contain a mix of text and any number of
162 child elements and attributes from any XML namespace, with the
163 exception of the f:feature element itself. Such markup is considered
164 to be metadata applicable to the feature identified. Software agents
165 MUST NOT stop processing or signal an error or change their behavior
166 as a result of encountering such markup.
168 An app:collection element MAY contain any number of f:feature
169 elements but MUST NOT contain more than one with the same ref
170 attribute value. The order in which f:feature elements appear within
171 the app:collection element is insignificant.
173 The presence of a f:feature element is an indication that the
174 collection supports the feature identified. The lack of a f:feature
175 element identifying a particular feature indicates that support for
176 that feature is unspecified. This does not mean that the feature is
177 not supported, only that the server has not explicitly declared
178 support. There are no means by which a server can indicate that a
179 given feature is unsupported.
181 3.1. Example
183 The following is an example of a collection using the f:feature
184 element to indicate its support for the app:draft element as defined
185 by [RFC5023].
187
191
192 My Workspace
193
194 My Atom Collection
195 application/atom+xml;type=entry
196
198
199
200
202 4. The "supportsDraft" Feature
204 The "supportsDraft" feature is used to indicate that a collection
205 supports the use of the app:draft control element as defined by
206 Section 13.1.1 of [RFC5023]. The IRI of the "supportsDraft" feature
207 is:
208 http://purl.org/atompub/features/1.0/supportsDraft
210 5. The "ignoresDraft" Feature
212 The "ignoresDraft" feature is used to indicate that a collection will
213 ignore the use of the app:draft control element as defined by Section
214 13.1.1 of [RFC5023]. The IRI of the "ignoresDraft" feature is:
215 http://purl.org/atompub/features/1.0/ignoresDraft
217 A server MUST NOT declare support for both the "supportsDraft" and
218 "ignoresDraft" features within the a single app:collection element.
220 6. Security Considerations
222 Specific features supported by a collection may introduce security
223 considerations and concerns beyond those discussed by the Atom
224 Publishing Protocol and Atom Syndication Format specifications.
225 Implementors must refer to the specifications and description of each
226 feature to determine the security considerations relevant to each.
228 7. IANA Considerations
230 This specification does not define any actions for IANA.
232 8. Normative References
234 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
235 Requirement Levels", BCP 14, RFC 2119, March 1997.
237 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
238 Resource Identifier (URI): Generic Syntax", STD 66,
239 RFC 3986, January 2005.
241 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
242 Identifiers (IRIs)", RFC 3987, January 2005.
244 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
245 Syndication Format", RFC 4287, December 2005.
247 [RFC5023] Gregorio, J. and B. de hOra, "The Atom Publishing
248 Protocol", RFC 5023, October 2007.
250 [W3C.REC-xml-20060816]
251 Bray, T., Paoli, J., Yergeau, F., Sperberg-McQueen, C.,
252 and E. Maler, "Extensible Markup Language (XML) 1.0
253 (Fourth Edition)", World Wide Web Consortium
254 Recommendation REC-xml-20060816, August 2006,
255 .
257 [W3C.REC-xml-infoset-20040204]
258 Tobin, R. and J. Cowan, "XML Information Set (Second
259 Edition)", World Wide Web Consortium Recommendation REC-
260 xml-infoset-20040204, February 2004,
261 .
263 [W3C.REC-xml-names-20060816]
264 Hollander, D., Tobin, R., Bray, T., and A. Layman,
265 "Namespaces in XML 1.0 (Second Edition)", World Wide Web
266 Consortium Recommendation REC-xml-names-20060816,
267 August 2006,
268 .
270 [W3C.REC-xmlbase-20010627]
271 Marsh, J., "XML Base", World Wide Web Consortium
272 Recommendation REC-xmlbase-20010627, June 2001,
273 .
275 Appendix A. Acknowledgements
277 The author acknowledges the feedback from the other members of the
278 IETF Atom Publishing working group during the development of this
279 specification.
281 Author's Address
283 James M Snell
285 Phone:
286 Email: jasnell@gmail.com
287 URI: http://snellspace.com
289 Full Copyright Statement
291 Copyright (C) The IETF Trust (2007).
293 This document is subject to the rights, licenses and restrictions
294 contained in BCP 78, and except as set forth therein, the authors
295 retain all their rights.
297 This document and the information contained herein are provided on an
298 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
299 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
300 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
301 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
302 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
303 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
305 Intellectual Property
307 The IETF takes no position regarding the validity or scope of any
308 Intellectual Property Rights or other rights that might be claimed to
309 pertain to the implementation or use of the technology described in
310 this document or the extent to which any license under such rights
311 might or might not be available; nor does it represent that it has
312 made any independent effort to identify any such rights. Information
313 on the procedures with respect to rights in RFC documents can be
314 found in BCP 78 and BCP 79.
316 Copies of IPR disclosures made to the IETF Secretariat and any
317 assurances of licenses to be made available, or the result of an
318 attempt made to obtain a general license or permission for the use of
319 such proprietary rights by implementers or users of this
320 specification can be obtained from the IETF on-line IPR repository at
321 http://www.ietf.org/ipr.
323 The IETF invites any interested party to bring to its attention any
324 copyrights, patents or patent applications, or other proprietary
325 rights that may cover technology that may be required to implement
326 this standard. Please address the information to the IETF at
327 ietf-ipr@ietf.org.
329 Acknowledgment
331 Funding for the RFC Editor function is provided by the IETF
332 Administrative Support Activity (IASA).