Hereafter are a few comments (before leaving on=20 holidays).

Besides the comments made below, there are more than 50= typo=20 errors or incorrect grammatical constructions.

The document states= on=20 page 6:

=   =20 "An LTA is a part of a general archive service that
   provides evidence used to= =20 demonstrate the existence of an archived
   data object at a given ti= me and=20 the integrity of the archived data
   object since that=20 time".

However, nothing in the protocols that are described allow to ac= hieve=20 this property.

The document should consider the existence of a jou= rnal=20 for keeping track of all operations
that are performed using LTAP. In= other=20 words, an "archive journal" should be considered
and actions like "re= ad",=20 "search" and "delete" allowed on it.

An archive service cannot wor= k=20 without any data storage capabilities as mentioned at the top of page 7=20 :

"= Alternatively, it may simply act as an= evidence=20 or information service without data storage capabilities
(it relies u= pon=20 other services for storage of the archived data).").

It may archive imprints of data rather than data itself= , and=20 thus needs to have storage capabilities.

On page 7, the document=20 states:

= "They are atomic elements of an LTA ser= vice=20 consisting of three logical parts:

   o Archive data (including metadat= a or=20 other related data) entering
      the LTA= using=20 the interaction protocol,

= =20 o Archive process-r= elated=20 meta or binding information, and

   o Evidence=20 information"

However, later on, the document does not consider "a= rchive process-related meta or binding=20 information"
or "Evidence information".

The=20 data to be considered instead should be :

- Archive data associated with=20 metadata,
- Archive dat= a=20 references with metadata, and
= -=20 Metadata alone.

If some evidence is provided, it should be conside= red as=20 a special type of metadata.

The document should make the differenc= e=20 between metadata that is opaque to LTAP and metadata
which needs to b= e=20 interpreted by LTAP, for example date of storage, end of retention, etc=20 ..

The document should consider the existence of "archive profiles= ". The=20 document currently considers
a "= service policy" but the concept behind= this=20 wording is not sufficiently explained.
It seems close (page 14) but is= =20 different:

"A clien= t MAY=20 indicate one or more service policy identifiers associated to a service t= ype=20
in order to select different features to be performed by the=20 LTA".

"Archive policy" should be able to be defined so that it is=20 possible to make a deposit according
to an archive policy. The archiv= e=20 policy should then state which metadata are mandatory
when making a d= eposit=20 and which are automatically computed and added to the data when making a=20 deposit.

Archive policies may be created and deleted. These operat= ions=20 performed on the archive policy objects
(e.g. create, read, modify, l= ist,=20 suppress) should be logged in the journal.

When=20 archiving some data, it is fundamental to know when the data should be de= leted.=20 It should be possible
to ask to the archive system to identify which=20 archives should be deleted. With the current operations, this is=20 impossible.

On page 7, the document states:

<= SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-fareast-font-fa= mily: 'MS Mincho'; mso-ansi-language: EN-US">"The=20 LTA performs perpetual maintenance of archive objects".
=
First of all, different concepts are be= hind this=20 wording as indicated on top of page 8: "e.g. by proof-reading,
copyin= g to=20 new material, or performing time stamp renewal)". The VERIFY=20 operation as defined in section 5.4
is too vague to allow reachi= ng=20 these different goals.

Note that the word "operation" is used on = page 9=20 and the wording "service type" is used on page 31.
The word "operatio= n"=20 should be used everywhere.

The VERIFY operation is not always nece= ssary=20 since some systems automatically take care of the move

of data=20 from one media to another. Some systems are also taking care automaticall= y of=20 the duplication
of data on different sites.

This topic is rel= ated to=20 another issue.

On page 19, the document=20 states:

=   =20 "Servers MUST create a server-wide unique identifier for each=20 data
   object mana= ged by=20 the LTA. The identifier MU= ST be=20 global during the
  =20 intended lifetime of an object".

On page=20 30, the document states:

