idnits 2.17.1
draft-ietf-acap-type-ext-01.txt:
** The Abstract section seems to be numbered
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
** Missing expiration date. The document expiration date should appear on
the first and last page.
** The document seems to lack a 1id_guidelines paragraph about
Internet-Drafts being working documents.
** The document seems to lack a 1id_guidelines paragraph about 6 months
document validity -- however, there's a paragraph with a matching
beginning. Boilerplate error?
** The document seems to lack a 1id_guidelines paragraph about the list of
current Internet-Drafts.
** The document seems to lack a 1id_guidelines paragraph about the list of
Shadow Directories.
== 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 an Introduction section.
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
** The document seems to lack separate sections for Informative/Normative
References. All references will be assumed normative when checking for
downward references.
** The abstract seems to contain references ([ACAP]), which it shouldn't.
Please replace those with straight textual mentions of the documents in
question.
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 (September 1998) is 9354 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)
** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC
4234)
Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group R. Earhart
3 Internet Draft: ACAP-TYPE-EXT Carnegie Mellon
4 Document: draft-ietf-acap-type-ext-01.txt March 1998
5 Expires September 1998
7 ACAP TYPE Extension
9 Status of this Memo
11 This document is an Internet-Draft. Internet-Drafts are working
12 documents of the Internet Engineering Task Force (IETF), its areas,
13 and its working groups. Note that other groups may also distribute
14 working documents as Internet-Drafts.
16 Internet-Drafts are draft documents valid for a maximum of six
17 months. and may be updated, replaced, or obsoleted by other
18 documents at any time. It is not appropriate to use Internet-Drafts
19 as reference material or to cite them other than as "work in
20 progress".
22 To learn the current status of any Internet-Draft, please check the
23 1id-abstracts.txt listing contained in the Internet-Drafts Shadow
24 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
26 ftp.isi.edu (US West Coast).
28 This document suggests a proposed protocol for the Internet
29 community, and requests discussion and suggestions for improvements.
30 Distribution of this draft is unlimited.
32 The protocol discussed in this document is experimental and subject
33 to change. Persons planning on either implementing or using this
34 protocol are STRONGLY URGED to get in touch with the author before
35 embarking on such a project.
37 1. Abstract
39 The Application Configuration Access Protocol [ACAP] defines rough
40 typing information in the form of an attribute naming convention.
41 This extension to ACAP allows a MIME content-type/subtype with
42 parameters to be associated with a given piece of data, providing
43 knowledgeable clients with useful information in a way which
44 maintains compatability with innocent clients and servers.
46 2. Conventions Used in this Document
48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
50 document are to be interpreted as described in "Key words for use in
51 RFCs to Indicate Requirement Levels" [KEYWORDS].
53 3. Specification
55 The TYPE extension may be used with any ACAP server which returns
56 "TYPE" as one of the supported capabilities in the initial untagged
57 ACAP response.
59 Servers that support the TYPE extension define a new type of metadata
60 on attributes, called "type". This metadatum is Read-Write, is
61 protected by the same ACL which protects the rest of the attribute,
62 and contains the MIME content-type/subtype of the "value" metadata
63 associated with the attribute, along with any associated parameters.
65 The "type" metadatum for an attribute MUST only be stored if the
66 "value" metadata are being set as well, in the same STORE command
67 (this is to deal effectively with inheritance; for example, it would
68 be bad if the "type" could be set in an inheriting attribute for an
69 inherited value, when the inherited value could change at a later
70 date. The value and the type of the value need to be considered
71 together, as a single unit).
73 Note that, in the case of a multivalued attribute, all of the values
74 are described by a single "type" metadatum, and thus MUST have the
75 same MIME content-type.
77 3.1. Client Issues
79 A client MAY request the "type" metadatum from any server which
80 supports the TYPE extension. This MUST NOT be taken as
81 authoritative; the associated "value" metadata might not in fact be
82 syntactically legal for the given type. Nevertheless, the type MAY
83 be used as a hint to indicate how the data should be treated or
84 displayed.
86 When a client stores a single or multi-value into the "value"
87 metadata of an attribute, it MAY, in addition, store a value into the
88 "type" metadatum of the attribute to indicate the type of the
89 associated "value" metadata. The type stored MUST be a legal MIME
90 type, and the "value" metadata MUST be legal values for that type.
92 If the client stores a NIL to the "value" metadata, it MUST either
93 store a NIL to the "type" metadatum, or omit the type information
94 from the STORE.
96 If the client stores a DEFAULT to the "value" metadata, it MUST
97 either store a DEFAULT to the "type" metadatum, or omit the type
98 information from the STORE.
100 If a server does not implement the TYPE extension, clients MUST NOT
101 assume anything about the type of the value associated with a given
102 attribute, or attempt to STORE to the "type" metadatum.
104 3.2. Server Issues
106 Servers implementing this extension SHOULD announce it via the
107 initial ACAP greeting, with the capability "TYPE".
109 Servers recieving a STORE command for a "type" metadatum MUST ensure
110 that the type is a legally formatted MIME type; if it is not, servers
111 MUST return a tagged BAD response.
113 If a client performs a STORE to the "type" metadatum of an attribute,
114 without simultaneously storing into the "value" metadata, the server
115 MUST return a tagged BAD response.
117 Servers MAY parse the "value" metadata and ensure that they conform
118 to the specified type; if they do not, a server MAY issue a tagged NO
119 response.
121 Servers MUST NOT reject STOREs to "type" metadatum merely because
122 they lack knowledge of the specific type, as long as the type is
123 correctly formatted.
125 If a server recieves a request to STORE a non-NIL or DEFAULT into the
126 "value" metadata of an attribute without an accompanying value for
127 the "type" metadatum, the server MUST behave as though the "type"
128 metadatum were being set to "application/octet-stream".
130 Note that this implies that the server MUST NOT reject a STORE into a
131 value that would be a legal store if this extension were not in place
132 -- a STORE without a supplied type MUST cause the type to change to
133 the most general type available given the restrictions imposed by the
134 base protocol on the types of data that a given attribute may assume.
136 If a server recieves a request to STORE a NIL to an attribute's
137 "value" metadata, the "type" MUST revert to NIL as well. If the
138 client STOREs NIL to the "value metadata, and explicitly specifies a
139 non-NIL value for the "type" metadatum, the server MUST issue a
140 tagged BAD response.
142 If a server recieves a request to STORE a DEFAULT to an attribute's
143 "value" metadata, the "type" MUST revert to DEFAULT as well. If the
144 client STOREs DEFAULT to the "value" metadata, and explicitly
145 specifies a non-DEFAULT value for the "type" metadatum, the server
146 MUST issue a tagged BAD response.
148 3.3. Examples
150 Example: C: A001 Store ("/user/rob/people/kelly"
151 "people.name" "Joe Kelly"
152 "people.description" ("value" "richtext"
153 "type" "text/enriched")
154 "people.icon.bin" ("value" {1024+}
155 "type" "image/png")
156 S: A001 OK "Store completed"
158 (where stands for the 1024 bytes of data that
159 make up the image/png object being stored).
161 4. Formal Syntax
163 The following syntax specification uses the augmented Backus-Naur
164 Form (BNF) notation as specified in [ABNF]. This uses the ABNF core
165 rules as specified in Appendix A of the ABNF specification [ABNF].
167 Except as noted otherwise, all alphabetic characters are case-
168 insensitive. The use of upper or lower case characters to define
169 token strings is for editorial clarity only. Implementations MUST
170 accept these strings in a case-insensitive fashion.
172 "metadata-type" describes the format of the data which may be stored
173 as "type" metadatum.
175 metadata-type ::= type "/" subtype *(";" SPACE parameter)
176 ;; type, subtype, and parameter as defined in [MIME-IMB]
177 ;; free insertion of linear-white-space is not permitted.
179 5. Security Considerations
181 Clients SHOULD NOT automatically launch potentially unsafe helper
182 applications to view data.
184 6. Copyright
186 Copyright (C) The Internet Society 1998. All Rights Reserved.
188 This document and translations of it may be copied and furnished to
189 others, and derivative works that comment on or otherwise explain it
190 or assist in its implementation may be prepared, copied, published
191 and distributed, in whole or in part, without restriction of any
192 kind, provided that the above copyright notice and this paragraph are
193 included on all such copies and derivative works. However, this
194 document itself may not be modified in any way, such as by removing
195 the copyright notice or references to the Internet Society or other
196 Internet organizations, except as needed for the purpose of
197 developing Internet standards in which case the procedures for
198 copyrights defined in the Internet Standards process must be
199 followed, or as required to translate it into languages other than
200 English.
202 The limited permissions granted above are perpetual and will not be
203 revoked by the Internet Society or its successors or assigns.
205 This document and the information contained herein is provided on an
206 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
207 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
208 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
209 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
210 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
212 7. References
214 [ABNF] Crocker, D., and Overell, P., "Augmented BNF for Syntax
215 Specifications: ABNF", RFC 2234, November 1997.
217
219 [ACAP] Newman, C., and Myers, J., "Application Configuration Access
220 Protocol", RFC 2244, November 1997.
222
224 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
225 Requirement Levels", BCP 14, RFC 2119, March 1997.
227
229 [MIME-IMB] Freed, N., and Borenstein, N., "Multipurpose Internet Mail
230 Extensions (MIME) Part One: Format of Internet Message Bodies", RFC
231 2045, November 1996.
233
235 8. Author's Address
237 Robert H. Earhart
238 Carnegie Mellon
239 5000 Forbes Ave.
240 Pittsburgh PA, 15213-3890
242 Email: earhart+@cmu.edu
244 Expires September 1998