Network Working Group Gregory M. Vaudreuil Internet Draft Tigon Corporation Expires 4/18/94 October 18th, 1993 Application/Signature 1.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 valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as a "work in progress". 2.Abstract The memo defines a MIME content type for the exchange of sender contact information and user agent capability information beyond what is feasable in the RFC822 header. This exchange is generally accomplished by use of a signature trailer appended to the message. These signatures commonly contain address, phone, and email addressing. This document outlines a formalization and extension of the signature concept to provide a machine readable, internationally friendly form to exchange this information. 3.Introduction Mechanisms for the exchange of contact information are lacking in the general internet. Directory services are not ubiquitous and it is not clear how to search for a given person even when they are available. The exchange of business cards provides a mechanism for identifying a specific person when you meet them. The application/signature body part provides a similar mechanism, to deliver contact information to a person you "meet" over electronic mail. The information to be exchanged between people over electronic mail is also growing. As Privacy Enhanced Mail grows in popularity, accessory information such as public keys becomes more essential to exchange with those who you normally contact. As Internet mail becomes multi- media, the exchange of information, such as a small portrait or short audio greeting become as useful as the RFC822 text name for identifying the sender. As the number of content-types, languages, and character sets increase, it becomes more essential to identify the capabilities of the destination mail agents without having to wait for error reports and letters of complaint. The Application/Signature body part Internet Draft Application/Signature Expires 4/10/93 provides a mechanism for sending a list of MIME content-types, the character sets supported, and the languages spoken by the mailbox owner. By saving and caching the information provided in the application/signature body part, a database of destinations frequently contacted can be populated and updated. This database can be used for providing basic, local alias directory services and can be used by mailers to notify the sender before sending the message if it is supported by the receiver. Automated update of the database requires loosely standardized attribute/value pair definitions. These elements are based on the MIME content-type/sub-type registry. Each attribute registration includes all information needed to unambiguously identify the content- type, parameters such as character set, and transport encoding. This specification does not explicitly include a universal database key value. X.500 distinguished names and email addresses may provide a suitable mechanism for correlating updates and providing lookup functions. 4.Definition of the Application/Signature Body Part Mime type name: Application Mime Sub-Type name: Signature Required Parameters: None Optional Parameters: None Encoding Considerations: 7 bit is always sufficient. The application/signature body part should be included as the last body part in a top-level Multipart/Mixed construct. The Application/Signature body part is a sequence of attribute/value pairs formatted according to the rules of RFC 822 header lines. As in RFC822 headers, lines may be wrapped and continued on subsequent lines by indenting with linear white space. Comments are optional and are not considered part of the value if included. All lines must be in 7bit US ASCII format. Non US ASCII textual data can be represented using the RFC 1522 encoded word. Non-text data must be encoded using base-64 or quoted printable, with the specific encoding specified in the attribute definition. The list of allowable attributes is maintained by the IANA. Except for Text/Plain, registered values must correspond to exactly one previously registered MIME content-subtype and must include constant values for all necessary parameters and specify the transport encoding if needed. Use of X- for experimental and bi-laterally defined (Private) values is permitted. The attribute "Capabilities" is provided to identify the MIME content- types supported by the destination. The list of attributes should Vaudreuil [Page 2] Internet Draft Application/Signature Expires 4/10/93 include any IANA registered content-type. To reduce the amount of data transferred, the list of capabilities should not include the basic MIME constructor types. These types are Message/RFC822, Message/Partial, Multipart/Mixed, Multipart/Parallel, Multipart/Alternative, and Application/Octet-Stream. Text/Plain if supported should be explicitly identified as some mixed media agents may not support text output. The attribute "Charsets" is provided to identify the character sets accepted for use in Text/* bodyparts. The list of character sets can include any IANA registered character set. US-ASCII does not need to be identified as it the default character set. The character sets should be listed in the order of preference. The attribute "Languages" is provided to communicate the languages understood by the mailbox owner. As communication becomes increasing global, a list of languages will allow the sender to choose an appropriate language without guessing. The set of language identifier can include any registered in XXXXX(need reference). The languages should be listed in the order of preference. Vaudreuil [Page 3] Internet Draft Application/Signature Expires 4/10/93 Initially Defined Application/Signature Values . 5 Attribute Content Type Description Encoding Email Text/Plain A fully qualified domain name style 7bit address. Name Text/Plain The name of the mailbox owner. Latin 7bit derived names must be in the Last, First, Middle initial format for ease of parsing. Telephone Text/Plain The international version of the telephone 7bit number. Multiple telephone numbers can be differentiated by use of an RFC 822 comment. Fax Text/Plain The international verison of the 7bit fascimilie number. Address Text/Plain The postal address, each line separated 7bit with a slash "/". Portrait Image/Gif A small bitmap portrait. This may be used Base-64 for visual message waiting identification. SpokenName Audio/ADPCM A short phrase containing the name in the Base-64 voice of the mailbox owner. Capabilities Text/Plain A coma separated list of the MIME content- 7bit types the mailbox owner is willing to accept. Message/RFC822, Message/Partial, Multipart/Mixed, Multipart/Parallel, and Multipart/Alternative are required and need not be listed. Text Text/Plain Free form text for comments, quotes, and 7bit ASCII art. Vaudreuil [Page 4] Internet Draft Application/Signature Expires 4/10/93 Charsets Text/Plain A coma separated prioritized list of the MIME content-types supported by the user agent. Languages Text/Plain A coma separated prioritized list of the languages understood by the mailbox owner. PEM_Cert Text/Plain The PEM certificate of the mailbox owner 7bit as specified in RFC 1421. Distname Text/Plain The X.500 distinguished name of the 7bit mailbox owner. Vaudreuil [Page ] 5 Internet Draft Application/Signature Expires 4/10/93 6.Example Application/Signature Body Part Content-Type: Application/Signature Name: Gregory M. Vaudreuil Email: GVaudre@cnri.reston.va.us Telephone: +1 214 555 2121 (Work) Fax: +1 214 555 3232 Address: 17080 Dallas Parkway/Suite 100/Dallas Texas, 75248 Portrait: R0lGODdhEAAQAIAAAAAAAP///ywAAAAAEAAQAAACK4wNqceR7UCT8FB n2aUc47550nZ5iFZWVqpG2bS+WhbK3frYrYmwOaRYMAoAOw== Capabilities: Text/Plain, Image/GIF, Image/Postscript, Audio/Basic PEM-Cert: MIIBlTCCAScCAWUwDQYJKoZIhvcNAQECBQAwUTELMAkGA1UEBhMCVVMxIDAeBgNV BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDzAN BgNVBAsTBk5PVEFSWTAeFw05MTA5MDQxODM4MTdaFw05MzA5MDMxODM4MTZaMEUx CzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEU MBIGA1UEAxMLVGVzdCBVc2VyIDEwWTAKBgRVCAEBAgICAANLADBIAkEAwHZHl7i+ yJcqDtjJCowzTdBJrdAiLAnSC+CnnjOJELyuQiBgkGrgIh3j8/x0fM+YrsyF1u3F LZPVtzlndhYFJQIDAQABMA0GCSqGSIb3DQEBAgUAA1kACKr0PqphJYw1j+YPtcIq iWlFPuN5jJ79Khfg7ASFxskYkEMjRNZV/HZDZQEhtVaU7Jxfzs2wfX5byMp2X3U/ 5XUXGx7qusDgHQGs7Jk9W8CW1fuSWUgN4w== 7.Security Consideration The information in the application/signature cannot be considered any more authoritative than the "from" line of the RFC 822 header. Authentication of the content is left to mechanisms specified in the Privacy Enhanced Mail extension to RFC 822. 8.Author's Address Gregory M. Vaudreuil The Tigon Corporation 17080 Dallas Parkway Dallas, TX 75248-1905 214-733-2722 Gvaudre@cnri.reston.va.us Vaudreuil [Page 6]