=   =20 "It MUST be ensured that in an actual context of a client/server   network names are scalabl= e and=20 global both in terms of actual
= ; =20 community space and time to live of the treated data=20 objects".

If the=20 reference of the data is server-specific (rather than service-specific) a= nd the=20 server is changed,
then the reference would change and the evidence w= ill no=20 more be valid.

Let us suppose that media migration is not automati= c and=20 that no automatic backup of the storage is supported.
The document sh= ould=20 provide some guidance on the use of the protocol. Currently it seems that= at=20 least
two operations would need to be done for the deposit. To increa= se the=20 performance, allowing to address
two servers, or better to archive se= rvices=20 at the same time, would be better.

On page 9, one operation is mi= ssing.=20 There should be a MODIFY operation to modify metadata.
Some metadata = may not=20 be modifiable, e.g. the time of an initial deposit. So the archive system= s=20
should be able to recognize which metadata is or is not=20 modifiable.

There should be a SEARCH operation, which is more expl= icit=20 than LISTIDS mentioned on the top of page 10.

The EXPORT operation= is=20 mentioned. This naming may be understood as "read and delete". It would b= e=20 advantageous
to call it READ. Read would apply to "data or imprint +=20 metadata" or to metadata only.

In order to increase the performan= ce=20 there should be a COPY operation. This means that the data would not flow= =20
through the client, but directly from one LTAS to another LTAS.
On=20 page 13, there is an odd sentence:

"Some=20 metadata MAY remain available even after deleting the object".
=

= If data is deleted, the metadata associ= ated with=20 the object is also deleted. However the recordings
of the various ope= rations=20 performed on the data are in the journal and are not deleted.=20

On page 19, the text=20 states:

= "The data=20 to be archived are arbitrary binary data and, minimally, an associated ty= pe that=20 MUST be either
available as part of a server configuration policy or=20 explicitly indicated by the client".

On page 27, about ArchiveData the text=20 states:

   "Thi= s type is=20 used to describe data together with optional metadata
   and reference information= . At least one of the optional=20 elements
   MUST be= provided=20 in order to either provide or identify the data".

Data to be archi= ved=20 shall always be associated with metadata. Some metadata types should be=20 mandatory,
in particular the one defining the type of metadata that i= s=20 archived (e.g. using a MIME type). No metadata
should be part of a =93= server=20 configuration policy=94. A said earlier, metadata may be explicitly provi= ded=20
by the client or be derived from an archiving policy.

On page= 20,=20 the text states:

  =20 Meta=20 information is associated with archive data and can be included
   implicitly, i.e. be a par= t of a=20 document, or explicitly, i.e. as a
   document attachment

and also:

  =20 Meta=20 information may occur in various forms and may be an integral
   part of archive data, e.g= .=20 security attributes in form of digital
   signatures.

Metadata should not be confused with security attributes of the = data.=20 Metadata is always associated with the data
and is NOT included in th= e data=20 itself. Signatures are part of the data and can be considered in some cas= es=20
as attributes of the data. However, a metadata may indicate that one = or more=20 signatures are present in the data.

On page 20, the text=20 states:

   "An LTA= does not=20 interprete metadata that may
&= nbsp;=20 express logical relations among documents in the archive that=20 is
   submitted selectively usi= ng=20 several requests". =

The text should rather say that a LTA MUST understand some types= of=20 metadata. For example, a metadata
may include a =93communication dela= y=94, i.e.=20 a time period starting from a date and time included in another metadata=20
which specifies the time after which the public may read the data. Th= e LTA=20 shall be able to control the release
of information to the=20 public.

The text states on page 20:

   To process such informati= on, the=20 LTA MUST retrieve
   enough=20 information on the type and purpose of information enclosed,
   which may simply be defin= ed with=20 the use of an apropriate archive
&nb= sp; =20 service policy, e.g. archive service for digitally signed=20 documents.

An =93archive service policy=94 is left undefined. Ther= e are not=20 enough explanations. The example is not sufficient
to understand whet= her=20 this concept is valid or not.

