One document matched: draft-ietf-ids-iwps-schema-spec-02.txt

Differences from draft-ietf-ids-iwps-schema-spec-01.txt

Integrated Directory Services Working Group


                                                      T. Genovese
                                                        Microsoft
                                                 Barbara Jennings
                                       Sandia National Laboratory

                                                                                                           
                                                  11 November 1996
                                              Expires: 10 May 1997


      A Common Schema for the Internet White Pages Service
      File Name: draft-ietf-ids-iwps-schema-spec-02.txt

Status of this Memo

This document is an Internet-Draft.  Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), it 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 learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au  (Pacific Rim).


Overview

The work is the result of the IETF Integrated Directory Services (IDS) 
Working Group which proposes to establish a specification for a simple 
Internet white pages service.  To facilitate this effort it would be 
helpful to have a common schema used by the various white page servers.  
This document is designed to specify the basic set of attributes to be 
used for a white page entry for an individual.  This schema does not 
describe how to represent other objects in the White page service.  
It does describe how new objects can be defined and registered.  This 
schema is independent of implementations of the White Page service.


1.0 Introduction

The Internet community has stated that there is a need for the 
development and deployment of a White Page service.  This service 
would be used to locate information about people in the Internet[PA94].  
To facilitate interoperability and a common user expectation the
Internet White Pages Service (IWPS) needs to have a common set of 
information about each person.

This Document will focus only on common information modeling issues to 
which all IWPS providers must conform.  To insure a consistent user 
experience of this service we need to define a common user object.  This 
will allow a user to go between different implementations of the service 
and have a consistent expectation as to what information can be found about 
people on the Internet.  Developers of this service need to have an 
unambiguous method of representing the Information objects managed by 
the service.  This will help facilitate interoperability and data management.

2.0 Scope

This document will establish the set of attributes that specify the common
user information object for the IWPS.  It will not attempt to be an 
exhaustive specification of all objects that will be stored in the IWPS. 
The process used by this document to define the user object will be used to
define all other information objects used in the IWPS.

This document will not specify rules with respect to information privacy.
Each country has its own set of laws and practices.  Work covering
this area was done by North American Directory Forum (NADF) [NADF92].  In 
this are recommendations for registrants rights for both the USA and Canada.

3.0 IWPS Schema Considerations

The information object description requirements for the IWPS 
consists of the following:

              1. Syntax for definition/representation of Information
                 Object Templates.
              2. Registration procedures for information object
                 Templates, etc.
              3. Database structure or schema.

Items 1 and 2 will be covered in this Document.  Database structure
can potentially restrict implementations (i.e. X.500 schema based verses 
DNS schema based) and will not be defined in this document.  This area is 
a separate Research topic and will be covered in its own document.

3.1 Syntax for Definition/Representation of Information objects

A clear, precise and consistent method must be used when information
object Templates and their associated attributes are discussed within 
the context of IWPS.  There are two possible methods to do this. i.e.

              1.  BNF
              2.  ASN.1

The Working Group has recommended the use of ASN.1.  It provides us with 
a set of defined attributes and encoding syntax's.  Also, it is well 
documented and widely available. 

The use of ASN.1 to specify the attributes of the information objects does 
not imply the use of Basic Encoding Rules (BER) for any IWPS servers 
protocols.  The use of Object inheritance is not used or specified by 
this document.  The IWP person object specifies a set of recommended 
attributes that a White Page Service chould include.  It suggests storage 
sizes, but does not recommend storage types. How an implementation stores 
the user attributes is a local issue.  The Syntax listed with the attributes 
are provided so the developers of user interfaces (UIs) may have a consistent 
expectation.  This document does not specify a Directory access protocol 
(i.e. whoi++, LDAP, DAP, etc.) or how the UI is to display these attributes.

Attributes that contain textual information that must be split over multiple
lines (i.e. Postal address) will use the procedure defined in RFC 822 in 
section 3.1.1 on "folding" long header lines [RFC-822].

For International localization it is recommended that attributes (except 
email addresses) used to identify people must follow the 
DirectoryString syntax defined by LDAP [LDAP-A].

3.2 Publishing of IWPS Information object Templates.

The Working Group recommends that all information object Templates
used for the IWPS be published as an RFC at the mimimum. To facilitate 
distribution of IWPS information object Templates they should be made 
available on the Internet information server (i.e. InterNIC).

Individual organizations may define information object Templates that
are only local in scope.  This may be needed to meet local
organizational needs.  All information that the organization wishes 
to be part of the IWPS must use an IWPS published information object 
Template.

4.0 Data Privacy

Each country and within the US, each state, has legislation defining
information privacy.  The suggested attributes in Appendix may be
considered private and a directory administrator is stongly advised
to verify the privacy legislation for his domain.

