[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: A new operation for LTAP, please comment
The list function we are discussing was orginally implemented thorugh STATUS function, i.e. if everything is lost by a client, a simple (empty) status operation may return available IDs. Furthermore, identification is done through different mchanisms, like internal (LTA) IDs, external (client) IDs or message imprints... Hence I see no particular reason for list operation. For now...
> -----Original Message-----
> From: owner-ietf-ltans@xxxxxxxxxxxx
> [mailto:owner-ietf-ltans@xxxxxxxxxxxx] On Behalf Of Istvan Zsolt BERTA
> Sent: 21. junij 2007 12:16
> To: ietf-ltans@xxxxxxx
> Subject: Re: A new operation for LTAP, please comment
> In our company we operate a long-term archiving service and
> we see that our clients send their documents into the
> archiving service not only for preserving the long-term
> validity of their signatures. What they want is to forget
> about all the archiving-related tasks after they send their
> documents into the archive.
> Although an archiving system can theoretically function
> without such a 'listing' function, we found this function to
> be essential in a real, practical system.
> I think an archiving system that loses the client's documents
> if the client fails to archive 'something' (e.g. references
> to the archived
> documents) does not solve the right problem: a client needs
> to archive something in order to make use of an archiving service.
> When implementing our service we did not want to create a
> document management system either, so we also planned atomic
> functions only.
> However, we had to add a lot of search and listing related
> functionality to make our system useable.
> Dr. István Zsolt BERTA, PKI expert
> MSc in Tech. Informatics, PhD, MBA, CISA
> e-mail: istvan.berta@xxxxxxxxxxx, tel: (+361) 505 4462
> Microsec Ltd., Záhony u. 7, Budapest, Hungary, H-1031
> Aljosa Jerman Blazic írta:
> >> Hello Peter,
> >> I would envision a call to get the list of references more as a
> >> document management function (which of course must have
> >> access control applied to it) and therefore would prefer it to be
> >> outside the scope of LTAP. The function definitely makes sense, as
> >> well as a query interface to receive certain documents, but this
> >> should not be part of LTAP.
> > I had the same concerns during the discussion with Peter... However
> > this may have implication on the protocol usage. The
> problem here is
> > the role of LTA. As defined up to now, there are only atomic level
> > functions, e.g. insert/get/verify/... Extending this
> functions somehow
> > pushes LTA towards EDMS and then the thing gets complex and
> indeed I
> > would not like to se it blown out of proportions. However, I would
> > definitely look forward for some basic LTA service
> >> I have thought a lot about LTAP lately, and would like to
> also talk
> >> about some thoughts about some kind of restructuring, to
> learn what
> >> you think:
> >> My major goal is that LTAP gets implemented.
> >> I get the feeling, that for many vendors it would be most
> >> for implementation, if there would be an "absolute minimal
> subset" of
> >> LTAP calls (like "get" and "put") together with the more
> >> sophisticated calls - that are definitely very useful - of LTAP.
> > Well, the current state of LTAP does exactly that. There are fields
> > that are mandatory and fields that are open. What we need is only
> > careful examination of field types/requirements.
> >> My concerns is that a one-piece complicated complete
> protocol might
> >> raise the bar too high and reduce the chance of implementation. To
> >> somehow split LTAP (e.g. inside the document or even in two
> >> documents) into one "absolute minimal" set and one
> "general use" set
> >> might help here, to get implementers to at first take the first
> >> hurdle quite easily and when they realize this is good and
> easy they
> >> will probably be more motivated to implement the whole thing.
> > If the minimal set is defined (i.e. required fields) then
> > extensions/upgrades are always optional. Furthermore, we
> might follow
> > the metainformation approach which has changed through the LTAP
> > versions and it is now open to be filled in with arbitrary metadata
> > types, even data objects. A very good point are guidelines
> for minimal usage set...
> > BR
> > A.
> >>> -----Original Message-----
> >>> From: owner-ietf-ltans@xxxxxxxxxxxx
> >>> [mailto:owner-ietf-ltans@xxxxxxxxxxxx]
> >>> On Behalf Of Peter Sylvester
> >>> Sent: Tuesday, June 19, 2007 1:28 PM
> >>> To: ietf-ltans@xxxxxxx
> >>> Subject: A new operation for LTAP, please comment
> >>> Hello,
> >>> I would like to ask the group about comments concerning a new
> >>> operation for LTAP before I try to write it down into the draft.
> >>> During a discussion with a company implementing an
> >> 'electronic safe',
> >>> and to see what functionality a protocol should provide, we
> >> stumbled
> >>> over the following.
> >>> It happens that a client wants to get all its data back
> but has not
> >>> kept any knowledge about the references.
> >>> This can occur in at least two scenarios, one is a real end user
> >>> asking to a service provider, and it seems reasonable for
> a service
> >>> provider to offer such a service.
> >>> One can argue that the service provider should maintain
> somewhere a
> >>> registry of all the stored data and provide a particular
> >>> But then, this registry must be operated in a way which provides
> >>> equivalent security as the archive itself. Or, if you loose the
> >>> registry/directory there is no way to get data out the
> >> archive unless
> >>> you have strict sequential naming conventions or a particular
> >>> operation.
> >>> What we came up is an operation DIRLIST (name to be
> discussed which
> >>> allows to ask an archive to return a list of data
> >> references that it
> >>> possesses.
> >>> Assuming that the archive has some internal order, the operation
> >>> operates in a 'next' mode, i.e. a parameter indicated that
> >> references
> >>> 'behind' a particular one should be returned.
> >>> We also think that this operation can have some other filters, at
> >>> least a 'after date x' and also one selector of an owner of data.
> >>> A client would then receive all the references and can get
> >> them back
> >>> individually.
> >>> This operation is also useful when a client sends many
> >> requests to the
> >>> server in order to determine the final outcome of all of
> >> them, instead
> >>> of polling and repeating each operation, the client can
> >> send a request
> >>> to list all finished archive operations, and then ask the
> >> final result
> >>> only once.
> >>> We are not sure whether such an operation should be part
> of LTAP or
> >>> definitely be outside.
> >>> Please don't hesitate to make comments.
> >>> Thanks in advance
> >>> Peter