The text states on page 21:

<= SPAN=20 style=3D"mso-spacerun: yes">   In some scenarios, a spec= ific set=20 of meta information must be
&n= bsp;=20 preserved together with archive data, e.g. information=20 identifying
   the = document=20 owner/author, location or time.

This highlights the fact that som= e=20 metadata must be understood by the LTA and thus need to be=20 standardized.

The text states on page 21:

   Evidence information demo= nstrates=20 the integrity and existence of
= ; =20 archived data. The = LTA=20 accepts data for the single purpose of
   generating or obtaining e= vidence=20 information for data submitted by a
   client. The evidence information struct= ure is=20 defined in [RFC4998].

It is unclear how ERS is being used. An ERS = record=20 should be a metadata.

The text states on page 21:

   In the case where LTA acc= epts data=20 only for the purpose of generating
   evidence information (wit= hout=20 storage capabilites to avoid, e.g.
   confidentiality issues), = the=20 archivation process is limited in time.

It is not explained why th= e=20 =93archivation=20 process is limited in time =BB.

The=20 text states on page 21:

   When an LTA performs a re= newal of=20 evidence, =85 .

It is not=20 explained what this means in terms of operations and metadata to=20 handle.

The text states on page 21:

   =85 collisions may exist = now or in=20 the future.

Hash=20 algorithms shall be chosen so that collisions do not exist =93now=94. Col= lisions=20 might exist in the future.
In this case, the draft should give guidan= ce on=20 how to handle them in the security considerations section.

The tex= t=20 states on page 23:

   The Metadata type is a li= st of=20 open types
What is an =93open type=94 ? As said ea= rlier, some=20 metadata MUST be understood by the LTA.
In order to be able to perfor= m=20 search operations using metadata, the LTAS MUST understand
the syntax= of the=20 metadata. Then it can apply matching rules. The matching rules may also b= e part=20
of the metadata.

The text states on page 23:

    specification, e.g., the = Dublin=20 Core.

Some metadata from the Dublin Core should be m= ade=20 mandatory. One particular type of metadata
should be standardized: to= allow=20 identifying an =93archive policy=94.

The text states on page 23:
&nb= sp; =20 Since some global metadata are always associated to data objects=20 and
   necessary fo= r the LTA=20 service, an LTA MUST provide a complete
   description of all metada= ta it=20 associates with an archived data
   object for operational=20 purposes.

The=20 text recognizes that some metadata is necessary for the LTA services. Tho= se that=20 are absolutely
necessary should be described.

The text states= on=20 page 23:

   A client is not required = to=20 understand the semantics of metadata.

How could a cl= ient=20 make a search, if it does not understand the semantics of the metadata=20 ?

On page 26, RawData should not be a choice but rather be a pair=20 composed of an OCTET STRING
and Meta Data indicating the type of the = OCTET=20 STRING.

The text states on page 27:

   For=20 preservation purposes, an LTA must have information on=20 archive
   data type (e.g., signed o= r=20 unsigned).

When preservation is supported, this type of metadata is necessa= ry for=20 the LTA services. It should be standardized.

The text states on pa= ge=20 33:

    =20 servicePolicyInfo PolicyInformation,

PolicyInformation is i= mported=20 from PKIX1Implicit-2009. However the semantics of this item has nothing t= o do=20
with this document since it is related to a Certification Policy rath= er than=20 an Archiving Policy. A reference to
an archiving Policy should be use= d=20 instead and should be optional.

The text states on page 33:
     serial       &nb= sp;   =20 SerialNumber OPTIONAL,
     nonce       &nb= sp;    =20 Nonce OPTIONAL,

There are no explanations allowing understa= nding=20 when a SerialNumber is needed/useful in addition to a Nonce.

The t= ext=20 states on page 37:

4.3. =20 OperationResponse

