ASID Working Group                                    Alexander Hopmann
INTERNET-DRAFT                                    Microsoft Corporation
draft-hopmann-mimedirxml-00.txt
Expires SIX MONTHS FROM--->                             July 30th, 1997


Conversion of MIMEDIR content into XML

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 inappropriate to use Internet-
  Drafts as reference material or to cite them other than as
  "work in progress."
  
  To view the entire list of current Internet-Drafts, 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).
	 
Abstract

  This document specifies how to translate information which is
  represented in the MIMEDIR format into a representation of the
  identical information using the XML syntax. Using this specification,
  applications which have been designed to understand MIMEDIR formatted
  data should be able to interoperate using XML representations of the
  same schemas.

Table of Contents

  1.  Introduction
  2.  Operation
  3.  Schemas
  4.  Examples
  5.  Security Considerations
  6.  References
  7.  Author's Address

1.  Introduction

  This document specifies how to translate information which is
  represented in the MIMEDIR [MIMEDIR] format into a representation of
  the identical information using the XML [XML] syntax. Using this
  specification, applications which have been designed to understand
  MIMEDIR formatted data should be able to interoperate using XML
  representations of the same schemas.

  This specification covers the translation of MIMEDIR content into XML.
  An XML document can not in the general case be converted into MIMEDIR
  since XML allows more complicated structures to be represented.

2.  Operation

  The MIMEDIR format represents properties using a "type:value"
  approach, with one property appearing on each line. Each of these
  properties can be translated into the XML syntax by representing the
  properties name as an element name, and the value as contents inside
  that element:

  MIMEDIR:
    propertyname: value

  XML:
    <propertyname>value</propertyname>


  The entire set of properties is enclosed inside a container so that
  the result is a well formed XML document. By convention the name of
  the outer element is the name of the MIMEDIR profile:

  <person>
	 <cn>Alex Hopmann</cn>
	 <sn>Hopmann</sn>
	 <email>alexhop@microsoft.com</email>
  </person>


  MIMEDIR supports parameters on properties. These can be represented
  in XML as sub-elements inside the main property:

  MIMEDIR:
    propertyname;paramname=paramvalue: value

  XML:
    <propertyname><paramname>paramvalue</paramname>value</propertyname>


  MIMEDIR also supports using the special BEGIN and END tokens to mark
  the beginning and end of a grouping of values. This can easily be
  represented in XML by grouping all of the items inside the BEGIN and
  END block as sub-elements.

  MIMEDIR:
    propertyname: value
    begin: foo
    another: property
    something: else
    end: foo

  XML:
    <propertyname>value</propertyname>
    <foo>
      <another>property</another>
	  <something>else</something>
    </foo>

  If the MIMEDIR description starts with a BEGIN token, the value of
  that token is used as the element name of the outermost element rather
  than the profile name.



3.  Schemas

  MIMEDIR identifies properties as belonging to a given "profile". This
  is a parallel mechanism to the schema mechanism being defined for XML
  in the W3C RDF Working Group [XML-DATA]. An XML schema is uniquely
  identified by a URL. Any MIMEDIR profile should be represented  in
  XML by the URL composed of the string "http://www.ietf.org/mimedir/"
  followed by the name of the profile. For example, the profile
  "person" is represented in XML by the schema
  "http://www.ietf.org/mimedir/person".


4.  Examples

  Drawing examples from the MIMEDIR specification:


  Content-Type: application/directory;
            charset="iso-8859-1";
            profile="person"
  Content-ID: <id3@host.com>
  Content-Transfer-Encoding: Quoted-Printable

  source:
ldap://cn=3DBjorn%20Jensen,o=3DUniversity%20of%20Michigan,c=3DUS
  name;proto=3Dldap: cn=3DBjorn Jensen, o=3DUniversity of Michigan,
