[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                         R. Earhart
Internet Draft: ACAP-TYPE-EXT                            Carnegie Mellon
Document: draft-ietf-acap-type-ext-01.txt                     March 1998
Expires September 1998


                          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.






Earhart                                                         [Page 1]


Internet DRAFT            ACAP TYPE Extension                 March 1998


2.   Conventions Used in this Document

   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 "Key words for use in
   RFCs to Indicate Requirement Levels" [KEYWORDS].


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 type of metadata
   on attributes, called "type".  This metadatum is Read-Write, is
   protected by the same ACL which 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 "type" metadatum for an attribute MUST only be stored if the
   "value" metadata are being set as well, in the same STORE command
   (this is to deal effectively with inheritance; for example, it would
   be bad if the "type" could be set in an inheriting attribute for an
   inherited value, when the inherited value could change at a later
   date.  The value and the type of the value need to be considered
   together, as a single unit).

   Note that, in the case of a multivalued attribute, all of the values
   are described by a single "type" metadatum, and thus MUST have the
   same MIME content-type.


3.1. Client Issues

   A client MAY request the "type" metadatum from any server which
   supports the TYPE extension.  This MUST 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.

   When a client stores a single or multi-value into the "value"
   metadata of an attribute, it MAY, in addition, store a value into the
   "type" metadatum of the attribute to indicate the type of the
   associated "value" metadata.  The type stored MUST be a legal MIME
   type, and the "value" metadata MUST be legal values for that type.




Earhart                                                         [Page 2]


Internet DRAFT            ACAP TYPE Extension                 March 1998


   If the client stores a NIL to the "value" metadata, it MUST either
   store a NIL to the "type" metadatum, or omit the type information
   from the STORE.

   If the client stores a DEFAULT to the "value" metadata, it MUST
   either store a DEFAULT to the "type" metadatum, or omit the type
   information from the STORE.

   If a server does not implement the TYPE extension, clients MUST NOT
   assume anything about the type of the value associated with a given
   attribute, or attempt to STORE to the "type" metadatum.


3.2. Server Issues

   Servers implementing this extension SHOULD announce it via the
   initial ACAP greeting, with the capability "TYPE".

   Servers recieving a STORE command for a "type" metadatum MUST ensure
   that the type is a legally formatted MIME type; if it is not, servers
   MUST return a tagged BAD response.

   If a client performs a STORE to the "type" metadatum of an attribute,
   without simultaneously storing into the "value" metadata, the server
   MUST return a tagged BAD response.

   Servers MAY parse the "value" metadata and ensure that they conform
   to the specified type; if they do not, a server MAY issue a tagged NO
   response.

   Servers MUST NOT reject STOREs to "type" metadatum merely because
   they lack knowledge of the specific type, as long as the type is
   correctly formatted.

   If a server recieves a request to STORE a non-NIL or DEFAULT into the
   "value" metadata of an attribute without an accompanying value for
   the "type" metadatum, the server MUST behave as though the "type"
   metadatum 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.







Earhart                                                         [Page 3]


Internet DRAFT            ACAP TYPE Extension                 March 1998


   If a server recieves a request to STORE a NIL to an attribute's
   "value" metadata, the "type" MUST revert to NIL as well.  If the
   client STOREs NIL to the "value metadata, and explicitly specifies a
   non-NIL value for the "type" metadatum, the server MUST issue a
   tagged BAD response.

   If a server recieves a request to STORE a DEFAULT to an attribute's
   "value" metadata, the "type" MUST revert to DEFAULT as well.  If the
   client STOREs DEFAULT to the "value" metadata, and explicitly
   specifies a non-DEFAULT value for the "type" metadatum, the server
   MUST issue a tagged BAD response.


3.3. Examples

   Example:  C: A001 Store ("/user/rob/people/kelly"
                "people.name" "Joe Kelly"
                "people.description" ("value" "<bold>richtext</bold>"
                                      "type" "text/enriched")
                "people.icon.bin" ("value" {1024+}
                                   <icon data> "type" "image/png")
             S: A001 OK "Store completed"

             (where <icon data> stands for the 1024 bytes of data that
             make up the image/png object being stored).


4.   Formal Syntax

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) notation as specified in [ABNF].  This uses the ABNF core
   rules as specified in Appendix A of the ABNF specification [ABNF].

   Except as noted otherwise, all alphabetic characters are case-
   insensitive.  The use of upper or lower case characters to define
   token strings is for editorial clarity only.  Implementations MUST
   accept these strings in a case-insensitive fashion.

   "metadata-type" describes the format of the data which may be stored
   as "type" metadatum.

   metadata-type ::=  type "/" subtype *(";" SPACE parameter)
             ;; type, subtype, and parameter as defined in [MIME-IMB]
             ;; free insertion of linear-white-space is not permitted.







Earhart                                                         [Page 4]


Internet DRAFT            ACAP TYPE Extension                 March 1998


5.   Security Considerations

   Clients SHOULD NOT automatically launch potentially unsafe helper
   applications to view data.


6.   Copyright

   Copyright (C) The Internet Society 1998. All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


7.   References

   [ABNF] Crocker, D., and Overell, P., "Augmented BNF for Syntax
   Specifications: ABNF", RFC 2234, November 1997.

      <url:ftp://ds.internic.net/rfc/rfc2234.txt>










Earhart                                                         [Page 5]


Internet DRAFT            ACAP TYPE Extension                 March 1998


   [ACAP] Newman, C., and Myers, J., "Application Configuration Access
   Protocol", RFC 2244, November 1997.

      <url:ftp://ds.internic.net/rfc/rfc2244.txt>

   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997.

      <url:ftp://ds.internic.net/rfc/rfc2119.txt>

   [MIME-IMB] Freed, N., and Borenstein, N., "Multipurpose Internet Mail
   Extensions (MIME) Part One: Format of Internet Message Bodies", RFC
   2045, November 1996.

      <url:ftp://ds.internic.net/rfc/rfc2045.txt>


8.   Author's Address

   Robert H. Earhart
   Carnegie Mellon
   5000 Forbes Ave.
   Pittsburgh PA, 15213-3890

   Email: earhart+@cmu.edu


Expires September 1998























Earhart                                                         [Page 6]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/