(=85)

   It references the initial= request=20 as well as the
   d= ata that=20 had been submitted.

  = =20 OperationResponse ::=3D SEQUENCE {
     information=20 RequestInformation,
   status     =20 StatusNotice,
  &nb= sp; =20 data       =20 ArchiveData
  =20 }

The ArchiveData should be made OPTIONAL, otherwise= 10=20 Mbytes of data might be returned with each response.

The text stat= es on=20 page 39:

    information item includin= g service=20 policy interpreting service
   characteristics and servi= ce=20 configuration parameters.

The=20 client should build a request including an archive policy and metadata in= =20 accordance with the archive policy.
There should be no =93service pol= icy=20 interpreting service characteristics =BB, nor =AB service confi= guration=20 parameters =BB.

The text states on page 40 about the DELETE=20 operation:

   After a successful operation, the the server does not
   maintain any status infor= mation=20 about the object.

This is incorrect. A log of what happened= should=20 be maintained.

The text states on page 40 about the DELETE=20 operation:

   o The metadata MAY be set to repl= ace the=20 existing metadata of the
     =20 object.

This is quite odd. When the object is= =20 deleted, the metadata is also deleted.

The text states on page 40 = about=20 the DELETE operation:

   If the client retries a d= elete=20 operation, it may happen that the LTA
   has already deleted all t= races of=20 the operation.

This is incorrect. If the client retries a delete operation, it = may=20 happen that the LTA has already deleted the object.
However, it shall= have a=20 trace of the operation.

The text states on page 41 about the VERI= FY=20 operation:

   This operation allows a c= lient to=20 verify the authenticity of
   information stored in the= =20 archive.

In=20 practice, the verify operation would be used for different purposes. The = primary=20 one is for checking the quality of the media.
In such a case, transie= nt=20 information may be returned and that information is not necessarily added= to the=20 metadata.
Thus the last sentence of this section is=20 wrong:

   "The LTA=20 returns updated metadata of the object".

If there is a wish to mai= ntain=20 the validity of the data by renewing = time-stamp tokens, then a different ver= b should be=20 used,
like =93MAINTAIN=94. The details of the parameters should then = be=20 given.

The text=20 states on page 41 about the STATUS operation:
=
   A client can request the = status of=20 a data object.
=
It is unclear what the status of the data object is. What is the= =20 difference between a status and metadata ?
In some places within the=20 document there is also confusion between the status of an operation and t= he=20 status

of a data=20 object. The current text is no sufficient to be able to correctly underst= and.=20 Normally a subset of
the metadata should be returned.

The text= on=20 page 41 about the LISTIDS operation is missing to include data to be used= with=20 matching rules
and to be compared with metadata. Simply providing a r= ange of=20 dates as indicated on page 42 is insufficient.

On page 43, the tex= t is=20 speaking of =93restricted=20 BER encoding =93. What is it ?

On page 44, th= e text=20 states:

=93The owner of the S/MIME arc doesn't like to register them in = the S/MIME=20 arc =BB.

Such a sentence should= be=20 deleted.

On page 48, the text states:

   The vali= dity of data=20 should be checked by periodic execution of
   VERIFY operations intende= d to=20 ensure data with demonstratable
&nbs= p; =20 integrity is available throughout the lifetime of an archived=20 data
   object.

The=20 sentence should be changed since some systems do this automatically witho= ut the=20 need of such an operation.

On page 48, the text=20 states:

   Depending on the lifetime= and the=20 quality of data, =85

Which=20 concept is behind the =AB quality of data =BB ?

On = page 48,=20 the text states:

  &nb= sp; =20 Nevertheless, in case th= e private=20 key does become
  =20 compromised, an audit trail of all the response generated by the   service SHOULD be kept as= a means=20 to help discriminate between
   genuine and false respons= es.

In=20 any case, an audit trail SHALL be kept.

End of=20 comments

Denis

"Some=20 metadata MAY remain available even after deleting the object".
=

=93The owner of the S/MIME arc doesn't like to register them in = the S/MIME=20 arc =BB.