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
- X.500 as document repository lazear
- Re: X.500 as document repository Sylvain Langlois
- Re: X.500 as document repository yeongw
- Re: X.500 as document repository Sylvain Langlois
- Re: X.500 as document repository Thomas Johannsen
- Re: X.500 as document repository Steve Hardcastle-Kille