The (revised) LTAP Protocol
12
The (revised) LTAP Protocol LTA, LTAP and AO Aleksej Jerman Blazic
description
The (revised) LTAP Protocol. LTA, LTAP and AO Aleksej Jerman Blazic. Preservation. Archiving is a process (!) May be successor of terminated process (e.g. workflow) or simply demonstrator of events (e.g. within a workflow) Has a starting point and termination point Perpetual maintenance - PowerPoint PPT Presentation
Transcript of The (revised) LTAP Protocol
The (revised) LTAP Protocol
LTA, LTAP and AO
Aleksej Jerman Blazic
Preservation
• Archiving is a process (!)– May be successor of terminated process (e.g.
workflow) or simply demonstrator of events (e.g. within a workflow)
– Has a starting point and termination point– Perpetual maintenance
• Availability – access• Readability – interpretation• Authenticity – existence• Stability – integrity
The global picture
Client
Client
TAS
Usermanagement
Data validation managemnt
Data management
ERSmanagement
Data storage
ERS storage
LTAPLTAP
SVCP-ERS/DVCS
Time stapimg
TSP/SOAP
Validation data
Certificate Authority
User data
Data Interpretation management
Interpretation dataLDAP
WebDav
Archive Object
Document
Document meta-data(category, key-words, size, etc.)
Digital signature (optional)
Complementary data(digital certificate, certificate chain, certificate revocation list, etc.)
Archive meta-data(document owner, origin of document, archival time, etc.)
Evidence record(document fingerprint, hash-links, timestamps, etc.)
Do
cum
ent'
sco
nse
rvat
ion
attr
ibu
tes
Long term archive protocol
• Technical vs. formal interaction
• Levels – to be clarified– LTA – a general service– LTA – an ERS service
• A position of LTA in data lifecycles• Redundancy and data moving – single repository
with bindings– Workflow– Archive– Etc.
The general picture
• Asynchronous model– One request– Two category response
• ACK/NACK• ACK/NACK + Process outcome
• Use of lower transport layers including authentication/security means
• Messages– Request information– Payload– Security assertions
Asynchronous model
LTAP Request (service request)
LTAP Response (request acknowledge)
LTAP Response (service response)
TAS ServiceTAS Client
Authorize request
Accept/refuse request
Send requestACK/NACK
Process request
Send service response with
parameters
Generate request
Accept ACK/NACK response
Accept service response
Definitions
• Clarification done– Structure of objects (still needs some work on
groups)• Data• Metadata• Binding info.
– Lifecycle of objects defined• Inside one transaction• As a result of export information
Services and configuration
• Principles of configurations and service parameters– client selects a service according a contract/archive
policy– Service/archive policy
• Global – general operation characteristics (e.g. redundancy, ERS type, etc.)
• Specific – archive process characteristics (e.g. grouping, retention, etc.)
– service has all necessary parameters– service management
• out of scope or• some configuration options available
Services and configuration
• LTA service types– Archive– Status– Verify– Export/Modify - TBC– Delete
• Issue– Configuration option – change process parameters,
e.g. retention• Change parameters• Change archive policy
To be done
• Details of specifications in xml and asn1• Integration with ERS???• Lower layer bindings – when lower layer bindings are removed, the
LTAP should work• Service configuration• Service types• Data group clarification (probably removal)• Splits processing (?)
– Done at the requestor level, i.e. all preparations done before and a metadata object added to each portion. Portions are handled by a front end – somewhat comparable to an entity that encrypts the data before archiving them
– Done by “splitting” device?– Splitting done instead time stamping? How does that affect the ERS?– Other?
Questions
P. Sylvester ([email protected])
C. Wallace ([email protected])
A. Jerman Blazic ([email protected])
