Network Working Group R. Earhart
Internet Draft: ACAP-TYPE-EXT Carnegie Mellon
Document: draft-ietf-acap-type-ext-00.txt April 1997
Expire in six months
ACAP TYPE Extension
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months.
and may be updated, replaced, or obsoleted by other documents at any
time. It is not appropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
This document suggests a proposed protocol for the Internet community,
and requests discussion and suggestions for improvements.
Distribution of this draft is unlimited.
The protocol discussed in this document is experimental and subject to
change. Persons planning on either implementing or using this
protocol are STRONGLY URGED to get in touch with the author before
embarking on such a project.
1. Abstract
The Application Configuration Access Protocol [ACAP] defines rough
typing information in the form of an attribute naming convention.
This extension to ACAP allows a MIME content-type/subtype with
parameters to be associated with a given piece of data, providing
knowledgeable clients with useful information in a way which maintains
compatability with innocent clients and servers.
2. Conventions Used in this Document
Earhart [Page 1]
Internet DRAFT ACAP TYPE Extension April 23, 1997
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
3. Specification
The TYPE extension may be used with any ACAP server which returns
"TYPE" as one of the supported capabilities in the initial untagged
ACAP response.
Servers that support the TYPE extension define a new item of metadata
on attributes, called "type". This metadata is Read-Write, is
protected by the same ACL that protects the rest of the attribute, and
contains the MIME content-type/subtype of the "value" metadata
associated with the attribute, along with any associated parameters.
The content-type of all data stored in attributes whose name does not
end in ".bin" MUST be "text", and the charset parameter (if specified)
MUST be "utf8" or a subset of utf8.
Changing the "type" metadata of an attribute in an entry MUST also
update the entry's "modtime" attribute.
"text/plain" is a valid type, and means exactly what it does in MIME
-- "text/plain; charset=us-ascii"; utf8 is only implied on attributes
that do not end in ".bin" in the absence of the type extension (when
no type is available, and the client must assume that any
syntactically valid utf8 value may be present).
3.1. Client Issues
A client MAY request the "type" metadata from any server which
supports the TYPE extension. This SHOULD NOT be taken as
authoritative; the associated "value" metadata might not in fact be
syntactically legal for the given type. Nevertheless, the type MAY be
used as a hint to indicate how the data should be treated or
displayed.
A client MAY STORE into the "type" metadata of an attribute to
indicate the type of the associated "value" metadata. The type stored
MUST be a legal MIME type, the "value" metadata MUST be a legal value
for that type.
Earhart [Page 2]
Internet DRAFT ACAP TYPE Extension April 23, 1997
If a server does not implement the TYPE extension, clients MAY assume
that the type of the value associated with a given attribute is
"text/plain; charset=utf8" if the attribute name does not end with
".bin"; otherwise, a client MAY assume that the type is
"application/octet-stream".
3.2. Server Issues
Servers recieving a STORE command for a "type" metadata MUST ensure
that the type is a legally formatted MIME type; if it is not, servers
MUST return a tagged BAD response.
Servers MUST also ensure that the content-type stored for an attribute
whose name does not end with ".bin" is "text", and that the charset
parameter is either not specified or specified as "utf8"; if either of
these conditions is not met, the server MUST return a tagged BAD
response.
Servers MAY parse the "value" metadata and ensure that it conforms to
the specified type; if it does not, servers SHOULD return a tagged NO
response.
Servers MUST NOT reject STOREs to "type" metadata merely because they
lack knowledge of the specified type.
If a server recieves a request to STORE into the "value" metadata of
an attribute without an accompanying value for the "type" metadata,
the server MUST behave as though the "type" metadata were being set to
"text/plain; charset=utf8" if the attribute name does not end with
".bin"; otherwise, the server MUST behave as though the type were
being set to "application/octet-stream".
Note that this implies that the server MUST NOT reject a STORE into a
value that would be a legal store if this extension were not in place
-- a STORE without a supplied type MUST cause the type to change to
the most general type available given the restrictions imposed by the
base protocol on the types of data that a given attribute may assume.
Storing a NIL into a "type" metadata MUST be treated as storing
"text/plain; charset=utf8" if the attribute does not end in ".bin", or
"application/octet-stream" if it does.
The server MAY change the charset specified in a "type" metadata
element to a more specific charset, as specified by [MIME-IMB]. For
instance, when the value consists solely of us-ascii characters, the
server MAY report the charset as being us-ascii (or just omit the
charset parameter altogether, as us-ascii is the default charset for
Earhart [Page 3]
Internet DRAFT ACAP TYPE Extension April 23, 1997
the "text/plain" type), instead of the more general utf8.
4. Examples
Example: C: A001 Store ("/user/rob/people/kelly"
"people.name" "Joe"
"people.description" "richtext"
"people.description" ("type") "text/richtext"
"people.icon.bin" {1024+}
"people.icon.bin" ("type") "image/png")
S: A001 OK "Store completed"
(where stands for the 1024 bytes of data that
make up the image/png object being stored).
5. Formal Syntax
The following syntax specification uses the same notation as is used
in [ACAP]. It describes the format of the data that may be stored as
"type" metadata.
metadata-type ::= type "/" subtype *(";" SPACE parameter)
;; type, subtype, and parameter as defined in [MIME-IMB]
;; free insertion of linear-white-space is not permitted.
6. References
[RFC 2119] Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119.
[ACAP] Myers, J., and Newman, C., "Application Configuration Access
Protocol (ACAP)", Work in Progress of the IETF ACAP WG, draft-ietf-
acap-spec-??.txt. Check Internet Drafts listing for latest version.
[MIME-IMB] Freed, N., and Borenstein, N., "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies", RFC
2045.
[UTF-8] Yergeau, F., "UTF-8, a transformation format of Unicode and
ISO 10646", RFC 2044.
7. Security Considerations
Clients SHOULD NOT automatically launch potentially unsafe helper
Earhart [Page 4]
Internet DRAFT ACAP TYPE Extension April 23, 1997
applications to view data.
8. Author's Address
Robert H. Earhart
Carnegie Mellon
5000 Forbes Ave.
Pittsburgh PA, 15213-3890
Email: earhart+@cmu.edu
Earhart [Page 5]