As suggested in RFC 1355 (4) each Directory provider should provide a 
clear statement of the purpose of the directory, the information that 
will be contained in it, and a privacy policy associated with the 
information that is stored within the directory. This policy should
include restrictions for data dissimenation.

This policy is strongly recommended for the US and Canada and required 
for many counties in the European Community for data sharing.

5.0 Data Integrity

Data Integrity was first addressed in RFC1107 [KS89].  Which states, 
that if the information is out of date it is useless and the service 
will not be used.  Therefore, a clear requirement is that any production 
IWPS provider must insure that all data is reasonably correct and current.

To facilitate the user in determining the quality of the data that
has been retrieved it is recommended that the optional Ancillary
attributes of the IWPS person Template be supported.  This would require 
that the IWPS User Agent to be able to retrieve and display this 
information.  This may be done as a separate operation from the fetch 
of the information object. The Ancillary Attributes are defined in 
Appendix A.  It is further recommended that any new information object 
Template include as a minimum the Ancillary attributes as an optional 
set of attributes.  It would then be left to the IWPS servers to 
optionally support the storage and retrieval of this data.

The Ancillary attributes have been designed to provide the following 
information about the information object with which it is associated:

              1.  The date and time of the last modification.

              2.  Who performed the last modification.

              3.  Who owns or is responsible for the data stored
                  in the information object.

              4.  What is the official source of the data.


6.0 References

   [LDAP-A] Wahl, M., Coulbeck, A., Howes, T., Kille, S., "Lightweight
   Directory Access Protocol: Standard and Pilot Attribute Definitions",
   Draft-ietf-asid-ldapv3-attributes-01.txt, June, 1996

   [KS89]  Sollins, K., "A Plan for Internet Directory Services", RFC
   1107, Laboratory for Computer Science, MIT, July 1989.

   [NADF92] North American Directory Forum, "User Bill of Rights for
    entries and listings in the Public Directory', RFC 1295,
    North American Directory Forum, January 1992.

   [PA94]  Postel, J., Anderson, C., "WHITE PAGES MEETING REPORT", RFC
   1588, University of Southern California, February 1994.

   [RFC-822] Crocker, D., "Standard for the Format of  ARPA  Internet  
   Text Messages", STD 11, RFC 822, August 1982.


8.0 Authors Address

   Tony Genovese
   The Microsoft Corporation
   One Microsoft way
   Redmond, Washington 98007
   USA

   Phone: (206) 703-0852
   EMail: TonyG@Microsoft.com

   Barbara Jennings
   Sandia National Laboratories
   Albuquerque, New Mexico 87106
   USA

   Phone:  (505) 845-8554
   EMail:  jennings@sandia.gov



Appendix A Information Object Template Definitions

This appendix contains the IWPS Person Information Object Template 
and its associated attributes.  The Person Object is a simple list 
of attributes, no structure or object inheritance is implied.  All 
size recommendations are in bytes.  

The following size recommendations should be used as an indication 
of the largest size of a particular attribute that an IWPS client 
application would see in practice.  In particular instances, actual 
user attributes may be larger or smaller than these recommendations,
and applications should be written to accept any size attribute returned
from a server.

-- SPECIAL CONSIDERATIONS --

Phone number:  should be the full international form 
               i.t. +1 206 703 0852.  The field may contain
               additional information following the phone
               number.  For example:

                        +1 800 sky page #123456
                        +1 882 8080 ext 30852

Email address: Is multivalued and uses the otherMailbox syntax
               to identify the different email addresses.

Certificate:   Is multivalued.

Common Name:   Is multivalued. 

-- THE INFORMATION OBJECT TEMPLATE FOR THE IWPS PERSON --

--General Attributes --

      Field Name         Size          Syntax

      Email               360          otherMailbox
      Cert               4000          Certificate
      Home Page           128          caseExactString
      Common Name          64          DirectoryString
      Given Name           48          DirectoryString
      Surname              48          DirectoryString
      Organization         64          DirectoryString
      Locality             20          DirectoryString
      Country              02          DirectoryString (ISO3166)
      Language Spoken      02          DirectoryString (ISO 639)

--Personal Attributes

      Telephone Number     30          PrintableString
      Fax                  30          PrintableString
      Mobile Phone         30          PrintableString
      Pager Number         30          PrintableString
      Postal Address       255         PostalAddress
      Bio                  255         DirectoryString
  
--Organizational Attributes

      Title                 64         DirectoryString
      Office Phone          30         PrintableString
      Office Fax            30         PrintableString
      Office Mobile Ph      30         PrintableString
      Office Pager          30         PrintableString
      Postal Address       255         PostalAddress
      
--Security
 
      Password              64         Password

--Ancillary

      Creation time         24         GeneralizedTime
      Last Modified         24         GeneralizedTime 
      Creator Name         255         DN
      Modifier Name        255         DN