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