home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_a_c / draft-ietf-acap-type-ext-00.txt < prev    next >
Text File  |  1997-04-23  |  9KB  |  283 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6. Network Working Group                                         R. Earhart
  7. Internet Draft: ACAP-TYPE-EXT                            Carnegie Mellon
  8. Document: draft-ietf-acap-type-ext-00.txt                     April 1997
  9. Expire in six months
  10.  
  11.  
  12.                           ACAP TYPE Extension
  13.  
  14. Status of this Memo
  15.  
  16.   This document is an Internet-Draft.  Internet-Drafts are working
  17.   documents of the Internet Engineering Task Force (IETF), its areas,
  18.   and its working groups.  Note that other groups may also distribute
  19.   working documents as Internet-Drafts.
  20.  
  21.   Internet-Drafts are draft documents valid for a maximum of six months.
  22.   and may be updated, replaced, or obsoleted by other documents at any
  23.   time.  It is not appropriate to use Internet-Drafts as reference
  24.   material or to cite them other than as "work in progress".
  25.  
  26.   To learn the current status of any Internet-Draft, please check the
  27.   1id-abstracts.txt listing contained in the Internet-Drafts Shadow
  28.   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
  29.   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  30.   ftp.isi.edu (US West Coast).
  31.  
  32.   This document suggests a proposed protocol for the Internet community,
  33.   and requests discussion and suggestions for improvements.
  34.   Distribution of this draft is unlimited.
  35.  
  36.   The protocol discussed in this document is experimental and subject to
  37.   change.  Persons planning on either implementing or using this
  38.   protocol are STRONGLY URGED to get in touch with the author before
  39.   embarking on such a project.
  40.  
  41.  
  42. 1.   Abstract
  43.  
  44.   The Application Configuration Access Protocol [ACAP] defines rough
  45.   typing information in the form of an attribute naming convention.
  46.   This extension to ACAP allows a MIME content-type/subtype with
  47.   parameters to be associated with a given piece of data, providing
  48.   knowledgeable clients with useful information in a way which maintains
  49.   compatability with innocent clients and servers.
  50.  
  51.  
  52. 2.   Conventions Used in this Document
  53.  
  54.  
  55.  
  56.  
  57. Earhart                                                         [Page 1]
  58.  
  59. Internet DRAFT            ACAP TYPE Extension             April 23, 1997
  60.  
  61.  
  62.   In examples, "C:" and "S:" indicate lines sent by the client and
  63.   server respectively.
  64.  
  65.   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT",
  66.   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  67.   document are to be interpreted as described in RFC 2119.
  68.  
  69.  
  70. 3.   Specification
  71.  
  72.   The TYPE extension may be used with any ACAP server which returns
  73.   "TYPE" as one of the supported capabilities in the initial untagged
  74.   ACAP response.
  75.  
  76.   Servers that support the TYPE extension define a new item of metadata
  77.   on attributes, called "type".  This metadata is Read-Write, is
  78.   protected by the same ACL that protects the rest of the attribute, and
  79.   contains the MIME content-type/subtype of the "value" metadata
  80.   associated with the attribute, along with any associated parameters.
  81.  
  82.   The content-type of all data stored in attributes whose name does not
  83.   end in ".bin" MUST be "text", and the charset parameter (if specified)
  84.   MUST be "utf8" or a subset of utf8.
  85.  
  86.   Changing the "type" metadata of an attribute in an entry MUST also
  87.   update the entry's "modtime" attribute.
  88.  
  89.   "text/plain" is a valid type, and means exactly what it does in MIME
  90.   -- "text/plain; charset=us-ascii"; utf8 is only implied on attributes
  91.   that do not end in ".bin" in the absence of the type extension (when
  92.   no type is available, and the client must assume that any
  93.   syntactically valid utf8 value may be present).
  94.  
  95.  
  96. 3.1. Client Issues
  97.  
  98.   A client MAY request the "type" metadata from any server which
  99.   supports the TYPE extension.  This SHOULD NOT be taken as
  100.   authoritative; the associated "value" metadata might not in fact be
  101.   syntactically legal for the given type.  Nevertheless, the type MAY be
  102.   used as a hint to indicate how the data should be treated or
  103.   displayed.
  104.  
  105.   A client MAY STORE into the "type" metadata of an attribute to
  106.   indicate the type of the associated "value" metadata.  The type stored
  107.   MUST be a legal MIME type, the "value" metadata MUST be a legal value
  108.   for that type.
  109.  
  110.  
  111.  
  112.  
  113. Earhart                                                         [Page 2]
  114.  
  115. Internet DRAFT            ACAP TYPE Extension             April 23, 1997
  116.  
  117.  
  118.   If a server does not implement the TYPE extension, clients MAY assume
  119.   that the type of the value associated with a given attribute is
  120.   "text/plain; charset=utf8" if the attribute name does not end with
  121.   ".bin"; otherwise, a client MAY assume that the type is
  122.   "application/octet-stream".
  123.  
  124.  
  125. 3.2. Server Issues
  126.  
  127.   Servers recieving a STORE command for a "type" metadata MUST ensure
  128.   that the type is a legally formatted MIME type; if it is not, servers
  129.   MUST return a tagged BAD response.
  130.  
  131.   Servers MUST also ensure that the content-type stored for an attribute
  132.   whose name does not end with ".bin" is "text", and that the charset
  133.   parameter is either not specified or specified as "utf8"; if either of
  134.   these conditions is not met, the server MUST return a tagged BAD
  135.   response.
  136.  
  137.   Servers MAY parse the "value" metadata and ensure that it conforms to
  138.   the specified type; if it does not, servers SHOULD return a tagged NO
  139.   response.
  140.  
  141.   Servers MUST NOT reject STOREs to "type" metadata merely because they
  142.   lack knowledge of the specified type.
  143.  
  144.   If a server recieves a request to STORE into the "value" metadata of
  145.   an attribute without an accompanying value for the "type" metadata,
  146.   the server MUST behave as though the "type" metadata were being set to
  147.   "text/plain; charset=utf8" if the attribute name does not end with
  148.   ".bin"; otherwise, the server MUST behave as though the type were
  149.   being set to "application/octet-stream".
  150.  
  151.   Note that this implies that the server MUST NOT reject a STORE into a
  152.   value that would be a legal store if this extension were not in place
  153.   -- a STORE without a supplied type MUST cause the type to change to
  154.   the most general type available given the restrictions imposed by the
  155.   base protocol on the types of data that a given attribute may assume.
  156.  
  157.   Storing a NIL into a "type" metadata MUST be treated as storing
  158.   "text/plain; charset=utf8" if the attribute does not end in ".bin", or
  159.   "application/octet-stream" if it does.
  160.  
  161.   The server MAY change the charset specified in a "type" metadata
  162.   element to a more specific charset, as specified by [MIME-IMB].  For
  163.   instance, when the value consists solely of us-ascii characters, the
  164.   server MAY report the charset as being us-ascii (or just omit the
  165.   charset parameter altogether, as us-ascii is the default charset for
  166.  
  167.  
  168.  
  169. Earhart                                                         [Page 3]
  170.  
  171. Internet DRAFT            ACAP TYPE Extension             April 23, 1997
  172.  
  173.  
  174.   the "text/plain" type), instead of the more general utf8.
  175.  
  176.  
  177. 4.   Examples
  178.  
  179.   Example:  C: A001 Store ("/user/rob/people/kelly"
  180.                "people.name" "Joe"
  181.                "people.description" "<bold>richtext</bold>"
  182.                "people.description" ("type") "text/richtext"
  183.                "people.icon.bin" {1024+}
  184.                <icon data> "people.icon.bin" ("type") "image/png")
  185.             S: A001 OK "Store completed"
  186.  
  187.             (where <icon data> stands for the 1024 bytes of data that
  188.             make up the image/png object being stored).
  189.  
  190.  
  191. 5.   Formal Syntax
  192.  
  193.   The following syntax specification uses the same notation as is used
  194.   in [ACAP].  It describes the format of the data that may be stored as
  195.   "type" metadata.
  196.  
  197.   metadata-type ::=  type "/" subtype *(";" SPACE parameter)
  198.             ;; type, subtype, and parameter as defined in [MIME-IMB]
  199.             ;; free insertion of linear-white-space is not permitted.
  200.  
  201.  
  202. 6.   References
  203.  
  204.   [RFC 2119] Bradner, "Key words for use in RFCs to Indicate Requirement
  205.   Levels", RFC 2119.
  206.  
  207.   [ACAP] Myers, J., and Newman, C., "Application Configuration Access
  208.   Protocol (ACAP)", Work in Progress of the IETF ACAP WG, draft-ietf-
  209.   acap-spec-??.txt.  Check Internet Drafts listing for latest version.
  210.  
  211.   [MIME-IMB] Freed, N., and Borenstein, N., "Multipurpose Internet Mail
  212.   Extensions (MIME) Part One: Format of Internet Message Bodies", RFC
  213.   2045.
  214.  
  215.   [UTF-8] Yergeau, F., "UTF-8, a transformation format of Unicode and
  216.   ISO 10646", RFC 2044.
  217.  
  218.  
  219. 7.   Security Considerations
  220.  
  221.   Clients SHOULD NOT automatically launch potentially unsafe helper
  222.  
  223.  
  224.  
  225. Earhart                                                         [Page 4]
  226.  
  227. Internet DRAFT            ACAP TYPE Extension             April 23, 1997
  228.  
  229.  
  230.   applications to view data.
  231.  
  232.  
  233. 8.   Author's Address
  234.  
  235.   Robert H. Earhart
  236.   Carnegie Mellon
  237.   5000 Forbes Ave.
  238.   Pittsburgh PA, 15213-3890
  239.  
  240.   Email: earhart+@cmu.edu
  241.  
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281. Earhart                                                         [Page 5]
  282.  
  283.