idnits 2.17.1
draft-ietf-acap-type-ext-00.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):
----------------------------------------------------------------------------
** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in
this document.
Expected boilerplate is as follows today (2024-04-26) according to
https://trustee.ietf.org/license-info :
IETF Trust Legal Provisions of 28-dec-2009, Section 6.a:
This Internet-Draft is submitted in full conformance with the provisions
of BCP 78 and BCP 79.
IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2:
Copyright (c) 2024 IETF Trust and the persons identified as the document
authors. All rights reserved.
IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3:
This document is subject to BCP 78 and the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the Simplified BSD License.
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 abstract seems to contain references ([ACAP]), which it shouldn't.
Please replace those with straight textual mentions of the documents in
question.
** The document seems to lack a both a reference to RFC 2119 and the
recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
keywords -- however, there's a paragraph with a matching beginning.
Boilerplate error?
RFC 2119 keyword, line 68: '... end in ".bin" MUST be "text", and th...'
RFC 2119 keyword, line 69: '... MUST be "utf8" or a subset of utf8....'
RFC 2119 keyword, line 71: '... of an attribute in an entry MUST also...'
RFC 2119 keyword, line 82: '... A client MAY request the "type" meta...'
RFC 2119 keyword, line 83: '...extension. This SHOULD NOT be taken a...'
(20 more instances...)
Miscellaneous warnings:
----------------------------------------------------------------------------
-- 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 (April 1997) is 9873 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)
-- Missing reference section? 'ACAP' on line 176 looks like a reference
-- Missing reference section? 'MIME-IMB' on line 180 looks like a reference
-- Missing reference section? 'RFC 2119' on line 173 looks like a reference
-- Missing reference section? 'UTF-8' on line 184 looks like a reference
Summary: 11 errors (**), 0 flaws (~~), 1 warning (==), 6 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-00.txt April 1997
5 Expire in six months
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 months.
17 and may be updated, replaced, or obsoleted by other documents at any
18 time. It is not appropriate to use Internet-Drafts as reference
19 material or to cite them other than as "work in progress".
21 To learn the current status of any Internet-Draft, please check the
22 1id-abstracts.txt listing contained in the Internet-Drafts Shadow
23 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
25 ftp.isi.edu (US West Coast).
27 This document suggests a proposed protocol for the Internet community,
28 and requests discussion and suggestions for improvements.
29 Distribution of this draft is unlimited.
31 The protocol discussed in this document is experimental and subject to
32 change. Persons planning on either implementing or using this
33 protocol are STRONGLY URGED to get in touch with the author before
34 embarking on such a project.
36 1. Abstract
38 The Application Configuration Access Protocol [ACAP] defines rough
39 typing information in the form of an attribute naming convention.
40 This extension to ACAP allows a MIME content-type/subtype with
41 parameters to be associated with a given piece of data, providing
42 knowledgeable clients with useful information in a way which maintains
43 compatability with innocent clients and servers.
45 2. Conventions Used in this Document
46 Internet DRAFT ACAP TYPE Extension April 23, 1997
48 In examples, "C:" and "S:" indicate lines sent by the client and
49 server respectively.
51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT",
52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
53 document are to be interpreted as described in RFC 2119.
55 3. Specification
57 The TYPE extension may be used with any ACAP server which returns
58 "TYPE" as one of the supported capabilities in the initial untagged
59 ACAP response.
61 Servers that support the TYPE extension define a new item of metadata
62 on attributes, called "type". This metadata is Read-Write, is
63 protected by the same ACL that protects the rest of the attribute, and
64 contains the MIME content-type/subtype of the "value" metadata
65 associated with the attribute, along with any associated parameters.
67 The content-type of all data stored in attributes whose name does not
68 end in ".bin" MUST be "text", and the charset parameter (if specified)
69 MUST be "utf8" or a subset of utf8.
71 Changing the "type" metadata of an attribute in an entry MUST also
72 update the entry's "modtime" attribute.
74 "text/plain" is a valid type, and means exactly what it does in MIME
75 -- "text/plain; charset=us-ascii"; utf8 is only implied on attributes
76 that do not end in ".bin" in the absence of the type extension (when
77 no type is available, and the client must assume that any
78 syntactically valid utf8 value may be present).
80 3.1. Client Issues
82 A client MAY request the "type" metadata from any server which
83 supports the TYPE extension. This SHOULD NOT be taken as
84 authoritative; the associated "value" metadata might not in fact be
85 syntactically legal for the given type. Nevertheless, the type MAY be
86 used as a hint to indicate how the data should be treated or
87 displayed.
89 A client MAY STORE into the "type" metadata of an attribute to
90 indicate the type of the associated "value" metadata. The type stored
91 MUST be a legal MIME type, the "value" metadata MUST be a legal value
92 for that type.
94 Internet DRAFT ACAP TYPE Extension April 23, 1997
96 If a server does not implement the TYPE extension, clients MAY assume
97 that the type of the value associated with a given attribute is
98 "text/plain; charset=utf8" if the attribute name does not end with
99 ".bin"; otherwise, a client MAY assume that the type is
100 "application/octet-stream".
102 3.2. Server Issues
104 Servers recieving a STORE command for a "type" metadata MUST ensure
105 that the type is a legally formatted MIME type; if it is not, servers
106 MUST return a tagged BAD response.
108 Servers MUST also ensure that the content-type stored for an attribute
109 whose name does not end with ".bin" is "text", and that the charset
110 parameter is either not specified or specified as "utf8"; if either of
111 these conditions is not met, the server MUST return a tagged BAD
112 response.
114 Servers MAY parse the "value" metadata and ensure that it conforms to
115 the specified type; if it does not, servers SHOULD return a tagged NO
116 response.
118 Servers MUST NOT reject STOREs to "type" metadata merely because they
119 lack knowledge of the specified type.
121 If a server recieves a request to STORE into the "value" metadata of
122 an attribute without an accompanying value for the "type" metadata,
123 the server MUST behave as though the "type" metadata were being set to
124 "text/plain; charset=utf8" if the attribute name does not end with
125 ".bin"; otherwise, the server MUST behave as though the type were
126 being set to "application/octet-stream".
128 Note that this implies that the server MUST NOT reject a STORE into a
129 value that would be a legal store if this extension were not in place
130 -- a STORE without a supplied type MUST cause the type to change to
131 the most general type available given the restrictions imposed by the
132 base protocol on the types of data that a given attribute may assume.
134 Storing a NIL into a "type" metadata MUST be treated as storing
135 "text/plain; charset=utf8" if the attribute does not end in ".bin", or
136 "application/octet-stream" if it does.
138 The server MAY change the charset specified in a "type" metadata
139 element to a more specific charset, as specified by [MIME-IMB]. For
140 instance, when the value consists solely of us-ascii characters, the
141 server MAY report the charset as being us-ascii (or just omit the
142 charset parameter altogether, as us-ascii is the default charset for
144 Internet DRAFT ACAP TYPE Extension April 23, 1997
146 the "text/plain" type), instead of the more general utf8.
148 4. Examples
150 Example: C: A001 Store ("/user/rob/people/kelly"
151 "people.name" "Joe"
152 "people.description" "richtext"
153 "people.description" ("type") "text/richtext"
154 "people.icon.bin" {1024+}
155 "people.icon.bin" ("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 5. Formal Syntax
163 The following syntax specification uses the same notation as is used
164 in [ACAP]. It describes the format of the data that may be stored as
165 "type" metadata.
167 metadata-type ::= type "/" subtype *(";" SPACE parameter)
168 ;; type, subtype, and parameter as defined in [MIME-IMB]
169 ;; free insertion of linear-white-space is not permitted.
171 6. References
173 [RFC 2119] Bradner, "Key words for use in RFCs to Indicate Requirement
174 Levels", RFC 2119.
176 [ACAP] Myers, J., and Newman, C., "Application Configuration Access
177 Protocol (ACAP)", Work in Progress of the IETF ACAP WG, draft-ietf-
178 acap-spec-??.txt. Check Internet Drafts listing for latest version.
180 [MIME-IMB] Freed, N., and Borenstein, N., "Multipurpose Internet Mail
181 Extensions (MIME) Part One: Format of Internet Message Bodies", RFC
182 2045.
184 [UTF-8] Yergeau, F., "UTF-8, a transformation format of Unicode and
185 ISO 10646", RFC 2044.
187 7. Security Considerations
189 Clients SHOULD NOT automatically launch potentially unsafe helper
191 Internet DRAFT ACAP TYPE Extension April 23, 1997
193 applications to view data.
195 8. Author's Address
197 Robert H. Earhart
198 Carnegie Mellon
199 5000 Forbes Ave.
200 Pittsburgh PA, 15213-3890
202 Email: earhart+@cmu.edu