X.500 as document repository

lazear@gateway.mitre.org Mon, 24 February 1992 16:05 UTC

Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa04499; 24 Feb 92 11:05 EST
Received: from bells.cs.ucl.ac.uk by NRI.NRI.Reston.VA.US id aa04494; 24 Feb 92 11:05 EST
Received: from gateway.mitre.org by bells.cs.ucl.ac.uk with Internet SMTP id <g.25533-0@bells.cs.ucl.ac.uk>; Mon, 24 Feb 1992 15:57:46 +0000
Return-Path: <lazear@gateway.mitre.org>
Received: by gateway.mitre.org (5.61/SMI-2.2) id AA22008; Mon, 24 Feb 92 10:43:50 -0500
Full-Name: Walt Lazear
Message-Id: <9202241543.AA22008@gateway.mitre.org>
To: osi-ds@cs.ucl.ac.uk
Cc: lazear@gateway.mitre.org, mcguthry@gateway.mitre.org
Subject: X.500 as document repository
Date: Mon, 24 Feb 1992 10:43:42 -0500
From: lazear@gateway.mitre.org

Well, X.500 has gotten such good press that we've got users
who want to use it for everything, including holding documents
for browsing and retrieval.  The problem is, although it sounds
wrong, I don't have any technical reasons for arguing them out
of their notion.  Are there restrictions on attribute lengths
(2k octets?), session PDUs (10k octets), total size of an 
entry (object size), or something that makes keeping a section
of a document as an object (in a TEXT_BODY type of attribute)
impossible.  Without such technical basis, it's just a religious
argument as to how large an entry should be.  I'd appreciate
solid technical reasons (beyond quipu's usage of RAM and
other early implementation problems).  Thanks.
	Walt