the (revised) ltap protocol
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 PresentationTRANSCRIPT
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])