idnits 2.17.1
draft-snell-atompub-feature-10.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 307.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 318.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 325.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 331.
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 (September 16, 2007) is 6068 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 September 16, 2007
4 Intended status: Experimental
5 Expires: March 19, 2008
7 Atom Publishing Protocol Feature Discovery
8 draft-snell-atompub-feature-10.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 March 19, 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 [I-D.ietf-atompub-protocol] format that
65 allows for the documentation and discovery of behaviors, functions or
66 capabilities supported by an Atompub collection. Examples of such
67 capabilities can include the preservation of certain kinds of
68 content, support for draft entries, support for the scheduled
69 publication of entries, use of a particular set of Atom format
70 extensions, and so on.
72 Describing features using the mechanisms defined in this
73 specification is currently considered to be largely experimental.
74 While there are examples of such mechanisms being put to practical
75 use in deployed applications, there is currently not enough
76 collective implementation experience to determine whether the
77 mechanism defined here is sufficient to fully address the general
78 needs of Atom Publishing Protocol client and server implementations.
79 Implementations and feedback are encouraged.
81 2. Notational Conventions
83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
85 document are to be interpreted as described in BCP 14, [RFC2119].
87 This specification uses XML Namespaces [W3C.REC-xml-names-20060816]
88 to uniquely identify XML element names. It uses the following
89 namespace prefix for the indicated namespace URI;
91 "f": "http://purl.org/atompub/features/1.0"
93 This specification uses terms from the XML Infoset
94 [W3C.REC-xml-infoset-20040204]. However, this specification uses a
95 shorthand; the phrase "Information Item" is omitted when naming
96 Element Information Items. Therefore, when this specification uses
97 the terms "element" and "attribute" it is referring, respectively, to
98 the Element and Attribute Information Items in Infoset terms.
100 This specification uses the terms "atomUri" and
101 "atomCommonAttributes" from the non-normative RELAX NG Compact schema
102 included in [RFC4287]. Where used, these serve the same purpose and
103 have the same meaning as their use in [RFC4287].
105 Atom allows the use of IRIs [RFC3987]. Every URI [RFC3986] is also
106 an IRI, so a URI may be used wherever below an IRI is named. There
107 are two special considerations: (1) when an IRI that is not also a
108 URI is given for dereferencing, it MUST be mapped to a URI using the
109 steps in Section 3.1 of [RFC3987] and (2) when an IRI is serving as
110 an identifier, it MUST NOT be so mapped.
112 Any element defined by this specification MAY have an xml:base
113 attribute [W3C.REC-xmlbase-20010627]. When xml:base is used, it
114 serves the function described in section 5.1.1 of [RFC3986],
115 establishing the base URI (or IRI) for resolving any relative
116 references found within the effective scope of the xml:base
117 attribute.
119 Any element defined by this specification MAY have an xml:lang
120 attribute, whose content indicates the natural language for the
121 element and its descendents. The language context is only
122 significant for elements and attributes declared to be "Language-
123 Sensitive". Requirements regarding the content and interpretation of
124 xml:lang are specified in XML 1.0 [W3C.REC-xml-20060816], Section
125 2.12.
127 3. The f:feature element
129 The f:feature element is used in an app:collection element to declare
130 the collection's support for a feature.
132 namespace f = "http://purl.org/atompub/features/1.0"
134 feature = element f:feature {
135 atomCommonAttributes,
136 attribute ref { atomUri },
137 attribute href { atomUri }?,
138 attribute label { text }?,
139 (anyElement)*
140 }
142 anyElement = element * - f:feature {
143 (attribute * { text }
144 | text
145 | anyElement)*
146 }
148 The ref attribute specifies a globally unique IRI identifying a
149 feature. The value of the ref attribute MUST be compared on a case-
150 sensitive, character-by-character basis. Relative references MUST
151 NOT be used. The IRI is used strictly for identification and cannot
152 be assumed to be dereferenceable.
154 An optional href attribute MAY be used to specify a dereferenceable
155 IRI of a human-readable description of the feature. Relative
156 references MAY be used.
158 The optional label attribute MAY be used to specify a human-readable
159 label for the feature. The value of the label attribute is Language-
160 Sensitive as defined by Section 2 of [RFC4287].
162 The f:feature element MAY contain any number of child elements and
163 attributes from any XML namespace, with the exception of the
164 f:feature element itself. Such markup is considered to be metadata
165 applicable to the feature identified. Software agents MUST NOT stop
166 processing or signal an error or change their behavior as a result of
167 encountering such markup.
169 An app:collection element MAY contain any number of f:feature
170 elements but MUST NOT contain more than one with the same ref
171 attribute value. The order in which f:feature elements appear within
172 the app:collection element is insignificant.
174 The presence of a f:feature element is an indication that the
175 collection supports the feature identified. The lack of a f:feature
176 element identifying a particular feature indicates that support for
177 that feature is unspecified. This does not mean that the feature is
178 not supported, only that the server has not explicitly declared
179 support. There are no means by which a server can indicate that a
180 given feature is unsupported.
182 3.1. Example
184 The following is an example of a collection using the f:feature
185 element to indicate its support for the app:draft element as defined
186 by [I-D.ietf-atompub-protocol].
188
192
193 My Workspace
194
195 My Atom Collection
196 application/atom+xml;type=entry
197
199
200
201
203 4. The "supportsDraft" Feature
205 The "supportsDraft" feature is used to indicate that a collection
206 supports the use of the app:draft control element as defined by
207 Section 13.1.1 of [I-D.ietf-atompub-protocol]. The IRI of the
208 "supportsDraft" feature is:
209 http://purl.org/atompub/features/1.0/supportsDraft
211 5. The "ignoresDraft" Feature
213 The "ignoresDraft" feature is used to indicate that a collection will
214 ignore the use of the app:draft control element as defined by Section
215 13.1.1 of [I-D.ietf-atompub-protocol]. The IRI of the "ignoresDraft"
216 feature is:
217 http://purl.org/atompub/features/1.0/ignoresDraft
219 A server MUST NOT declare support for both the "supportsDraft" and
220 "ignoresDraft" features within the a single app:collection element.
222 6. Security Considerations
224 Specific features supported by a collection may introduce security
225 considerations and concerns beyond those discussed by the Atom
226 Publishing Protocol and Atom Syndication Format specifications.
227 Implementors must refer to the specifications and description of each
228 feature to determine the security considerations relevant to each.
230 7. IANA Considerations
232 This specification does not define any actions for IANA.
234 8. Normative References
236 [I-D.ietf-atompub-protocol]
237 Hora, B. and J. Gregorio, "The Atom Publishing Protocol",
238 draft-ietf-atompub-protocol-17 (work in progress),
239 July 2007.
241 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
242 Requirement Levels", BCP 14, RFC 2119, March 1997.
244 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
245 Resource Identifier (URI): Generic Syntax", STD 66,
246 RFC 3986, January 2005.
248 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
249 Identifiers (IRIs)", RFC 3987, January 2005.
251 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
252 Syndication Format", RFC 4287, December 2005.
254 [W3C.REC-xml-20060816]
255 Paoli, J., Maler, E., Yergeau, F., Bray, T., and C.
256 Sperberg-McQueen, "Extensible Markup Language (XML) 1.0
257 (Fourth Edition)", World Wide Web Consortium
258 Recommendation REC-xml-20060816, August 2006,
259 .
261 [W3C.REC-xml-infoset-20040204]
262 Tobin, R. and J. Cowan, "XML Information Set (Second
263 Edition)", World Wide Web Consortium Recommendation REC-
264 xml-infoset-20040204, February 2004,
265 .
267 [W3C.REC-xml-names-20060816]
268 Hollander, D., Tobin, R., Bray, T., and A. Layman,
269 "Namespaces in XML 1.0 (Second Edition)", World Wide Web
270 Consortium Recommendation REC-xml-names-20060816,
271 August 2006,
272 .
274 [W3C.REC-xmlbase-20010627]
275 Marsh, J., "XML Base", World Wide Web Consortium
276 Recommendation REC-xmlbase-20010627, June 2001,
277 .
279 Appendix A. Acknowledgements
281 The author acknowledges the feedback from the other members of the
282 IETF Atom Publishing working group during the development of this
283 specification.
285 Author's Address
287 James M Snell
289 Phone:
290 Email: jasnell@gmail.com
291 URI: http://snellspace.com
293 Full Copyright Statement
295 Copyright (C) The IETF Trust (2007).
297 This document is subject to the rights, licenses and restrictions
298 contained in BCP 78, and except as set forth therein, the authors
299 retain all their rights.
301 This document and the information contained herein are provided on an
302 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
303 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
304 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
305 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
306 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
307 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
309 Intellectual Property
311 The IETF takes no position regarding the validity or scope of any
312 Intellectual Property Rights or other rights that might be claimed to
313 pertain to the implementation or use of the technology described in
314 this document or the extent to which any license under such rights
315 might or might not be available; nor does it represent that it has
316 made any independent effort to identify any such rights. Information
317 on the procedures with respect to rights in RFC documents can be
318 found in BCP 78 and BCP 79.
320 Copies of IPR disclosures made to the IETF Secretariat and any
321 assurances of licenses to be made available, or the result of an
322 attempt made to obtain a general license or permission for the use of
323 such proprietary rights by implementers or users of this
324 specification can be obtained from the IETF on-line IPR repository at
325 http://www.ietf.org/ipr.
327 The IETF invites any interested party to bring to its attention any
328 copyrights, patents or patent applications, or other proprietary
329 rights that may cover technology that may be required to implement
330 this standard. Please address the information to the IETF at
331 ietf-ipr@ietf.org.
333 Acknowledgment
335 Funding for the RFC Editor function is provided by the IETF
336 Administrative Support Activity (IASA).