c=3DUS
  cn: Bj=F8rn Jensen
  sn: Jensen
  email: bjorn@umich.edu
  phone: +1 313 747-4454
  certificate;encoding=3Dbase64:
dGhpcyBjb3VsZCBiZSAKbXkgY2VydGlmaWNhdGUK

  Content-Type: text/xml; charset="iso-8859-1"

  <person>
    <rdf::namespace href="http://www.ietf.org/mimedir/person" name="p"/>
    <p::source>
      ldap://cn=3DBjorn%20Jensen,o=3DUniversity%20of%20Michigan,c=3DUS
      </p::source>
    <p::name>cn=3DBjorn Jensen, o=3DUniversity of Michigan, c=3DUS
      <proto>3Dldap</proto></p::name>
    <p::cn>Bj=F8rn Jensen</p::cn>
    <p::sn>Jensen</p::sn>
    <p::email>bjorn@umich.edu</p::email>
    <p::phone>+1 313 747-4454</p::phone>
	<p::certificate>dGhpcyBjb3VsZCBiZSAKbXkgY2VydGlmaWNhdGUK
      <encoding>3Dbase64</encoding></p::certificate>
  </person>

  BEGIN:vCard
  FN:Frank Dawson
  ORG:IBM Corporation;Network Software Division
  ADR;TYPE=WORK,POSTAL,PARCEL:APNA/CC-303/Bldg. 002;
   3039 Cornwallis Rd.;Research Triangle  Park;
   NC;27709;U.S.A.
  TEL;TYPE=VOICE,MSG,WORK: +1 (919) 254-5861
  TEL;TYPE=FAX,WORK: +1-919-543-6822
  EMAIL;TYPE=INTERNET,PREF:fdawson@raleigh.ibm.com
  EMAIL;TYPE=INTERNET:fdawson@earthlink.net
  URL:http://home.earthlink.net/~fdawson
  END:vCard

  <vCard>
    <rdf::namespace href="http://www.ietf.org/mimedir/vCard" name="v"/>
    <v::FN>Frank Dawson</v::FN>
    <v::ORG>IBM Corporation;Network Software Division</v::ORG>
    <v::ADR>
      <TYPE>WORK,POSTAL,PARCEL</v::TYPE>
      APNA/CC-303/Bldg. 002;
      3039 Cornwallis Rd.;Research Triangle  Park;
      NC;27709;U.S.A.</v::ADR>
    <v::TEL><TYPE>VOICE,MSG,WORK</TYPE>+1 (919) 254-5861</v::TEL>
    <v::TEL><TYPE>FAX,WORK</TYPE>+1-919-543-6822</v::TEL>
    <v::EMAIL><TYPE>INTERNET,PREF</TYPE>
      fdawson@raleigh.ibm.com</v::EMAIL>
    <v::EMAIL><TYPE>INTERNET</TYPE>fdawson@earthlink.net</v::EMAIL>
    <v::URL>http://home.earthlink.net/~fdawson</v:URL>
  </vCard>



5.  Security Considerations

  This specification does not introduce any additional security
  considerations beyond those created by the MIMEDIR and XML formats
  themselves. The conversion of MIMEDIR contents into XML does
  not loose any data. Care should be taken however since a digitally
  signed MIMEDIR structure would no longer be signed once it has
  been converted.

6.  References

  [MIME-DIR] Howes, T., Smith, M., "A MIME Content-Type for Directory
  Information", Internet-draft-ietf-asid-mime-direct-05.txt, March,
  1997.

  [XML] Bray, T., Sperberg-McQueen, C. M.,
  "Extensible Markup Language (XML)", WD-xml-961114, November 14, 1996.

  [XML-DATA] Layman, A., Paoli, J., De Rose, S., Thompson, H.,
  "Specification for XML-Data", June 26, 1997.

7.  Author's Address

  Alex Hopmann
  Microsoft Corporation
  One Microsoft Way
  Redmond, WA, 98052 USA
  alexhop@microsoft.com